Re: Bug#248853: 3270: 5250 emulation code, all rights reserved
In case anyone was wondering, this is far from cleared up. :-( >Ahh, the horror continues. > >I would be happy to remove all of the Minolta-copyrighted code. Perhaps the best choice. Beat Rubischon has sent a nice message apparently granting permission to use his code under "any license" as long as his name is preserved (earlier in the bug trail) -- so for anything copyrighted by him, we're OK. *UN*fortunately he apparently isn't the sole copyright holder of the 5250 code. Permission would be needed from Minolta, and I seriously doubt he has the right to speak for them, even though he's an employee. I doubt he wants to go to the trouble of clearing this with Minolta's legal department. :-( >As for the "what this means" paragraph in the Lineage file, that was >written >by an idiot, and should be removed (in fact, I thought I had removed it >already). Well, that's simple then. :-) >As for the Georgia Tech copyrighted code, I've been through this issue >with >them twice over the years, and the "public use" language was something >they >suggested. I don't know what it means, either. Shall I give it >another go >with them, to see if they will allow a different copyright notice? If >so, >what kinds of notices would be acceptable? Ideally, the MIT/X11-like license already used by most of the code; that would look like this: > Copyright © 1989 by Georgia Tech Research Corporation, Atlanta, GA 30332. > Permission to use, copy, modify, and distribute this software and its >documentation for any purpose and without fee is hereby granted, >provided that the above copyright notice appear in all copies and that >both that copyright notice and this permission notice appear in >supporting documentation. (It could also be consolidated with the other essentially identical notices.) If they don't like that, perhaps change it to "hereby granted to all members of the public"? That's probably (hopefully) what they mean by "public use". Alternately, the Georgia Institute of Technology license appears to be an acceptable and DFSG-free license (-legal, please verify -- I'm not 100% sure). That, changed for Georgia Tech Research, would look like this: > Copyright © 1989 by Georgia Tech Research Corporation, Atlanta, GA 30332. >All rights reserved except for those rights explicitly mentioned below. >Permission is granted to distribute freely or to modify and distribute >freely any materials and information contained herein as long as the >above copyright and all terms associated with it remain intact. This appears to be a free, all-permissive license. (Debian-legal should probably comment, of course; I am assuming that "freely" is not a no-fee restriction but simply intended to make the permission broad, and that "copy" is clearly implied by "distribute". Ideally the copyright holders would clarify that my interpretation is the same as theirs.) If Georgia Tech Research Corporation has some relationship with the Georgia Institute of Technology, it might be more amenable to using a "familiar" license statement. If none of these options work for them, we really need to figure out what they *want*. If we know *why* they don't like the standard license used for the rest of 3270, debian-legal can probably recommend a license tailored to suit their needs.
Conditions vs. (possibly inaccurate) notices (was Re: Please pass judgement on X-Oz licence: free or nay?
Matthew Garrett wrote: >The wording of the clause is identical. Are you claiming that the >differing location of it in the license alters the situations that it >applies to? Absolutely. In the X11 license: "Permission is hereby granted provided that... and that... appear in supporting documentation. [Warranty Disclaimer] [Problem Clause] [Other Stuff]" Note that only the conditions in the "Permission is granted" sentence are actually conditions on the permission grant. The "Problem Clause" has a status equivalent to the warranty disclaimer; it's another statement. In the X-Oz license: "Permission is hereby granted... subject to the following conditions: 1. [Other Stuff] 2. [Other Stuff] 3. [Other Stuff] 4. [Problem Clause] [Warranty Disclaimer] Here, the Problem Clause is *clearly* a condition on the permission grant. (The Warranty Disclaimer might be, but probably isn't.) - Now, the BSD no-advertising clause is a condition. So if the Problem Clause ("Except as contained in this notice, the name of X-Oz Technologies shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from X-Oz Technologies.") is equivalent to the similar BSD clause ("Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission"), then it is of course fine. However, Branden believes that the X clause is stronger and more restrictive. (Which doesn't really matter if it's not a condition of the permission grant, but does if it is.) We asked X-Oz if they simply meant it to be equivalent to the BSD clause, but we got weird nonsense and no useful reply. :-( Side topic. Warranty disclaimers often state false things. For instance, the standard disclaimer in the BSD license says IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY ...DAMAGES... ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE"; many warranties simply cannot be disclaimed in many jurisdictions, the copyright owner could be offering a separate warranty on the software, and so forth. The "Problem Clause" could state false things as well, but it's not actually a condition of the permission grant, so it's not a big deal. I have mentioned before that making people agree to poorly drafted warranty disclaimers in order to use/modify/distribute software can open up a can of worms and may even make the software non-free. In contrast, having the warranty disclaimer as a separate legal notice which must be preserved but is not a condition -- and this is the usual thing -- raises far fewer issues, if any. The GPL does *much* better on the warranty front than most licenses because it includes key phrases like "TO THE EXTENT PERMITTED BY APPLICABLE LAW" and "EXCEPT WHEN OTHERWISE STATED IN WRITING". So it's just fine that the GPL warranty disclaimer *is* a condition, because it's actually properly drafted.
Re: Free & open DRM software
Brian M Hunt <[EMAIL PROTECTED]> writes: > I was contemplating the conundrum of open source digital rights management, > and would like some feedback. If someone were to write digital rights > software, eg. for downloading from iTunes, could they license it under a free > software license like the GPL, with an added clause: > > "If the Program is designed to uphold digital rights management pursuant to > the distribution of copyrighted material, any modification to the Program to > undermine the terms of distribution for that copyright will violate this > license. All rights to publish, redistribute, and use the modified Program > are revoked upon violation of this clause. Derivative works may not modify > this license so as to remove this clause." That isn't DFSG-free, no. The last sentence also reflects a curious understanding of how copyrights and licenses adhere to works. Perhaps you would be satisfied with a notice that, in the US and the EU and maybe elsewhere, it's often illegal to circumvent digital rights management technologies -- and that while your copyright doesn't stop them from doing so, the copyrights of others do. Note that this *isn't* part of the license, just a note passed along with the software. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Netatalk and OpenSSL licencing
On Mon, Aug 09, 2004 at 01:33:09PM +0100, Matthew Garrett wrote: > Freek Dijkstra <[EMAIL PROTECTED]> wrote: > > 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. > If you're lucky, no code changes would be needed. > > I take it that it is not possible to put a source-only (no-binary) > > distribution) in the main section of Debian? > 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. Not exactly. The issue with GPL applications linking against OpenSSL is the GPL's broad definition of "source code", which for an application includes any libraries it links against *except* for components that are part of the OS and are not distributed with the application. Debian always fails to be eligible for the so-called "OS exemption", on account of this second requirement. In any case, the issue is not linked at all to the FSF's much weaker claim that applications constitute derivative works of libraries. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Re: Please pass judgement on X-Oz licence: free or nay?
Joe Wreschnig wrote in http://lists.debian.org/debian-legal/2004/08/msg00200.html: >I guess I'm also convinced that just because it's not numbered like it >is in the BSD license, doesn't make it not a clause. That is, the X >license says "Permission is hereby granted... subject to the following >conditions:" Actually, this is incorrect. Which perhaps is the key difference. From http://www.x.org/Downloads_terms.html: >Permission is hereby granted, free of charge, to any person obtaining a >copy of this software and associated documentation files (the >"Software"), to deal in the Software without restriction, including >without limitation the rights to use, copy, modify, merge, publish, >distribute, and/or sell copies of the Software, and to permit persons >to whom the Software is furnished to do so, provided that the above >copyright notice(s) and this permission notice appear in all copies of >the Software and that both the above copyright notice(s) and this >permission notice appear in supporting documentation. It simply does not say "subject to the following conditions". It says: >...provided that the above >copyright notice(s) and this permission notice appear in all copies of >the Software and that both the above copyright notice(s) and this >permission notice appear in supporting documentation. The conditions quite clearly end with the period at the end of the sentence. That single sentence is, in fact, the entire permission grant. Above it is the copyright notice (which ends with the words "All rights reserved."). Below it are some other statements. A more exhaustive analysis: The permissions are granted "...provided that... (condition 1) and (condition 2)." Condition 1 is "the above copyright notice(s) and this permission notice appear in all copies of the Software". Condition 2 is "the above copyright notice(s) and this permission notice appear in all copies of the Software". Then the sentence ends, ending the grant of permission and completing the list of conditions. This is simply parsing of English. > and then goes on to lay out the requirement that the >copyright notice be preserved; then the warranty disclaimer; then the >paragraph in question. At no point is it obvious to me that "the >following conditions" is ending and being replaced by something else. Pay more attention. :-) The warranty disclaimer is not a condition of the license; it's not a condition of any sort, simply an assertion that there is no warranty. Now if a license said "provided that you accept the following disclaimer", that would be a condition. Similarly, the sentences following the warranty disclaimer are not conditions; they're wholly independent. "Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder." "X Window System is a trademark of The Open Group." "OSF/1, OSF/Motif and Motif are registered trademarks, and OSF, the OSF logo, LBX, X Window System, and Xinerama are trademarks of the Open Group. All other trademarks and registered trademarks mentioned herein are the property of their respective owners." Any of these claims could be independently disputed. They are independent sentences.
Re: New MySQL "Free/Libre and Open Source Software (FLOSS) Exception" licence.... (re #242449)
Jonas Meurer said on Tue, Aug 10, 2004 at 03:00:21AM +0200,: > how exatly, is php itself not gpl compatible, or only the php scripts? >From http://www.gnu.org/philosophy/license-list.html:- This license is used by most of PHP4. It is a non-copyleft free software license which is incompatible with the GNU GPL. We recommend that you not use this license for anything except PHP add-ons. -- Mahesh T. Pai<<>> http://paivakil.port5.com free - (adj) able to act at will; not hampered; not under compulsion or restraint; free from obligations or duties; not bound to servitude; at liberty.
Free & open DRM software
I was contemplating the conundrum of open source digital rights management, and would like some feedback. If someone were to write digital rights software, eg. for downloading from iTunes, could they license it under a free software license like the GPL, with an added clause: "If the Program is designed to uphold digital rights management pursuant to the distribution of copyrighted material, any modification to the Program to undermine the terms of distribution for that copyright will violate this license. All rights to publish, redistribute, and use the modified Program are revoked upon violation of this clause. Derivative works may not modify this license so as to remove this clause." Similarly, would such a clause violate DFSG? If this cannot satisfy DFSG, what changes are required to make it so? The hyperbole of this obviously leads to all sorts of non-free problems, where authors start contriving arbitrary restrictions. Is there a restriction that can be placed on open source software that prevents modifying digital rights management, and yet still satisfies DFSG? Regards, Brian Hunt
Re: nmap license
On Mon, Aug 09, 2004 at 08:07:01PM -0400, MOB JUNKY wrote: > * Note that the GPL places important restrictions on "derived works", > yet * > * it does not provide a detailed definition of that term. To > avoid * > * misunderstandings, we consider an application to constitute > a * > * "derivative work" for the purpose of this license if it does any of > the * As I understand it, "derivative work" is a specific legal term, defined by law, not individual licenses. > * o Integrates source code from > Nmap * > * o Links to a library or executes a program that does any of the > above * "Executes a program"? Is this claiming that bash and Linux are derivative works of nmap? > * We don't consider these to be added restrictions on top of the GPL, > but * > * just a clarification of how we interpret "derived works" as it > applies * > * to our GPL-licensed Nmap product. This is similar to the way > Linus * > * Torvalds has announced his interpretation of how "derived > works"* > * applies to Linux kernel modules. Our interpretation refers only As far as I know, Linus has no real standing to make such "interpretations"; I really wish people wouldn't use him as an example of how to handle legal issues, as he sets, as far as I can tell, a horribly bad example. -- Glenn Maynard
Re: New MySQL "Free/Libre and Open Source Software (FLOSS) Exception" licence.... (re #242449)
On 10/08/2004 Christian Hammers wrote: > The MySQL and its libraries has been put under the GPL (not LGPL) a while ago > and since then conflicts with PHP etc which is not GPL compatible but still > DFSG compliant (or so I understood). how exatly, is php itself not gpl compatible, or only the php scripts? if php itself is gpl compatible (sorry, i simply don't know), the problem is about php-scripts not being gpl compatible? or is it the php package not being gpl compatible, but linked against mysql? what about python, do we have similar problems there? bye jonas
mysql license and python-mysqldb
hi, as far as i understood the messages on debian-legal, the license of some mysql libraries changed from lgpl to gpl. this makes it impossible to link any non-gpl conform software with them. anyway, i've no glue about what this has to do with pyhton-mysqldb, as this is licensed under "GPL or the original license based on Python 1.5.2's license", where we always can choose GPL. i don't know whether "python 1.5.2's license" is gpl compatible or not, but maybe we can ask upstream to clarify the situation if it is that way. bye jonas
nmap license
Download nmap 3.55 and look at the source code. Each file contains a notice with the following text. Is this dfsg-free? I'm not-subscribed, and I don't care about the results of this, so don't bother to cc me. I just want to stir the pot. * Note that the GPL places important restrictions on "derived works", yet * * it does not provide a detailed definition of that term. To avoid * * misunderstandings, we consider an application to constitute a * * "derivative work" for the purpose of this license if it does any of the * * following: * * o Integrates source code from Nmap * * o Reads or includes Nmap copyrighted data files, such as* * nmap-os-fingerprints or nmap-service-probes. * * o Executes Nmap * * o Integrates/includes/aggregates Nmap into an executable installer * * o Links to a library or executes a program that does any of the above * * * * The term "Nmap" should be taken to also include any portions or derived * * works of Nmap. This list is not exclusive, but is just meant to* * clarify our interpretation of derived works with some common examples. * * These restrictions only apply when you actually redistribute Nmap. For * * example, nothing stops you from writing and selling a proprietary * * front-end to Nmap. Just distribute it by itself, and point people to * * http://www.insecure.org/nmap/ to download Nmap. * * * * We don't consider these to be added restrictions on top of the GPL, but * * just a clarification of how we interpret "derived works" as it applies * * to our GPL-licensed Nmap product. This is similar to the way Linus * * Torvalds has announced his interpretation of how "derived works"* * applies to Linux kernel modules. Our interpretation refers only to * * Nmap - we don't speak for any other GPL products. * * * * If you have any questions about the GPL licensing restrictions on using * * Nmap in non-GPL works, we would be happy to help. As mentioned above, * * we also offer alternative license to integrate Nmap into proprietary* * applications and appliances. These contracts have been sold to many* * security vendors, and generally include a perpetual license as well as * * providing for priority support and updates as well as helping to fund * * the continued development of Nmap technology. Please email * * [EMAIL PROTECTED] for further information. *
Re: Netatalk and OpenSSL licencing
On Tue, Aug 10, 2004 at 12:06:39AM +0200, Freek Dijkstra wrote: > >> 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*. > > > > This is incorrect. It is the GPL which is being violated, not the OpenSSL > > license. > > Huh. Why? > > 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. > PS: I took this off-list, since I have the impression people get bored by > this topic. Feel free to respond on-list though! I'd prefer to keep things on the list. Although this is a repeat topic, it's more productive to repeat it where others can read it, so if, for example, we happen to come up with any nice, succinct explanations, they can be referred to the next time the topic comes up. Also, it's possible that I may not personally be able to explain everything; it's fairly common to not be able to figure out exactly where misunderstandings are. If we keep the discussion public, it's possible that somebody else will figure it out. Don't worry too much about people getting bored with a topic; if people really don't want to bother with it, they'll stop reading it. I'll be upfront, though: this is a very well-understood topic and you're not raising any new arguments, so I don't see any possibility that this discussion will change conclusions or policies. However, I do believe that one of the secondary uses of this list is to help people better understand free software licensing issues--insofar as us phony non-lawyers can possibly hope to, at least--and so I think this type of discussion is useful (within reason). (Obviously, IANAL, TINLA, etc.) -- Glenn Maynard
Re: Bug#248853: 3270: 5250 emulation code, all rights reserved
The upstream reply is below... I think I have a copy of some of the earlier go 'rounds on this - when Carey worked with Paul. Be careful folks, while Paul is willing to help - I don't think we can come back on this issue at a later time, we better get it right this time ! --- Ahh, the horror continues. I would be happy to remove all of the Minolta-copyrighted code. As for the "what this means" paragraph in the Lineage file, that was written by an idiot, and should be removed (in fact, I thought I had removed it already). As for the Georgia Tech copyrighted code, I've been through this issue with them twice over the years, and the "public use" language was something they suggested. I don't know what it means, either. Shall I give it another go with them, to see if they will allow a different copyright notice? If so, what kinds of notices would be acceptable? -- -- Rick Nelson Where do you think you're going today?
New MySQL "Free/Libre and Open Source Software (FLOSS) Exception" licence.... (re #242449)
Hello The MySQL and its libraries has been put under the GPL (not LGPL) a while ago and since then conflicts with PHP etc which is not GPL compatible but still DFSG compliant (or so I understood). MySQL addressed this issue now by making yet another version of their FLOSS Exception license public which should resolve all problems. It does no longer contain a section that was found conflicting last time I asked but just to be sure someone should take a look at it. (E.g. I wasn't sure if a Debian CD-Set where source and binaries are not on the same CD is still considered as same "Medium" etc...) and what exactly they were trying to say in point "3."... thanks, -christian- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=242449 http://dev.mysql.com/doc/mysql/en/Copyright.html http://dev.mysql.com/doc/mysql/en/MySQL_licenses.html http://www.mysql.com/products/licensing/foss-exception.html pgpQ6LHh0QzxP.pgp Description: PGP signature
Re: Netatalk and OpenSSL licencing
On Mon, 09 Aug 2004, Freek Dijkstra wrote: > 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. This may be the case, but that shouldn't prevent you from making the modification in the netatalk packages incorporated in Debian, ideally in a method that allows the code to link with either gnutls or OpenSSL. [Just because upstream won't (or can't) cooperate, doesn't mean that Debian packages should languish...] Don Armstrong -- The beauty of the DRUNKENNESS subprogram was that you could move your intoxication level up and down at will, instead of being caught on a relentless down escalator to bargain basement philosophy and the parking garage. -- Rudy von Bitter _Software_ p124 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Netatalk and OpenSSL licencing
On Mon, Aug 09, 2004 at 09:50:30PM +0200, Freek Dijkstra wrote: > 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). If they lose that lawsuit, then the virality of the GPL would be completely undermined. I'm not the GPL's biggest fan, but I don't want to see that happen. In any event, I agree with it in principle: if something is legitimately restricted when statically linking, the idea that you can "get around" the requirement simply by putting part of the code in another binary file and linking it at runtime seems silly. > 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*. This is incorrect. It is the GPL which is being violated, not the OpenSSL license. The OpenSSL license says "advertising materials are required to contain this and that acknowledgement"[1]. The GPL says "you may not add any requirements in derived works". These requirements are mutually exclusive: requiring the former is in violation of the latter. > (You could for > that matter have looked at the LGPL as well, which explicitly would have > allowed dynamic linking). The GPL and the LGPL have very different requirements; the LGPL was explicitly intended to allow this case, where the GPL was explicitly intended to forbid it. [1] among other GPL-incompatible things -- Glenn Maynard
Re: summaries bugs, was: Please pass judgement on X-Oz licence: free or nay?
On 2004-08-09 18:26:19 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote: [MJR] summary guidelines suggest a link back to the DFSG for all problems in clauses 3-4. The list of reasons in Jeremy Hankin's guidelines need not connect to the DFSG at all. Either: a. I was trying to con debian-legal into thinking that aspect was a purely editorial wording change; OR b. I didn't think that was controversial at all or even remarkable any more. ;-) -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
Re: Please pass judgement on X-Oz licence: free or nay?
On 2004-08-09 18:07:24 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote: I guess I'm also convinced that just because it's not numbered like it is in the BSD license, doesn't make it not a clause. [...] At no point is it obvious to me that "the following conditions" is ending and being replaced by something else. Oh well, there's our difference. -- MJR/slefMy Opinion Only and not of any group I know
Re: Netatalk and OpenSSL licencing
On Mon, Aug 09, 2004 at 06:29:21PM +0200, Freek Dijkstra wrote: > 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. Yeah, old argument, short answer: it's wrong. Your binary does not need to contain a copy of their binary in order to be a derivative of it. Your binary is based upon their binary. That is enough. "Derivative work" here is a legal term. Your entirely arbitrary definition is not what it means. In colloquial English: If you use their code, you have created a derivative work of their code. All code used in a GPLed project must be available under the terms of the GPL. That is the whole point of the GPL. We can't say that in legal discussions because 'use' means something else there (specifically, the act of running the code) - and damnit, it's too imprecise. Please don't jump up and down upon the greasy smear on the pavement where this horse once stood. We've done this one *so* *many* *times*. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
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
Re: Netatalk and OpenSSL licencing
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. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Netatalk and OpenSSL licencing
Freek Dijkstra <[EMAIL PROTECTED]> wrote: > 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. Right. Which, arguably, makes a small part of netatalk a derivative work of openssl. And since netatalk is a derivative work of other people's GPLed code, this results in license issues. Of course, nobody is actually going to sue over this. > 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). Yes. That only applies if the component does not accompany the executable. Debian's position is that everything inside Debian accompanies everything else, so the exemption in the GPL is not applicable to anything we distribute. > 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 GPLed software linked against OpenSSL is not legal to distribute, in main or elsewhere. There is an argument that it would be illegal to distribute the source as well. I find this line of argument unlikely, but the FSF occasionally appear to use it. -- Matthew Garrett | [EMAIL PROTECTED]
Re: summaries bugs, was: Please pass judgement on X-Oz licence: free or nay?
On Mon, 2004-08-09 at 03:45, MJ Ray wrote: > On 2004-08-09 06:17:17 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote: > > > Since February, -legal has had an "official" (as official as they get) > > document claiming that even without further annoyances from X-Oz that > > clause is non-free. Simon Law, who wrote that summary, has since > > realized it was a huge mistake. That means something is wrong in the > > way > > we approach license analysis and summary writing. > > I agree that something is wrong. Most recently, I mentioned and made > suggestions about this in > http://lists.debian.org/debian-legal/2004/07/thrd3.html#00334 > http://lists.debian.org/debian-legal/2004/07/msg00334.html and part of > another subthread around > http://lists.debian.org/debian-legal/2004/07/msg00219.html > > Sadly, I commit the same sin of poor referencing that I percieve as a > problem with the summaries. I think the "unpleasantness" was mostly > about the handling of the MPL threads that month and the month before. > > My suggestion wasn't clearly liked, but I feel there wasn't much > participation. It seems that I don't have time to get discussion on > this. You seem to care about fixing summaries too: please can you take > it forwards? I have been going over that thread and thinking about it, but will probably need a few more days before I can come to any conclusions worthy of posting. One thing I find interesting, that you didn't mention in your changes (but you changed) and no one commented on is that your summary guidelines suggest a link back to the DFSG for all problems in clauses 3-4. The list of reasons in Jeremy Hankin's guidelines need not connect to the DFSG at all. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Please pass judgement on X-Oz licence: free or nay?
On Mon, 2004-08-09 at 11:02, Brian Thomas Sniffen wrote: > Joe Wreschnig <[EMAIL PROTECTED]> writes: > > > On Mon, 2004-08-09 at 03:31, MJ Ray wrote: > >> On 2004-08-09 05:35:10 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote: > >> > >> > Clause 4 -- which you declared non-free in that thread *before* public > >> > conversations with X-Oz, and Brian declared non-free at the start of > > > The 3rd clause of the 3 clause BSD license. I made a case elsewhere that > > the X wording is actually less restrictive because it only affects the > > original software, where the BSD clause affects all derived software. > > In that case, do you think the issue can be made to go away by making > a trivial change to the software? I don't yet admit that the paragraph in question is an "issue". -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Please pass judgement on X-Oz licence: free or nay?
On Mon, 2004-08-09 at 04:59, MJ Ray wrote: > On 2004-08-09 10:38:45 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote: > > > I don't see the difference. I mean, I see the difference that one can > > be > > read as an "assertion" and the other can be read as a "clause". But I > > don't see how that affects any practical or legal conclusions. In > > other > > words, if I write a license like the BSD one, but append "You will > > wear > > a hat on Fridays." I think it will be clear to everyone, including a > > judge, that I intend that to be a requirement to use the freedoms set > > forth in the license, even though it's just an "assertion" rather > > than a > > "clause". > > That's not the impression I have, especially given the "clarification" > posts from X-Oz. Does someone know the legal reasoning of this? Would > the same hold if you appended "You may not wear a hat on Fridays" > which I think is closer to the BSD wording? The entire X license is written in an assertoric rather than imperative manner. All conditions are phrased with "X shall Y" or "X is Y" rather than "You shall do X". A study of differing legal interpretations between assertoric statements and imperative clauses in licenses may be interesting. I also think it's enough hair-splitting that we shouldn't bother with it. I guess I'm also convinced that just because it's not numbered like it is in the BSD license, doesn't make it not a clause. That is, the X license says "Permission is hereby granted... subject to the following conditions:" and then goes on to lay out the requirement that the copyright notice be preserved; then the warranty disclaimer; then the paragraph in question. At no point is it obvious to me that "the following conditions" is ending and being replaced by something else. > MJ Ray wrote: > >> No-one found a licence with a similar *condition* in it. > > The 3rd clause of the 3 clause BSD license. > > That says "may not be used to endorse or promote products derived from > this software" while the X-Oz one says "shall not be used in > advertising or otherwise to promote the sale, use or other dealings in > this Software". There's the difference in verb, which I think is > substantial, and I think X-Oz has added sufficient lawyerbombs to make > me a lot more uncomfortable with it than the 3 clause BSD one. > > I suspect we also have more postitive clarifications about the BSD > one. It is possible we will get a bizarre interpretation from a > particular licensor, but we'll deal with that when it happens. Since I don't buy that it's not actually a clause, the whole of XFree86 licensing stands up as positive clarification of a free interpretation of this. > > I made a case elsewhere that > > the X wording is actually less restrictive because it only affects the > > original software, where the BSD clause affects all derived software. > > Do both affect derived software, because we need copyright permission > for the original in order to use the derived, which would otherwise > infringe copyright of the original? They both affect derived software in the sense that they place some conditions you, which you must meet to derive from the software. However, those conditions only apply to The Software in the X license; they only apply to derived software in the BSD license. Personally I think this is extreme hair splitting; I was using it as an example of why I think it's silly to claim the BSD license is free and this one isn't. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
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 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
Freek Dijkstra <[EMAIL PROTECTED]> writes: > OpenSSL does give that permission: > http://www.openssl.org/support/faq.html#LEGAL2 (last paragraph of > answer) The OpenSSL license requires an ad for Eric Young on all software using it. The GPL conflicts with that requirement. > 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=detail&aid=890674&group_id=864 > 2&atid=358642 Well, then what you're really saying is that the Samba and Libiconv folks have offered their software under the GPL, and won't give permission for the OpenSSL exception. So this isn't just a failing of licenses; it's a legitimate disagreement between some copyright holders. > 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. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Web application licenses
Josh Triplett <[EMAIL PROTECTED]> writes: > And obtaining GNU Emacs does not entitle you to run it on a gnu.org > machine. Why should this be any different? You have control over your > own boxes and what runs on them. I have the same control over mine. If > you make software available, I can run it on my boxes, but not on yours > unless you permit it. This would still give me Freedom over the > software I'm using; what you suggest would infringe _your_ Freedom to > decide what software you run on your own hardware. Some software, like Emacs or gcc, is mostly local. Some software, like traffic-signal control software, or homeland-security massive database software, is useful only where it is; it is inherently remote. I have no interest in running my own Giant Database Aggregator of Doom. I just want to make sure *theirs* works right, and doesn't compromise the privacy of citizens. >>>* Allowing a user to log into your box and run the software. >> >> So if I want to have a dialup server, it must include the source for >> all its > > This sentence seems incomplete. Yes. It should say something about all the dialup's software, or maybe just software I've modified. > Yes, you would have to provide source for the programs users may run on > your server, if those programs are covered by this license, or are based > on such software. However, that can probably be handled for 99% of the > software on that server by saying "Get it from *.debian.org". No, I routinely modify all software I install and give those modifications to others. Those are both freedoms Debian wants to guarantee, so a license can't be free if it restricts me from doing them in any quantity. For example, look at the response to the stoplight provision here: > You really _should_ be able to get the source to everything you interact > with that is under this license. On the other hand, that is a good > example of how the requirement might be difficult to meet. Then again, > the DoT can always choose not to derive their software from software > under this license. You're suggesting that some people might want to avoid modifying free software and using it, because they don't want to bear the burden that this would have. That just doesn't sound like free software to me. >> No, but if I don't have those things then I can't use the software >> anyway. > > My point is, you are asking for too much control over how the other > party uses their hardware. You should certainly have the right to use > it on your own hardware; that would be more freedom than you have now, > and certainly enough to consider it Free Software. I'm sure that there > is plenty of software in Debian main that neither of us could take > advantage of for whatever reason. That does not make the software any > less Free. True, but your argument for why they should have to give me copies of their software is that to do so enhances my freedom. I don't understand why that argument applies to software and not hardware. If I implement an Emacs Machine, which provides Emacs but only in hard-wired circuits, but in such a way that it's a derivative of a work under this license, is it free to require me to give you one? To give you the plans? Why is the answer different for software? -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Please pass judgement on X-Oz licence: free or nay?
Joe Wreschnig <[EMAIL PROTECTED]> writes: > On Mon, 2004-08-09 at 03:31, MJ Ray wrote: >> On 2004-08-09 05:35:10 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote: >> >> > Clause 4 -- which you declared non-free in that thread *before* public >> > conversations with X-Oz, and Brian declared non-free at the start of > The 3rd clause of the 3 clause BSD license. I made a case elsewhere that > the X wording is actually less restrictive because it only affects the > original software, where the BSD clause affects all derived software. In that case, do you think the issue can be made to go away by making a trivial change to the software? -Brian -- Brian Sniffen [EMAIL PROTECTED]
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
Freek Dijkstra <[EMAIL PROTECTED]> wrote: > 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. If you're lucky, no code changes would be needed. > I take it that it is not possible to put a source-only (no-binary) > distribution) in the main section of Debian? 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. The whole argument over whether linking against a library makes a derived work has never (as far as I'm aware) been tested in court. It's probably the weakest part of the GPL. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Netatalk and OpenSSL licencing
Freek Dijkstra <[EMAIL PROTECTED]> wrote: > 1. Has anything changed in the statement made to debian-legal in 2002? It's still the case that the openssl license is considered incompatible with the GPL. > 2. Is the netatalk upstream author correct that he cannot reasonably make >the exception (without asking all possible contributors) Yup. You can't change the license something is under without the permission of the copyright holder, and adding an exception for openssl is changing the license. > 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? :-) GnuTLS has a openssl compatibility module. It's not complete, but it's sufficient for some openssl code. GnuTLS is under the GPL, so there's no problem with linking GPLed stuff against it. It's possible that you could just link netatalk with that. Alternatively, the SSL code in netatalk could be rewritten to use GnuTLS directly. -- Matthew Garrett | [EMAIL PROTECTED]
Re: periodic summaries, was: RPSL and DFSG ...
On Mon, Aug 09, 2004 at 04:36:31AM +0100, MJ Ray wrote: > On 2004-08-09 03:10:06 +0100 Walter Landry <[EMAIL PROTECTED]> wrote: > > >I'm not so sure that it should go to d-d-a. For one time deals, where > >a legal analysis affects a lot of packages, sure. But not for a > >weekly synopsis. That is more like a mailing list of its own (like > >kernel-traffic). > > Then, unless the world shouts you down, for now I'll put it to d-l and > then my free software news blog (also on planet.debian.net) and rely > on subject line consistency to help people find them. If it seems to > work, I'll look for a better home next month. Both of those are great choices. Thank you very much for doing this. - David Nusinow
Re: Suggestions of David Nusinow, was: RPSL and DFSG-compliance - choice of venue
On Sun, Aug 08, 2004 at 07:07:11PM -0500, Branden Robinson wrote: > Apart from Raul Miller's[1], I have yet to read a rebutal to Manoj's draft > position statement on the GNU FDL[2]. > > If you would direct me to one which represents "the will of the project as > a whole", I'd appreciate it. > > Given that Raul himself, after a thread that went several directions, said > "I'm not trying to convince people that the GFDL as it currently stands > should be considered DFSG free. I'm ambivalent about that."[3], we seem to > be rather short on comprehensive and well-reasoned defenses of the > DFSG-freeness of the GNU FDL. Maybe you can help. Actually, I agree with the GNU FDL position, and I even submitted a draft version of a small portion of it to Manoj while he was in the writing phase of it. :-) - David Nusinow
Re: Netatalk and OpenSSL licencing
On 2004-08-09 13:55:01 +0100 Freek Dijkstra <[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. http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs [...] However, I do not entirally understand what is being said there. I don't think OpenSSL is *normally* distributed with the major components of the debian operating system, so that doesn't apply. It is only a standard priority package in the utils section, not a required or even important priority. Sorry. A couple of bits from the other subthread: http://www.openssl.org/support/faq.html#LEGAL2 OpenSSL doesn't give that permission - they just claim it's not needed for any major distribution. I assume we're not major in their eyes then. :-/ 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. You wrote that it's impractical to contact all copyright holders, so how can you make this conclusion safely about all of them? You seem to be exaggerating, so I think I'm right to doubt your "NO derivative work" conclusion: is that a similar exaggeration? I don't think there's much point in attributing "fault" for this situation anyway. It still won't get the permission. -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
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=detail&aid=890674&group_id=864 2&atid=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 2004-08-09 13:35:30 +0100 Freek Dijkstra <[EMAIL PROTECTED]> wrote: As an end-user, it's far easier to just compile it all myself (which is of course perfectly fine, and allowed according to both the GPL and the openssl licence) 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. 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? Sadly, yes, someone has to do this, until laws change. [...] I don't think laws have anything to do with it. Copyright law means we need permission for acts which would otherwise infringe copyright. If there was no legal support for copyright, you could distribute compiled GPL'd OpenSSL-using works without legal trouble. The issue at case (im my naive opinion) is that GPL is so strict [...] GPL is a copyleft, which means that it somehow requires derived works to be under the same licence, which is stronger than DFSG 3. OpenSSL's licence contains something that prevents derived works being covered by the GPL. 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. If this is not the issue, please have someone explain me what does prevent netatalk from linking with openssl and distributing it in Debian. 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... -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
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 09-08-2004 14:18, "MJ Ray" <[EMAIL PROTECTED]> wrote: > I don't know. I would probably look at porting to gnutls if no-one has > tried that yet. Yes, I've seen the suggestion before. It seems like a non-option to me. As an end-user, it's far easier to just compile it all myself (which is of course perfectly fine, and allowed according to both the GPL and the openssl licence) then to change the code of netatalk to have it link to gnutls. >> 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? > > Sadly, yes, someone has to do this, until laws change. [...] I don't think laws have anything to do with it. The issue at case (im my naive opinion) is that GPL is so strict that I am not allowed to distribute a program which is *partily* GPL, partialy other open source software. Even not if I *do* distribute the source code with it. If this is not the issue, please have someone explain me what does prevent netatalk from linking with openssl and distributing it in Debian. >> All lawyers on this list: please find an other job. ;-) > > That would actually be unhelpful, assuming we have more helpful > lawyers than evil spy lawyers on this list. I'm glad you labelled that > as a rant. LOL. Next time, I'll change my rant to "all lawyer, not on this list, find another job" :-) Regards, and thanks for the prompt feedback! Freek
Re: Netatalk and OpenSSL licencing
On 2004-08-09 12:36:46 +0100 Freek Dijkstra <[EMAIL PROTECTED]> wrote: 2. Is the netatalk upstream author correct that he cannot reasonably make the exception (without asking all possible contributors) I think so. 3. Is there any way of getting netatalk with encrypted passwords in sarge? I don't know. I would probably look at porting to gnutls if no-one has tried that yet. 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. IIRC, this licence conflict makes it non-distributable, so "move it out of main" wouldn't allow you to compile against OpenSSL. 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 Sadly, yes, someone has to do this, until laws change. If the developers haven't done it and it's important to you, you need to cause some development on this... Copyright won't necessarily ignore you (or us) just because you ignore copyright. That is the fault of your lawmakers, at least partly. Debian aims to be universal, so can't really rely on the few blanket copyright permissions for certain kinds of use. rather had spend all this time doing something *useful*. All lawyers on this list: please find an other job. ;-) That would actually be unhelpful, assuming we have more helpful lawyers than evil spy lawyers on this list. I'm glad you labelled that as a rant. -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
Re: Suggestions of David Nusinow, was: RPSL and DFSG-compliance - choice of venue
Hello Brian, * Brian Nelson <[EMAIL PROTECTED]> [2004-08-09 12:58]: > It can be really tough to test NM's who are not native English speakers > about licensing issues. Legal text is very different from colloquial > English, and non-native speakers are often completely overwhelmed. > Hell, even native speakers have difficulty understanding licenses like > the graphviz license. oh thats what i like to say too. read my emails :) regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
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...]
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=detail&aid=890674&; group_id=8642&atid=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: Please pass judgement on X-Oz licence: free or nay?
On 2004-08-09 10:38:45 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote: I don't see the difference. I mean, I see the difference that one can be read as an "assertion" and the other can be read as a "clause". But I don't see how that affects any practical or legal conclusions. In other words, if I write a license like the BSD one, but append "You will wear a hat on Fridays." I think it will be clear to everyone, including a judge, that I intend that to be a requirement to use the freedoms set forth in the license, even though it's just an "assertion" rather than a "clause". That's not the impression I have, especially given the "clarification" posts from X-Oz. Does someone know the legal reasoning of this? Would the same hold if you appended "You may not wear a hat on Fridays" which I think is closer to the BSD wording? MJ Ray wrote: No-one found a licence with a similar *condition* in it. The 3rd clause of the 3 clause BSD license. That says "may not be used to endorse or promote products derived from this software" while the X-Oz one says "shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software". There's the difference in verb, which I think is substantial, and I think X-Oz has added sufficient lawyerbombs to make me a lot more uncomfortable with it than the 3 clause BSD one. I suspect we also have more postitive clarifications about the BSD one. It is possible we will get a bizarre interpretation from a particular licensor, but we'll deal with that when it happens. I made a case elsewhere that the X wording is actually less restrictive because it only affects the original software, where the BSD clause affects all derived software. Do both affect derived software, because we need copyright permission for the original in order to use the derived, which would otherwise infringe copyright of the original? -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
Re: Please pass judgement on X-Oz licence: free or nay?
On Mon, 2004-08-09 at 03:31, MJ Ray wrote: > On 2004-08-09 05:35:10 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote: > > > Clause 4 -- which you declared non-free in that thread *before* public > > conversations with X-Oz, and Brian declared non-free at the start of > > this thread -- is identical to that used in the existing X license. > > It can be read as a simple assertion in the X licence > http://www.x.org/Downloads_terms.html (which seems to be how most > copyright holders have treated it), while the copyright permissions of > the X-Oz licence > http://lists.debian.org/debian-legal/2004/02/msg00154.html clearly > depend on it. I don't think it's identical. I don't see the difference. I mean, I see the difference that one can be read as an "assertion" and the other can be read as a "clause". But I don't see how that affects any practical or legal conclusions. In other words, if I write a license like the BSD one, but append "You will wear a hat on Fridays." I think it will be clear to everyone, including a judge, that I intend that to be a requirement to use the freedoms set forth in the license, even though it's just an "assertion" rather than a "clause". > I think I explained this to selussos <[EMAIL PROTECTED]> in > http://lists.debian.org/debian-legal/2004/03/msg00048.html but I got a > reply of a Mark Twain quote and an assertion that US law is global and > the subthread digressed without resolution. No-one found a licence > with a similar *condition* in it. The 3rd clause of the 3 clause BSD license. I made a case elsewhere that the X wording is actually less restrictive because it only affects the original software, where the BSD clause affects all derived software. > The summary http://lists.debian.org/debian-legal/2004/02/msg00229.html > may have bugs and need updating, but I doubt the ultimate outcome will > be different: software under the X-Oz licence does not clearly follow > DFSG. I agree with you on this; but I think it derives entirely from clause 3. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Bits from debian-legal between 2004-08-02 and 2004-08-08
This summary covers 2 August to 8 August 2004. http://lists.debian.org/debian-legal/2004/08/maillist.html#00052 Active threads with over 4 posts: Please pass judgement on X-Oz licences: free or nay?, over 40 posts, last post 8 Aug http://lists.debian.org/debian-legal/2004/08/threads.html#00014 RPSL and DFSG-compliance - choice of venue, over 10 posts, last post 8 Aug http://lists.debian.org/debian-legal/2004/08/threads.html#00051 RPSL and DFSG-compliance, under 10 posts, last post 8 Aug http://lists.debian.org/debian-legal/2004/08/threads.html#00032 Periodic summaries, under 10 posts, started 7 Aug, last post 8 Aug http://lists.debian.org/debian-legal/2004/08/threads.html#00143 Web application licenses, under 10 posts, last post 5 Aug http://lists.debian.org/debian-legal/2004/08/threads.html#00011 Acceptable copyright, under 10 posts, started 3 Aug, last post 8 Aug http://lists.debian.org/debian-legal/2004/08/threads.html#00104 Free non-software stuff, around 10 posts, last post 3 Aug http://lists.debian.org/debian-legal/2004/08/threads.html#6 Bits author picks: evan offers to summarise W3 software license http://lists.debian.org/debian-legal/2004/08/msg00174.html Tail of a htdig licensing thread http://lists.debian.org/debian-legal/2004/08/msg00035.html Mozilla relicensing progress http://lists.debian.org/debian-legal/2004/08/msg00144.html Notes about I think this should be done: The header should be obvious, I hope. The first section should be rigid forms of "subject, rough number, started date if in range, last post date, newline, link to thread index". The cutoff number should be set to get a maximum of the top 7. The second section is "author's description, newline, link to message". I counted posts helped by: wget -O- http://lists.debian.org/debian-legal/2004/08/maillist.html | sed -n -e '/Aug 02/,/Aug 09/{;s/^.*]*>//;s/Re: //g;s/<\/a.*$//;p;}' | sort | uniq -c | sort -n # pardon linewrap Please inform me of errors or improvements. -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast RFC3156 defines security multipart formats for MIME with OpenPGP. pgphmDeYwGZAH.pgp Description: PGP signature
summaries bugs, was: Please pass judgement on X-Oz licence: free or nay?
On 2004-08-09 06:17:17 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote: Since February, -legal has had an "official" (as official as they get) document claiming that even without further annoyances from X-Oz that clause is non-free. Simon Law, who wrote that summary, has since realized it was a huge mistake. That means something is wrong in the way we approach license analysis and summary writing. I agree that something is wrong. Most recently, I mentioned and made suggestions about this in http://lists.debian.org/debian-legal/2004/07/thrd3.html#00334 http://lists.debian.org/debian-legal/2004/07/msg00334.html and part of another subthread around http://lists.debian.org/debian-legal/2004/07/msg00219.html Sadly, I commit the same sin of poor referencing that I percieve as a problem with the summaries. I think the "unpleasantness" was mostly about the handling of the MPL threads that month and the month before. My suggestion wasn't clearly liked, but I feel there wasn't much participation. It seems that I don't have time to get discussion on this. You seem to care about fixing summaries too: please can you take it forwards? -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
Re: Suggestions of David Nusinow, was: RPSL and DFSG-compliance - choice of venue
On Sun, Aug 08, 2004 at 06:57:03PM -0500, Branden Robinson wrote: > [I am not subscribed to -newmaint.] > > On Fri, Jul 30, 2004 at 08:37:40PM +1000, Matthew Palmer wrote: > > For that matter, I'm not quite sure we should necessarily be subjecting > > applicants to the joys of rigorous licence analysis. We have d-legal for > > this purpose just so maintainers don't have to be licence experts. The > > question about Pine licencing is a pretty good test of basic DFSG analytical > > ability. > > The trouble is, some of the same people who are excused from doing rigorous > license analysis during P&P proceed to style themselves as licensing > experts and spitefully ridicule the people who *do* do the hard work on > debian-legal. We've seen great many examples of this over the past few > months. > > Count me in favor of increasing the amount of licensing-oriented material > in P&P. In my opinion, we want new developers to more easily grasp the > facts that: > > 1) sometimes subtle issues are involved when trying to understand a license; > 2) even licenses like the BSD and GPL represent compromises with "pure > freedom" > 3) phenomena like "moral rights" (droit d'auteur), software patents, and >regulations on cryptography can cause a given work under a given license >to be de facto licensed differently in different jurisdictions that >Debian cares about It can be really tough to test NM's who are not native English speakers about licensing issues. Legal text is very different from colloquial English, and non-native speakers are often completely overwhelmed. Hell, even native speakers have difficulty understanding licenses like the graphviz license. Making sure an NM grasps the gist of the DFSG is reasonable, but actually getting them to understand the subtleties involved is frustrating at best. -- You win again, gravity!
Re: Please pass judgement on X-Oz licence: free or nay?
On 2004-08-09 05:35:10 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote: Clause 4 -- which you declared non-free in that thread *before* public conversations with X-Oz, and Brian declared non-free at the start of this thread -- is identical to that used in the existing X license. It can be read as a simple assertion in the X licence http://www.x.org/Downloads_terms.html (which seems to be how most copyright holders have treated it), while the copyright permissions of the X-Oz licence http://lists.debian.org/debian-legal/2004/02/msg00154.html clearly depend on it. I don't think it's identical. I think I explained this to selussos <[EMAIL PROTECTED]> in http://lists.debian.org/debian-legal/2004/03/msg00048.html but I got a reply of a Mark Twain quote and an assertion that US law is global and the subthread digressed without resolution. No-one found a licence with a similar *condition* in it. The summary http://lists.debian.org/debian-legal/2004/02/msg00229.html may have bugs and need updating, but I doubt the ultimate outcome will be different: software under the X-Oz licence does not clearly follow DFSG. -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
Re: W3 software license
On Sun, Aug 08, 2004 at 05:36:29PM -0700, Josh Triplett wrote: > >>>The license looks OK to me, with the possible exception that it says > >>>"obtaining, using and/or copying this work" implies acceptance of the > >>>license. > > I think it sets a bad precedent to wave such language into a > > list of licenses we accept as DFSG-free without at least asking the > > upstream authors to remove this wording. Why don't we do this: I'll write up a summary of the license, and note that we think that works released under the license would, barring complications, be free. I'll also add a suggestion to drop the use language. How does that sound? ~ESP
Re: Please pass judgement on X-Oz licence: free or nay?
On Sun, 2004-08-08 at 17:57, Branden Robinson wrote: > On Tue, Aug 03, 2004 at 12:20:47PM -0500, Joe Wreschnig wrote: > > On Tue, 2004-08-03 at 11:15, Matthew Garrett wrote: > > > The summary claims that clause 4 makes the license non-free. > > ...because we don't undestand what X-Oz means when they say it. ... which you didn't know until after the summary was published and even then I don't find questions of interpretations of clause 4, but mostly about clause 3. I'd prefer follow-ups on this topic to go to the other subthread though. > > > Since clause 4 is identical to what's contained in the X11 license, it > > > makes it difficult to take the summary terribly seriously. > > > > Oh, wow. > > > > Shame on you, Branden, for placing Debian's X packaging scripts under a > > non-free license! Or have you recanted from your position in > > http://lists.debian.org/debian-legal/2004/02/msg00162.html? > > Is this sort of remark intended to be productive, or are you just venting > your spleen because you don't appear to have actually comprehended the > message you cite? Since February, -legal has had an "official" (as official as they get) document claiming that even without further annoyances from X-Oz that clause is non-free. Simon Law, who wrote that summary, has since realized it was a huge mistake. That means something is wrong in the way we approach license analysis and summary writing. My hope is that in the future we will be more careful in our evaluation of licenses; we will compare them to existing licenses more often; we will try to keep our core criteria as the DFSG, and try, whenever possible, to relate arguments back to the DFSG. I don't think they're exhaustive or meant to be, but lately it seems that the proposed tests are our "core" criteria and the DFSG are treated as a sort of footnote. I realize this is because often the licenses we deal with here are on the borderline. But just because the DFSG aren't a checklist doesn't mean they're not useful. We also need to engage the rest of the project more; a common criticism of -legal is that we're too strict, and too closed to new ideas and participants. A good way to stop being closed is to admit when we're wrong. And that summary is wrong. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part