Re: OT: GPL - was Re: My brief and torrid affair with Ruby.

Austin Ziegler <[e-mail]> skrev den Thu, 10 Jul 2003 10:10:03 
+0900:

> -----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."
>
What I'm trying to say is that in practice it has to do with ESR's concepts 
since a commercial entity will want to protect the additions they do and 
thus do not want them to be open and thus are reluctant to use GPL'ed code. 
Can you point out where I go wrong here?

> 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.
>
Yes but does any of them force the full app to be open-sourced
without requiring anything more about (the code in the app - the code in 
lib Y)?

>> 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.)
>
And I'm trying to understand in detail why you don't like the GPL. It
seems you don't like it because of its "philosophical baggage" and
not because you want to allow commercial entities to use your code
in their closed apps.

I think the Alladin Free Public License is the most appropriate for what I 
wanna do: allow anyone to use it in open-source projects but restrict 
commercial use of my code without talking to me.

Here's from an interview with Peter Deutsch (author of AFPL):

"The essence of the Aladdin license I can describe in one sentence and it 
is very much about social contracts.

Namely, if you are willing to play by what I think are the 1960s rules, 
then the Aladdin license gives you exactly the same rights and benefits as 
the GPL: it's free to use, it's free to copy, and you are free to modify 
it. All of those things.

In a nutshell, I see the 1960s rules, or the cooperative rules, this way: 
"everybody contributes, so everybody benefits." Unlike the GPL I make a 
very solid distinction between distribution as part of a commercial 
endeavor and distribution not as part of a commercial endeavor. 
Distribution not as part of a commercial endeavor is covered by essentially 
the GPL rules, while distribution in any commercial endeavor is not 
permitted by the Aladdin free license."

Unfortunately AFPL is not OSI-approved. I think its a pity AFPL is not in
more widespread use; I think it would promote even more high-quality open- 
source libraries. In current methods we are at the mercy of people
spending there free time (I guess its mostly college students around the
world).

BTW, I found that we've discussed Ruby/licenses on ruby-talk before:

http://www.ce.chalmers.se/~feldt/ruby/summaries/licensing_ruby_extensions_and_tools.html

I'm not sure I have the same view nowadays...

>> 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.
>
So the sources need not be made publicly available? Aha, I see the problem 
more clearly now.

>> 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.
>
I will need to take a renewed look at my licensing situation. I really
wanna restrict commercial use of my code without asking me. Unfortunately
that seems hard without people getting the impression my stuff is not
free.

Regards,

Robert Feldt