On 21 Aug 2009 19:58:13 +0300, Shlomi Fish wrote: > > 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.
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). 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. 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: http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html 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. Regards, Mikhael. -- perl -e 'print+chr(64+hex)for+split//,d9b815c07f9b8d1e' _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
