google-code-export / jslibs

Automatically exported from code.google.com/p/jslibs
0 stars 0 forks source link

change jslibs license to LGPL #31

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I have a liitle problem with licensing. GNU GPL is great but this
JavaScript+jslibs biggest usage scenario will be in embedding it into
the applications. And if anyone embed one of your libraries then the
one must also release the project under GNU GPL. This is restrictive a
bit, I would like to have LGPL there which permits linking of
unmodified library without the must of releasing whole project as GPL. -
Lukas Zapletal

Original issue reported on code.google.com by sou...@gmail.com on 14 Feb 2008 at 12:20

GoogleCodeExporter commented 9 years ago
Well I am fan of BSD-like licenses but LGPL is much better here. Assures 
continuing
of the development for you and possibility to include the library in nonchanged 
form
in non-compatible programs.

Original comment by lukas.zapletal on 14 Feb 2008 at 12:32

GoogleCodeExporter commented 9 years ago
I'd go for LGPL as well. GPL is nice, but using a open-source license that 
viral is
counterintuitive to the goal of this project.

The goal of jslibs is to improve the list of JavaScript libraries, and make
JavaScript a viable solution for embedding into a wide variety of solutions.

However with that broad of a goal the GPL will only hinder it. Because of how 
viral
the GPL is, it would only be viable for open-source projects embed jslibs into 
their
projects. Corporate companies will likely avoid it.

The wide success of languages like PHP and ruby is because they use permissive
licenses that allow big companies to develop software using them. If PHP were
licensed in GPL, it is likely that many companies would have chosen other 
languages
like Java or ASP instead of PHP reducing how widely PHP is adopted.

SpiderMonkey as I recall is also under LGPL, so I think it would fit in best.

Original comment by nadir.se...@gmail.com on 12 Nov 2008 at 12:10

GoogleCodeExporter commented 9 years ago
LGPL is probably not a bad fit, although I'd have to check with legal here if 
even
the LGPL was permissible. To use any jslibs code, I would have to wrap it
ever-so-slightly in some macros and add two functions per module.

GPLv2 code is simply not usable here, as we have major problems with the viral 
nature
of GPL.

For what it's worth, our embedding platform and public libs are released under 
the
same license terms as Mozilla Spidermonkey -- the "triple" license, GPL, LGPL 
and
MPL. Our goal is to get as many people as possible to use the product.

Original comment by wes.garl...@gmail.com on 9 Mar 2009 at 5:25

GoogleCodeExporter commented 9 years ago
One issue I see with the LGPL (or a no GPL) license is that some of my modules 
are
GPL only and this mean that I will have to remove them before changing the 
license.

Original comment by sou...@gmail.com on 10 Mar 2009 at 10:41

GoogleCodeExporter commented 9 years ago
Here's the roster of licenses:
zlib: zlib/libpng
vst: VSTGUI License, BSD-like
sqlite: Something strange but even more liberal than BSD.
sdl: LGPL 2.1
pixman: MIT?
pango: LGPL 2
openal: None listed
ode: LGPL 2.1+ BSD dual-license
nspr: MPL 1.1 GPL 2+ LGPL 2.1+ tri-license
libxml2: MIT
libvorbis: BSD
libtommath: Public Domain
libtomcrypt: Public Domain
libsndfile: LGPL 2.1
librsvg: LGPL 2
libpng: zlib/libpng
libogg: BSD
libjpeg: Unknown, liberal but requires you state you've used IJC code inside 
your
software
libiconv: LGPL 2+
libffi: MIT
js: MPL 1.1 GPL 2+ LGPL 2.1+ tri-license
gloox: GPL 2
glib: LGPL 2
gdk-pixbuf: LGPL 2+
freetype: FreeType (ftl; heh perfect acronym) GPL dual-license
fontconfig-msvc: Part Apache Software License 1.1, part MIT?
fastcgi: MIT
cairo: LGPL 2.1 MPL 2.1 dual-license

Everything is ok except the only ugly ones are openal, libjpeg, gloox, freetype,
fontconfig-msvc. But the only actual issue is probably gloox.
gloox is the only pure GPL project in the entire lib area, so if we can drop it
jslibs can freely be whatever licence it wants.
libjpeg, freetype, openal, and fontconfig-msvg are a little ugly though.
libjpeg uses one of those rude licenses that forces you to say in your 
documentation
that you use their library.
freetype is a FreeType License/GPL dual-license. FTL ( ;) perfect name, heh) is
pretty much the same as BSD, though for some reason they decided they wanted to 
write
their own license. It's another one of the rude licenses requiring you 
explicitly
point out that you use their library.
fontconfig-msvg is a little ugly in that one of the files inside of it is 
licensed
with the old 1.1 version of the Apache Software License. Rest of the code is 
MIT.
openal doesn't seam to have any note of any license at all. I guess they just 
care
more about code than bothering to restrict it's use?

Original comment by nadir.se...@gmail.com on 6 May 2009 at 6:01

GoogleCodeExporter commented 9 years ago
Oh right... in any case rather than LGPL or whatever best bet is probably 
sticking
with the standard stuff used in other SpiderMonkey/NSPR/etc... projects
The MPL 1.1 GPL 2+ LGPL 2.1+ tri-license. If we want to be nice to Flusspferd 
we can
make that a MPL 1.1 GPL 2+ LGPL 2.1+ MIT quad-license.

Original comment by nadir.se...@gmail.com on 6 May 2009 at 6:04

GoogleCodeExporter commented 9 years ago
Oh: http://camaya.net/glooxlicense
Apparently Gloox is one of those horrid extreme cases where they want to either 
force
you to make everything you write that uses their code be GPL or pay them for a
commercial license.

Original comment by nadir.se...@gmail.com on 6 May 2009 at 6:08