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: > > 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. 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 God gave us two eyes and ten fingers so we will type five times as much as we read.
_______________________________________________ Discussions mailing list [email protected] http://hamakor.org.il/cgi-bin/mailman/listinfo/discussions
