1. Open source licenses explained
- Posted by D. Newhall <derek_newhall at yahoo.com>
Sep 20, 2006
-
Last edited Sep 21, 2006
Since we've been debating licenses for Euphoria I figured someone should
probably explain all of them. So, here's an explanation for the most popular open
source licenses out there (all opinions and biases are mine unless otherwise
noted). Everyone should read the original licenses as well.
(Note: I am not a lawyer and am simplifying everything a lot. Also, some of
these licenses I haven't read recently and may have forgotten something.)
3-clause BSD: http://www.xfree86.org/3.3.6/COPYRIGHT2.html#5
Pretty much complete freedom except that you can't use the creator's name in
advertising.
4-clause BSD: http://www.netbsd.org/Goals/redistribution.html#default
3-clause BSD but you need to explicitly acknowledge the original creator of the
code. This acknowledgment causes the 4-clause BSD license to be incompatible with
most "copy-left" licenses. The FSF actively discouraged using it for practical
reasons since the list of contributors gets hard to deal with after a while.
Personally, I prefer it it for most of my code since anyone can use it for
anything so long as they acknowledge they got the code from me. It's my current
vote in Vincent's poll.
MIT X11: http://www.opensource.org/licenses/mit-license.php
3-clause BSD license without the "no-use-of-creators-name-in-advertising"
clause. Practically the closest to public domain you can get with a license.
GPL: http://www.gnu.org/licenses/gpl.html
A very, very popular strong copy-left license. Using any code in any manner in a
project makes it GPL. The biggest problem with it is that using euphoria code in
a library would make any code that uses that library GPL as well regardless of
the format that library is released in. This would be a big detriment to people
who want to use the Euphoria code as a plugin for a server or as an application
scripting language.
LGPL: http://www.gnu.org/copyleft/lesser.html
The GPL but can be used in binary form in a non-GPL project. Also, contains a
special clause to make LGPLed code GPLed easily.
Apache 2.0 license: http://www.apache.org/licenses/LICENSE-2.0
The Apache license is essentially the 3-clause BSD license but with a clause
that requires any patented code be released for public use if this license is
used on it (this also renders it incompatible with the GPL).
MPL: http://www.mozilla.org/MPL/MPL-1.1.html
The MPL requires that only files that are changed be released. All original code
remains completely open but people can add any proprietary features they want. I
think that this is the best compromise choice between the GPL and BSD license
camps since it allows "non-free" use but keeps the code freely distributed with
changes. This would be my second choice of a license behind 4-clause BSD.
Lucent license: http://plan9.bell-labs.com/plan9/license.html
4-clause BSD but with some explicit protections against legal action by
disgruntled users. Relatively uncommon.
CDDL: http://www.opensolaris.org/os/licensing/cddllicense.txt
MPL but with some additional legal restrictions. Primarily the ability to
specify where you can sue people for breach of licensing terms in the
documentation but also some patent. Also, any code released under the CDDL is
ONLY under the CDDL (no other licensing choices) and all patented code is
released to the public. These legal restrictions are often said to be burdensome
for developers (I'd agree). You also MUST declare that any code you contribute is
your own. It's a kind of weird license and wouldn't recommend it.
APSL 2: http://www.opensource.apple.com/apsl/2.0.txt
This one I haven't read as thoroughly as the others but seems to be an
Apple-centric version of the MPL.
AFL 3: http://opensource.org/licenses/afl-3.0.php
Supposedly, it's similar to the Apache license but with some additional legal
freedoms and restrictions. For example, any patented code must be released and
you must not use the creator's name for advertising. Apparently, the FSF and OSI
disagree on whether it's GPL incompatible or not (or so I hear, it seems to be
pretty obviously incompatible in my opinion). Pretty uncommon but advocated by
the OSI to a degree. I also think that section 2 of the license could be worded
ambiguously.
2. Re: Open source licenses explained
D. Newhall wrote:
> Since we've been debating licenses for Euphoria I figured someone should
> probably
> explain all of them. So, here's an explanation for the most popular open
> source
> licenses out there (all opinions and biases are mine unless otherwise noted).
> Everyone should read the original licenses as well.
>
> (Note: I am not a lawyer and am simplifying everything a lot. Also, some of
> these licenses I haven't read recently and may have forgotten something.)
Thanks for that summary.
I won't decide anything for sure until I hear more of
what people have to say on this.
All I can say now is I'm
leaning toward a less restrictive license. I'm really not
that concerned if someone takes my code and uses it in
a closed source program, but I'd be concerned if that
possibility would turn off certain people from contributing to
Euphoria. I have no interest in trying to champion "open source"
over closed source. I would just like to see Euphoria steadily improve
and become more useful to more people. If someone somehow makes a
few bucks off my code it doesn't particularly bother me, especially
if that somehow increases the popularity of Euphoria,
but if it would bother other contributors I'd like to hear about it.
I tend to get turned off when I see a lengthy, complicated license
attached to some code that I'm considering using.
Maybe someone can suggest some "worst case" scenarios that
I may be missing here.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Open source licenses explained
I appreciate it's Rob's call anyway but according to Vincent's last post,
"LGPL is gaining the most traction with 42% of the votes and the 3-clause BSD
license is in second with 28%".
LGPL (thanks for the links Derek) is vague and confusing to me. Am I to
assume that it is more restrictive to programmers in some ways than Rob's
present licence, especially for professionals who might want to sell their
own shrouded programme without letting anyone else see their code? Hence,
many of the people affected in this respect might be those with the skills
and experience required to develop Euphoria. Or have I got it all wrong and
LGPL requires disclosure of source code only for different versions of a
language and it’s libraries?
How would it impact (selling shrouded programs) on programmers using
Win32lib.ew or on the future development of Win32lib.ew itself?
Would people want to continue as before under Rob's present rules
using 2.5 once 3.0 alpha is out, should any ensuing licence restrictions
become unfavourable to them?
As I say, it's Rob's call and it must be a difficult one, letting go for
the sake of Euphoria’s future development. I'm just a little confused by
the poll results and my interpretation of LGPL restrictions.
Regards,
Bob
4. Re: Open source licenses explained
- Posted by D. Newhall <derek_newhall at yahoo.com>
Sep 21, 2006
-
Last edited Sep 22, 2006
Bob Thompson wrote:
>
(snip)
>
> LGPL (thanks for the links Derek) is vague and confusing to me. Am I to
> assume that it is more restrictive to programmers in some ways than Rob's
> present licence, especially for professionals who might want to sell their
> own shrouded programme without letting anyone else see their code? Hence,
> many of the people affected in this respect might be those with the skills
> and experience required to develop Euphoria. Or have I got it all wrong and
> LGPL requires disclosure of source code only for different versions of a
> language and it’s libraries?
Yes, in some ways the LGPL is more restrictive than Rob's present license but in
other ways is a lot less restrictive. The LGPL is, for all intents and purposes,
the GPL except that you can use the code as a stand-alone library in non-"free"
applications. So, if Euphoria goes LGPL any modification to the Euphoria code
must be open sourced as well under the LGPL (or possibly the GPL) but unlike the
GPL you can put the LGPLed source code into a library or something that is used
by another incompatible license. If the code is GPLed then if you link to the
external library your program must be GPLed as well.
However, Rob's license is more restrictive in most respects. You can't release
anything you do unless it's for a different platform (end even then you can't
release the code) or the person receiving it has a license as well.
> How would it impact (selling shrouded programs) on programmers using
> Win32lib.ew or on the future development of Win32lib.ew itself?
If it's shrouded/bound currently it won't be effected because licensing
restrictions can't be added retroactively for the most part (some exceptions
exist however but I doubt they'd apply here). However, bound programs that use an
LGPLed or GPLed interpreter would almost surely have to be open-sourced as well
(I'm going to have to read through it again carefully checking to see how binary
modification would be treated in regards to being a derivative work but I'm
pretty sure it would be considered as such). Shrouding shouldn't have any major
problems except people might be able to see the unshrouding algorithm reducing
part of the point of shrouding.
> Would people want to continue as before under Rob's present rules
> using 2.5 once 3.0 alpha is out, should any ensuing licence restrictions
> become unfavourable to them?
This brings up an interesting point. Rob could open-source Euphoria and then
continue to sell his version of it since he owns the copyright to it so long as
it's all his code.
(snip)
> As I say, it's Rob's call and it must be a difficult one, letting go for
> the sake of Euphoria’s future development. I'm just a little confused by
> the poll results and my interpretation of LGPL restrictions.
It's absolutely Rob's call. The poll is just an unofficial (unless Rob wants to
make it official) way to gauge who would prefer what license.
My take on the LGPL is that it is infinitely better than the GPL since it allows
freer use but is still a bit cumbersome. I think the MPL is a better license over
the LGPL since you only need to open-source changes to already existing code
(with the LGPL anything you add becomes LGPL once you release it). So, if
Euphoria is MPLed and I write a CAD application that uses Euphoria as a scripting
language I need to release all the Euphoria source code but none of my
application code but if Euphoria was LGPL I could only turn Euphoria into a
library (and any additions to the library I need to open source) and use it from
my application.
5. Re: Open source licenses explained
- Posted by Ray Smith <ray at RaymondSmith.com>
Sep 21, 2006
-
Last edited Sep 22, 2006
Robert Craig wrote:
>
> All I can say now is I'm
> leaning toward a less restrictive license. I'm really not
> that concerned if someone takes my code and uses it in
> a closed source program, but I'd be concerned if that
> possibility would turn off certain people from contributing to
> Euphoria. I have no interest in trying to champion "open source"
> over closed source. I would just like to see Euphoria steadily improve
> and become more useful to more people. If someone somehow makes a
> few bucks off my code it doesn't particularly bother me, especially
> if that somehow increases the popularity of Euphoria,
> but if it would bother other contributors I'd like to hear about it.
> I tend to get turned off when I see a lengthy, complicated license
> attached to some code that I'm considering using.
I for one would prefer something that allowed anyone to "use" Euphoria to write
commercial or open source programs (this is almost obvious but I guess needs
mentioning).
I'd also prefer if the Euphoria source was open sourced in such a way that no
one could take what others have contributed and turn it into a closed source "new
language" or "updated Euphoria" language.
I don't see why a LGPL based license wouldn't work.
It allows you write Euphoria programs and do anything you want with them, but
protects the Euphoria language itself from being used by someone in a closed
source environment.
Regards,
Ray Smith
http://RaymondSmith.com
6. Re: Open source licenses explained
When ever I see the word licenses I quit reading because I find it boring.
If I am installing a new program and it says "I agree with the terms of license"
or "I do not agree with the terms of the license" I ALWAYS select
"I agree" whether I agree to the terms or not. Otherwise the new program will
not install. Don't tell me I'm the only one who lies about this. I believe the
licensing should be left up to the attorneys for I am just a simple programmer.
Don Cole
7. Re: Open source licenses explained
- Posted by ags <eu at 531pi.co.nz>
Sep 22, 2006
don cole wrote:
>
> When ever I see the word licenses I quit reading because I find it boring.
> If I am installing a new program and it says "I agree with the terms of
> license"
> or "I do not agree with the terms of the license" I ALWAYS select
> "I agree" whether I agree to the terms or not. Otherwise the new program will
> not install. Don't tell me I'm the only one who lies about this. I believe the
> licensing should be left up to the attorneys for I am just a simple
> programmer.
I do this too Don (with the exception of scanning the license for my permission
to install spyware, then I very rarely agree).
But when it comes to developing an application with libraries I always look at
the license (in case I want to commercialise it, not that I ever have 
A classic example is BASS. I developed an databased (EDS) MP3 playing system
using BASS (which is very good) for a radio station which while technically
belonging to my employer (or at least morally) would take very little effort to
reimplement in a 'clean' environment (since I would want to re-write it anyway).
But one look at the BASS library license put me off that idea completely. (Can
you say $$$? :)
As far as Euphoria goes, I would like to see a dual license like Perl (LGPL and
something else).
Gary
8. Re: Open source licenses explained
D. Newhall wrote:
>
> Yes, in some ways the LGPL is more restrictive than Rob's present license but
> in other ways is a lot less restrictive. The LGPL is, for all intents and
> purposes,
> the GPL except that you can use the code as a stand-alone library in
> non-"free"
> applications. So, if Euphoria goes LGPL any modification to the Euphoria code
> must be open sourced as well under the LGPL (or possibly the GPL) but unlike
> the GPL you can put the LGPLed source code into a library or something that
> is used by another incompatible license. If the code is GPLed then if you link
> to the external library your program must be GPLed as well.
I'm curious as to how the LGPL is more restrictive. You can't even share
binaries with the 2.5 source license, let alone source. The LGPL just
goes the other way, saying that you *have* to allow distribution of the
source.
> My take on the LGPL is that it is infinitely better than the GPL since it
> allows
> freer use but is still a bit cumbersome. I think the MPL is a better license
> over the LGPL since you only need to open-source changes to already existing
> code (with the LGPL anything you add becomes LGPL once you release it). So,
> if Euphoria is MPLed and I write a CAD application that uses Euphoria as a
> scripting
> language I need to release all the Euphoria source code but none of my
> application
> code but if Euphoria was LGPL I could only turn Euphoria into a library (and
> any additions to the library I need to open source) and use it from my
> application.
I think you're confusing the LGPL with the GPL. I'm not so familiar with
the MPL, but it sounds like a derivative of the LGPL. Basically, if Euphoria
were LGPL'd, any modifications you made to the interpreter would be LGPL'd,
too. But you could link it to other non-LGPL'd code, and you wouldn't
have to release any of that code.
Even if Euphoria were GPL'd, I don't think that you'd have to GPL anything
that you wrote in Euphoria. You'd have issues if you translated, since
you'd be linking to the Euphoria run-time library.
Matt Lewis
9. Re: Open source licenses explained
Matt Lewis wrote:
>
>
> I'm curious as to how the LGPL is more restrictive. You can't even share
> binaries with the 2.5 source license, let alone source. The LGPL just
> goes the other way, saying that you *have* to allow distribution of the
> source.
The only way that the LGPL is more restrictive is that you have to open source
your contributions. The current license allows you to keep your improvements
hidden if so desired.
> I think you're confusing the LGPL with the GPL. I'm not so familiar with
> the MPL, but it sounds like a derivative of the LGPL. Basically, if Euphoria
> were LGPL'd, any modifications you made to the interpreter would be LGPL'd,
> too. But you could link it to other non-LGPL'd code, and you wouldn't
> have to release any of that code.
Nope, I'm not confusing the two. What you say is correct (except that the MPL is
not a derivative of the LGPL). The difference between the MPL and LGPL (my
examples probably weren't that clear) is that you can use MPLed code in a closed
source project you just need to open source any changes to the original source
files. If I have files A, B, and C files A and B are proprietary or whatever and
C is MPL file C can be used with no problems in the program so long as I release
C to the public. If C was LGPL however A and B would have to be LGPLed as well
and my entire program's code would have to be released.
> Even if Euphoria were GPL'd, I don't think that you'd have to GPL anything
> that you wrote in Euphoria. You'd have issues if you translated, since
> you'd be linking to the Euphoria run-time library.
The problem with Euphoria being GPL is that I couldn't then use it to make an
Apache module or as a scripting language in a commercial application.
10. Re: Open source licenses explained
D. Newhall wrote:
>
> Matt Lewis wrote:
> >
> >
> > I'm curious as to how the LGPL is more restrictive. You can't even share
> > binaries with the 2.5 source license, let alone source. The LGPL just
> > goes the other way, saying that you *have* to allow distribution of the
> > source.
>
> The only way that the LGPL is more restrictive is that you have to open source
> your contributions. The current license allows you to keep your improvements
> hidden if so desired.
>
I was referring to the following extracts from LGPL and how they restrict
selling bound/shrouded/compiled programmes. I'm off on business now for
two weeks so I won't be able to respond.
Let me know if I have it wrong.
Regards,
Bob
5. A program that contains no derivative of any portion of the Library,
but is designed to work with the Library by being compiled or linked with
it, is called a "work that uses the Library". Such a work, in isolation,
is not a derivative work of the Library, and therefore falls outside the
scope of this License.
However, linking a "work that uses the Library" with the Library creates
an executable that is a derivative of the Library (because it contains
portions of the Library), rather than a "work that uses the library".
The executable is therefore covered by this License. Section 6 states
terms for distribution of such executables.
6. As an exception to the Sections above, you may also combine or link
a "work that uses the Library" with the Library to produce a work
containing portions of the Library, and distribute that work under terms
of your choice, provided that the terms permit modification of the work
for the customer's own use and reverse engineering for debugging such
modifications.
11. Re: Open source licenses explained
D. Newhall wrote:
<snip>
The problem with the MPL is that it's not compatable with the GPL. Modules
governed under MPL cannot legally link with modules under GPL.
Regards,
Vincent
12. Re: Open source licenses explained
- Posted by Ray Smith <ray at RaymondSmith.com>
Sep 22, 2006
-
Last edited Sep 23, 2006
Bob Thompson wrote:
> I was referring to the following extracts from LGPL and how they restrict
> selling bound/shrouded/compiled programmes. I'm off on business now for
> two weeks so I won't be able to respond.
>
> Let me know if I have it wrong.
>
> Regards,
>
> Bob
>
> 5. A program that contains no derivative of any portion of the Library,
> but is designed to work with the Library by being compiled or linked with
> it, is called a "work that uses the Library". Such a work, in isolation,
> is not a derivative work of the Library, and therefore falls outside the
> scope of this License.
>
> However, linking a "work that uses the Library" with the Library creates
> an executable that is a derivative of the Library (because it contains
> portions of the Library), rather than a "work that uses the library".
> The executable is therefore covered by this License. Section 6 states
> terms for distribution of such executables.
I don't see a problem with this Bob.
Making a derivative of the library - is making a new version of Euphoria - if
you make a new version of Euphoria you must open source it.
Making a program that "uses" Euphoria, can stay closed source if you wish.
Regards,
Ray Smith
http://RaymondSmith.com
13. Re: Open source licenses explained
- Posted by Jason Gade <jaygade at yahoo.com>
Sep 22, 2006
-
Last edited Sep 23, 2006
Ray Smith wrote:
>
> Bob Thompson wrote:
>
> > I was referring to the following extracts from LGPL and how they restrict
> > selling bound/shrouded/compiled programmes. I'm off on business now for
> > two weeks so I won't be able to respond.
> >
> > Let me know if I have it wrong.
> >
> > Regards,
> >
> > Bob
((snip))
> I don't see a problem with this Bob.
> Making a derivative of the library - is making a new version of Euphoria - if
> you make a new version of Euphoria you must open source it.
>
> Making a program that "uses" Euphoria, can stay closed source if you wish.
>
> Regards,
>
> Ray Smith
> <a href="http://RaymondSmith.com">http://RaymondSmith.com</a>
The problem is with programs that are bound or shrouded. Bound code contains a
copy of the interpreter therefore falling under the section that he quoted.
It's a legitimate concern.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
