Ruby community discovers annoyance of GPL libraries
This interesting post describes one or the reasons why PEAR/PECL doesn’t allow (L)GPL code in the repositories
The problem that I’ve stumbled upon is that Ruby’s Gem repository is full of randomly licensed code, including lots of GPL stuff. At the very least, this information ought to be very visible so that it’s possible to weed out any GPL’ed libraries. At best, the Ruby guys would only accept MIT/BSD licensed code for the standard repository.
I am of the opinion that small snippets of code serve everyone best when released into the public domain.
June 13th, 2007 at 11:06 pm
LGPL is allowed in PEAR.
http://pear.php.net/group/docs/20040402-la.php
June 14th, 2007 at 6:21 am
Keep in mind that for people using GPL code in their project, the PEAR/PECL collection is a land mine. The PHP license (once the default for most PEAR entries) is incompatible with GPL. Worse, you can’t search based on library - you have to go to the individual package.
I’m with you on MIT/BSD licensing for greater interop and re-usability, but many people (incorrectly) thought the PHPL was ’similar enough’, when in fact it causes major conflicts.
June 14th, 2007 at 12:43 pm
iamsure, not really… if you have a GPL project you can still require PEAR libs to be installed on the system (or pull them down during the installation), you just can’t bundle them and turn them into GPL code.
That’s my interpretation, but a lot of GPL projects are doing it.
June 15th, 2007 at 3:31 pm
I think it’s the authors decision under which license she/he want’s to release. For an open source library like PEAR GPL should be a choice as well.
June 16th, 2007 at 7:49 am
LGPL and GPL are two totally different beasts. I’m amazed at the number of people who see any part of a license with the letters “GPL” in it and freak out.
LGPL is perfectly ok to bundle away, the only thing you can’t do is modify it and then change the modified code’s license. Though I haven’t investigated MPL, I’ve seen applications based off of Mozilla code distributed in a very similar way. All of the MPL modified code is handled within a separate portion of the package, then the proprietary code is segregated.
That’s the reason the “license bigots” - to pull a phrase from Welton’s post - hate the LGPL so much and even have a page on gnu.org trying to talk you out of using it. It’s not viral like the GPL. That said, it does make sure that anyone who uses your code can’t “take it proprietary”, something I’m all in favor of.
June 16th, 2007 at 3:29 pm
Travis, I love the GPL and I think makes great sense both in a philosophical and business sense (with a dual licensing model).
Tom: When you start talking about repositories and specifically package which have dependencies on other packages, when you throw GPL licensed code into the mix the entire repository is “tainted”.
June 17th, 2007 at 10:57 pm
Aaron: Didn’t mean it to come across quite as harsh as it did. It wasn’t directed specifically at you, but more a general observation on the state of understanding of licenses. Licensing can be a touchy spot with me…
Though I’m not a lawyer, I would disagree with the presence of GPL code in a repository such as PEAR as an automatic “taint” on the rest of the repository. The only things it would affect are the packages that rely specifically on it. Granted, mixed license repositories do lend themselves to confusion, but the GPL specifically deals with aggregation through the “mere aggregation” clause:
“In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.”
June 18th, 2007 at 1:34 pm
Travis, I agree. My point was that if I want to use the (BSD Licensed) MDB2 package and the mysql driver was licensed under the GPL, then I would not be able to use (bundle) that into a BSD (or commercially) licensed product.
The only solution would be to make an alternative package with a different license which I could bundle with non-gpl code. Creating 2 packages with different licenses is bad for the integrity of a software repository like PEAR, and therefore so is the GPL.
It would be silly to license a package like that under the GPL, knowing that it would be used with other packages, which was the point of not using the GPL for small projects.
June 19th, 2007 at 8:31 am
Yeah Aaron, that’s it. GPL tends to free more and more software, so this gives something back to the developer, the community and the world. Isn’t it great? Shure.
Anyway I strongly doubt that PEAR goes paddy with LGPL since LGPL is made for the source of binary libraries. PHP is an interpreter language so I assume that LGPL won’t do the job in PEAR if you put some pressure on it. Even if this a personal assumption of me only I think PEAR guys should check on that and open PEAR for GPL.