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 > On Saturday 22 August 2009 18:31:38 Mikhael Goikhman wrote: > > On 21 Aug 2009 19:58:13 +0300, Shlomi Fish wrote: > > 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. > 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. 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. > 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. > > 2) Your catalogizing of Artistic License as weak copyleft is false. > > Noone (except for you) considers it copyleft, see wikipedia. > > According to: > > [skipped to reduce message length] > > 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. 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. > > 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 > > practice 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. 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. > Furthermore, according to this interview with the SleepyCat CEO - > [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. 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. 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. 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. > 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 > "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. > > 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? 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. > > 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. 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. > 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. It is not that hard to prove. May be done by anyone having access to the server/service. Just like unrelated people seeing crime (car assident, robbery) tend to call police. It is very hard to keep secret even under authoritaric regimes, not to speak about the world where people search sensations. > 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. I said that the original free software service was trustful and verificable by security experts. In my example, AGPL helps to keep the original security level in the long run. Other licenses do not. Of course verifiable security is just one property of FOSS, other benefical properties of FOSS may be used as a pro-AGPL argument too. > 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. > 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. > > 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. 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. > > 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 ? 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? > 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. 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) 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-Perens-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 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. > > 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. 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? > > 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. 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. > > 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 > > 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 > > Hopefully, I'll read it later, but I have other priorities. 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. > > 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. 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. Regards, Mikhael. _______________________________________________ Discussions mailing list [email protected] http://hamakor.org.il/cgi-bin/mailman/listinfo/discussions
