Why so many Common Libraries?

[JavaWiz]

Ok, I am in the process of setting up a project on SourceForge. In order to set it up, it requires that I choose an open source license. Following are the choices:

GNU General Public License (GPL)
GNU Library or Lesser General Public License (LGPL)
BSD License
Public Domain
MIT License Apache License V2.0
Artistic License
Mozilla Public License 1.1 (MPL 1.1)
Academic Free License (AFL)

I've been trying to find something that compares each license and lists the differences, but have been unable to. I don't have time (or the inclination) to read the legalesse for each of the license types.

Can anyone point me to a reference that can dumb it down so I can understand what the differences are?

[whurlston]

Ok, I am in the process of setting up a project on SourceForge. In order to set it up, it requires that I choose an open source license. Following are the choices:

GNU Library or Lesser General Public License (LGPL)
BSD License
Public Domain
MIT License Apache License V2.0
Artistic License
Mozilla Public License 1.1 (MPL 1.1)
Academic Free License (AFL)

I've been trying to find something that compares each license and lists the differences, but have been unable to. I don't have time (or the inclination) to read the legalesse for each of the license types.

Can anyone point me to a reference that can dumb it down so I can understand what the differences are?

http://developer.kde.org/documentation/l...mmary.html

Key for the list points:
License

1. Proprietary Software linking
   
2. Distribution of “the Work”
   
3. Redistributing of the code with changes
   
4. Compatible with GNU GPL
   

GPL

1. Not allowed (since the linked software is considered a whole)
   
2. Not allowed with software whose license is not GNU GPL compatible.
   
3. Only if the derivative is GNU GPL.
   
4. Yes
   

LGPL

1. Allowed (since the software that links to the library is not considered a derivative work)
   
2. Allowed with some restrictions: You have to provide source code of the distributed LGPL library with (if any) modifications, changes to the LGPL library should be allowed to third parties and if BC your app/lib should still work with the modified LGPL lib/app.
   
3. Only if the derivative is GNU LGPL or GNU GPL.
   
4. Yes
   

Apple Public

1. Allowed (the requirements of Apple License apply only to the Covered Code)
   
2. Allowed.
   
3. Only under Apple Public license.
   
4. No
   

Apache Public

1. Allowed.
   
2. Allowed.
   
3. Allowed (as long as the name “Apache” isn't used in the name of the derivative work)
   
4. No
   

Artistic 2.0

1. Allowed.
   
2. Allowed (as long as C or perl subroutines supplied by you and linked into the Covered Code are not considered a part of the Covered Code)
   
3. Allowed if one of the following is true:
   • a) modifications are freely available,
     
     
   • b) one uses the modified package only within corporation or organization,
     
     
   • c) rename any non-standard executables,
     
     
   • d) make other distribution arrangements with the Copyright Holder
     
     
   • And the name of the Copyright Holder may not be used to promote derived products without his/hes written permission.
     
4. Yes [1]
   

BSD

1. Allowed.
   
2. Allowed.
   
3. Allowed.
   
4. Only the modified BSD license is compatible with GPL. The original BSD license is not compatible because it includes a weird advertising clause. [2]
   

Common Public

1. License not clear on that, but do not mix Code Covered by this license with incompatible licenses.
   
2. Not clear, but again do not mix it with code licensed under an incompatible license.
   
3. Only under CPL or a compatible license.
   
4. No
   

Jabber

1. Allowed
   
2. Allowed. Only the portions of “the Work” licensed under the Jabber license needs to stay licensed as such.
   
3. Can be under a different license as long as the source code is provided and a few License specific requirements are fulfilled.
   
4. No
   

MIT (X11)

1. Allowed.
   
2. Allowed.
   
3. Allowed.
   
4. Yes
   

MPL

1. Allowed.
   
2. Allowed.
   
3. Only under MPL.
   
4. No/Yes [3]
   

Python

1. Allowed (?)
   
2. Allowed.
   
3. Allowed, assuming the package includes a list of changes to the original Python and copyright notices on all files.
   
4. Yes
   

QPL

1. Not allowed.
   
2. Only if it's Open Source.
   
3. Only in the form of patches to the original code.
   
4. No
   

Sleepycat

1. Allowed
   
2. Allowed
   
3. Allowed
   
4. Yes
   

Sun Public

1. Allowed.
   
2. Allowed.
   
3. Only under Sun Public.
   
4. No
   

W3C

1. Allowed.
   
2. Allowed.
   
3. Allowed
   
4. Yes
   

[JavaWiz]

Ok, so if I understand, GPL is out since GBPVR is not Open Source.

I am leaning towards LGPL. Does anyone have any concerns that this is not a good choice?

[whurlston]

I don't pretend to understand them, so I really have no idea. I'll go with whatever you decide.

[herrmannj]

I don't pretend to understand them

as far as I understand LGPL would lead to the fact that everything derived from has to be open source too, which would be fine.

Any thought about the scope and the topic of the project ?
UI Support and UI Controls ?

joerg

[Fatman_do]

I believe going upstream is not required to be open source, just down stream.
GBPVR not being open source should have no affect on 3rd party plugins.

[MixMan]

I don't know much about the license terms either!
If someone finds a really good open source GPL, class and want to integrate that into the CommonLibraries.
Would that be possible if the CommonLibraries are LGPL?
Is it then possible to have GPL classes int the CommonLibraries as LGPL and used by plugins that are not open source?
I think it would be great if this was possible ....especially for the metadata stuff.

[sub]

If someone finds a really good open source GPL, class and want to integrate that into the CommonLibraries.
Would that be possible if the CommonLibraries are LGPL?
Is it then possible to have GPL classes int the CommonLibraries as LGPL and used by plugins that are not open source?

No, unfortnately not. If there is anything GPL in there, then the whole thing needs to be GPL. This is the 'viral' nature of it you often see talked about.

Effectively we'll need to avoid anything covered by the GPL license.

[herrmannj]

so I vote for LGPL with adding a "gentlemen agreement": plugins which use it "should" be also distribute source code, so others may also participate.

[JavaWiz]

The WizUtilities use the HTMLAgilityPack which has a creative commons "ShareAlike" license.

Not sure what the impact of this is, we may need to drop the 'scraping' functions until a home-grown replacement methodology for parsing the html is developed.