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. > > > 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. 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. > > > 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. > 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). > > > > > > 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. I see. > > > 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. 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. > > 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. > 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. > > > 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. > 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. > > > > > > 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. 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? > > > > 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. 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. > > > > > > 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? > 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. > > 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) 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. > > > > 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? 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: http://www.shlomifish.org/philosophy/computers/open-source/gpl-bsd-and- suckerism/ (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. > > > > 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. 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 > > > > 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. > Right. > > > 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. 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. _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
