OSI exempt to GPL: advise requested
Hi, After bumping into some license incompatibilities (between GPL and OpenSSL) a few years ago, I've been using the BSD license. A recent discussion made me consider the following scheme: GPL license version 3 or higher with the following exemption: Notwithstanding any other provision of this GPL license, you have permission to dynamically link with a work licensed under an OSI approved license, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but not to the dynamically linked part. Rationally: you can dynamically link with any other open source library (http://www.opensource.org/licenses/), but not with proprietary code. Linking must be dynamic or using a clear API, as to keep a clear separation of the parts with a different license. I presume it is obvious what I try to do here: make sure the work remains in open source, but remove the license incompatibilities headaches that come with GPL (don't get me started on projects that use the GPLv2 license and forgot the or higher part -- you can't even combine that with GPLv3). Now, I am not a lawyer, and am reluctant to invent my own license, which is kind of what I do here. So my question is: is there an existing license which (roughly) does the above? I rather use that instead of fiddling with my own exempts. Thanks, Freek -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8e4cee.6080...@macfreek.nl
Re: CC Non-waivable Compulsory License Scheme (was: Anti-TPM clauses)
Francesco Poli wrote: Well, I made a detailed analysis of the issues I see in CC-by(-sa)-v3.0 licenses. http://lists.debian.org/debian-legal/2007/07/msg00124.html http://lists.debian.org/debian-legal/2007/03/msg00105.html Just saying that they are in spirit the same as GPL is *not* a convincing rebuttal of my arguments, sorry. Other replies seen on this list are not convincing rebuttals either. Francesco, While I don't think I can remove you worries on the anti-TPM, especially not if CC has not elaborated on it, I maybe can clarify a bit on one other part of the CC: The Non-waivable Compulsory License Schemes. In Dutch law, I know of at least one example. In the Netherlands, it is legal to make a copy of a work *for strict personal use*. So, for example, it is indeed legal to download MP3 from file-sharing (p2p) sources, as long as you only use it personally (So it is illegal to distribute them though!) This was done to allow sharing of a book or DVD with your neighbour. Obviously, this law was created before any P2P software existed. However, the law does have a circumvention to compensate authors of works: we pay a fee for each media we buy. So there is a tax on blank tapes, CDs and DVDs, which everyone pays, even if you use the CD to burn a Debian distrib, not copy your music. This fee is such a Non-waivable Compulsory License Schemes. I think author can get a piece of the money by registering at a certain society (Stichting Thuiskopie). According to the Dutch website of creative commons, the addition of this text in the CCv3 license is a clarification about these kind of fees. So it seems to me that CC does not make any more limitations or restrictions then those that are already there in the law (e.g. the restriction you can only buy blank CDs and DVDs if you pay a fee). So this part basically says we can't circumvent the law. Not much news there, so I would consider the CCv3 equivalent if it simply had this part removed. So in my view this is a non-issue. Hope this helps. I'm now stepping out of the discussion. Feel free to continue without me, but I think I said all there is to it (or at least all there is I know about it). Regards, Freek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CC Non-waivable Compulsory License Scheme
Francesco Poli wrote: What is not clear to me is: if Non-waivable Compulsory License Schemes are absurd things such as sort-of-taxes on virgin media (recordable CDs, DVDs, ...), why does the clause included in CC-v3.0 licenses talk about the right to collect royalties for any exercise by You of the rights granted under this License ? | i. Non-waivable Compulsory License Schemes. In those | jurisdictions in which the right to collect royalties through | any statutory or compulsory licensing scheme cannot be | waived, the Licensor reserves the exclusive right to collect | such royalties for any exercise by You of the rights granted | under this License; I fail to see any connection between buying a CD-R(W) and exercising the rights granted under the license... Hence I cannot understand how can those Non-waivable Compulsory License Schemes be things like sort-of-taxes on virgin media. This is simply how Creative Commons Netherlands explicitly describes it on their website: http://creativecommons.nl/2007/07/31/nieuw-versie-30-van-de-licenties/ Use Babelfish, along with these corrections: The first subheader is Specific clauses concerning collective rightsmanagement organisations. The first bullet says: Non-waivable Compulsory License Schemes (for example home copies [the thing I explained in my previous mail). Because [Dutch] copyright[law] does not permit author to distantiate from [waive, transfer] these rights, the [CC] licenses clearly state that the author retains these right for both commercial and non-commercial use. How I can collect these royalties, even for free work? - I make a MP3 of me singing some song, and distribute it under a CC license. - Now that I done that, I register myself as rights holder of the neighbouring rights at https://secure.sena.nl/senaregwizard/UI/WizardBasic.aspx?culture=en-GB (Depending on the type of work, I register at specific organisations: Stemra, LIRA, SENA, NVPI, VEVAM, Beeldrecht, Burafo, Norma, or SEKAM -- strangely NONE of these are specifically for software authors yet!) - Someone downloads my work, and burns it on CD. - This person uses a blank CD, which has a € 0.14 fee. - It is so hideous my work appears all over the place (people like to make fun of others). More people pay the € 0.14 fee per CD. - Stichting thuiskopie (association for collection of home copy fees), receives € 8.1 mln for blank CDs sold each year (the actual number is declining). - SONT (Association for Negotiation of Prices for home copies fees - yes there is a seperate association for that!) hires a bureau to do marketing research. - Marketing research shows that 82% of all burned CD's contains audio - 82% of € 8.1 mln goes to Audio-related rights associations. Of this amount 40% goes to authors, 30% to performers, and 30% to producers. - Thus SENA (society for distributing fees collected for neighbouring rights for music performers) receives 30% of 82% of 8.1 (= ~€ 2mln), for just blank CDs. They receive additional money from other fees. E.g. fees from public broadcasters who broadcasted my song. - SENA does some marketing research too, and acknowledge my song is real popular. I get my share of this 2 mln. Probably € 0.001 with my singing capabilities. Nothing can be done to stop this € 0.14 fee. I can waive my money by not registering at SENA, but that simply means this € 0.001 is distributed among other artists. *it still is collected*. This right to collect € 0.001 is non-waivable. Or in CC legal lingo: I retain the exclusive right to collect such royalties. It simply says that I don't transfer this right for you to claim the € 0.001. That's all there is too it. If you really don't like this non-waivable rights, complain with the politics. I actually suspect they listen, remove the rights, and in the mean time disallow making home copies and thus promote further DRM restrictions. As author, I follow this interpretation of the CC. As user, I follow this interpretation of the CC license. I suspect that in the case of a conflict, a judge will follow this interpretation of the CC license. If you still don't like it, by all means use your own license. Actually, you could do like the FSF: fight the system by using their own methods. There is nothing that can stop Debian from registering as a rights society, and as such could become a society to collect these non-waivable fees on behalf of the (open-source) software authors. Regards, Freek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anti-TPM clauses
Thanks for all the feedback! The majority of the discussion seems to have shifted to CC-BY-SA 3.0, even though my initial question was about GPL v3. Let me first summarize the comments on the creative commons discussion. Kudos to Olive for making the most useful distinction in this discussion: it is not about whether or not CC-BY and CC-BY-SA are free, but whether or not CC-BY and CC-BY-SA are free according to the DFSG. Are they *DFSG-free* or not? So yes, it *is* a GR-vote who decides here. Because the DFSG are only changed or clarified by such a vote. FYI, My personal opinion is that CC-BY and CC-BY-SA are clearly created with the intention of keeping a work available for other to build upon it, and are thus free or Freek-free, since it is my, Freek's, definition of free. (Hmm, that name a nice ring to it ;-) .). Clearly, Freek-free and Francesco-free are not equal. Not surprising: there is always a trade-off in freeness. We probably all agree that allowing someone to take existing work, claim it as his/her own, and exploit it is actually a freedom for that person. However, it is a freedom that we like to limit, to allow others to experience similar freedoms. Freedom is a trade-off, and so there are multiple definitions. Anyway, it is my opinion that the DFSG should be clarified, and allow CC licensed work in main. But for now, package authors should be cautious. Note that the discussion actually applies to both BY and BY-SA creative commons licenses: both have the anti-TPM clause, even though I only quoted BY-SA. OK, enough about CC. My original question was about GPLv3. I was utterly confused by an anti-TPM clause in there, and wondered how it differs from the CC anti-TPM clause. Ben Finney was kind enough to explain to me: The difference is: one is a restriction, the other is not. It [The GPL anti-TPM clause] is instead a declaration: the licensor, by choosing these license terms for a work, states explicitly that the work isn't an effective technological measure under copyright law. The intent is that this in effect prevents certain restrictive laws from applying to recipients of the work. I agree that in the legal wording, this is a big difference in approach: - The CC explicitly restricts derivatives with TPM (e.g. DRM'ed) - In the GPLv3 the author asserts that his/her work does not apply TPM. Correct? However, the GPL *does* restrict an author in the choice of license for derivative works: he/she can choose the GPLv3. So effectively, GPLv3 is forcing authors to assert that he/she does not apply TPM, and thus restricts authors not to use technology protective measures. So while the method is rather different, the end-result is exactly the same. At least, so it seems to me. So I asl my question again: In this light, doesn't that make GPLv3 just a free or non-free (in particular DSFG-free or DSFG-non-free) as CC-BY and CC-BY-SA? Regards, Freek (Wishing life was as easy as my disclaimer) -- Disclaimer: This is an e-mail message. Use your own judgment about its value. If you do not have such common sense (e.g. you are a lawyer) or you like to see crap like warranties, intended-audience or as-is statements, then the following applies: you do not understand the concept of satire and are not allowed to read this e-mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Anti-TPM clauses
Hi, The anti-TPM (technology protection measure, like DRM) in Creative Commons 3.0 has been extensively discussed on this list. Relevant part, in article 4a of http://creativecommons.org/licenses/by-sa/3.0/legalcode You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. There seem to be consensus that as long as there is no vote on it (similar to 2006_001), it's probably non-free, and best not put it in main. Correct? However, as a total non-lawyer type, I am confused about either the similarity or difference in another well-know anti-TDM clause: Relevant part, in article 3 of http://www.gnu.org/licenses/gpl-3.0.html No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures. Could someone please decypher this legal mumbo-jumbo (I can barely read the CC, but have a harder time reading this text!) and tell me how this is different from the creative commons anti-TPM clause. What is the correct conclusion: 1. This is the same. Both licenses are non-free 2. This is the same. Both licenses are free 3. This is clearly totally different. The difference is Confusingly yours, Freek Dijkstra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A short licence check
On 22-8-2004 14:58, Andrew Suffield [EMAIL PROTECTED] wrote: On Sun, Aug 22, 2004 at 02:51:39PM +0200, Igor Stroh wrote: could someone check this licence[1]? I believe it's somewhat BSD-like, but I'm not quite sure. It's the licence of python-gtk2-tutorial. Since there's no description of what kind of licence this actually is, I'm afraid the ftp-masters won't like it... This is a GPL-incompatible, copyleft, DFSG-free license. In other respects it is a MIT clone, not a BSD one; this is essentially a copyleft MIT license. Out of curiousity: What makes a licence GPL-compatible? In particular, why is this one not? I understand if it places additional restrictions the GPL does not have. But I didn't spot it here. That the upstream author does not like the GPL: OK, can do. However, writing hist own licence is indeed strongly discoureaged. There is so much already out there. Look at: http://www.gnu.org/licenses/license-list.html Regards, Freek
Re: [Spi-trademark] Re: Bug#265352: grub: Debian splash images for Grub
On 18-8-2004 08:22, Luis R. Rodriguez [EMAIL PROTECTED] wrote: Please arrange for your project to officially change the license. The project leader can do it by fiat (it is a simple thing, after all) or you can do it through your resolution process. Tell us when you are done. Anyone know who it is we are really supposed to be addressing this request to then? Debian-legal, any more advice? Luis, The resolution process is described in the Debian constitution (appendix A I belief), and involves getting a vote out: http://www.debian.org/devel/constitution http://www.debian.org/vote I'm not sure which project Bruce refers to when he talks about the project leader here. I assume the Debian project. Apparently. SPI will change the licence if the Debian project tells them to. Regards, Freek PS: I stripped most people from the cc. Feel free to strip more or add them again.
Re: Netatalk and OpenSSL licencing
On 13-8-2004 06:33, Josh Triplett [EMAIL PROTECTED] wrote: What annoys me propably most is that this simple licence is non-GPL compatible, and any software written with this licence is not allowed to be linked against GPL-software: This code may be freely modified, copied and distributed, so long as no fee is charged for it. (question 3, http://www.gnu.org/cgi-bin/license-quiz.cgi) That license is not only non-GPL-compatible, it is entirely non-free (by the DFSG, the OSD, and the FSF's criteria), so the GPL is doing its job there. You are correct. However, I strongly have the impression that still most people more or less think the same about it. First of all, the FSF does not push any idea of open software, and many members of the FSF will probably be quite vocal about that. :) See http://www.gnu.org/philosophy/free-software-for-freedom.html . That is a very good read. Thank you! For me, I did not make a distinction between open source and free software. All I wanted is contribute whatever I do back to the community. Likely, this is a moral aberration I got by being employed as scientist. I distinctly did not realize the difference, and only recently got shocked to notice that this not only existed, but it prevented me from integrating two pieces of open source software and give that back to the community. Especially the latter was shocking to me: I want to publish; give whatever is done back to the community. I want that to be possible for software I care about as well. I currently realize that whoever makes licences must do so extremely careful. After all, all I ever read what that line This code may be freely modified, copied and distributed, more or less ignoring the rest. I blame the GPL for not making it clearer in the first place what restrictions come with it, but instead push people away from the LGPL to the GPL. Just see the caption at http://www.gnu.org/licenses/why-not-lgpl.html They make the advantage clear (that's good), but they don't make the disadvantage clear enough. I blame the authors of the OpenSSL or whatever BSD-style licence as well. If they were ignorant of the fact that incompatibilities could exist, I blame them for making a licence without knowing what they're doing. If instead, they did know what they're doing, I blame them for making the incompatibilities by forcing the acknowledgements to be so prominent. Despite that, according to the GPL, it is still possible (and even obligatory) to get acknowledgement in the code. So by explictly designing GPL code to link against non-GPL code, the author *implicitly* gives the exception that the program may indeed be linked to this particular non-GPL code. The implicit exception has indeed been argued in the past. However, as that FAQ entry points out, it is better to make an explicit exception; otherwise, people who copy, modify, and distribute your software may be unable to know whether they are in violation of the license or not. Furthermore, how does that handle the case when the authors were not the ones to add the OpenSSL linkage (or not all of the authors were)? You are suggesting that the ability to link with GPL-incompatible code would only be usable by the authors (which is already the case). You are right -- as I understand now, the author who wrote the link with OpenSSL into netatalk was wrong to redistribute that additional code back to the community. At least, if the reasoning of the FSF is followed in detail. Though this particular author has, by just doing it, granted an implicit exception to the GPL. However, he could only have done so by asking all previous authors of the netatalk software he built upon. I'm convinced he (or she) never asked. Regards, Freek
Re: Netatalk and OpenSSL licencing
A bit off-topic reply. On 13-8-2004 13:18, MJ Ray [EMAIL PROTECTED] responded to my mail: Likely, this is a moral aberration I got by being employed as scientist. Maybe, but there is recently an increasing consideration of scientific ethics and science and society topics as we are faced with public-debate science topics like GM/Frankenstein foods and theraputic/designer cloning. Perhaps your discovery of this is related to that in some way, but perhaps not. Thankfully not! I have to deal with ethics in personal life already (like till what the ethical cost -the number of lab mice- for the development of a medicine should be). That is hard enough for me already, thank you. For the record, I'm working in pure optical networks. On copyright, you do not seem particularly unusual among scientists, software authors, all authors or the public in general. Many resent having to deal with these things and I can understand why. I hope you are finding these discussions helpful. Yes! At least I know have a clear understanding of the consequences of choosing a particular licence. It's not my main interest, but at least now can make a better decision when choosing licence. Thanks to all who gave me feedback! If I was to start a new project now, at least I would be inclined to pick a GPL-compatible, but less restrictive licence. As for current contributions to other projects, I realised now that I can even add those contributions under a different (compatible) licence -- something that never occurred to me before. I don't see why I would do that, though. Because I mostly learned that if you make odd decisions, you really need to know very carefully what you're doing. One thing I haven't mentioned: I may blame the FSF for being a bit to fanatical when it comes to free software (by knowingly imposing barriers to other open-source software). However, I do very much respect them for not only making the problem, but providing a solution as well (in this case in the form of GnuTLS). Now if only I get my just broken hard disk of my server to relive, I can give that a shot. I think one can argue easily that many people involved are wrong in some way and it is the combination of them that causes this effect. Yes; let's not talk about my mistakes, shall we. This thread is long enough as it is :-) Regards, Freek
Re: GPL-licensed packages with depend-chain to OpenSSL
Given the fact that this topic seems to come up relatively often, would it be a good idea to put a few things into a FAQ for people to refer to? I am willing to put down a draft of questions. I have proposed this as a side note in a private mail, and was pointed that this not a Debian-specific question. I agree. However, given the interest and the number of times it pops up, I belief a FAQ is a good idea. In my opinion, it should be added to, or referred from either or both: http://people.debian.org/~bap/dfsg-faq.html http://www.debian.org/doc/debian-policy/ Here is a quick draft: Q: How to find if a licence is 'free'? A: See http://www.nl.debian.org/legal/licenses/byclass Or http://www.gnu.org/licenses/license-list.html Q: How to find if a licence is 'GPL-compatible'? A: See http://www.gnu.org/licenses/license-list.html Q: Why is licence x free, but not GPL-compatible? A: There may be different reasons. See http://www.gnu.org/licenses/license-list.html for specific arguments. For example licence x may give permission to use, modify and redistribute the source code (making it free), but also requires you to give attribution to the original copyright owner. This is called the advertising clause, and is incompatible with the GPL, because it places an additional restriction on the source which the GPL does not has. So that code can never be redistributed under the GPL. In addition, the GPL explicitly forbids anyone to add additional restrictions on GPL-licenced code, so code once code is under the GPL, it can never be redistributed under a licence x which has such an advertising clause. The FSF takes the prohibition of added resistrictions very strict. For example, the following licence is not GPL-compatible: This code may be freely modified, copied and distributed, so long as no fee is charged for it., because of the added restriction that no fee may be applied. Q: Can I redistribute a binary of program xxx with non-GPL compatible licence y if it has been linked to library zzz, which has the GPL licence? A: No. The binary you are to distribute is a derivate on library zzz, according to copyright law. Therefor, according to the definition in the GPL, the binary is based on library zzz, and must therefor be released under the GPL. See also http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL Q: Can I redistribute a binary of program xxx with a non-GPL compatible licence y if it is dynamically linked to library zzz, which has the GPL licence, even if I make sure only to distribute program xxx and not library zzz. A: No. It is technically possible to distribute the two parts seperately. But according to section 2b of the GPL, you must distribute the program as a whole under a single licence. As you may read in the GPL, this requirements apply to the modified work as a whole, not if the the program xxx and the library zzz can be considered independant and separate works in themselves. Now, this is a tricky business. Ultimately, a judge will decide if the combination is one whole or two separate parts. According to the FSF, linking is an act specifically to combine programs making it one whole. See http://www.gnu.org/licenses/gpl-faq.html#MereAggregation for details. Nobody has so far been willing to have a lawsuit over this, so it's not possible to confirm or deny this. Believing the FSF is safer than not doing so, so Debian takes the low-risk approach. Q: Can I redistribute a binary of program xxx with non-GPL compatible licence y if it has been linked to library zzz, which has the LGPL licence? A: Yes, only if you use dynamic linking. Unlike the GPL, the LGPL (lesser GPL) does explicitly make a distinction between a work based on the library and a work that uses the library. Such a binary is not covered by the LGPL, as explained in section 5 of the LGPL. Q: Can I redistribute a binary of program xxx with the GPL licence if it has been linked to library zzz which is covered by non-GPL compatible licence y? A: No. First of all, licence y may not allow this. But even if it does, the GPL does not allow this. According to the GPL, if your program is specifically code against an other library, then the two parts form one whole combined program. According to section 2b of the GPL, you must release this whole under a single licence. According to section 6 of the GPL, this must be the GPL. However, since licence y is incompatible with the GPL, this is not possible. See also http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleAlone Q: Can I even not redistribute a binary of program xxx with the GPL licence if it has been dynamically linked to library zzz which is covered by non-GPL compatible licence y? When it is dynamically linked, it does not contain any byte of executable code generate by non-GPL code! A: No. According to section 2 of the GPL, the combination may only distributed together under a single licence. The fact that it is technically possible does not allow it. Some people have claimed
Re: Netatalk and OpenSSL licencing
On 13-08-2004 0:09, Josh Triplett [EMAIL PROTECTED] wrote: I think the issue of non-GPL-compatible licenses is certainly annoying, but I don't really see any way around it without losing the copyleft. I see a theoretical and a practical way. First of all the theoretical way: I would have preferred that the GPL would be less strict in allowing dynamic linking of GPL software with non-GPL compatible, but still free software. Given the list at http://www.gnu.org/licenses/license-list.html, the FSF is perfectly capable of making the distinction between free and non-free (where BSD, Apache, OpenSSL, etc. licences are still considered free; thus basically all licences which force that the source is kept open). I'm 100% convinced they can put that into a solid licence. However, they explicitly decided not to, in order to push their idea of open software. See http://www.gnu.org/licenses/gpl-faq.html#WhySomeGPLAndNotLGPL What annoys me propably most is that this simple licence is non-GPL compatible, and any software written with this licence is not allowed to be linked against GPL-software: This code may be freely modified, copied and distributed, so long as no fee is charged for it. (question 3, http://www.gnu.org/cgi-bin/license-quiz.cgi) Secondly, a practical way may be: As you surely are aware, it is possible to include an exception to the GPL, stating you, as the copyright holder allow that your program links against (specific) non-GPL-compatible libraries. Now, if I read the answer to this FAQ: http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat The FSF states here: If you wrote and released the program under the GPL, and you designed it specifically to work with those facilities, people can take that as an implicit exception permitting them to link it with those facilities. But if that is what you intend, it is better to say so explicitly. those facilities refer to a interpreter who automatically binds to non-GPL-compatible software, like libraries. Well, I do not see a technical difference from, for example the people who designed netatalk to specifically work with the OpenSSL facility, and a linker who dynamically links with (binds to) the OpenSSL library. So by explictly designing GPL code to link against non-GPL code, the author *implicitly* gives the exception that the program may indeed be linked to this particular non-GPL code. Kind regards, Freek Dijkstra
Re: Netatalk and OpenSSL licencing
On 10-8-2004 00:49, Glenn Maynard [EMAIL PROTECTED] wrote: I propose to built netatalk (with GPL licence) against OpenSSL (a non-GPL licence) and distribute the whole with the GPL licence. How does that violate the GPL? You can't distribute the whole under the GPL. You must adhere to the OpenSSL license *and* the GPL, since the binary you're distributing combines both. In order to distribute a binary under the GPL, you must grant a license to the entire work under the terms of the GPL (see GPL section 6). That includes all code being used, regardless of what technology is being used to bind that stuff together (static linking, dynamic linking). However, you can't do that; you don't have permission to grant me a license to OpenSSL under those terms. Therefore, you can't comply with GPL#6, and so you can't distribute the binary. OK. I understand your argument, but I do not agree with it, and in fact would argue that this Since your opinion forms the majority, that is the end of that. For the record, this is my opinion: If indeed, if I am ONLY distributing netatalk binary, linked to OpenSSL, but no including OpenSSL. Then I have a program able to talk to OpenSSL is present. However, it can just as well work without it (as long as I don't use the features it requires OpenSSL for). So because of that, I'd say that this makes netatalk a standalone work. If this nonetheless *due to the GPL* (as opposed to due the OpenSSL licence) contaminates the *WHOLE* OpenSSL package by forcing it to redistribute as GPL (note: be aware that I do not actually distribute any actual executable OpenSSL code! I may not distribute OpenSSL with it, or distribute it as source). Well, this would be a violation of rule #9 of the Debian Free Software Guidelines: 9. License Must Not Contaminate Other Software The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software. If your reasoning of this contamination is correct (I personally hope it is not, but FSF seems to think so), I argue that the above line of the DFSG explicitly forbids to use the GPL for any component of Debian software. Shocking... Also for the record, if I look at the restriction imposed by the OpenSSL licence, they are not as bad as the restrictions imposed by the GPL when it comes to distributing a binary version of netatalk: According to #3 of the OpenSSL licence, you must include the attribute to the OpenSSL Group. However, you do not to place whole or part of netatalk under the OpenSSL licence, because it does not talk about derivate works. Or to be precise: it does not explicitly define 'derivate works' as extremely broad, as the GPL does (but other licences like the LGPL do not). Simular to if OpenSSL would have been under LGPL, then netatalk would also not be a derivate work. The OpenSSL talks about redistributions in binary form. However, since 0 bytes of OpenSSL code are shipped with the linked version, I can only reasonably conclude that this would not apply to this particular binary distribution of netatalk. I will have a look in incorporating GnuTLS, even though I personally belief that this whole thing (duplicating an effort, just because of a single line of attribution) is a serious indication that restrictions are overrated in our society. I knew that, but I'm currently disappointed that this also applies to open software. To me it is not in the spirit of free as mentioned in the Debian Social Contract. Oh well, I'll survive. Regards, Freek Dijkstra (being very disappointed in the GPL now)
Re: Netatalk and OpenSSL licencing
On 10-08-2004 11:24, Glenn Maynard [EMAIL PROTECTED] wrote: For the record, this is my opinion: If indeed, if I am ONLY distributing netatalk binary, linked to OpenSSL, but no including OpenSSL. Then I have a program able to talk to OpenSSL is present. However, it can just as well work without it (as long as I don't use the features it requires OpenSSL for). So because of that, I'd say that this makes netatalk a standalone work. I don't buy that you can circumvent the GPL simply by taking GPL code, pushing it into a loadable module, making your proprietary code use it, and making them two separate downloads: I can't distribute these together; in order to get around the GPL, you'll have to download and install these separately. You indeed can not do that. But I hope you can do the reverse: take propriatory code, push it into a loadable module, making your GPL code use it, and make them into two seperate downloads. Because THAT is what I wish, what you describe (which, as I understand now, is indeed not allowed by the GPL). As a side-note. What I want is already common practice. In particular this is what happens in kernel development. The GNU/Linux kernel is GPL-licenced, while a lot of hardware drivers (the loadable modules) have non-GPL compatible licences. Maybe I need to ask this question on one of the GNU lists. [Argument that GPL violates rule #9 of the DFSG snipped] The GPL is placing restrictions on software that it's combined with; the restriction is unrelated to what it is distributed along with. OK. I was probably wrong there. combined with and distributed along with are two different things. Maybe my argument holds if I refine it, but honestly, I really hope not to prove that, so I let that rest. Thanks for the counter-argument. ['Silly' requirements in the OpenSSL licenced pointed out] I'm not arguing that the license isn't free; just that the GPL isn't the only license placing annoying restrictions here. I agree. Thanks. I guess it is just that in my limited vision, GPL was 'top of the bill' and was great because it 'allowed free software'. I now realise that things are not as black and white. I may come over it. :-) But I will probably use LGPL (or the MIT licence you mentioned) for my projects in the future. Regards, Freek Dijkstra (who never thought that a good argument about laws and licence could be this exciting)
Netatalk and OpenSSL licencing
Hi, I'm asking for advice. The best explanation can be found at this feature request on SourceForge: http://sourceforge.net/tracker/index.php?func=detailaid=890674; group_id=8642atid=358642 This is licence related. I'm using Debian, and prefer to grab netatalk using the appropriate package [1]. However, this package is not allowed to link to OpenSSL (and thus DHX passwords are disabled) [2]. The reason comes from debian- legal (don't ask *me*, I'm an ignorant user): GPL software linked against OpenSSL is not allowed in the main archive without either a license exemption from the upstream author of the GPL package, a change in the license of OpenSSL itself, or a clear legal precedent sustaining the OpenSSL FAQ's opinion on this point. [3] In short, the OpenSSL and GPL are incompatible (as was noted on this list in 2001), so you may link it yourself, but may not distribute it because the GPL forbids it, despite that both licences are considered free. (Well, at least that's what people on debian-legal claim). Thankfully, both the OpenSSL FAQ [4] and the GPL FAQ [5] give a solution: Add an exception to the licence, stating that it really is OK with you to compile the whole bunch, link with OpenSSL and put it in a package. So, my question. Could you pretty please add the following statement in one of your legal-blahblah files for both the 1.6 and 2.0 version? I just copied it from gnu.org [5]: In addition, as a special exception, the netatalk developers give permission to link the code of this program with the OpenSSL library (or with modified versions of OpenSSL that use the same license as OpenSSL), and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. [1] http://packages.debian.org/netatalk [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191790 [3] http://lists.debian.org/debian-legal/2002/debian-legal -200210/msg00173.html [4] http://www.openssl.org/support/faq.html#LEGAL2 (last paragraph of answer) [5] http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs Thanks a LOT! And sorry to have distracted you from serious coding with this silly feature! I have since bother the maintainer of netatalk debina package and the upstream maintainers. The latter are perfectly happy to make the exception to the licence, but can not: We have discussed this internally, and I fear it is not possible to make that change. Netatalk (at least 2.0) includes some GPL'ed code from other projects, mostly libiconv and Samba. Distributing Netatalk under a different license than the original GPL is AFAIKT (IANAL) therefore impossible without getting the permissions from the original authors and possibly all other contributors. So: my questions: 1. Has anything changed in the statement made to debian-legal in 2002? 2. Is the netatalk upstream author correct that he cannot reasonably make the exception (without asking all possible contributors) 3. Is there any way of getting netatalk with encrypted passwords in sarge? I can think of source-only distributions, or asking to move it out of main. However, I do not fully understand the implications of this. So: what would be a possible next move? Maybe just put it in Sarge, and ask FSF to sue you to create legal precedent? :-) Kind regards, Freek Dijkstra [rant mode on] PS: to play the devils advocate on this list: is this [EMAIL PROTECTED]$(%$ really necessary for me as an end-user to get open-source software to work? I'd rather had spend all this time doing something *useful*. All lawyers on this list: please find an other job. ;-) [rant mode off]
Re: Netatalk and OpenSSL licencing
On 09-08-2004 13:49, Matthew Garrett [EMAIL PROTECTED] wrote: GnuTLS has a openssl compatibility module. Thanks! Personally I fear the upstream maintainers are not willing to change their code for just this. After all, they already link with the technically excellent OpenSSL library, which is indeed open source. I take it that it is not possible to put a source-only (no-binary) distribution) in the main section of Debian? Regards, Freek Dijkstra [Who is trying very hard to refrain myself from make *very* saracastic remarks about lawyers who make incompatible open source licences, forcing people to write two functionally completely equal software libraries. What was it again about open source and duplicating efforts again? One more think, and I'll be back to good old proprietory software...]
Re: Netatalk and OpenSSL licencing
On 09-08-2004 14:33, Matthew Garrett [EMAIL PROTECTED] wrote: Nope. The same argument actually applies - if netatalk is a derivative of openssl (and if it's been coded against it, then the FSF would probably claim that it is) then it's illegal to distribute it in any form under the current license. Netatalk is absolutely NO derivate of openssl. It is a standalone package which (mainly) provides Apple Filesharing Protocol (AFP) support. It is very simular in functionality to Samba, if you're familiar with that. Netatalk CAN be linked against openssl, to provide password encryption. The current package in sarge (testing) is not linked against OpenSSL, so all passwords are sent in clear text over the line. Does this, in any way, according to you, change if netatalk, linked against OpenSSL is allowed to be distributed? I am aware of the statment made at http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs stating, that, in some cases, you can just distribute the packages without making an exception to the GPL (which the provider is willing, but unable to make). However, I do not entirally understand what is being said there. I (and the current package maintainer) completely really on that someone on debian-legel says that GPL software linked against OpenSSL is not allowed in the main archive without either a license exemption from the upstream author of the GPL package source: http://lists.debian.org/debian-legal/2002/10/msg00173.html If this statement is incorrect, given the statement in the GPL-FAQ, please let me know immediately! Kind regards, Freek Dijkstra
Re: Netatalk and OpenSSL licencing
On 2004-08-09 13:35:30 +0100 Freek Dijkstra wrote: As an end-user, it's far easier to just compile it all myself [...] then to change the code of netatalk to have it link to gnutls. Fine. If you choose not to help others, that's your choice. I don't like it. I could have just compiled all myself, and stopped there. That solved my problem. I instead choose to spent some time and change it for those who only use packages and do not have the time to find the problem and compile software on their own. My apologies if I sound blunt because I did not commit myself to making changes I do not see the need for. I may do it after all, now that Matthew suggested that it doesn't require much changes, but I personally belief OpenSSL is just fine. To keep on-topic: Netatalk is no derivate work. However, it is not clear if the compiled program, which is linked with but the compiled program is. Technically, for DHX (password encryption support), netatalk does compile against openssl by linking against the header files found in /usr/include/openssl (it adds -I/usr/include/openssl to CFLAGS) Aparently, in simular cases (with Courier in the 2002 thread), this was taken as incompatible with this note on the GNU FAQ: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. I was, and still am surprised (and yes, also disappointed) by this. We want copyright permission from the copyright holders for this act not covered by their licences in combination. Either openssl or netatalk could give an exception. They haven't give it, for whatever reasons. Regardless of what we think of their reasons, we don't have permission... OpenSSL does give that permission: http://www.openssl.org/support/faq.html#LEGAL2 (last paragraph of answer) Netatalk is willing to give it, but can not: It is practically unrealistic to ask every possible contributor (including samba and libiconv contributors) to make this exception to the GPL licence. http://sourceforge.net/tracker/index.php?func=detailaid=890674group_id=864 2atid=358642 It is sad that despite all copyright holders are more then willing to co-operate, there still is something holding them back. Please attribute the fault to whoever you like, but not the copyright holders. If you want to argue that copyleft is wrong for software, this is not the list for that and I'm not sure what is. Maybe ox-en or gnu-misc, but maybe not. As for suggestion that GPL is wrong. Well, that it too harsh, but you are right. I should take this part of the discussion to gnu-misc. For the record, I don't think copyleft is wrong. On the contrary. However, I DO argue that licences which limit people in using (other) open source software are not optimal. If that is indeed what GPL does, I dislike it, and prefer other (better?) licences, like maybe BSD or Apache (APSL). Sorry if I sound too pessimistic here. Regards, Freek Dijkstra
Re: Netatalk and OpenSSL licencing
On 09-08-2004 14:33, Matthew Garrett [EMAIL PROTECTED] wrote: Nope. The same argument actually applies - if netatalk is a derivative of openssl (and if it's been coded against it, then the FSF would probably claim that it is) then it's illegal to distribute it in any form under the current license. Netatalk is absolutely NO derivate of openssl. It is a standalone package which (mainly) provides Apple Filesharing Protocol (AFP) support. It is very simular in functionality to Samba, if you're familiar with that. Netatalk CAN be linked against openssl, to provide password encryption. The current package in sarge (testing) is not linked against OpenSSL, so all passwords are sent in clear text over the line. Does this, in any way, according to you, change if netatalk, linked against OpenSSL is allowed to be distributed? I am aware of the statment made at http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs stating, that, in some cases, you can just distribute the packages without making an exception to the GPL (which the provider is willing, but unable to make). However, I do not entirally understand what is being said there. I (and the current package maintainer) completely really on that someone on debian-legel says that GPL software linked against OpenSSL is not allowed in the main archive without either a license exemption from the upstream author of the GPL package source: http://lists.debian.org/debian-legal/2002/10/msg00173.html If this statement is incorrect, given the statement in the GPL-FAQ, please let me know immediately! Kind regards, Freek Dijkstra -- Never ask a man what kind of computer he owns. If it's a Mac, he'll tell you. If not, why embarrass him?
Re: Netatalk and OpenSSL licencing
On 09-08-2004 17:14, MJ Ray [EMAIL PROTECTED] wrote: Netatalk is absolutely NO derivate of openssl. From a quick inspection, I don't think that will be true for all of a netatalk binary compiled with openssl-related parts enabled. I think you realised this in your later message. No. This is untrue. I just realised that Netatalk, just like most binary distributions are *dynamically* compiled. Not statically. For example, all the password encryption-related parts (which link against openssl) do end up in so-called UAMS (authentication modules). For example, the one I talked about it /usr/lib/netatalk/uams_dhx_pam.so I did compile it manually and found: netatalk-2.0-beta1# ldd /usr/local/lib/netatalk/uams_dhx_passwd.so libcrypto.so.0.9.6 = /usr/lib/i686/cmov/libcrypto.so.0.9.6 (0x4000f000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x400d) libnsl.so.1 = /lib/libnsl.so.1 (0x400fe000) libdl.so.2 = /lib/libdl.so.2 (0x40113000) libc.so.6 = /lib/libc.so.6 (0x40116000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) As you can see it indeed is DYNAMICALLY linked. Which means that no part of the openssl binary code is included. I did try to verify that. # cd source/netatalk-2.0-beta1 # grep -rsi libssl * Only matches a few readme files # grep -rsi libcrypto * Matches config and some binary files. I have the impression that no binary output file includes code which is either (1) compiled from openssl sources or (2) include libssl.a or libcrypto.a I will verify this this evening. If it is not the case, then the only thing that is included are the *header* files in /usr/include/openssl. However, header files result in no code (that's why they're header files) and are neither included in the distribution. Clearly uams_dhx_pam.so co do include executable code which is compiled from GPL-covered source code. Technically, the issue boils down to this part of the OpenSSL licence: ( http://www.openssl.org/source/license.html ) * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/) The third point, the inclusion of the line, is incompatible with the GPL. As such, just including the line is no incompability. That's fine. The issue is that according to #1 or #2, redistributions must contain this licence as well, and thus place restriction #3 on further derivate works. This is not allowed, since it also places an added restriction on GPL-derivate code. So if indeed netatalk contains executable code from openssl, then according to #2, the redistributed binary must have the openssl-licence, and that is not allowed. However, just thinking about how dynamic libraries work, I belief there is no executable code of the library being called involved, even though the header files are used (since they only contain definitions, but don't lead to executable code). Could someone confirm or deny this? In the mean time, I'll check this assertion by examining the header files, compiling them, and by forcefully removeing libssl.a and libcrypto.a from /usr/lib before compiling netatalk. Kind regards, Freek Dijkstra
Re: Netatalk and OpenSSL licencing
On 09-08-2004 18:25, Brian Thomas Sniffen [EMAIL PROTECTED] wrote: It is sad that despite all copyright holders are more then willing to co-operate, there still is something holding them back. Yes -- the rest of the copyright holders. Bug the Samba/libiconv folks if you like, but I suggest you blame Eric Young. He could make this issue go away by behaving in a less unmutual manner. OK, agreed. I was too quick in drawing conclussions on that one. It is an issue with licences though. In time you just don't know anymore who wrote what piece, and you can't fix issues in licencing. I know have to congratulate the GPL folks who encourage the or any later version practice. But let's not discuss that here. Freek
Re: Netatalk and OpenSSL licencing
On 9-8-2004 18:58, Matthew Garrett [EMAIL PROTECTED] wrote: Freek Dijkstra [EMAIL PROTECTED] wrote: So if indeed netatalk contains executable code from openssl, then according to #2, the redistributed binary must have the openssl-licence, and that is not allowed. However, just thinking about how dynamic libraries work, I belief there is no executable code of the library being called involved, even though the header files are used (since they only contain definitions, but don't lead to executable code). Could someone confirm or deny this? The FSF disagree - their claim is that even with dynamic linking the libraries must be GPL compatible. Nobody has so far been willing to have a lawsuit over this, so it's not possible to confirm or deny this. Believing the FSF is safer than not doing so, so we take the low-risk approach. I understand the low risk thing. However, in this case, I'd say it's worth the lawsuit. Though I have supported FSF, in the particular case I'd hope they lose :-) (I'm sure Richard Stallman doesn't agree with me). For those interested, there was an discussion on this topic on gnu-misc-discuss last month. Read this mail for interesting pointers: http://lists.gnu.org/archive/html/gnu-misc-discuss/2004-07/msg00070.html For example, the first pointer, page 16 of it on how Richard Stallman and Eben Moglen (general counsel of FSF) disagree on what is derivate works. However, that being said, I claim it does not apply to this particular scenario! In this case, I suggested to distributed a binary of netatalk, including the UAMS linked with OpenSSL under GPL. To see if this is allowed you have to look at the *OpenSSL-licence*, NOT at the *GPL*. (You could for that matter have looked at the LGPL as well, which explicitly would have allowed dynamic linking). Well *I* do not see anything in the OpenSSL licence which specifically forbid dynamic linking against it. So I think it is allowed. (If you like, I am more then willing to contact the OpenSSL on this matter). Would you agree that if the OpenSSL licence doesn't forbid this, then it is OK for netatalk to link against OpenSSL? Or do I still miss something? Regards, Freek Dijkstra
