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 REBOL.org 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:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/license-help.r
(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
Anton:
> 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:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/license-help.r
And the template used to produce it is here:
http://www.rebol.org/library/public/license-descriptions.txt
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
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted