New Essay - "FOSS Licences Wars"
migo at homemail.com
Sat Aug 22 18:31:38 IDT 2009
On 21 Aug 2009 19:58:13 +0300, Shlomi Fish wrote:
> I have published a new essay about free software licences:
> Any comments will be welcome.
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.
1) To use a term "Wars" together with "FOSS Licenses" is to seriously
misunderstand the topic. Different licenses are for different needs.
2) Your catalogizing of Artistic License as weak copyleft is false.
Noone (except for you) considers it copyleft, see wikipedia.
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 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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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:
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.
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.
perl -e 'print+chr(64+hex)for+split//,d9b815c07f9b8d1e'
More information about the Discussions