From: Austin Ziegler Date: 2003-07-10T10:10:03+09:00 Subject: Re: OT: GPL - was Re: My brief and torrid affair with Ruby. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 10 Jul 2003 07:02:00 +0900, Chalmers wrote: > I hope we can agree that the GPL'ed lib Y hinders app-X-developers > that want to sell X without releasing the source code (lets call > it the "cathedral-X" strategy). From my understanding this is the > essence of the GPL: preventing cathedral-X. Not at all. The GNU GPL has nothing to do with ESR's Cathedral and Bazaar development methods. There are open source projects that are Cathedral in nature (GCC was one until egcs; same for emacs). Depending on who you talk to, the GNU GPL is about "freeing the code" (which is just silly) or "freeing the users" (which is more correct) or "ensuring source code access and modification rights" (which is exactly correct). The particular trick that the GPL uses to ensure that the source code remains available throughout the development process and across multiple developers is "copyleft." Note that there are a lot of licences that have copyleft features in them, but none of them are as broad as the GNU GPL. The MozillaPL, for example, has copyleft features relating to the direct modification of code under the MPL (the FSF calls them "not strong copyleft"). If I make modifications to the code files in the MPLed library, I have to make those modifications available. If I *use* the MPLed library, I don't need to make my using app MPLed. If I make the MPLed library *use* a non-MPLed library, all I have to do is release the modifications that I made to the MPLed library in order to make the connection (in which way someone can then attempt to reverse engineer the closed source library). This is very similar to the GNU LGPL. What is significant is the broadness of the copyleft provisions in the GNU GPL. As I noted in another message, if I were to make a AdvocacyFreePL, which was the GNU GPL without the philosophical twaddle at the beginning, it would *probably* be incompatible with the GPL itself, even though it achieves the exact same effect. > However, people that want to do cathedral-X might still be able to > go ahead. The GPL only forces them to contact the author of Y and > ask for permisson to do cathedral-X. So Y-author still has the > power to decide what to allow. How can this be a bad thing? Unfortunately, the conflict with the GPL's broad-based copyleft is more likely to happen with someone who doesn't philosophically like the GNU GPL but actually likes developing open source software (me, for example). I don't like the idea that because someone uses the GPL, *I* have to use the GPL for my entire project. The source is still available in my case, I just don't want to place what I view as unnecessary restrictions on my users. (And the GNU GPL is a *very* restrictive licence, compared to most other OSI-approved open source licences.) The most annoying use of the GPL in Ruby I've seen so far is actually in something that the PragProgs did with their DbC implementation. To me, that should have been LGPL. Since it's GPL, though, I don't use it (and I don't understand DbC well enough to reimplement it, either). Don't get me wrong -- it was Andy's call to use the GPL in DbC for Ruby. I'll never say it wasn't his choice. I just think it was a bad choice. > I think I can understand the almost-any-use-of-X types and why > they don't want to GPL their code. Would they be ok if Y is still > under GPL but they were allowed to have (app-X - Y) under some > other license? Maybe their needs could be addressed with a > GPL-variant that do not push GPL on X but still does not allow > cathedral-X++ since the author of Y should have a say in that. Is > LGPL the solution for this? The LGPL is the solution for this -- but author of Y would not be permitted to prohibit use of Y in a commercial project, but RMS/FSF discourage use of that because they don't feel that it's radical enough. IMO, most other OSI licences are better than the GPL, but the best licences from my perspective are (no order) LGPL, MIT, BSD, and MPL. > You can add your own little value while preventing commercial > entities to "steal" your work and make it part of something > outside of the ecosystem. The GPL doesn't prevent this. Seriously. All the GPL does is say that the source code must follow the binaries, and that the source code must not have restrictions exceeeding those of the GPL (so no "due credit" clauses permitted). So someone can pick up your software and sell it for $1,000,000 after improvements. They only have to give the source code to those customers that purchase it. > The idea of using BSD-style license for most of the stuff and GPL > for your innovative was a good one; I'll try to adopt that. Might I suggest using LGPL instead of GPL if it's a library? If it's an application, by all means, make it GPL if you want. - -austin - -- austin ziegler * austin@halostatue.ca * Toronto, ON, Canada software designer * pragmatic programmer * 2003.07.09 * 20:34:40 -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 - not licensed for commercial use: www.pgp.com iQA/AwUBPwy8z2ZOwWepqGDiEQI/pACgkDndtMod+YOMve2KE4GIOnBFHQwAn39H ObvSCPFqPLzesHCdo581zaJj =6q2h -----END PGP SIGNATURE-----