Subject: New Essay - "FOSS Licences Wars"

From: Shlomi Fish <[email-masked]>
Date: Fri, 21 Aug 2009 19:58:13 +0300

Hi all!

I have published a new essay about free software licences:

http://www.shlomifish.org/philosophy/computers/open-source/foss-licences-wars/

Any comments will be welcome.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Optimizing Code for Speed - http://xrl.us/begfgk

God gave us two eyes and ten fingers so we will type five times as much as we
read.

---

From: Dotan Cohen <[email-masked]>
Date: Tue, 25 Aug 2009 19:29:31 +0300

> Any comments will be welcome.

Tens of comments here already:
http://developers.slashdot.org/story/09/08/25/1356213/Getting-Through-the-FOSS-License-Minefield

-- 
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

---

From: Shlomi Fish <[email-masked]>
Date: Tue, 25 Aug 2009 22:55:59 +0300

> http://developers.slashdot.org/story/09/08/25/1356213/Getting-Through-the-F

Hi Dotan!

Thanks for submitting this story to Slashdot, (which got it accepted 
eventually). I submitted it too, but I didn't see it published. I'm not sure I 
understood the teaser paragraph:

<<<<<<<<<<<<<
Here's an exercise: Write a GPLed server for solving Freecell that the 
graphical game would communicate with using TCP/IP or a different IPC 
mechanism. Easy, right? Except for that pesky licensing bit. Our own Shlomi 
Fish gives an overview of the various options in picking up a licence for 
one's FOSS project, and tries to give some guidelines choosing one."

What I meant by giving the GPLed Freecell solving server example was that it's 
an option even if one only has found a strong-copylefted Freecell-solving 
library, which can work around the licence's limitations, and will allow you 
to use it withing programs of incompatible licences. On the other hand, you 
implied that it may not be an option due to the licence. But I may not read 
you correctly.

Anyway, thanks - I'll try to read the comments when I have some spare cycles. 
Oh, and I'm planning to respond to Mikhael Goikhman ("Migo") email too later 
as well.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Original Riddles - http://www.shlomifish.org/puzzles/

---

From: Dotan Cohen <[email-masked]>
Date: Wed, 26 Aug 2009 15:11:22 +0300

> eventually). I submitted it too, but I didn't see it published. I'm not sure
> I understood the teaser paragraph:
>
> <<<<<<<<<<<<<
> What I meant by giving the GPLed Freecell solving server example was that
> it's an option even if one only has found a strong-copylefted
> Freecell-solving library, which can work around the licence's limitations,
> and will allow you to use it withing programs of incompatible licences. On
> the other hand, you implied that it may not be an option due to the licence.
> But I may not read you correctly.
>

I meant that licensing issues would be the main challenge in writing
and distributing the software, as opposed to a programming challenge.

> Anyway, thanks - I'll try to read the comments when I have some spare
> cycles. Oh, and I'm planning to respond to Mikhael Goikhman ("Migo") email
> too later as well.
>

Don't browse at -1 unless you want to get offended! There were some
trolls there, but I conveniently had some modpoints at just the right
time.

-- 
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

---

From: Shlomi Fish <[email-masked]>
Date: Fri, 28 Aug 2009 21:39:14 +0300

Hi Mikhael!

Thanks for your comments and sorry for the late response. I'm also De-CCing 
Perl-IL . See below for my comments.

On Saturday 22 August 2009 18:31:38 Mikhael Goikhman wrote:
> On 21 Aug 2009 19:58:13 +0300, Shlomi Fish wrote:
> This article contains several factual errors as well as many arguments
> like "I didn't read or read once and am unable to understand, so it
> should be bad", that makes it difficult to take the article seriously.
> But I will try to constructively comment anyway.

I didn't say that the licence was "bad" because I didn't understand it after 
reading it a few times. I said it made it somewhat worse than a licence that 
was easily-understood-by-laymen, and that often people used such licences 
without being aware of their implications. Many people are using the GPL, 
because it was recommended by their friends, while actually desiring a weak 
copyleft or even a permissive licence.

>
> 1) To use a term "Wars" together with "FOSS Licenses" is to seriously
> misunderstand the topic. Different licenses are for different needs.

You're possibly right. But in many categories, you can find competing projects 
under both GPL-like licences and permissive licences. And now the OpenBSD 
project wants to replace most GPL software with permissive, BSD-style licences 
(specifically the ISC licence, I believe). What in your opinion makes the GPL 
superior in that case?

I should note that, as I'm explaining in the article, I've picked "FOSS 
Licences Wars" by inspiration from this Joel-on-Software feature called 
"Language Wars":

http://www.joelonsoftware.com/items/2006/09/01.html

In the article, I didn't try to dissuade people from picking a licence from 
the strong-copyleft, weak-copyleft or permissive licences categories, but 
instead tried to argue against specific licenses. 

>
> 2) Your catalogizing of Artistic License as weak copyleft is false.
> Noone (except for you) considers it copyleft, see wikipedia.
>

According to:

http://catb.org/~esr/writings/taoup/html/ch19s05.html#id3014963

{{{{{{{{{{{{
The next most restrictive kind of license grants unrestricted rights to copy, 
use, and locally modify. It allows redistribution of modified binaries, but 
restricts redistribution of modified sources in ways intended to protect the 
interests of the authors and the free-software community.
The Artistic License, devised for Perl and widely used in the Perl developer 
community, is of this kind. It requires modified files to contain “prominent 
notice” that they have been altered. It also requires people who redistribute 
changes to make them freely available and make efforts to propagate them back 
to the free-software community.
You can find a copy of the Artistic License at the OSI Site.
}}}}}}}}}}}}

This seems like copyleft to me, at least as far as the source code is 
concerned. 

http://en.wikipedia.org/wiki/Artistic_License indeed says that it is not 
copyleft, but I would classify it as marginally copyleft.

> 3) Your advice to use The Sleepycat License if one needs strong copyleft
> is very problematic in several aspects.
>
> First, The Sleepycat License is not the classical copyleft that mandates
> the free nature of the derivatives. It fails on at least one important
> property of the classical copyleft (i.e. GPL or GFDL) that is code
> interoperability. It is too easy to create derivative works that are
> under incompatible terms (think about any license that speaks about
> available sources, but incompatible with GPL; there are many of these).
>
>   http://www.gnu.org/copyleft/copyleft.html
>
> Second, its use of "reasonable conditions" wording makes it too vague and
> open to all kinds of attacks. It is not even clear whether proprietary
> deriatives are allowed, and in which cases. I would say it has serious
> holes to be even considered Strong Copyleft. Anyone who uses this license
> for his own work should be prepared for it to be interpreted more as
> Permissive License than Copyleft License. Another problem of short
> license texts (see my point 11) is their ambiguity. It fully depends on
> the "common practive and interpretation". If it is interpreted as yet
> another all-permissive license then it shares all their problems that the
> classical copyleft tries to solve, including the license proliferation.
>

[citation-needed]

http://en.wikipedia.org/wiki/Sleepycat_License does not mention that. And the 
licences list at:

http://www.gnu.org/philosophy/license-list.html#BerkleyDB

Says just:

<<<<<<<<<
This is a free software license, compatible with the GNU GPL.

Without any warning such as the ISC Licence's:

<<<<<<<<<
This license is sometimes also known as the OpenBSD License. It is a free 
software license, and compatible with the GNU GPL. 

This license does have an unfortunate wording choice: it provides recipients 
with "Permission to use, copy, modify, and/or distribute this software...." 
This is roughly the same language from the license of Pine that the University 
of Washington later claimed prohibited people from distributing modified 
versions of the software. 

ISC has told us they do not share the University of Washington's 
interpretation, and we have every reason to believe them. Thus, there's no 
reason to avoid software released under this license. However, to help make 
sure this language cannot cause any trouble in the future, we encourage 
developers to choose a different license for their own works. The Expat 
License and FreeBSD License is similarly permissive and brief.

Furthermore, according to this interview with the SleepyCat CEO - 
http://www.winterspeak.com/columns/102901.html - SleepyCat has been 
"profitable since inception" and been exempting vendors of embedded and 
proprietary software from using its Berkeley DB product (and later products 
based on it) for a pay, while still maintaining it as FOSS under the SleepyCat 
licence. I do not rule out that some entities have violated the spirit of the 
SleepyCat licence. But it seemed to have enough legal standing so many vendors 
acting out of good will (and the advice of their lawyers) to have sustained 
SleepyCat Inc. until Oracle bought it. Moreover, Berkeley DB was used by a lot 
of free software projects such as RPM, Subversion and others.

> So it is irresponsible to blindly suggest The Sleepycat License for every
> programmer without describing its multiple problems.
>
> On the contrary, the GNU GPL was written and verified by the best lawers
> and found not to contain any known hole, was proven to be enforceable in
> courts, and does not have interoperability problem mentioned above.
>

The GPL has huge interoperability problems. The GPLv2 is not compatible with 
the Apache licence, the GPLv3, the LGPLv3 (!), the original BSD licence and 
many other licences. See:

http://www.gnu.org/philosophy/license-list.html

> 4) To say "GPL v3 has more restriction than v2" is to show ignorance on
> the topic. All GPL versions implement the same idea that was not changed
> since its start (enforce the four software freedoms for any evolution of
> the program). Just some bugs were fixed for the changed reality.

The GPLv3 also has some additional restrictions against the so-called "tivo-
isation", more patents stuff, etc. If it doesn't have any extra restrictions, 
then why isn't it compatible with GPLv2-only-licensed software?

>
> 5) All classical copyleft license are incompatible between themselves,
> on purpose. The way to make them compatible is by adding explicit
> relicensing permission (say GPL v3 and AGPL v3 are mutually compatible).
> Or dual licensing, including the "or later" tip.

The LGPLv2.1 or LGPLv3 is a (weak) copyleft license that aims to be compatible 
with as many licences as possible. By "classical copyleft" do you mean "strong 
copyleft" by any chance?

>
> 6) Your comments about Affero GPL are unfounded. It seems you think that
> this license is applicable to any normal (desktop) program. It is not. It
> is only applicable to a special program that was designed (and was born
> from the start) as a network interface (like web service) _and_ has a
> functionality to download its own source code over network. Then it is
> believed that removing this functionality in deriative works would mean
> turning such free software service into a non free software service, that
> would indicate a hole in Strong Copyleft in a multi-computer environment
> and in ability to enforce providing the four freedoms to users.
>
> There are cases when no other license alternatives for web services
> (designed to be free and trustful) exist other than AGPL. No sane user
> would/should use "Online Secure Voting" or other services if he can't
> verify its sources first. Including you. So please either remove your
> advice to avoid non-FOSS licenses, or remove your prejudice against AGPL.

This is a:

http://www.nizkor.org/features/fallacies/ad-hominem-tu-quoque.html

I didn't recommend people to avoid non-FOSS-licenses - instead I said that it 
was out of the scope of this document. If someone wants to create non-FOSS 
software because they're not happy with the Free Software Definition and/or 
the Open Source Definition, then I wish them success, but I specifically said 
it was out of the scope of the document. I specifically could not give them 
any further advice, due to lack of knowledge in phrasing such licences. 

Regarding the AGPLv3 : I can always deploy an AGPLed application on my 
servers, hack it so it will still send the original code, and change it to my 
heart's content. A violation of the licence, but it would be hard to prove. So 
where is your secure online voting system's security now that the licence was 
violated unbeknownst to everybody else. Good security should be made available 
by more measures than just legal ones, and this can be applied to BSD-style 
software too, and certainly to the GPL.

As for the AGPLv3 : If I deploy a software on my servers, then I want to be 
able to modify it for my use without the need to share my modifications with 
the outside. This includes writing a configuration file (possibly with 
passwords), installing plug-ins, fixing bugs internally without releasing 
them, etc. The AGPL aimed to close the "Application Software Provider (ASP) 
loophole" for many programs that are much lower profile than a voting system. 
Using it on a server will cause risk that everything you run based on it will 
be exposed to the world-wide-world.

As a result, I don't consider the AGPL a free licence according to the way I 
interpret the Free Software Definition. However, other people may interpret 
the Free Software Definition differently and consider it free, and that is 
within their right. 

>
> 7) You always use "Licence" spelling when you refer to the licenses, even
> if the official names have "License" spelling. I would not do this.
>

Granted. This will be remedied in the second revision, when and if I get to 
write one.

> 8) To advocate one MIT license in all cases is not wise. Then you would
> better start to advocate Loosy Software (5 freedoms, the fifth is to be
> able to convert to a closed source) and not Free Software (4 freedoms).
>

I'm not very interested in another GPL-vs-BSD war. I prefer using the X11 
licence for all programs that I write, regardless of their intended use, 
audience or whatever. Other people like to use different licences in different 
contexts (or GPL-only, etc.). What I said in the "Why I prefer the X11L" was 
that this was my personal preference, and that I tried to explain why. You are 
free to disagree, and explain your reasons when you think each licence is 
appropriate, and if I like them, I may incorporate them in the next edition of 
the article.

> 9) Unfortunately the section "Bad Idea No. 6: Using the GPL or the LGPL"
> deeply places the whole article into the troll category. It seems you
> are very confused. On one hand you use the Free Software definition by
> FSF, and on the other hand you dismiss the licences that implement this
> FSF definition in the most optimal, practical and preserving way.
>
> This section also sounds as FUD. If you don't understand GPL as you say
> (although it is crystal clear; enforce the 4 software freedoms for any
> evolution of the program, using legal language), you should not write an
> article about FOSS Licenses and start unneeded wars. Sorry to say this.
>

Isn't it again an 
http://www.nizkor.org/features/fallacies/ad-hominem-tu-quoque.html ? 
While I did not understand the GPL's text, I do understand most of its 
implications, and I don't like them. I know GPLv2 is incompatible with GPLv3 
and with LGPLv3 and that both the GPLv2 and the GPLv3 are incompatible with 
many other free software licences. I also was told that the LGPL requires that 
all programs linking to it will be allowed to be reverse engineered, and that 
it was otherwise extremely complicated.  

> 10) "I had no problem understanding the Sleepycat licence, the Perl
> Artistic licence [...]".
>
> As you see, you did have problems understanding the Sleepycat licence and
> the Perl Artistic licence. And you say you didn't read LGPL and GPL v3.
> Yet you feel the need to strongly advise on the licenses to other people.
>

I don't think I do.

> 11) It is not true that shorter license texts are better. The way short
> permissive licenses work is only because of the common practice of using
> these licenses, without which their short text would be inadecvate.
>

I agree on principle that shorter may not be better. But what's wrong with the 
MIT/X11 licence? It specifically allows sub-licensing for example.

> If you don't believe me, think about claims of OpenBSD people some years
> ago that all boiled down to different interpretation of this short text.

URL, please.

> I.e. if the text does not mention a possibility to "effectively
> relicense" the derivative code or modifications, then it is not allowed.
> However it is a common believe that it is allowed and this is what makes
> these licenses permissive. Before you start to argue, please read this
> document fully and thoroughly that uses "historical community practice",
> "uninterrupted, longstanding practice" as the only argument for
> compatibility between short permissive licenses and GPL:
>
>  
> http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.htm
>l
>

Hopefully, I'll read it later, but I have other priorities.

> So a shorter text just means more ways for different interpretations. A
> clear explicit explanation of all use cases is always less problematic.
> Specifically, explaining the idea under the license in the license text
> makes it more clear and helps to avoid incorrect interpretations.

OK.

Regards,

	Shlomi Fish

>
> P.S. I am not subscribed to the first two lists, you are free to forward
> my message to all lists on which you advertise your article.
>
> Regards,
> Mikhael.

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
"The Human Hacking Field Guide" - http://shlom.in/hhfg

---

From: Shlomi Fish <[email-masked]>
Date: Tue, 01 Sep 2009 21:09:24 +0300

> Any comments will be welcome.

Replying to myself (while de-CCing Perl-IL) I'd like to note that in my 
coverage of the reasons of why I prefer public domain licences instead of weak 
copyleft or strong copyleft licences, I probably missed the one that was the 
most important for me. So this is a GPL-vs.-BSDL post.

I'll start with a little history. Back when I got my first computer - an 8088 
PC XT with two 5.25" 360 KB diskette drives, and no hard disk, I started 
programming in BASIC - first the one that came on the BIOS and then BASIC.COM 
or GWBASIC. (BASICA wouldn't run on my computer, for some reason). Back then, 
I programmed mostly games and my friends and I shared tips and programs 
between ourselves.

I took a long break in programming, and then started programming BASIC again - 
this time QBasic. Then I got my father to buy a C compiler and he bought me 
Turbo C++, which I used for somewhat more "serious" stuff than BASIC (though I 
still used QBasic). Back then I wrote two libraries-of-sorts - called CCalc 
(for various mathematical routines) and CSee (for graphics) which I intended 
to distribute as shareware. I don't recall if I wanted to include the source.

I've now made them, and some other C code from that era, available as FOSS at:

http://www.shlomifish.org/open-source/nostalgia/

In any case, back then we were used to the fact that we have to pay for our 
software, so I probably thought that making these libraries public-domain was 
not worth it. 

After I started getting into the world of UNIX, Linux, GNU, and open-source I 
realised there was a lot of software out there distributed with the source, 
which I could download and compile. I used to think of prep.ai.mit.edu (the 
old primary FTP host for gnu.org) as a cool collection of source code, which I 
could download, read the INSTALL file, build and install (sometimes after 
fixing the source). I wasn't interested in the implications of its FOSSness or 
the GPL licence. I also downloaded other software. I did know the software was 
gratis, as opposed to MiniSQL/mSQL which was sourceware and shareware, and it 
was good enough for me.

After I became more involved and started playing with Linux for developing 
software on it, I learned even more and understood what "free (as in speech) 
software" or as it was later called open-source software was all about. One 
thing I understood back then, was that it took me a long time to fully get to 
the bottom of all the GPL's nuances, and that I thought the public domain was 
preferable, because I didn't care too much about people changing the licence 
to something else, or using it in their own non-free/non-GPL-compatible 
software. A lot of people I have talked with since have shown some mis-
understandings of the GPL.

In any case, I had initiated some FOSS projects under the public-domain which 
didn't amount to a lot. I also wrote a patch for GIMP (see 
http://www.shlomifish.org/grad-fu/ ) which I made available, but has since 
taken some other iterations and incarnations to be embedded. And then I 
released Freecell Solver (originally under the Public Domain - now MIT/X11) 
and did a lot of extensive work on it, and then started some other moderately 
successful MIT/X11 projects, or contributed to or adopted FOSS projects under 
various licences.

So why am I still sticking with the MIT/X11? The main reason I think is that 
as an open-source programmer, I'm not interested in worrying about how people 
abuse my code. I don't like Apple, and am not fond of many Microsoft products. 
But I'm not interested to prevent Apple or Microsoft or any other developer of 
commercial and/or proprietary software for Windows or Mac OS X or the iPhone 
or whatever from using my code in their projects. In fact, I would prefer them 
to use my code than to create a proprietary replacement. Not to mention that 
making my code GPLed may also make it inappropriate for some developers of BSD 
software, BSD distributions, some developers of non-GPL-compatible-but-still-
free software, etc. I don't want that - I want my code to be of the maximal 
use possible.

I should note that I'm more worried about my code being used for malicious 
purposes by evil governments, as I think no big corporation in history has 
been as abusive as some past and present governments that come to mind. But 
preventing internal use or "defence use" or government use or whatever will 
make it non-FOSS, (and non-GPL-compatible), not to mention that adding random 
restrictions ("cannot be used by Neonazis", "cannot be used by terrorists", 
"cannot be used by 'Zionists'", etc.) will fragment the software world as a 
whole. 

Back to the topic: I don't want to be bothered about legal issues with my 
software. If you want to use my code - use it. "Drive safely, the keys are 
inside.". If you encounter any technical problems with the code (bugs, 
documentation issues, etc.) then I'd be interested to hear about them, because 
that will improve the quality of the product, which will hopefully make it 
even more successful. But I'm not a FOSS developer, so I can sue people for 
violating the licences of my works. I have better things to do with my time, 
that bring me much more benefit.

Now, on to the issue of whether developing BSD-style code makes me a "sucker". 
I covered it earlier in:

http://www.shlomifish.org/philosophy/computers/open-source/gpl-bsd-and-
suckerism/

(short URL - http://shlom.in/gpl-bsd-sucker )

In short, I don't see why contributing to one's neighbour (or the public at 
large), willingly and on one's free time (which may be called "donation", 
"philantropism" or even "altruism") and for a non-harmful cause can be 
considered as being a "sucker". Everybody is able to use GPLed software of 
various originators too free-of-charge or put it into good use in many legal 
and legitimate ways and yet you don't hear that often that people who develop 
GPLed software are "suckers".

I don't see myself as a sucker, just by allowing people (whether individuals, 
corporations, governments or any other organisations) to use my software in 
non-free contexts, and don't think anyone should say that the GPL is the 
"don't-be-a-sucker" licence because BSD-style licences are by implications 
"be-a-sucker" licence. I hate selfishness. (And I don't mean "rational self-
growth" or acting-out-of-one's-own-best-self-interest, which is what Ayn Rand 
meant in the book "The Virtue of Selfishness" - I discuss it in the link 
briefly).

Another argument that you can often hear against the BSDL was that the Linux 
kernel was more successful than the BSDs due to its GPLed licence. However, 
this is:

1. A post-hoc fallacy - http://en.wikipedia.org/wiki/Post_hoc_ergo_propter_hoc 
- just because Linux is more successful than the BSDs, doesn't mean that the 
licence was the main reason for it, or the only reason.

2. In accordance to #1 - may be attributed to other factors such as Linus 
Torvalds' leadership skills, the kernel's adoption of the Bazaar-style of 
development, the willingness of Linux distributions to use the GNU project's 
software by default as run-time, the cooler name, the lack of initial legal 
limbo that the BSDs had, etc. etc.

3. One can find examples to projects in other niches that have been very 
successful despite their permissive licences - Apache, X-Windows, SQLite, 
PostgreSQL, Python, libxml2, OpenSSH, etc. So extrapolating from one instance 
(the kernel) to everything is not scientific.

4. The BSD-based kernels and operating systems are doing fine, despite not 
being as popular as Linux. Often, people use code from efforts by BSD 
developers in Linux (e.g: OpenSSH or some of the OpenBSD wireless drivers that 
were adapted and integrated into the Linux kernel). So it's not as if, they 
have completely "lost".

-----------------------

While I'm still using GNU/Linux (Mandriva Linux Cooker in my case) because 
that's what I've grown accustomed to using, I would still like to play with 
some BSD derivatives and OpenSolaris. I'm also not planning on switching to 
gNewSense or one of the Free Software Foundation's endorsed "100% Free 
Distributions", because Mandriva is free enough for me.

To sum up, I'm not trying to dissuade you from licensing your software under 
weak copyleft or strong copyleft licences, but I'm still happy with my code 
being BSD-style. I'm glad to learn of any use someone has been making of it, 
and in the few times it has been used in commercial or proprietary contexts, 
it did not make me regret that I released it as FOSS. I hadn't wanted it to be 
an issue in the first place, and so it wasn't. Hakuna Matata.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Stop Using MSIE - http://www.shlomifish.org/no-ie/

---

From: Shlomi Fish <[email-masked]>
Date: Sat, 03 Oct 2009 15:48:53 +0200

Hi Mikhael!

On Sunday 30 Aug 2009 02:51:47 Mikhael Goikhman wrote:
> On 28 Aug 2009 21:39:14 +0300, Shlomi Fish wrote:
> > Hi Mikhael!
> >
> > Thanks for your comments and sorry for the late response.
> 
> No worry about the late response, mostly because I didn't see much to
> discuss here. You wrote a somewhat provocative article advising against
> major FOSS licenses, so I just needed to defend the FOSS licenses.
> 
> However, if you are honestly open to learn facts and opposite opinions,
> we may hold a short discussion. The anti-GPL arguments you used are
> actually as old as GPL itself (20 years) and are quite easy to parry.
> This is mostly already done in GPL FAQ:
> 
>   http://www.gnu.org/licenses/gpl-faq.html

I read parts of it and it does not answer them successfully. I also think that 
having such a long document (even longer than the licences which are 
themselves very long), is a big red flag that it is over-complicated.

> > Many people are using the GPL, because it was recommended by their
> > friends, while actually desiring a weak copyleft or even a permissive
> > licence.
> 
> To suggest that many people want to yield all their rights granted by
> Copyright Law and to use permissive license would not be right.
> However to suggest that their friends recommend GPL because it has no
> problems would be more correct.

I don't understand. Many people who are new to the FOSS world release programs 
that they wrote under the GPL, without being fully aware of its implications, 
from various reasons. How they actually want people to use their software may 
be very different from the implications of the GPL. Like they may not mind 
people closing derived versions of the source under a different licence. Or 
they don't want the various anti-patent clauses of the GPL. Or they want 
something that is a weak copyleft licence. I already talked with someone who 
wanted to use the GPL, and after I asked him what he want, it was actually 
weak copyleft.

Many people just hear about the GPL licences online and believe the hype about 
them, don't investigate what their implications are and so end up using them.

> 
> > And now the OpenBSD project wants to replace most GPL software with
> > permissive, BSD-style licences (specifically the ISC licence, I
> > believe).
> 
> Good luck to this purely political action of BSD people. I predict it
> will fail in the whole, although they may replace 3-4 projects from
> 100000.

I don't know the scope of this replacement. In any case, most GPLed software 
out there is of little interest to anyone, or have permissively-licensed 
alternatives that are good enough, so that would be good enough. The user-land 
of the BSD distributions have already implemented a lot of the features of the 
GNU user-land. 

> 
> OpenBSD developers have some respect from me, mostly because they
> refuse to include non free software drivers. But they are still not too
> high on my scale, because their principles are somewhat twisty. They
> had an opportunity to be listed on the GNU site as a fully free OS, but
> explicitely refused to do the needed thing, i.e. to stop to include or
> advertise non-free software (in one or another way, being it optional
> packages/ports or on the web site). Developers who knowlingly choose
> GPL for the sake of free software have more respect from me.

Well, arguably this is besides the point of the GPL suitability for other 
projects, and whether it encourages duplicate effort or not. But to answer 
your question - the FSF is far too picky and fanatical about its choice of 
what is a "100% Free Distribution". From my understanding, the FSF does not 
even want to have references or mentions of non-free-software anywhere, or 
that there will be repositories of non-FOSS software. This seems way too 
irrational and impractical.

The following popular Linux distributions - Debian, Ubuntu, Mandriva, Fedora, 
openSUSE, Gentoo, Archlinux, Slackware - none of them are free enough for the 
FSF's tastes, and instead it has the following list - 
http://www.gnu.org/distros/free-distros.html - of incredibly obscure 
distributions, and gNewSense which is based on Ubuntu, only to exclude the 
non-free stuff.

> 
> > What in your opinion makes the GPL superior in that case?
> 
> The superiority of GPL (and its family) over other licenses is well
> known. Anyone who is willing to have more free software chooses this
> license. It is the BSD people who should justify their "need" to
> replace free software just on the sake of easier serving non-free
> software, or out of the not-invented-here syndrom.
> 

Sorry, I lost context. Next time, please don't trim the message so much.

> > [skipped to reduce message length]
> >
> Artistic License may sound more copyleftish than MIT license, but it is
> not at all. Not because wikipedia says this, but because of the actual
> intend of the license, that is just to disallow you to call it Perl if
> you removed brases {} from the syntax and added
> leading-whitespace-counter instead, but you may call it Pyrl.
> 
> The redistribution "limitation" only says that I can't redistribute
> Freecell Solver (in binary way) with my modifications without specifying
> that I modified it, or alternativelly I can rename it to Opencell Solver.
> That is all. It does not mandates me to show the modifications as
> required by weak or strong copyleft.
> 
> And if Freecell Solver is distributed under MIT, then I (not the original
> author) may supposedly make my own distribution (in binary way) and just
> name it Freecell Solver that will compete with the original distribution.
> 

Interesting. Thanks for the clarification.

> > > 3) Your advice to use The Sleepycat License if one needs strong
> > > copyleft is very problematic in several aspects.
> > >
> > > First, The Sleepycat License is not the classical copyleft that
> > > mandates the free nature of the derivatives. It fails on at least
> > > one important property of the classical copyleft (i.e. GPL or GFDL)
> > > that is code interoperability. It is too easy to create derivative
> > > works that are under incompatible terms (think about any license
> > > that speaks about available sources, but incompatible with GPL;
> > > there are many of these).
> > >
> > > Second, its use of "reasonable conditions" wording makes it too
> > > vague and open to all kinds of attacks. It is not even clear
> > > whether proprietary deriatives are allowed, and in which cases.
> > > I would say it has serious holes to be even considered Strong
> > > Copyleft. Anyone who uses this license for his own work should be
> > > prepared for it to be interpreted more as Permissive License than
> > > Copyleft License. Another problem of short license texts (see my
> > > point 11) is their ambiguity. It fully depends on the "common
> > > practice and interpretation". If it is interpreted as yet another
> > > all-permissive license then it shares all their problems that the
> > http://en.wikipedia.org/wiki/Sleepycat_License does not mention that.
> 
> I don't think that anyone may say much for sure about the nature of
> Sleepycat License, just because there are almost no software using it,
> so there are no much "common practice and interpretation".
> 
> The only interesting thing about this license is that with one or another
> interpretation that makes any sense it seems to be compatible with GPL.
> But whether it is weak or strong copyleft or just yet another permissive
> license can't be easily deduced directly from just the license text. You
> yourself in your article suggest that proprietary derivatives seem to be
> allowed. Noone can prove or disprove this without the court case.
> 
> One thing is clear - this license is more than vague in nature and as
> such should not be recommended. It is just much better if the license
> just explicitely describes its nature and common use cases, so noone
> should ever guess.
> 
> If you really care about the sane interpretation of this license, ask
> RMS. He usually answers such questions in a matter of days.
> 
> Other people thinking this license is "vague":
> 
>  
>  http://snk.tuxfamily.org/web/2007-05-02-copyleft-variation-of-mit-license.
> html
> 
> Of course I would strongly suggest to this guy just to use LGPL here
> that does exactly what he wants, instead of inventing yet another vague
> license, but this is another story already.

I see. 

> > [skipped]
> > Moreover, Berkeley DB was used by a lot of free software projects such
> > as RPM, Subversion and others.
> 
> As a library. Without modifications. By good players. Nothing is clear
> if any of these conditions are not satisfied. To suggest this license
> for arbitrary FOSS, as you did, is problematic and IMO irresponsible.
> 
> > > So it is irresponsible to blindly suggest The Sleepycat License for
> > > every programmer without describing its multiple problems.
> > >
> > > On the contrary, the GNU GPL was written and verified by the best
> > > lawers and found not to contain any known hole, was proven to be
> > > enforceable in courts, and does not have interoperability problem
> > > mentioned above.
> >
> > The GPL has huge interoperability problems. The GPLv2 is not
> > compatible with the Apache licence, the GPLv3, the LGPLv3 (!), the
> > original BSD licence and many other licences. See:
> 
> If you call these problems, then Sleepycat License has all of them too.

No, the Sleepycat licence is compatible with all the GPLs, the Apache License, 
the MPL and most other open-source licences. For example, Subversion ( 
http://subversion.tigris.org/ ) which was under the Apache Licence, made use 
of Berkeley DB, which is under the Sleepycat licence. 

> If you write MPL derivative and Apache License derivative, they will be
> incompatible between themselves, nothing new here. And I don't even
> speak about future version 2 of this license that will be incompatible
> with the current version.

Isn't the MPL a weak copyleft licence, that allows code from other licences to 
link against it? Or I didn't understand you.

> 
> You omit one important thing. All classical GPL projects (that use
> "or later" tip mentioned in the license itself) are compatible between
> themselves, there is no need to invent unexisting problems.
> 

Right. But not all GPL projects use the "or later" clause. Many are GPLv2-only 
:

http://freshmeat.net/tags/gnu-general-public-license-v2

As such, they are incompatible with GPLv3-or-later code.

> So it is always possible to share code between classical GPL projects,
> since all of the parts are under compatible licenses (MIT, LGPL, GPL).
> But this is not guaranteed at all in the world where Sleepycat License
> partially replaced GPL as of your advise. Then we would see real (not
> invented) interoperability problems and license proliferation.
> 

What? Why? You can use code under the BDB licence from GPL-licensed, X11L-
licensed, LGPL-licensed, etc. code.

> > > the topic. All GPL versions implement the same idea that was not
> > > changed since its start (enforce the four software freedoms for any
> > > evolution of the program). Just some bugs were fixed for the changed
> > > reality.
> >
> > The GPLv3 also has some additional restrictions against the so-called
> > "tivoisation", more patents stuff, etc. If it doesn't have any extra
> > restrictions, then why isn't it compatible with GPLv2-only-licensed
> > software?
> 
> I refuse to call any of these "restrictions", because they only add to
> the freedom of the software, fixing holes to workaround copylef). And I
> suggest you to call it properly too, i.e. "fixes", making the license
> stronger against attacks. As a demonstration, adding patent termination
> clause makes several popular FOSS licenses compatible, so how can this
> be called restriction. Similarly with all other changes. Only the
> closed source proponents having anti free software agenda may call them
> restrictions. And we are not such people, I hope.
> 

I see them as things that add to the complexity of the licence, are more 
political and demanding in nature, and generally something that I don't like 
in a free software licence.

> > > relicensing permission (say GPL v3 and AGPL v3 are mutually
> > > compatible). Or dual licensing, including the "or later" tip.
> >
> > The LGPLv2.1 or LGPLv3 is a (weak) copyleft license that aims to be
> > compatible with as many licences as possible. By "classical copyleft"
> > do you mean "strong copyleft" by any chance?
> 
> By "classical copyleft" I mean any license that mandates the same terms
> for the direct derivative work (LGPL, GPL, AGPL, GFDL, MPL or similar).
> Some of them were designed to be compatible, just like I said.
> 

OK. You didn't phrase yourself properly.

> > > 6) Your comments about Affero GPL are unfounded. It seems you think
> > > that this license is applicable to any normal (desktop) program. It is
> > > not. It is only applicable to a special program that was designed (and
> > > was born from the start) as a network interface (like web service)
> > > _and_ has a functionality to download its own source code over network.
> > > Then it is believed that removing this functionality in deriative works
> > > would mean turning such free software service into a non free software
> > > service, that would indicate a hole in Strong Copyleft in a
> > > multi-computer environment and in ability to enforce providing the four
> > > freedoms to users.
> > >
> > I didn't recommend people to avoid non-FOSS-licenses - instead I said
> > that it was out of the scope of this document. If someone wants to create
> > non-FOSS software because they're not happy with the Free Software
> > Definition and/or the Open Source Definition, then I wish them success,
> > but I specifically said it was out of the scope of the document. I
> > specifically could not give them any further advice, due to lack of
> > knowledge in phrasing such licences.
> 
> Ok, I accept this. I would like to reword what I said: Please either
> remove your advice to use FOSS or remove your prejudice against AGPL.
> Sorry, if it sounds the same, just reworded, but it is just that
> simple. If you believe free software is good, then anything that
> intensifies the software freedoms (like AGPL) is good too.

Well, let me clarify my position. I think that releasing any program to the 
public is a good thing, but naturally, the more liberal the licence - the 
better. If you want to release a program you wrote under the Microsoft Windows 
Vista Home Basic EULA, then all the power to you - it's better than had you 
kept it for yourself. I wouldn't get near this code with a ten-foot pole, but 
some people may opt to.

Now, if you want to release a program under the AGPL, then I won't prevent you 
from doing this. Some people may consider software under this licence free, 
and it is still better than a closed-source program or a program that was not 
released either. But I won't get near it either.

Which licences I consider free or not have little do with my desire to 
encourage people to release code they wrote to the wild, preferably under 
licences that are as liberal as possible, so people can benefit. 

> > As for the AGPLv3 : If I deploy a software on my servers, then I want
> > to be able to modify it for my use without the need to share my
> > modifications with the outside. This includes writing a configuration
> > file (possibly with passwords), installing plug-ins, fixing bugs
> > internally without releasing them, etc. The AGPL aimed to close the
> > "Application Software Provider (ASP) loophole" for many programs that
> > are much lower profile than a voting system.  Using it on a server
> > will cause risk that everything you run based on it will be exposed
> > to the world-wide-world.
> 
> This fear, uncertainty and doubt argument was started by paranoid
> people when GPL v3 was only in plans.
> 
> The reality is you are never ever supposed to yield your passwords and
> configurations. This is against common sense and no license may ever
> ask you to do such things.
> 
> If you don't trust some application and think it may do malicious things
> (regardless of its license), just don't use it. If you think an
> application has some bugs sending passwords, then just fix these bugs,
> this will be in full compliance with any FOSS license, including AGPL.

Not sure I understand.

> 
> > As a result, I don't consider the AGPL a free licence according to
> > the way I interpret the Free Software Definition. However, other
> > people may interpret the Free Software Definition differently and
> > consider it free, and that is within their right.
> 
> I still have all reasons to think your arguments are unfounded.
> 
> There is no really difference between GPL and AGPL in the intend. GPL
> similarly has a clause that if the original program has a way to tell
> users that this is a Free Software program (say, using --help or
> --license option) then you can't remove this principal mentioning (but
> you may of course provide an alternative). This clause is perfectly
> acceptable by OSI, Debian and others. AGPL is just a very similar by
> intend clause.

Doesn't AGPL also require the server to send the modified code to the client?

> > I'm not very interested in another GPL-vs-BSD war. I prefer using the
> > X11 licence for all programs that I write, regardless of their
> > intended use, audience or whatever. Other people like to use
> > different licences in different contexts (or GPL-only, etc.). What I
> > said in the "Why I prefer the X11L" was that this was my personal
> > preference, and that I tried to explain why. You are free to
> > disagree, and explain your reasons when you think each licence is
> > appropriate, and if I like them, I may incorporate them in the next
> > edition of the article.
> 
> For most of the application GPL is the best. It increases sharing.
> 
> However, as FSF itself says, using the ordinary GPL is not advantageous
> for every software/library. There are reasons that can make it better
> to use the Lesser GPL in certain cases. And sometimes even to use
> permissive licenses iff it solves more serious problems than non-free
> software, like software patents. I.e. zlib and linpng are blessed by
> FSF to be under a permissive license.

Well, in my case, I have released all my software under the X11L (and 
previously the pure "Public Domain", however defined). So far it worked 
perfectly well: I've had many users, many contributors or people who commented 
on it or asked me for questions about it, or emailed me to thank me about it; 
some of my programs have also been integrated in some larger works - both FOSS 
and non-FOSS; and some of them have been re-distributed by FOSS distributors.

I have yet to find a problem domain for which I ended up choosing a more 
restrictive licence. I respect people who opt to use weak-copyleft or strong-
copyleft licences (like I respect developers of non-free or not-entirely-free 
software), but so far I didn't find a need for anything copyleft.

> 
> > > 9) Unfortunately the section "Bad Idea No. 6: Using the GPL or the
> > > LGPL" deeply places the whole article into the troll category. It seems
> > > you are very confused. On one hand you use the Free Software definition
> > > by FSF, and on the other hand you dismiss the licences that implement
> > > this FSF definition in the most optimal, practical and preserving way.
> > >
> > > evolution of the program, using legal language), you should not write
> > > an article about FOSS Licenses and start unneeded wars. Sorry to say
> > > this.
> >
> > Isn't it again an
> Any technical argument (including mine) that uses some kind of logic
> may be presented as AHTQ. Seems useless for me, if I can't suppose you
> are a free software supporter and are not a hypocrite.
> 
> And once I suppose this, and we both agree that GPL is just a technical
> legal way to enforce software freedoms for any evolution of the program,
> then it becomes very unclear for me why you wrote this section. How would
> you express my feelings in a different way?
> 

Well, I dislike the GPL and LGPL due to their inherent complexity, their lack 
of compatibility with many other licences and their additional restrictions 
above the general spirit of copyleft. That's why I recommended against them. 

My recommendation against them does not invalidate the entire article as a 
whole.

> > implications, and I don't like them. I know GPLv2 is incompatible with
> > GPLv3 and with LGPLv3 and that both the GPLv2 and the GPLv3 are
> > incompatible with many other free software licences.
> 
> And if we exclude this incompatibility argument, since as I said, this
> is an invented problem? GPL has revisions, this is known for anybody in
> advance, this should not come at surprise. The how-to-apply part of the
> license itself suggests the perfect solution for this. Most of the GPL
> software uses this solution (including about 60% of linux kernel code)

the other 40% of the Linux kernel code is not exactly negligible or easy to 
re-implement again. 

> that is "or later" wording. So this is not a problem, or at least a
> perfectly solvable problem. And many FOSS advocates think similarly:
> 
>  
>  http://itmanagement.earthweb.com/osrc/article.php/12068_3803101_2/Bruce-Pe
> rens-How-Many-Open-Source-Licenses-Do-You-Need.htm
> 
> It would be much more productive if people just stopped this invented
> "GPL is not compatible" argument. Most of the FOSS lincenses in actual
> use are compatible with the latest GPL revision, just accept this fact.

I still think that the fact people can make code GPLv2-only or GPLv3-and-
above-only (or GPLv3-only) incurs mutual incompatibilities between them, and 
that's not a good thing. This prevents code re-use and puts legal and 
artificial problems in re-using other people's code, that stand against the 
Hacker Ethics which says that "No problem should ever have to be solved 
twice":

http://catb.org/~esr/faqs/hacker-howto.html#believe2

> 
> > I also was told that the LGPL requires that all programs linking to
> > it will be allowed to be reverse engineered, and that it was
> > otherwise extremely complicated.
> 
> Reverse engineering is only needed to allow modifications of the LGPL'd
> library itself used by (included by) the proprietary program. Doing
> reverse engineering for any other purpose is out of the scope.
> 
> And if you already speak about "reverse engineering", then it is both
> legal in most of countries and morally ok. And has nothing to do with
> LGPL, of course, but with proprietary programs that need this at all.
> 
> If you are not a lawer, then instead of calling LGPL complicated, you
> may just ask a lawer about it, he will most certainly appreciate the
> clear explicit legal language used to explain all use cases.
> 
> LGPL is actually what most of the people, willing to create non
> all-permissive free software, while still allowing proprietary
> programs, want and need. Anyone who thinks to invent a weak copyleft on
> top of MIT should better just use LGPL instead, and save the large
> legal work done to make LGPL work without problems.

OK.

> > > As you see, you did have problems understanding the Sleepycat licence
> > > and the Perl Artistic licence. And you say you didn't read LGPL and GPL
> > > v3. Yet you feel the need to strongly advise on the licenses to other
> > > people.
> >
> > I don't think I do.
> 
> Does not your article advise against many [major] FOSS licenses?
> 
> This is really a problem. Most of the people (and FSF) would not say
> you a word about your usage of MIT for your code, as long as it is free
> software. So why do you tell other FOSS developers that they did
> something wrong choosing more appropriated for them licenses?

The GPL and the LGPL are still better than nothing, and people who release 
software under them should be commended. Sometimes, they are good enough. 
However, I think a better choice would be to use copyleft licences (both weak 
and strong) that are less complicated, easier to understand and less political 
in nature.

And some people have criticised my choice of the X11 License, like implying 
that I was a sucker (or "פראייר" in Hebrew) see:

(short URL: http://xrl.us/bfp7sj )

Some people claimed I was doing the world a dis-service and that I was not 
behaving altruistically enough by making my software X11L, because people can 
prepare derived non-free works.

So I have been criticised for it as well.

> > > permissive licenses work is only because of the common practice of
> > > using these licenses, without which their short text would be
> > > inadecvate.
> >
> > I agree on principle that shorter may not be better. But what's wrong
> > with the MIT/X11 licence? It specifically allows sub-licensing for
> > example.
> 
> The MIT License contains this wording about sublicense and some other
> common use cases, but BSDL does not contain it. You are free to verify.
> So MIT License is relatively explicit, and this is a good thing.

OK. :-)

Yes, I realise the BSDL does not contain an explicit language about sub-
licensing. 

> 
> > > If you don't believe me, think about claims of OpenBSD people some
> > > years ago that all boiled down to different interpretation of this
> > > short text.
> >
> > URL, please.
> 
> http://www.linux-watch.com/news/NS2902106404.html
> 
> > > relicense" the derivative code or modifications, then it is not
> > > allowed. However it is a common believe that it is allowed and this is
> > > what makes these licenses permissive. Before you start to argue, please
> > > read this document fully and thoroughly that uses "historical community
> > > practice", "uninterrupted, longstanding practice" as the only argument
> > > for compatibility between short permissive licenses and GPL:
> > >
> > > http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration
> > >.html
> >
> This document explains how to "effectivelly relicense" the evolved code
> (i.e modifications) from a permissive license into GPL, and it lists
> several different ways, the most radical is to add a GPL header on top
> of BSDL header.
> 
> So, basically, linux kernel developers had valid ways to evolve the
> code under GPL, but they decided to be nice to OpenBSD brothers.
> 
> There were too many claims from some BSDL supporters that changing the
> license is just not allowed, since BSDL does not allow any relicensing,
> and the code once BSDL-ed always stays such.
> 
> This is a very valid and understandable willing, but the wrong tool
> (BSDL) is choosen for this. LGPL would suit this willing nicely.
> 

Right.

> This message is lengthy, but it should still weight less than the
> parent message, since you posted it in html, making it more than 3
> times bigger than needed.

Yes, that was a mis-configuration of KMail, that has been fixes since then.

Happy Sukkoth!

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
"Star Trek: We, the Living Dead" - http://shlom.in/st-wtld

Chuck Norris read the entire English Wikipedia in 24 hours. Twice.