Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

Script Library Licenses

 [1/5] from: SunandaDH:aol at: 16-Aug-2004 6:24

I'm looking for some assistance in clarifying and simplifying the license options for scripts contributed to the Script Library. Since the new Library was launched it has always been possible to add a license: keyword to scripts to specify conditions under which they can be used, redistributed or modified. We've just added a page recently to explain the license options: (As you can see, the majority of scripts so far do not say what their license conditions are). To complete this page, I'm asking for some advice and feedback: -- what licenses should we allow? -- which of the existing ones should we drop (many of them have a zero in the scripts column, meaning no existing script applies that license? -- can anyone help with a simple one-line summary for the various licenses so we can easily distinguish between, say GLP and LGPL)? And any other help would also be greatly appreciated.....and I know other people have a much stronger interest in getting these details right than I do. Thanks. Sunanda

 [2/5] from: antonr:lexicon at: 17-Aug-2004 0:54

Cool! -Anton.

 [3/5] from: SunandaDH:aol at: 17-Aug-2004 2:17

> Cool!
Thanks. Cool but skeletal. So if anyone can help with expanding the license descriptions and other details, please let me know. As a reminder, the web page is here: And the template used to produce it is here: Thanks again, Sunanda

 [4/5] from: brian:hawley at: 18-Aug-2004 14:29

At 02:17 AM 8/17/04 -0400, Sunanda wrote:
>So if anyone can help with expanding the license descriptions and other >details, please let me know.
<<quoted lines omitted: 4>>
>Thanks again, >Sunanda
I think you should include a definition of concepts used in the licenses that may not have an obvious analog in the REBOL world. Here's my first stab at it - comment as you will. BINARY (in the application or library sense): Any encapped, compressed, encrypted or obfuscated script that was written in clear code and then translated. SOURCE: The REBOL or dialect source of a script; the code that you write instead of generate. LINKING, STATIC: Combining REBOL script or data into one script, perhaps through a preprocessor, i.e. Prebol, the Rugby packager, SLIM, etc. LINKING, DYNAMIC: LOADing a script, or DOing a script that makes changes to the REBOL environment that persist after the script is done, such as setting a word or defining a function. The script must exist as a separate file at run time, or the linking is static. LOAD/LIBRARY is dynamic. It may be that the script is strictly data-only, and thus not linked, but be sure to clearly define what is data and what is code. Keep in mind that dialect code is data to the dialect processor, and thus not linked to the processor, but dialect code can be linked to other dialect code. It can be a little confusing, so remember your philosophy classes and wing it. CALLING EXTERNAL PROGRAM/SCRIPT: This encompases use of the CALL, LAUNCH and BROWSE functions, and code that behaves in a similar way, such as async-call. This can also include DO of a script that doesn't set any words visible outside of the script, or return any significant values (maybe just unset!) - a script just done for effect, like a LAUNCH in the same process. DISTRIBUTION: Script posted to a rebsite, web site, script library, yes. Script embedded in a web page for execution by the REBOL plugin, yes. Execution on your server as a service, no. Local utilities, no. That's my best take on the concepts. I am not a lawyer, but I have been programming for maybe 20 years, REBOL for more than 5, and I have read a lot of licenses. As far as I can tell, and assuming that you want to keep your source proprietary (which I don't), this means that the PD, BSD-like and such licenses are compatible with encapping. All code can be CALLed as defined above, even GPL code, but be careful of patent issues unless the code is under the CPL or some such. LGPL code can be dynamically linked as well, even by encapped binaries, as long as the code is separate as mentioned above (perhaps as plugins). Any comments? Brian Hawley

 [5/5] from: brian:hawley at: 18-Aug-2004 15:56

Whoops, I forgot... At 02:29 PM 8/18/04 -0500, I wrote:
>At 02:17 AM 8/17/04 -0400, Sunanda wrote: > >So if anyone can help with expanding the license descriptions and other > >details, please let me know. > >I think you should include a definition of concepts used in the >licenses that may not have an obvious analog in the REBOL world. >Here's my first stab at it - comment as you will.
.... Some clarifications relative to other REBOL circumstances: Rugby: Loading the client into your script is linking the client, integrating your script with the Rugby server is linking with the server, but using a Rugby service from a Rugby client is calling, not linking - separate address spaces (processes, whatever). This means that you can call a GPL'ed server from a proprietary client and vice versa. This is similar to a web browser/server. GPL linking exceptions: You can link GPL'ed code with proprietary code if the proprietary code is considered part of the development tool or standard runtime env. This means it is OK to load/library a DLL installed with Windows, but not a third-party proprietary DLL, including any you write yourself. This should also mean that you can use the standard REBOL script library that comes with the SDK, but I would like some clarification from REBOL Tech to be sure. AFAIK, it is considered politically incorrect to use proprietary development tools to build GPL programs, but not illegal. You should be sure to include the source to any changes you make to the SDK scripts so that others with a stock SDK can build your program. You will probably need to distribute these changes as patches to comply with SDK licensing rules, and will need to provide REBOL Tech. with these patches as per the license rules. The SDK scripts are shared-source, not open-source. SDK patches probably can't be GPL'ed, unless you prohibit them from being applied or add an exception to allow that, and only link with code with a similar exception. Actually, it would be a good idea with GPL code that depends on the SDK to explicitly include an exception to allow linking with SDK code, but be careful because that code won't be license-compatible with GPL code without any such exception. You may be able to use BSD or similar GPL-compatible non-copyleft licenses for your patches instead, or public domain. This all probably needs some clarification from REBOL Tech's lawyers. Brian Hawley

  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted