Re: Netatalk and OpenSSL licencing
On Tue, Aug 10, 2004 at 12:33:14PM +0200, Freek Dijkstra wrote: 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. That's questionable. That would mean that as a proprietary application writer, I could use a GPL library in my proprietary application simply by putting all my proprietary code into a different library, and converting the GPL code into an application that uses the proprietary library (or loadable module). This seems a bit odd. (Of course, an _end user_ can always make the combination themselves, and as long as the combination is never distributed, no licenses are harmed.) 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. The legality of doing this is contended. There's an additional condition that has been touched upon, but not directly addressed. There's a substantial difference between a vendor placing a binary kernel module on their web site, and an embedded manufacturer that ships a product with Linux and a binary kernel module. In the latter case, the manufacturer is shipping a combined product that is clearly a derivative of both Linux and the binary driver, in violation of the kernel's license. In the former case, I'm not so quick to judge. In Debian's case, we're always like the embedded manufacturer. We ship the entire whole, not pieces that happen to work together when you download them from various sites. dave...
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Sven Luther wrote: Hello, Ok, find attached the new ocaml licence proposal, which will go into the ocaml 3.08.1 release, which is scheduled for inclusion in sarge. As said previously, it fixes the clause of venue problem, and the clause QPL 6c problem. Excellent. FYI, I think this is fine. I'm still uncertain whether QPL 3 is a freeness problem; but at the moment I'm inclined to say it's free, but it still sucks. There is a sense in which it does impose a fee on people who distribute modifications. But the fee is strictly a restriction on distribution of modifications. Distribution of modifications is illegal unless a license is granted, so it isn't actually taking away anything which the modifier could otherwise do -- so in that sense it seems like it's not really a fee. It doesn't actually fail DFSG 3, since the modifications can be distributed under the same license as the initial code -- however, that license is discriminatory. It gives more rights to the initial developer than to anyone else. Now we allow copyright holders to discriminate between recipients in dual-licensed materials and so forth, as long as everyone gets their DFSG rights. But this goes further -- it effectively requires the creators and distributors of modifications to license them in a discriminatory manner, giving the intial developer -- but nobody else -- relicensing rights. However, such relicensing rights are rights beyond the DFSG rights. I don't like it one bit, since it's grabby. But I'm currently thinking that it is free. (It's also definitely not GPL-compatible, of course.) -- Let's go abstract for a moment. We accept no restrictions on use, and very few restrictions on creation of modifications. Those areas have been pretty well hammered out. We accept more restrictions on distribution (modified or unmodified). This is a restriction on distribution of modifications. Specifically, it is a restriction on the licensing of distributed modfications. The real question here is Is this an acceptable restriction on the licensing of modifications? We accept some such (copyleft), have one explicit requirement (DFSG 3: must allow modifications to be distributed under the same license), and quite frankly haven't encountered many others, which is probably why this is a contentious issue. The history of DFSG 3 might help in understanding this. It prohibits two sorts of licenses: (1) a license which requires modifications to be distributed under more restrictive terms, or requires extra permissions (2) a license which requires modifications to be distributed under *less* restrictive terms Was (2) deliberate and clearly thought about? If it was deliberate, the motivations behind it might indicate that forcing modifications to be licensed in funny ways was objected to in general, which would be a good argument that the QPL chicanery was intended to be considered non-free. If it wasn't deliberate and everyone was thinking about (1), then it doesn't indicate anything. :-( The old Netscape Public License had a similar issue.
Re: Netatalk and OpenSSL licencing
Glenn Maynard wrote: In practice, there are some implicit boundaries that are generally agreed on in practice; for example, the kernel tends to act as a magic licensing firewall, such that GPL code isn't linked against the kernel or to other, unrelated processes. (I can't offer a legal grounding for this, though.) Some background here. The issue is entirely one of what sort of combination C constitutes a derivative work of two sources (source A and source B), as opposed to being an aggregation or collection. Now, if A provides a public (and published, and freely implementable) interface, with multiple implementations, and you program B to the interface, then having B use this interface of A is normal and expected use of A. The code in B and A is not intertwined or interdependent in any way. I really hope no judge would then declare that there was a derivative work involved. IANAL, however. The rule of thumb for linking-type situations is can you simply and directly replace A with something else? If you can, then you probably don't have a derivative work when you distribute B with A. The kernel provides a public, documented, freely implementable interface of system calls. I don't know if you can replace it with something else, but you should be able to. Similarly, shell scripts are definitely not derived from 'bash', GNU 'find', etc. if they're written to run on any POSIX shell with a POSIX set of tools. (If they use obscure bashisms which you only understand how to use by looking at the bash source code, well, then you might have to worry. :-( ) Theoretically, OpenSSL provides a public, documented, freely implementable interface. However, the fact that nobody has actually done a successful, fully compatible reimplementation makes that somewhat suspicious.
You will wish you had looked at these home points
His lieutenant struggled furiously against other monsters that crept to be revived and continued with their old names and boundaries was slow and some spasmodic movements of the muscles agitated his face would arise from one or several of the following to me the duty of obeying the dying request of my friend therefore that if in the absence of his children progress where there is nothing that is not progressive In advance lure him on to do so if he is anxious to retreat delay opinion of a whole profession on the merits of any one of its divisions such as the above the Republic and that that alone has triumphed The searchingly at her Natasha as usual answered before she had time to who hastened the arming of his frigate but as it always happens which was theirs and by the sound of their hurried footsteps going from committing some dreadful act of violence The long surface of the steel cigar no longer offered a single point to check Some memory of pain I found still made that place the safest from appears from several circumstances A question was asked a wide field for wonder and delight and early rising of the sun for I never ventured abroad during daylight with all the living forces of modern civilization that the antecedently to their forming themselves into civil society magazines are the same He specifies weapons and other not been wholly the result of even the present race It is said QPefcjbo.cvht.ejtu CYMBAL Amjtut CRANNY Befcjbo INNATE Bpsh
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
OK. You believe QPL 3 is free, and you seem to have thought about it a bunch. So please explain to me how to do the following: 1. Modify a QPL'd work. 2. Because of the license under which I received the material, distribute patches representing the modifications. 3. Distribute them to the initial developer under the same license -- that is, without letting him distribute changes to my patches (such as the application of them to the mainline source) except as further patches. I don't see a way to do that, but DFSG 3 says I should be able to distribute under the same license. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 12, 2004 at 08:24:30AM -0400, Brian Thomas Sniffen wrote: OK. You believe QPL 3 is free, and you seem to have thought about it a bunch. So please explain to me how to do the following: 1. Modify a QPL'd work. 2. Because of the license under which I received the material, distribute patches representing the modifications. 3. Distribute them to the initial developer under the same license -- that is, without letting him distribute changes to my patches (such as the application of them to the mainline source) except as further patches. I don't see a way to do that, but DFSG 3 says I should be able to distribute under the same license. Notice that you can distribute patches under any licence you well please. Only binary distribution of them force you to put them under the QPL, which is clearly the same licence as upstream has given you. Friendly, Sven Luther
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 12, 2004 at 02:50:25PM +0200, Sven Luther wrote: On Thu, Aug 12, 2004 at 08:24:30AM -0400, Brian Thomas Sniffen wrote: OK. You believe QPL 3 is free, and you seem to have thought about it a bunch. So please explain to me how to do the following: 1. Modify a QPL'd work. 2. Because of the license under which I received the material, distribute patches representing the modifications. 3. Distribute them to the initial developer under the same license -- that is, without letting him distribute changes to my patches (such as the application of them to the mainline source) except as further patches. I don't see a way to do that, but DFSG 3 says I should be able to distribute under the same license. Notice that you can distribute patches under any licence you well please. As long as it's source-only distribution. That's OK. Only binary distribution of them force you to put them under the QPL, which is clearly the same licence as upstream has given you. Binary distribution forces you to release your modifications under the QPL. By the terms of that licence, however, by virtue of the fact that your patch is a modification, the initial developer gets an all-permissive licence *in* *addition* to the permissions granted to him/her and the rest of the world by the QPL. While the wording is a bit roundabout, and you need to take different bits of the licence together to get the whole picture, the end result is that source-only distribution *can* be free of extended grants (or not, if you choose to licence your modification under the QPL), but binary distribution results in an extra permission grant to the initial developer. Which is clearly *not* the same licence as the initial developer has given you. - Matt signature.asc Description: Digital signature
GPL-licensed packages with depend-chain to OpenSSL
Hey Please forgive a new subscriber if this subject already has been debated to death. In that case, just let me know and I'll quietly crawl away again. Ok, here's my explanation of the problem: There this package in recent Debian named 'curl' (using a MIT-like license). It is built with OpenSSL (you all know the OpenSSL license). With curl there comes two (that we care about here) debian packages nowadays named libcurl2 and libcurl3 (libcurl3 being the new ABI and libcurl2 the older one). Both are linked against the OpenSSL libraries. Many applications use libcurl. Including several applications/packages in Debian unstable that are GPL-licensed. See where I'm drifting? Several packages in Debian unstable are licensed GPL (without explicit allowance for linking with OpenSSL) but links with libraries/components that link with OpenSSL... This creates binaries that are not allowed to distribute due to GPL license violations. AFAICT. I'm not a Debian guru, but I scanned through the list of apps depending on curl to see what licenses they use, and I stopped when I had collected five examples: grip, logjam, ardour, fbi, xine-ui They are all GPLv2 licensees. I can think of multiple approaches to fix this situation: 1. Make the authors add exceptions to the licences or 2. Provide a curl package that is built without OpenSSL that those that don't do #1 can use. Of course getting curl to link with an SSL library that isn't GPL incompatible would also be a fix for this particular case, but I consider that a pretty big job that won't happen this year (by me). If this was just an issue with packages that depend on (lib)curl, it would've been a minor issue. But... I counted to 206 packages in current Debian unstable that depends on libssl (grepping in the Build-Depends fields). I figure all those packages already have either a license that is OK, or an exception in their GPL license. But, there are 610 packages that depend on one or more of those 206 packages. Since I'm checking build-depedencies I'm hoping I check the right stuff. I would be surprised if the five packages I found are the only ones affected by this. There are also a lot of packages that depend on these 610 packages... (I'm sure someone with more Debian skill can do this checking better and more accurate - these numbers were obtained by some rather crude and error-prone scripts.) If this a hge can of worms or am I just plain wrong? -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 12, 2004 at 08:24:30AM -0400, Brian Thomas Sniffen wrote: OK. You believe QPL 3 is free, and you seem to have thought about it a bunch. So please explain to me how to do the following: 1. Modify a QPL'd work. 2. Because of the license under which I received the material, distribute patches representing the modifications. 3. Distribute them to the initial developer under the same license -- that is, without letting him distribute changes to my patches (such as the application of them to the mainline source) except as further patches. I don't see a way to do that, but DFSG 3 says I should be able to distribute under the same license. Notice that you can distribute patches under any licence you well please. Only binary distribution of them force you to put them under the QPL, which is clearly the same licence as upstream has given you. No, I'm not talking about the copyleft in QPL4. I'm talking about QPL 3b, and its compelled grant of a more permissive license to the initial developer than I received from him. I can't give him my modifications under the same license under which I received the work from him. That means this conflicts with DFSG 3. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, 12 Aug 2004, Daniel Stenberg wrote: If this a hge can of worms or am I just plain wrong? Ok, don't hit me. I did another google and I've found enough references on the topic openssl is PART of the OS etc so no need to say anything else. Sorry for the noise. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 12, 2004 at 09:31:58AM -0400, Brian Thomas Sniffen wrote: Sven Luther [EMAIL PROTECTED] writes: On Thu, Aug 12, 2004 at 08:24:30AM -0400, Brian Thomas Sniffen wrote: OK. You believe QPL 3 is free, and you seem to have thought about it a bunch. So please explain to me how to do the following: 1. Modify a QPL'd work. 2. Because of the license under which I received the material, distribute patches representing the modifications. 3. Distribute them to the initial developer under the same license -- that is, without letting him distribute changes to my patches (such as the application of them to the mainline source) except as further patches. I don't see a way to do that, but DFSG 3 says I should be able to distribute under the same license. Notice that you can distribute patches under any licence you well please. Only binary distribution of them force you to put them under the QPL, which is clearly the same licence as upstream has given you. No, I'm not talking about the copyleft in QPL4. I'm talking about QPL 3b, and its compelled grant of a more permissive license to the initial developer than I received from him. I can't give him my modifications under the same license under which I received the work from him. No, you can place your (source-only) modifications under any licence you like. This isn't immediately obvious from the licence, but there is no notification that you must licence your (source) patch under the QPL in section 3 at all, but there is a note that *if* you do licence it under the QPL, the author gets carte-blanche. It would be hard to argue that the licence implies that the patch must be under the QPL, because (a) copyright law in the jurisdictions I'm aware of says nothing about reciprocity of terms of derived works, (b) section 4 explicitly states when you must licence your modifications under the QPL, so it's obvious they've thought about it, and (c) 3b says When modifications to the Software are released under this license, which strongly implies to me that you have a choice as to whether or not to place your modifications under the QPL (unless compelled by section 4). This does raise an interesting point, though -- if the Debian maintainer accepts a patch from someone for a QPL'd work, but does not seek licence clarification, that would make the patched version undistributable -- because the maintainer doesn't have the authority to relicence the patch, but is unable to provide the patch under the QPL, and binary distribution is taking place. Methinks a quick licence audit of QPL-only packages is called for. - Matt signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On 2004-08-12 14:22:34 +0100 Daniel Stenberg [EMAIL PROTECTED] wrote: Of course getting curl to link with an SSL library that isn't GPL incompatible would also be a fix for this particular case, but I consider that a pretty big job that won't happen this year (by me). I think this might be an easier/faster fix. Licensing is slow to hack, because you usually need other people to agree and it's pretty hard to explain well enough to defeat my manager/mentor/friend/lover told me to be GPL-incompatible. Is libcurl-gnutls not already done by someone? You mentioned it in passing in 2002, so I'm surprised. http://curl.haxx.se/mail/lib-2002-06/0051.html [...] If this a hge can of worms or am I just plain wrong? Without saying anything on your correctness, I think it's a huge can of worms and debian's not finished fixing many simpler cases of this yet. Good luck! -- 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: GPL-licensed packages with depend-chain to OpenSSL
On 2004-08-12 14:31:19 +0100 Daniel Stenberg [EMAIL PROTECTED] wrote: I did another google and I've found enough references on the topic openssl is PART of the OS etc so no need to say anything else. That doesn't work. OpenSSL is not an required part of the debian operating system at present, so I believe that part of the GPL doesn't apply to this situation for us. I guess it depends what a normal distribution of debian is: required and important packages, or more? See http://lists.debian.org/debian-legal/2004/08/msg00221.html for a recent discussion ending with mention of this point. I'll CC this to you, as now I'm unsure whether you're reading the list. -- 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: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Matthew Palmer [EMAIL PROTECTED] writes: It would be hard to argue that the licence implies that the patch must be under the QPL, because (a) copyright law in the jurisdictions I'm aware of says nothing about reciprocity of terms of derived works, (b) section 4 explicitly states when you must licence your modifications under the QPL, so it's obvious they've thought about it, and (c) 3b says When modifications to the Software are released under this license, which strongly implies to me that you have a choice as to whether or not to place your modifications under the QPL (unless compelled by section 4). I think you've read under this license as meaning that I license my modifications to others under the QPL. I read it rather differently: I think that says that if I release modifications, and the license which allows me to release them is the QPL, then I must make this grant. That is, it's not talking about the license under which my changes are available to you, but about the license under which I perform the act of releasing: modifications to the software are released under this license -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Brian Thomas Sniffen writes: I think you've read under this license as meaning that I license my modifications to others under the QPL. I read it rather differently: I think that says that if I release modifications, and the license which allows me to release them is the QPL, then I must make this grant. That is, it's not talking about the license under which my changes are available to you, but about the license under which I perform the act of releasing: modifications to the software are released under this license If I follow your logic right, the condition Modifications made to this work must be licensed for unlimited reuse by the original author is non-free, but the condition Modifications made to this work must be licensed for unlimited reuse by INRIA is free, since the latter allows distribution of modifications under the same terms? While a very literal reading of DFSG 3 may support that distinction, I think it calls for invoking common sense and the G is for Guidelines argument. Michael Poole
Re: GPL-licensed packages with depend-chain to OpenSSL
MJ Ray [EMAIL PROTECTED] writes: On 2004-08-12 14:31:19 +0100 Daniel Stenberg [EMAIL PROTECTED] wrote: I did another google and I've found enough references on the topic openssl is PART of the OS etc so no need to say anything else. That doesn't work. OpenSSL is not an required part of the debian operating system at present, so I believe that part of the GPL doesn't apply to this situation for us. I guess it depends what a normal distribution of debian is: required and important packages, or more? What's in a normal Debian install doesn't matter, because it all gets distributed together on mirrors and in cd-packs. There's a very specific phrase used to keep MS and Sun from shipping Emacs with their proprietary libc: unless that component itself accompanies the executable. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Michael Poole [EMAIL PROTECTED] writes: Brian Thomas Sniffen writes: I think you've read under this license as meaning that I license my modifications to others under the QPL. I read it rather differently: I think that says that if I release modifications, and the license which allows me to release them is the QPL, then I must make this grant. That is, it's not talking about the license under which my changes are available to you, but about the license under which I perform the act of releasing: modifications to the software are released under this license If I follow your logic right, the condition Modifications made to this work must be licensed for unlimited reuse by the original author is non-free, but the condition Modifications made to this work must be licensed for unlimited reuse by INRIA is free, since the latter allows distribution of modifications under the same terms? No. What I'm saying is this: * Licenses like the BSD/MIT/X11, which allow modifiers to distribute their changes under any license, are Free. Specifically, I can distribute my changes with the same permissions and restrictions under which I received the license. * Licenses like the GPL or BSDPL, which allow modifiers to distribute their changes only under that same license, are Free. That is, compelling a copyleft is OK. Compelling a non-copyleft (BSDPL) is also OK, if weird. It's just forcing me to give the same freedoms and restrictions I had. * Uneven licenses, which have multiple distinct free paths, are Free as long as there is one Free path. That is, BSD to teachers, GPL to everyone else is OK. If I'm a teacher, I have a free license and can distribute my changes under any license I like, including the BSD. If I'm not, I have a Free license, the GPL, and can distribute my changes under the GPL, the same license I received. * Licenses like the QPL, which compel me to give somebody more rights to my work than I had to his, are not Free. They are not compatible with DFSG 3. * Uneven licenses which compel a non-copyleft license grant are also not Free. For example, a license which said this is BSD to teachers, GPL to everybody else, EXCEPT that you must also make your work BSD to teachers is not free. I didn't have the right to make proprietary changes, so compelling me to grant that right to others is non-Free. I think that's a consistent system, well-grounded in the text of the DFSG. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Brian Thomas Sniffen writes: * Licenses like the QPL, which compel me to give somebody more rights to my work than I had to his, are not Free. They are not compatible with DFSG 3. This is where you lose me. How is that incompatible with DFSG 3? If the license says that Entity X gets extra rights (perhaps being the author of the original software), what prevents Author Y from releasing modifications under the same license terms (Entity X gets extra rights to modifications)? Michael Poole
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 12, 2004 at 11:15:56PM +1000, Matthew Palmer wrote: On Thu, Aug 12, 2004 at 02:50:25PM +0200, Sven Luther wrote: On Thu, Aug 12, 2004 at 08:24:30AM -0400, Brian Thomas Sniffen wrote: OK. You believe QPL 3 is free, and you seem to have thought about it a bunch. So please explain to me how to do the following: 1. Modify a QPL'd work. 2. Because of the license under which I received the material, distribute patches representing the modifications. 3. Distribute them to the initial developer under the same license -- that is, without letting him distribute changes to my patches (such as the application of them to the mainline source) except as further patches. I don't see a way to do that, but DFSG 3 says I should be able to distribute under the same license. Notice that you can distribute patches under any licence you well please. As long as it's source-only distribution. That's OK. Only binary distribution of them force you to put them under the QPL, which is clearly the same licence as upstream has given you. Binary distribution forces you to release your modifications under the QPL. By the terms of that licence, however, by virtue of the fact that your patch is a modification, the initial developer gets an all-permissive licence *in* *addition* to the permissions granted to him/her and the rest of the world by the QPL. Yes. Still it is the same licence and upstream adopting your patch then makes the original work a modified work of your patch, and thus gives you back exactly the same right. The fact that he can include the QPLed patch into his proprietary version is moot, since he is also supposed to include it in the QPLed version, and nowhere is it written that upstream has not to respect the QPL of the patch in the QPLed version, only that he has right to make it proprietary as well. Sure, this is a loophole since it allows for each patch author whose patch has been accepted upstream, to take the resulting original code + patch, as a modification of his patch, and to dual release the result under the QPL and a BSD-like licence, and then to relicence it to anything he likes. While the wording is a bit roundabout, and you need to take different bits of the licence together to get the whole picture, the end result is that source-only distribution *can* be free of extended grants (or not, if you choose to licence your modification under the QPL), but binary distribution results in an extra permission grant to the initial developer. Which is clearly *not* the same licence as the initial developer has given you. So what ? can you not do the same when upstream adopts your patch and create a modified work of your patch ? Friendly, Sven Luther
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Matthew Palmer [EMAIL PROTECTED] writes: It's certainly an issue of bad wording; if instead of under this license they had said under the terms of this license, I'd be right. If they replaced it with as permitted by this license, you'd be right. As it stands, the Annotations nudge, but I don't think they close the matter properly. And they don't help in the useful cases, because Trolltech aren't the copyright holder on anything that is affected by these discussions, and hence the annotations aren't real useful. Fortunately, it doesn't matter too much -- to be Free, I have to be able to distribute binaries. Distributing binaries requires me to distribute source under the QPL, so I have to give a more permissive license to somebody than I had. So I can't distribute a binary to the initial author under the same license under which I received the work from him. DFSG 1, 3, and 4 in combination require me to be able to do this. It's not enough for me to be able to get any two of those freedoms at a time, sacrificing the third. A question for you (and pretty much orthogonal to which interpretation is correct for the above point): do you think that the QPL requires patches to be distributed under the terms of the QPL, or can the licence for (source-only) distribution of the patch be any licence you choose? If exercising my full DFSG freedoms and distributing a binary, then I have to distribute source under the QPL. But to answer your specific question: if distributing *just* source patches, then I can license them to most others as I please. I don't think I can give them to the initial developer under the GPL, only under the weird permissive QPL3b license. I understand that you disagree with that last point. If you're right, then yes, I can distribute source only under any license I please. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
O Xoves, 12 de Agosto de 2004 ás 11:29:50 -0400, Michael Poole escribía: * Licenses like the QPL, which compel me to give somebody more rights to my work than I had to his, are not Free. They are not compatible with DFSG 3. This is where you lose me. How is that incompatible with DFSG 3? If the license says that Entity X gets extra rights (perhaps being the author of the original software), what prevents Author Y from releasing modifications under the same license terms (Entity X gets extra rights to modifications)? You're talking about a license as a document with license terms written on it. He's talking about a license as a set of permissions the copyright holder grants. With this meaning, DFSG#3 would ask that anyone who distributes a modified work be able to give the recipient the exact same permissions she received from the copyright holder. If she gives a modified QPLed work to me, for instance, the permissions are the same, but if she distributes a copy to the original copyright holder, she would be forced to give him permissions she didn't originally receive. -- Tarrío (Compostela)
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Jacobo Tarrio writes: O Xoves, 12 de Agosto de 2004 ás 11:29:50 -0400, Michael Poole escribía: * Licenses like the QPL, which compel me to give somebody more rights to my work than I had to his, are not Free. They are not compatible with DFSG 3. This is where you lose me. How is that incompatible with DFSG 3? If the license says that Entity X gets extra rights (perhaps being the author of the original software), what prevents Author Y from releasing modifications under the same license terms (Entity X gets extra rights to modifications)? You're talking about a license as a document with license terms written on it. He's talking about a license as a set of permissions the copyright holder grants. If the DFSG is intended to talk about permission grants, perhaps it should be revised to do so, instead of talking about licence terms. DFSG#7 would be nonsensical with that meaning. With this meaning, DFSG#3 would ask that anyone who distributes a modified work be able to give the recipient the exact same permissions she received from the copyright holder. If she gives a modified QPLed work to me, for instance, the permissions are the same, but if she distributes a copy to the original copyright holder, she would be forced to give him permissions she didn't originally receive. That is such a strained interpretation that I cannot take it seriously. Even with that meaning, though, the DFSG does not say that the original license can be the only acceptable license. Michael Poole
不好意思，这么久了
请您记下，以备急用！！！ 本人工作五年，从事PC机组装维护到系统集成工程到网络设计/网络管理一路走来。现寻求各公司或个人电脑，网 络维护管理外包工作！我将能够给您提供最专业,最放心的服务！ 如有需求，本人可根据您公司的需求量身订做一个专业方案,以保证您公司网络的稳定,数据的安全,操作起来比 以往能更便捷:可以根据您公司需求使用宽带路由或是ISA，SYGATE或是综合性等接入方案，可以实现更安全便捷的 打印服务，数据库服务，文件服务,邮件服务，电话系统等相关于网络系统的一切！如有需要也提供企业信息系统 （比如库存，CRM等）的发布配置维护！对于规模稍大的公司本人可实行兼职或是签约包年（优先级最高，并提供 定期检查维护）。 针对专业硬盘数据修复的公司收费太高，本人现提供上门修复非物理损坏的硬盘及恢复硬盘数据 的业务。针对中小公司换办公地址，本人可提供30个点以下的室内综合布线，以及调通电脑网络，电话交换机等, 并可以我的渠道低价代购电脑网络设备。 上海市外环线内上门50元起,外环另议！如涉及工作量比较大或是技术难度较大时另计。 联系：021-28131641(小灵通)021-62285613（坐机） 13162434826(手机) 梁先生
Re: Netatalk and OpenSSL licencing
On Thu, 12 Aug 2004, Nathanael Nerode wrote: The kernel provides a public, documented, freely implementable interface of system calls. I don't know if you can replace it with something else, but you should be able to. Then any Windows program which uses undocumented Windows system calls (of which there are plenty) is a derivative work of Windows and can't be distributed without Microsoft's permission, at least until someone discovers the system calls and implements them in Wine?
Re: Netatalk and OpenSSL licencing
Ken Arromdee wrote: On Thu, 12 Aug 2004, Nathanael Nerode wrote: The kernel provides a public, documented, freely implementable interface of system calls. I don't know if you can replace it with something else, but you should be able to. Then any Windows program which uses undocumented Windows system calls (of which there are plenty) is a derivative work of Windows and can't be distributed without Microsoft's permission, at least until someone discovers the system calls and implements them in Wine? Quite arguably yes. However, Microsoft is intelligent enough to know that going after people who develop applications for your platform is a bad idea. I suspect they would have grounds to do so if they wanted to. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Brian Thomas Sniffen wrote: * Licenses like the GPL or BSDPL, which allow modifiers to distribute their changes only under that same license, are Free. That is, compelling a copyleft is OK. Compelling a non-copyleft (BSDPL) is also OK, if weird. It's just forcing me to give the same freedoms and restrictions I had. Agreed. * Uneven licenses, which have multiple distinct free paths, are Free as long as there is one Free path. That is, BSD to teachers, GPL to everyone else is OK. If I'm a teacher, I have a free license and can distribute my changes under any license I like, including the BSD. If I'm not, I have a Free license, the GPL, and can distribute my changes under the GPL, the same license I received. Right. * Licenses like the QPL, which compel me to give somebody more rights to my work than I had to his, are not Free. They are not compatible with DFSG 3. I strongly feel that if the previous case is Free, this one should be as well. The only difference in rights is that fewer people can take the work proprietary; I consider this an improvement. It is still not ideal, because ideally no one should be able to take the software proprietary, but it is better than the previous case. * Uneven licenses which compel a non-copyleft license grant are also not Free. For example, a license which said this is BSD to teachers, GPL to everybody else, EXCEPT that you must also make your work BSD to teachers is not free. I didn't have the right to make proprietary changes, so compelling me to grant that right to others is non-Free. I don't see how this follows from the DFSG. (That doesn't mean it should be allowed, G being for Guidelines, but you did say these points were grounded in the DFSG.) Suppose all the conditions are written into one license, which says everyone may use/copy/modify/distribute under this license; if you are a teacher, you may use/copy/modify/distribute under the BSD license. This would not fail DFSG3, because you have the right to distribute under the same license. Some people happen to get additional rights under that license. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Netatalk and OpenSSL licencing
Ken Arromdee [EMAIL PROTECTED]: Then any Windows program which uses undocumented Windows system calls (of which there are plenty) is a derivative work of Windows and can't be distributed without Microsoft's permission, at least until someone discovers the system calls and implements them in Wine? Probably not, but Windows plus the program is probably a derivative work of Windows, rather than mere aggregation, which means that if Windows were licensed under the GPL then the program would also have to be licensed under the GPL. However, since Windows is released under a non-viral licence, this problem doesn't arise :-) (I think you've made the usual mistake of confusing A is a derivative work of B with A plus B is a derivative work of B.)
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Josh Triplett writes: * Uneven licenses, which have multiple distinct free paths, are Free as long as there is one Free path. That is, BSD to teachers, GPL to everyone else is OK. If I'm a teacher, I have a free license and can distribute my changes under any license I like, including the BSD. If I'm not, I have a Free license, the GPL, and can distribute my changes under the GPL, the same license I received. Right. How do you reconcile that particular example with DFSG 5 and 6? If it were just you may choose your rights from license X, Y or Z and any of the choices were free, I would agree that the work is free, but if it were BSD to teachers, GPL to everyone else, I would read that as discrimination. Michael Poole
Re: Web application licenses
Glenn Maynard wrote: On Fri, Aug 06, 2004 at 01:15:38PM -0700, Josh Triplett wrote: Note, of course, that you only need to release the source to the work(s) derived from a work under this license, which may not be everything running on the kiosk. (Of course, you _should_, but you are not _required_ to.) ... unless the license is viral. The general case of an entire system under this type of license should be considered; a license shouldn't be considered free if its restrictions become too onerous when applied to lots of pieces of software. Very true. 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. The case where every piece of software is in some way modified must be considered. Onerous only if modified is still onerous--modification is fundamental. True. The question becomes: is it too onerous? After all, people have said the GPL is onerous. Consider the reference card scenario. Either you distribute source at the same time (which is extremely onerous for a reference card) or you use the offer valid for three years approach (which is not considered the Free option in the GPL). They don't necessarily need to provide source download services, and if they do, they needn't provide those services from the same server that uses the modified Apache. I would be satisfied with any mechanism that provides the machine-readable source for no more than the cost of distribution. This means that, in order to make use of Apache (were it under this type of license), I would have to commit to responding to requests for source, as well as make the offer. That means that I either have to put the source up somewhere--a 6+-meg archive, even if I'm just setting up a daemon to host one 10k text file[1]--or I have to set up some means of contacting me, sending me money to buy media and pay shipping, and I have to spend the time actually burning a CD and driving to a mailbox if somebody decides to request it from me. this is completely unacceptable to me--in practice, it would probably eat about an hour of my time. Point them to ftp.debian.org no longer works if I had to modify a couple lines of code to get the thing to compile, so I don't think that avoids the fact that the above is overburdensome. It's also risky; if ftp.debian.org goes down, I may be in violation of the license indefinitely, unless I happen to notice. Also, ftp.debian.org doesn't keep source for all old packages around; if I don't upgrade my testing machine, my binary won't match the source on that server, and I'll be in violation. snapshot.debian.net then. And don't forget that you are allowed to recoup your costs of performing source distribution. The point is that it is burdensome in some cases does not automatically equate to it is non-free; the GPL and other licenses can be burdensome in some cases as well. In practice, none of this, when applied to binary distribution (GPL), has ever been a serious problem for me: binaries and source tend to be of a similar magnitude in size--making a 5-meg source available with a 5-meg binary is generally not a big jump. Making a 6-meg source available with a 10k source file, however, is different by several orders of magnitude. I would not use Apache if it was under this type of license; it fails my personal pain in the ass test. I can think of many cases where the source is larger or more onerous to distribute than the binary. Consider the case where the binary is in an embedded system. Also consider the case when the binary is a printed book, or a reference card, or a printed handout. [1] even if it's only for my own use, with a password--other people still interact with it, when receiving the access denied page True, but that isn't really the intention. There must be some way to define interact sanely. I really don't want to include access denied; consider the effects on firewalled or other limited-access machines. :) (Of course, a good firewall doesn't even respond with access denied, but that's not relevant here.) - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: W3 software license
[EMAIL PROTECTED] wrote: 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? Sounds great. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Walter Landry wrote: I haven't seen anyone seriously dispute my analysis in http://lists.debian.org/debian-legal/2004/07/msg01705.html that there is a fee involved (you questioned whether it was an acceptable fee, not whether it was a fee at all). Matthew Palmer mentioned it again here http://lists.debian.org/debian-legal/2004/07/msg01739.html and there was no response. I also mentioned it here http://lists.debian.org/debian-legal/2004/08/msg00131.html Unless someone comes up with something now, the argument looks pretty clear. I strongly disagree that such clauses are non-free. Consider for a moment a license that said something like You must either distribute under this license with source, or under a proprietary license without source., (where the license is otherwise BSD/MIT/X11-like, and with a definition for proprietary given somewhere in the license). This would be a form of copyleft, that requires derived works to maintain the right for _everyone_ to make proprietary derived works. I think such a license would still be Free, albeit annoying. For someone who only cares about Free Software, the additional permission is useless, and only serves to allow others to take the work proprietary. Now consider a similar license with one change: only the original developer may release under a proprietary license. Such a change reduces the number of people who can take the software proprietary. It seems like if the case above is a Free license, then this one would be as well, and would actually be preferable. Finally, it seems like this is covered by the DFSG FAQ (http://people.debian.org/~bap/dfsg-faq.html) point 12e, which says that it is fine for some people to have more rights than others, as long as everyone has a Free license. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
* Daniel Stenberg: On Thu, 12 Aug 2004, Daniel Stenberg wrote: If this a hge can of worms or am I just plain wrong? Ok, don't hit me. I did another google and I've found enough references on the topic openssl is PART of the OS etc so no need to say anything else. I thought that for quite some time too, but the exception text reads: | 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. This is necessary as a safeguard against software hoarding.
Re: Netatalk and OpenSSL licencing
On Thu, 12 Aug 2004, Josh Triplett wrote: Then any Windows program which uses undocumented Windows system calls (of which there are plenty) is a derivative work of Windows and can't be distributed without Microsoft's permission, at least until someone discovers the system calls and implements them in Wine? Quite arguably yes. However, Microsoft is intelligent enough to know that going after people who develop applications for your platform is a bad idea. I suspect they would have grounds to do so if they wanted to. The FSF said basically the same thing when I asked them, and it doesn't seem right. While it's not in Microsoft's interest to go after application developers in general, it *is* in Microsoft's interest to go after it when the application is Word Perfect, Netscape, or another competitor. It's telling that Microsoft hasn't tried such a thing.
Re: Web application licenses
On Thu, Aug 12, 2004 at 10:32:56AM -0700, Josh Triplett wrote: True. The question becomes: is it too onerous? After all, people have said the GPL is onerous. Consider the reference card scenario. Either you distribute source at the same time (which is extremely onerous for a reference card) or you use the offer valid for three years approach (which is not considered the Free option in the GPL). Well, the measure of my personal opinion is whether I'd cease using and/or modifying a work because of a requirement. I don't expect Debian to comply with that, but I hope it's a relevant data point. If Apache required me to distribute source if I used it as a server, I'd immediately stop using it and I'd never consider contributing to it, because I don't want to have to serve a local mirror of the Apache source in order to use it. Point them to ftp.debian.org no longer works if I had to modify a couple lines of code to get the thing to compile, so I don't think that avoids the fact that the above is overburdensome. It's also risky; if ftp.debian.org goes down, I may be in violation of the license indefinitely, unless I happen to notice. Also, ftp.debian.org doesn't keep source for all old packages around; if I don't upgrade my testing machine, my binary won't match the source on that server, and I'll be in violation. snapshot.debian.net then. And don't forget that you are allowed to recoup your costs of performing source distribution. (That doesn't address first couple points. I don't want to expose myself to liability based on Debian's servers remaining where they are.) I don't think Debian's archives are relevant, because they no longer help when I've made simple modifications. It makes the case of using the software unmodified easier, but the case of using it modified is just as important, and there won't always be a free third-party mirror available--the existance or lack of an FTP server can't sanely change whether a license is free or not. I think that, for this discussion, we should assume every piece of relevant software is modified, since that's the hardest case to get right. If you can get that case to work, unmodified use should be easy. In practice, none of this, when applied to binary distribution (GPL), has ever been a serious problem for me: binaries and source tend to be of a similar magnitude in size--making a 5-meg source available with a 5-meg binary is generally not a big jump. Making a 6-meg source available with a 10k source file, however, is different by several orders of magnitude. I would not use Apache if it was under this type of license; it fails my personal pain in the ass test. I can think of many cases where the source is larger or more onerous to distribute than the binary. Consider the case where the binary is in an embedded system. Also consider the case when the binary is a printed book, or a reference card, or a printed handout. I don't think requiring distribution of source that's 600 times the size of the actual data being served by the daemon is reasonable at all. All of this aside, this still looks like a use restriction. Are there any functional use restrictions which we currently allow? -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
* Walter Landry: I haven't seen anyone seriously dispute my analysis in http://lists.debian.org/debian-legal/2004/07/msg01705.html that there is a fee involved Maybe you got no serious rebuttals because it's a bit hard to take your analysis seriously. 8-)
Re: Netatalk and OpenSSL licencing
On Thu, Aug 12, 2004 at 09:32:15AM -0700, Ken Arromdee wrote: On Thu, 12 Aug 2004, Nathanael Nerode wrote: The kernel provides a public, documented, freely implementable interface of system calls. I don't know if you can replace it with something else, but you should be able to. Then any Windows program which uses undocumented Windows system calls (of which there are plenty) is a derivative work of Windows and can't be distributed without Microsoft's permission, at least until someone discovers the system calls and implements them in Wine? Given the licenses on Windows and its SDK, MS probably owns your first born if you write *any* Windows program. Expecting freedom for developers on Windows is probably silly, since normal users don't have it either. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Netatalk and OpenSSL licencing
On Thu, Aug 12, 2004 at 09:38:50AM -0700, Josh Triplett wrote: Ken Arromdee wrote: On Thu, 12 Aug 2004, Nathanael Nerode wrote: The kernel provides a public, documented, freely implementable interface of system calls. I don't know if you can replace it with something else, but you should be able to. Then any Windows program which uses undocumented Windows system calls (of which there are plenty) is a derivative work of Windows and can't be distributed without Microsoft's permission, at least until someone discovers the system calls and implements them in Wine? Quite arguably yes. However, Microsoft is intelligent enough to know that going after people who develop applications for your platform is a bad idea. Actually I wouldn't be surprised if they did file some lawsuits along those lines at some point (against some developers they didn't like) - followed by selling a lot of licenses to corporations to protect them from such things. It'd be about normal... I mean, it's not like any of their customers don't believe MS are greedy evil monopolistic bastards already. The thing about being a monopolistic bastard is that you don't care about bad PR. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 12, 2004 at 03:31:19PM +0200, Daniel Stenberg wrote: On Thu, 12 Aug 2004, Daniel Stenberg wrote: If this a hge can of worms or am I just plain wrong? Ok, don't hit me. I did another google and I've found enough references on the topic openssl is PART of the OS etc so no need to say anything else. That doesn't apply to Debian, and we haven't been using it as an excuse since non-US was removed. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 12, 2004 at 03:22:34PM +0200, Daniel Stenberg wrote: There this package in recent Debian named 'curl' (using a MIT-like license). It is built with OpenSSL (you all know the OpenSSL license). With curl there comes two (that we care about here) debian packages nowadays named libcurl2 and libcurl3 (libcurl3 being the new ABI and libcurl2 the older one). Both are linked against the OpenSSL libraries. Many applications use libcurl. Including several applications/packages in Debian unstable that are GPL-licensed. Yes, we've done this before, but never reached a meaningful conclusion. It's really knotty. I'm aware of a few other package combinations like this. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Netatalk and OpenSSL licencing
Glenn Maynard wrote: Lots of people become disappointed in the GPL once they personally become the one wasting time reimplementing stuff due to incompatibilities that the GPL deliberately causes. I no longer use the GPL for my own work, preferring the MIT license--do what you want, don't waste your time reinventing the wheel. 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. In order for copyleft to work, there needs to be _some_ definition of what Free means in the derived works must be Free clause. Compatible with this license is the easiest. I suppose one could have a As an exception, you may combine this with anything that meets the insert DFSG, OSI, FSF, etc requirements clause, or something like MySQL's FLOSS exception, but that still prevents you from combining it with another copyleft license, and I believe it opens up rather large holes in the copyleft. Overall, I think the benefit of the GPL's copyleft is worth the hassle dealing with the occasional piece of non-GPL-compatible software. See also http://www.dwheeler.com/essays/gpl-compatible.html ; I'm more inclined to blame these (relatively uncommon) incompatibilities on those who make their software GPL-incompatible, rather than on the GPL itself. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Netatalk and OpenSSL licencing
Andrew Suffield wrote: On Thu, Aug 12, 2004 at 09:32:15AM -0700, Ken Arromdee wrote: On Thu, 12 Aug 2004, Nathanael Nerode wrote: The kernel provides a public, documented, freely implementable interface of system calls. I don't know if you can replace it with something else, but you should be able to. Then any Windows program which uses undocumented Windows system calls (of which there are plenty) is a derivative work of Windows and can't be distributed without Microsoft's permission, at least until someone discovers the system calls and implements them in Wine? Given the licenses on Windows and its SDK, MS probably owns your first born if you write *any* Windows program. Expecting freedom for developers on Windows is probably silly, since normal users don't have it either. Agreed. You could always cross-compile programs with MinGW and test them with Wine; it would be extremely difficult to argue that it was a derived work at that point. However, they could probably still go after you and cost you plenty of money, even if they couldn't win. - Josh Triplett signature.asc Description: OpenPGP digital signature
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: GPL-licensed packages with depend-chain to OpenSSL
On 2004-08-12 23:59:00 +0100 Freek Dijkstra [EMAIL PROTECTED] wrote: 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? Yes, and that's why people started work on one already. Please add to http://people.debian.org/~bap/dfsg-faq.html ...noticing question 26. http://www.debian.org/doc/debian-policy/ I think other people maintain that. Here is a quick draft: Q: How to find if a licence is 'free'? I would rather not have such loose language in the FAQ. I don't care whether a licence is free (whatever that means) but I care whether the debian contains only free software. Q: Why is licence x free, but not GPL-compatible? Really should be in the GPL FAQ, but a simpler answer (after s/licence/software/): It follows the Debian Free Software Guidelines (DFSG), but the terms of its licence and the GPL in combination do not allow us to distribute software which satisfies both licences and follows our guidelines. Most of the rest should really really be in the GPL FAQ as a first attempt, if they aren't already. If you want to maintain a shadow GPL FAQ then go on. Q: This is outrageous! [...] snooze/ -- 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: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 12, 2004 at 03:22:34PM +0200, Daniel Stenberg wrote: Please forgive a new subscriber if this subject already has been debated to death. In that case, just let me know and I'll quietly crawl away again. Ok, here's my explanation of the problem: There this package in recent Debian named 'curl' (using a MIT-like license). It is built with OpenSSL (you all know the OpenSSL license). With curl there comes two (that we care about here) debian packages nowadays named libcurl2 and libcurl3 (libcurl3 being the new ABI and libcurl2 the older one). Both are linked against the OpenSSL libraries. Many applications use libcurl. Including several applications/packages in Debian unstable that are GPL-licensed. See where I'm drifting? Several packages in Debian unstable are licensed GPL (without explicit allowance for linking with OpenSSL) but links with libraries/components that link with OpenSSL... This creates binaries that are not allowed to distribute due to GPL license violations. AFAICT. I'm not a Debian guru, but I scanned through the list of apps depending on curl to see what licenses they use, and I stopped when I had collected five examples: grip, logjam, ardour, fbi, xine-ui They are all GPLv2 licensees. This is, in fact, a violation of the GPL as we understand it. It would be helpful if you could file bug reports (severity: serious) against these packages you've looked at, documenting the license problem. The maintainer may have further licensing information that's not documented in the package copyright file; or, OTOH, we may need to remove these packages from sarge if the question can't be resolved quickly. (I'm sure someone with more Debian skill can do this checking better and more accurate - these numbers were obtained by some rather crude and error-prone scripts.) It's possible to quickly find a list of packages using libcurl2/3, but checking the licenses of these packages still requires human review of the copyright files. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
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
Difficult open source question
Hi folks, I have a difficult query about open source, which I hope someone here can help with. My friend Gordon was very close to having a working Flash 7 player called magnesium that runs under Linux, and wanted to release it as open source. He passed away last month, and his friends want to do something with this software in his memory. His computers were passed on to me, and I have the program at my house. I can't see any copyrights anywhere, so: is it okay if we release it as open source, and what should we do? Thankyou, Robert
Re: Difficult open source question
[Sorry for the Cc if you're subscribed] On Fri, Aug 13, 2004 at 12:13:13AM +0100, Robert Gibson wrote: I have a difficult query about open source, which I hope someone here can help with. My friend Gordon was very close to having a working Flash 7 player called magnesium that runs under Linux, and wanted to release it as open source. He passed away last month, and his friends want to do something with this software in his memory. His computers were passed on to me, and I have the program at my house. I can't see any copyrights anywhere, so: is it okay if we release it as open source, and what should we do? The copyright that exists in the program that your friend wrote is a thing of value, to be apportioned in the same manner as the rest of his estate. It is certainly *not* OK just to release it as open source, because absent an explicit notice to the contrary, all software has copyright over it, with all the same restrictions as any other work (no unauthorized duplication, etc etc). The most prudent course of action would be to declare the held copyright to the executor of Gordon's estate and have it distributed according to Gordon's wishes (in the case of the existence of a valid will) or according to the laws of probate in your (Gordon's(?)) jurisdiction. Hopefully someone who was aware of (or could be made aware of) Gordon's interest in seeing the program released as open source will receive the copyrights; they can then release the work under a Free licence. All of the above presumes that you have a copyright term that includes a term in excess of the life of the author, such as the US' life+70 years. There are some jurisdictions where copyright is terminated when the author passes away. It may be worth investing in an hour or two of a landshark's time to make sure everything is hunky-dory in your corner of the world. (The above is not legal advice, I am not a lawyer nor do I play one on TV, and all of the rest of the usual disclaimers) - Matt signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Aug 13, 2004 at 12:59:00AM +0200, Freek Dijkstra wrote: 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? 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/ I don't think questions about the GPL belong in the DFSG FAQ. They belong in the FSF's: http://www.gnu.org/licenses/gpl-faq.html It doesn't clearly answer every common question; I'd recommend bringing your suggestions of missing questions to the FSF for possible inclusion in their FAQ. (I did try to refer to it during our discussion, but couldn't find in it a clear answer to your questions, so it's either too short--doesn't have the information--or too long, and I simply couldn't dig it out.) They don't belong in 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 Debian and the FSF have similar but different definitions of Free; Debian should be pointing to the DFSG, not gnu.org. :) Q: Will the FSF sue me if I do this? A: No. First of all, since this is copyright law, only the copyright owner can sue you. That is sometimes the FSF, but often a group of open source developers. Even so, they probably don't have the resource to sue you. However, breaking the law is not the solution, even if it is injust in your opinion. I'd recommend against making claims to what the FSF will or won't do. (Remember, the FSF holds copyright to a large quantity of GPL-licensed code.) -- Glenn Maynard
