Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Sven Luther <[EMAIL PROTECTED]> wrote: > On Wed, Aug 18, 2004 at 10:02:01AM -0400, Brian Thomas Sniffen wrote: > > Sven Luther <[EMAIL PROTECTED]> writes: > > >> I fail to see how requiring modifiers to contribute to proprietary > > >> software helps free software. > > > > > > Because the proprietary version can only happen if the _SAME_ > > > patch is also applied to the QPLed version. > > > > To *some* QPL'd version. It doesn't have to be the public one. > > Well, ok. But the same happens on the GPL, no ? And in general, > upstream would not want to maintain a forked version, which is > exactly why he chose this licence, so ... No, the same thing does not happen with the GPL. Trolltech can take contributions under the QPL and include it both in the free X11 version and the (very expensive) Windows version. If you tried to do that with the GPL, you would have to make the Windows version GPL'd as well. > > > Also, this clause allow upstream to apply the patch to his tree > > > without over burdening him to keep two separate trees. > > > > What's burdening him is his desire to have a proprietary version, not > > a contribution of free software for him to use in other free software. > > And ? Is that so wrong ? Will you declare the BSD non-free too ? It is the forced license of modifications that is the problem. BSD makes little demands on modified versions. > > > So this means that more patches can be incorporated, and thus > > > the community benefits from it. The fact that there is a > > > proprietary version which is _THE SAME_ as the QPLed one, is > > > hardly even noticeable, especially in the ocaml case, where i > > > doubt there is any significant business going around the > > > proprietary version. > > > > It's not the same. It has extra features -- anything from the free > > Maybe in the Qt case, but not in the ocaml case. Are you saying that if Qt were licensed under the same terms as ocaml, Qt would be non-free while ocaml would be free? Even though they are under the exact same license? This is yet another example where you are assuming that the initial developers are angels. Debian must assume that they are devils, not the least because developers have become devils in the past. I wonder how many times we are going to have to repeat this before you get it. > > software community goes into both, but INRIA's own work or paid work > > for paying supporters can go into the private one alone. And if > > The aim is to provide a version of the code base to the ocaml > consortium team members, which has a less restrictive licence, in > order for them to do their own in-house variant or whatever. Or > simply because their hierarchy is frivolous with open source > stuff. All the ocaml-team based development is going into the open > source version, except maybe some highly experimental stuff that > never got released. You're giving me the impression that they want to do something to other people's code that they won't allow to their own code. They are free to have those goals, but that doesn't make licenses which further those goals free. > > there's no business being helped by this clause, then what's the harm > > in removing QPL 3? > > Well, i would much prefer that they change licence wholy to something more > acceptable, that they continue this "our code is under the QPL, but long list of exception>. > > > > Now, this is much better than the BSD situation, where any code > > > can be made proprietary without restrictions, and the BSD is > > > free. > > > > But the BSD license doesn't *force* a proprietary version; it just > > allows it. The QPL forces modifiers to grant permission for a > > proprietary version. > > So ? > > > That force is what makes it non-free. > > How is your freedom to use the program diminished in any way ? You > can do with the software anything you could without the QPL 3 > clause, and if upstream is incorporating their stuff in a > proprietary version, you probably won't even notice. How can you > consider something a fee, if you are not in the slightest affected > by it ? RMS came up with copyleft precisely because of the problems of third parties incorporating stuff into proprietary versions. If you don't understand the motivations behind copyleft, I'm not sure that there is much to talk about. > > > And ? Did i not say that the ocaml team was considering moving > > > the licence to the little brother of the CECILL family ? And > > > that we should postpone the debate right now until those are > > > released, and upstream is ready to make the change, probably for > > > the next version. I even provided the link and quoted upstream > > > on this two times here, but nobody seems to have cared. > > > > You have not posted a link to a new CECILL-like license that I've > > Stop being obtuse, and go read the archive. I posted it two times, not a link > to this new CECILL licence, but a post of Xavier, where he claimed the > possibility of oc
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Glenn Maynard <[EMAIL PROTECTED]> wrote: > On Thu, Aug 19, 2004 at 09:47:42PM +1000, Matthew Palmer wrote: > > > If not, for example, this would seem to imply that software under the GPL > > > with a special exception releasing John Smith from the requirement to > > > release > > > source would fail. > > > > > > I think that's clearly silly, because the same effect can be achieved by > > > giving that individual a separate license. Additional licenses being > > > granted > > > only to certain people, independently from the one Debian sees, never make > > > software less free. So, it would seem silly to reject a single license > > > that combines the effect of this licensing arrangement into one license, > > > even if using two licenses would be cleaner. > > > > The effect is different. For a copyleft, incorporating "group X gets extra > > rights" into the licence under which the work is distributed means that any > > changes I make have to also be under that discriminatory licence -- that is, > > the licence that Debian uses is discriminatory. > > It's not different. > > That example wasn't meant to say "... and you must also release John > Smith from that requirement in all modifications". (It was meant to > be a trivial example of granting extra permissions.) I'll look at > that, too, of course: > > The dual-licensing equivalent of that would be one license that says > "GPL, but everyone is released from the requirement to release > source, and you must release everyone from this in your > modifications"; and another that says "GPL, but John Smith is > released from the requirement to release source, and you must > release him from this requirement in your modifications". > > The former is clearly free, This is where I disagree. Requiring modifiers to license changes as free for everyone to make proprietary is not free. I don't know of any other licenses in main that have that requirement. Regards, Walter Landry [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Matthew Garrett <[EMAIL PROTECTED]> wrote: > Walter Landry <[EMAIL PROTECTED]> wrote: > > Matthew Garrett <[EMAIL PROTECTED]> wrote: > >> Oh, come on. Any argument that implies that we only consider the GPL > >> free because we explicitly say it is is insane. > > > > I am hardly the first person to bring this up [1] [2]. This comment > > from Raul Miller is particularly illuminating [3] > > I'm aware of that. They're all insane, too. At least we understand your sanity standard now ;) > > As I remember it, DFSG#10 was specifically added to the DFSG because > > some people were saying that there were strict interpretations of > > the DFSG which could cause the GPL to fail, while others (including > > the author) were dismissing this as stupid. [In part, because they > > are "guidelines".] > > Raul remembers incorrectly. Anyone with access to the debian-private > archives is free to check this. Secret deliberations. Bah. This is why having almost any discussion on debian-private is a bad thing. > The addition of the list of licenses was a direct result of Ray > Dassen suggesting that a list of licenses we considered free be > added. I can find no suggestion that the GPL would otherwise be > considered non-free. Raul provided links to statements that the Artistic license is not free. > > Raul provided further details later [4]. > > The vast majority of DFSG-related discussion (for better or for worse) > occured on debian-private. Without checking that, large quantities of > historical context are lost (though, to be fair, even /with/ checking > debian-private there's large parts of context that are missing. The > reason for DFSG 3 being changed from "You must have these freedoms" to > "The recipient must be able to relicense under the same conditions" is > never explained - Bruce is presumably the only person who knows. > > >> Without considering the GPL free, we have nothing. > > > > No one is calling the GPL non-free. > > People are suggesting that copyleft licenses are only free because of > DFSG 10. My position is that there is a clear reading of the DFSG that keeps the GPL out. However, if you interpret the word "fee" in a strange way, then you can keep the GPL in. DFSG #10 forces that interpretation. So other copyleft licenses are also ok. However, that kind of munging is a very different beast from what would be required to make QPL 3b ok. > That's a hideous fudge. Don't look at me. I didn't write the DFSG. > Are you honestly suggesting that it is the intention of the DFSG to > draw the line of freedom in such a way that the GPL falls outside > it, and that the GPL is only accepted for pragmatic reasons? I would say that the DFSG uses imprecise language. DFSG #10 enforces a particular interpretation of the language. That is, DFSG #1 does not really mean _no_ fee, just not certain types of fees. > >> Interpreting the DFSG in such a way that we can only ship a kernel > >> and basic userland because the GPL is explicitly listed suggests > >> that the interpretation is incorrect. > > > > This point is actually controversial. I am sure that many people > > would like DFSG #10 to be a noop, but it isn't obviously true. In any > > case, whether or not DFSG #10 is a noop has little practical effect. > > This point was not controversial at the point where the social contract > was written and voted on. Any controversy is purely down to people's > interpretations of the DFSG changing. Then why was there so much discussion over the Artistic license? Regards, Walter Landry [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
* Andrew Suffield: > Here's the snarly bit: > > Take a copy of curl, not built with ssl support. Build your GPLed > application, linking it to this curl. There should unarguably be no > problems here - everything involved is GPL-compatible. > > Now, go and build a copy of curl that is linked to openssl. Install > that one instead, not touching the GPLed application. > > What just happened? What is going on here and where is the boundary? Probably distribution. If you distribute just the OpenSSL of curl version, it's rather clear that you intent that all applications linking against curl also link against OpenSSL.
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > In any case, a more direct answer is that your original question about > the difference between grants of permissions and freedoms is > irrelevant. I was and am talking about the difference between a grant > of extra permissions and a compelled grant of extra permissions, and > objecting to the compulsion as non-free. No, I really am lost here. Is your argument: a) compulsion of provision of freedoms (as in the GPL, for instance) is non-free, or b) compulsion of provision one set of freedoms to some people and a different set to others is non-free If the first is free, I have difficulty in seeing how the second is non-free (providing, of course, that either set of freedoms in option b would be free on its own) -- Matthew Garrett | [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
Måns Rullgård wrote: David Schleef <[EMAIL PROTECTED]> writes: Symbol references are not necessarily resolved at that time, unless you define LD_BIND_NOW or are using prelinking. There's really no method of doing "lazy linking" as you suggest with C, since it would either fail (such as with global variables in libraries) or be required to violate the ISO standard, such as taking the address of a function. There is no requirement that the linker be written in C, or that it follow any standard whatsoever as long as the interface and operation visible to applications is as expected. Surely this is to be read "There's really no method of doing 'lazy linking' as you suggest [of programs written in] C", rather than "There's really no method of doing 'lazy linking' as you suggest [using a linker written in] C"? As we all know, any TC language can be converted into any other TC language. It doesn't matter to the operation of the linker which language it's written in. -- Lewis Jardine IANAL IANADD
Re: GPL-licensed packages with depend-chain to OpenSSL
David Schleef <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote: >> When using dynamic linking that is not necessarily the case. Most >> dynamic linkers use lazy loading of libraries, such that the openssl >> libraries would not actually be mapped in to the process address space >> until one of its functions is called. > > This is not how an ELF runtime linker works. Run ldd on a binary -- > this lists all the shared object files that are mapped into the > address space of the process before main() is called. Sorry, I was a little too quick there. The file is mapped, but is not read from disk until the code is required. The mapping is also shared with other applications using the library. Are all these applications derived from each other? > Symbol references are not necessarily resolved at that time, unless > you define LD_BIND_NOW or are using prelinking. There's really no > method of doing "lazy linking" as you suggest with C, since it would > either fail (such as with global variables in libraries) or be > required to violate the ISO standard, such as taking the address of > a function. There is no requirement that the linker be written in C, or that it follow any standard whatsoever as long as the interface and operation visible to applications is as expected. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Aug 20, 2004 at 12:26:43AM +0200, Måns Rullgård wrote: > David Schleef <[EMAIL PROTECTED]> writes: > > For one thing, it's absolutely not possible to run the binary in > > such a way that openssl is not part of the process image. > > Since when is Debian distributing linked process images? I have a lot of difficulty dicerning a legal difference between "distrubuting a file containing a program" and "distributing a bunch of files that become a program when assembled automatically by the system". I think a judge or jury would have difficulty with this difference as well. (I'd be happy to be swayed by arguments that demonstrate such a difference, though.) dave...
Re: GPL-licensed packages with depend-chain to OpenSSL
David Schleef <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 08:59:44PM +0200, Måns Rullgård wrote: >> > I didn't say anything about derived works. Neither does the GPL when >> > talking about source code. >> > >> > The GPL also doesn't define source code to include "all modules it >> > uses", it defines it to include "all modules it contains". >> >> Could you please explain to me how something linked against libcurl >> contains openssl? > > For one thing, it's absolutely not possible to run the binary in > such a way that openssl is not part of the process image. Since when is Debian distributing linked process images? -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 19, 2004 at 08:59:44PM +0200, Måns Rullgård wrote: > > I didn't say anything about derived works. Neither does the GPL when > > talking about source code. > > > > The GPL also doesn't define source code to include "all modules it > > uses", it defines it to include "all modules it contains". > > Could you please explain to me how something linked against libcurl > contains openssl? For one thing, it's absolutely not possible to run the binary in such a way that openssl is not part of the process image. dave...
Re: GPL-licensed packages with depend-chain to OpenSSL
Here's the snarly bit: Take a copy of curl, not built with ssl support. Build your GPLed application, linking it to this curl. There should unarguably be no problems here - everything involved is GPL-compatible. Now, go and build a copy of curl that is linked to openssl. Install that one instead, not touching the GPLed application. What just happened? What is going on here and where is the boundary? -- .''`. ** 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 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote: > When using dynamic linking that is not necessarily the case. Most > dynamic linkers use lazy loading of libraries, such that the openssl > libraries would not actually be mapped in to the process address space > until one of its functions is called. This is not how an ELF runtime linker works. Run ldd on a binary -- this lists all the shared object files that are mapped into the address space of the process before main() is called. Symbol references are not necessarily resolved at that time, unless you define LD_BIND_NOW or are using prelinking. There's really no method of doing "lazy linking" as you suggest with C, since it would either fail (such as with global variables in libraries) or be required to violate the ISO standard, such as taking the address of a function. dave...
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 09:47:42PM +1000, Matthew Palmer wrote: > > If not, for example, this would seem to imply that software under the GPL > > with a special exception releasing John Smith from the requirement to > > release > > source would fail. > > > > I think that's clearly silly, because the same effect can be achieved by > > giving that individual a separate license. Additional licenses being > > granted > > only to certain people, independently from the one Debian sees, never make > > software less free. So, it would seem silly to reject a single license > > that combines the effect of this licensing arrangement into one license, > > even if using two licenses would be cleaner. > > The effect is different. For a copyleft, incorporating "group X gets extra > rights" into the licence under which the work is distributed means that any > changes I make have to also be under that discriminatory licence -- that is, > the licence that Debian uses is discriminatory. It's not different. That example wasn't meant to say "... and you must also release John Smith from that requirement in all modifications". (It was meant to be a trivial example of granting extra permissions.) I'll look at that, too, of course: The dual-licensing equivalent of that would be one license that says "GPL, but everyone is released from the requirement to release source, and you must release everyone from this in your modifications"; and another that says "GPL, but John Smith is released from the requirement to release source, and you must release him from this requirement in your modifications". The former is clearly free, and a superset of the latter: if you release everyone from that requirement, you're releasing John, too. So, I think calling the latter non-free is silly. More generally, if a license X is free, it seems bizarre to call license Y non-free if its requirements can be met simply by meeting the requirements of free license X (making it a subset of X, so to speak). I think this interpretation of "discrimination" in DFSG#5 isn't a useful one. The QPL is lopsided, but doesn't force you to discriminate; you can simply give to *everyone* the permissions it requires you to give to the initial author. > Not particularly. With only a slight modification to the QPL, you can get > that effect. Remove the requirement for the initial developer to re-release > your changes in the QPL version, and tell me that's a free licence. And yet > everyone gets free rights to the software, some people just get more free > rights. Because the QPL is a copyleft, that's a real problematic clause, > because I can't licence my changes separately. I think QPL3b's requirements fail DFSG#3, but not DFSG#5--and also would fail and pass (respectively) in the same way with this modification. -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 03:30:13PM +0200, Sven Luther wrote: > Indeed, so by arguing that way, we could bring this clause to be modified by > the upstream author, could we not ? Yes, you could probably trick them into changing licenses by convincing them that the license says something that it does not. The license just doesn't say what you're claiming. For it to do so, the initial author's incorporation of your code would have to be made under the entirety of QPL clause 3. However, that clause requires that all modifications be made as patches. You've waived that for the initial author due to QPL#3b. All other QPL#3 requirements went with it, including the "give special permission" requirement. The *only* limitation the special permission places is that the software remain available under the terms of the QPL. -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 01:56:07PM +0200, Sven Luther wrote: > > Nope. Under QPL#3, I can only distribute my changes as patch files; I > > can't distribute the work with my changes incorporated. However, the > > original author can, since I'm required to give him special permission > > to do so under QPL#3b. > > As others using your code have to give you special permission, so ... Even if that was the case, what good is that? It allows me to incorporate their metapatches to my patches back into my patches? > > I believe this extra permission violates DFSG#3. I can't release my > > changes under the terms I received; I have to make a special additional > > license grant, granting the original author permissions to my work that > > he explicitly denied me to his. > > I am not 100 % convinced of this being the case, but even if it where, sure, > there is a disymetry here, but then there is a disymetry anyway, since > upstream wrote most of the code, and you only provide a small patch, and use > it. That doesn't matter. Freedom to distribute modifications is important regardless of the scale of those modifications. Small modifications are important, too. DFSG#3 doesn't say "must allow modifications and derived works, and must allow modifications to be distributed under the same terms as the license of the original software, but only if they're big changes". > Now, you may claim that the patch may be more significant than the original > code, or equaly so. But then, in this case, it would be argued which of those > correspond to a derived work of the other. My position is that each one is a > derived work of the other, each being QPLed, and so each get the same licence > and the same benefit, in particular your right to claim upstream's code is a > derived work of your own stuff, and can thus be incorportated in your own code > base, provided upstream incorporate your work. The QPL requires that I give special permission to the original author to incorporate my changes. It does not give me that permission in return if he does so. -- Glenn Maynard
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: > >> Matthew Garrett <[EMAIL PROTECTED]> writes: >> >> > Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: >> >> Matthew Garrett <[EMAIL PROTECTED]> writes: >> >>> Why is granting of extra freedoms non-free? >> >> >> >> It isn't. The part of my message that you snipped made clear that >> >> it's the requirement that I must grant extra permissions which is >> >> non-free. >> > >> > What is the difference between granting of extra permissions and >> > granting of extra freedoms? >> >> Nothing. Therefore, I require you to grant me a permissive license to >> all code you have ever written. >> >> Oh wait, that doesn't seem free to you? Why? Because it's a >> requirement. What's the difference between charity and tax? Tax is a >> requirement, charity is freely given. > > Although certain varieties of logical fallacy[1] are popular on this > list, please try to engage less in hyperbole and more in arguments > that believably relate to software. Ideally arguments will clearly > relate to actual licenses on software under discussion. Look, Matthew's been repeatedly failing to recognize the difference between a grant of permission and a requirement for a grant of permission. I'm trying to make the difference as clear as possible, and to emphasize why the requirement is non-Free. While it's true that arguments will ideally refer to actual licenses on software under discussion, sometimes it's easiest to see a feature, whether problem or virtue, when it's shown in clear relief. For example, a license which was essentially "GPL, but replace the phrase "this License" in GPL 2b with "the MIT/X11 license"" would be non-Free for violating DFSG 3. The QPL's 3b is a close relative of that non-Free license. By imagining that strange copy-not-quite-left, I can clearly demonstrate the problem with the QPL. Ideally, arguments will also relate to the messages to which they purport to respond, not slight variations of those messages which omit a few words. -Brian > Michael Poole > > [1]- Fallacies like strawmen arguments, illustrated in your post, are > members of a group colloquially known as Making Shit Up. -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
David Nusinow <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 12:09:01PM -0400, Brian Thomas Sniffen wrote: >> Matthew Garrett <[EMAIL PROTECTED]> writes: >> >> > Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: >> >> Matthew Garrett <[EMAIL PROTECTED]> writes: >> >>> Why is granting of extra freedoms non-free? >> >> >> >> It isn't. The part of my message that you snipped made clear that >> >> it's the requirement that I must grant extra permissions which is >> >> non-free. >> > >> > What is the difference between granting of extra permissions and >> > granting of extra freedoms? >> >> Nothing. Therefore, I require you to grant me a permissive license to >> all code you have ever written. >> >> Oh wait, that doesn't seem free to you? Why? Because it's a >> requirement. What's the difference between charity and tax? Tax is a >> requirement, charity is freely given. > > That's not a fair example because all the code he has ever written is not a > derived work from the licensed code. Just because there are requirements of > people receiving the license to give up something does not make it non-free. Neither is all of the code used to modify a QPL'd work a derivative of the licensed code. If I take some spiffy-keen code written elsewhere and write some shims to cram it into the OCaml compiler, it's a modification, but what I wrote before I ever saw OCaml is not a derivative work. The whole program taken together is, but I never distribute that because I can only distribute source as patches. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Matthew Garrett <[EMAIL PROTECTED]> writes: > On Thu, 2004-08-19 at 17:09, Brian Thomas Sniffen wrote: >> Matthew Garrett <[EMAIL PROTECTED]> writes: >> > >> > What is the difference between granting of extra permissions and >> > granting of extra freedoms? >> >> Nothing. Therefore, I require you to grant me a permissive license to >> all code you have ever written. >> >> Oh wait, that doesn't seem free to you? Why? Because it's a >> requirement. What's the difference between charity and tax? Tax is a >> requirement, charity is freely given. > > No, it seems non-free because it's a contamination of other software, > which is something we believe to be outside the scope of a free software > license. Hm. It is objectionable because it's a contamination, but I think it's also objectionable because it's a requirement that distribution of modifications be under a license the modifier didn't have. In any case, a more direct answer is that your original question about the difference between grants of permissions and freedoms is irrelevant. I was and am talking about the difference between a grant of extra permissions and a compelled grant of extra permissions, and objecting to the compulsion as non-free. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Choice-of-Venue is OK with the DFSG.
On Thu, Aug 19, 2004 at 03:35:49PM +0200, Sven Luther wrote: > On Thu, Aug 19, 2004 at 08:41:57AM -0400, Joe Moore wrote: > > Sven Luther wrote: > > >Well, imagine the following case. I have contributed some code to the linux > > >kernel, if i want to sue SCO over it, i have to go to the US, and ruin > > >myself > > >in lawyer and other such nonsense. This clearly mean that only the rich and > > >powerfull have the right to get their licence respected, isn't it ? > > Are you not aware that SCO is being sued in Germany and Australia? > > Despite being a US-based company, SCO has a physical presence (i.e. > > personal jurisdiction) in every country where it has an office, and > > arguably in every location where it either sells its "software"[0] > Well, did you heard the case where, i think it was california, decided that it > could sue people all over the world ? You seem to get a different version of the news than I do; the case I've heard of involved a Debian developer successfully appealing to the California Supreme Court, and overturning this jurisdictional claim. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
Steve Langasek <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote: >> Steve Langasek <[EMAIL PROTECTED]> writes: > >> > If your understanding of the license exception requirements were >> > correct, it would be a very easy loophole for people to exploit, using >> > GPL-compatible library layers to "sanitize" the licenses of library >> > dependencies. > >> > But in fact, the GPL's definition of source code is: > >> > The source code for a work means the preferred form of the work for >> > making modifications to it. For an executable work, complete source >> > code means all the source code for all modules it contains, plus any >> > associated interface definition files, plus the scripts used to >> > control compilation and installation of the executable. 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. > >> > For GPL applications linked against curl, "all modules it contains" >> > includes both libcurl and libssl. > >> When using dynamic linking that is not necessarily the case. Most >> dynamic linkers use lazy loading of libraries, such that the openssl >> libraries would not actually be mapped in to the process address space >> until one of its functions is called. If, as per assumption, the >> application does not use any ssl related features of curl, the openssl >> libraries would never be touched, except for a possible scan of its >> symbol table. The openssl libraries could be replaced by another >> library containing dummy entries for all the required symbols and the >> curl using application would still function correctly. How the >> presence or absence of a particular library at runtime could possibly >> change the derivedness of a some program from said library is beyond >> my comprehension. > > I didn't say anything about derived works. Neither does the GPL when > talking about source code. > > The GPL also doesn't define source code to include "all modules it > uses", it defines it to include "all modules it contains". Could you please explain to me how something linked against libcurl contains openssl? -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > If your understanding of the license exception requirements were > > correct, it would be a very easy loophole for people to exploit, using > > GPL-compatible library layers to "sanitize" the licenses of library > > dependencies. > > But in fact, the GPL's definition of source code is: > > The source code for a work means the preferred form of the work for > > making modifications to it. For an executable work, complete source > > code means all the source code for all modules it contains, plus any > > associated interface definition files, plus the scripts used to > > control compilation and installation of the executable. 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. > > For GPL applications linked against curl, "all modules it contains" > > includes both libcurl and libssl. > When using dynamic linking that is not necessarily the case. Most > dynamic linkers use lazy loading of libraries, such that the openssl > libraries would not actually be mapped in to the process address space > until one of its functions is called. If, as per assumption, the > application does not use any ssl related features of curl, the openssl > libraries would never be touched, except for a possible scan of its > symbol table. The openssl libraries could be replaced by another > library containing dummy entries for all the required symbols and the > curl using application would still function correctly. How the > presence or absence of a particular library at runtime could possibly > change the derivedness of a some program from said library is beyond > my comprehension. I didn't say anything about derived works. Neither does the GPL when talking about source code. The GPL also doesn't define source code to include "all modules it uses", it defines it to include "all modules it contains". -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Raul Miller <[EMAIL PROTECTED]> writes: >> that's not Free. The QPL says "BSD to inria/cristal, copyleft/patch >> to everyone else, and that pair must be passed along" -- that "must", >> that added restriction, is the non-free part. > > I'm not sure about this. > > As stated, that "must" is inherent in copyright law -- if we start saying > that "free software" requires that non-copyright holders be allowed to > change license terms, I think we've missed the boat. That "must" is not inherent in copyright law. This is talking about derived works -- it would have been more clear if I'd said "passed along with modifications" in every example. So I own a copyright interest in the work as well, and copyright law certainly does not require that I grant the initial developer a license to exploit my work. So I'm not insisting that non-copyright holders be allowed to change terms; only that modifiers be able to release their code under the same license that they had to the initial work -- you know, what DFSG 3 says. > Can you express this point focussing on issues of real, practical > non-freeness? [for example, stuff which interferes with porting, bug > fixes, security fixes, ...] There were demands that I point at the DFSG, and I did so. Now you want a practical example. Here's some attempts at one: * I cannot exercise my free-software rights (modify and distribute the code) *and* restrict what the initial developer does in any way. * I can't fork the code, even distributing as patches. There's no way for me to make XEmacs, which is FSF Emacs + code by people who won't transfer copyright to the FSF. * This is the case that bothered me: I can't distribute a modification which incorporates a change to which I can't give INRIA a permissive license. In fact, I can't merge in *any code whatsoever* that I didn't write myself, because I have to be able to give INRIA that particular permissive license to it. For example, the Debian O'Caml maintainer can't integrate any patch submitted, because he can't grant INRIA the license they demand. > What you're essentially saying, from my point of view, is that where we > have two licenses, both of which are free, one discriminates against > users and the other does not. But if that were the case, one of them > wouldn't be free. I don't understand you here. I don't think you're characterizing what I've said correctly; is there some bit I can explain in more depth? -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Bug#265352: grub: Debian splash images for Grub
On Thu, Aug 19, 2004 at 05:21:16PM +0100, Martin Michlmayr - Debian Project Leader wrote: > * David Schleef <[EMAIL PROTECTED]> [2004-08-17 15:23]: > > The Debian Open Use Logo License is generally considered to be > > non-DFSG free. However, it appears to be a widely held belief > > that Debian should have _some_ logo that is DFSG-free, and that > > the license of the open logo should be changed to make this so. > > I think the open use logo itself should be DFSG-free, but it probably > should be accompanied by a trademark license. I'll contact SPI to see > what needs to be done to change the license, and I've asked Matthew > Garrett to discuss the trademark issue with SPI's trademark lawyer and > others on spi-trademark. You rock. > What would a good license for the logo be? Debian-legal, what do you advise? Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E pgpLB4WcDv4lg.pgp Description: PGP signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, 2004-08-19 at 17:09, Brian Thomas Sniffen wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > > > What is the difference between granting of extra permissions and > > granting of extra freedoms? > > Nothing. Therefore, I require you to grant me a permissive license to > all code you have ever written. > > Oh wait, that doesn't seem free to you? Why? Because it's a > requirement. What's the difference between charity and tax? Tax is a > requirement, charity is freely given. No, it seems non-free because it's a contamination of other software, which is something we believe to be outside the scope of a free software license. -- Matthew Garrett | [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 12:09:01PM -0400, Brian Thomas Sniffen wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > > Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > >> Matthew Garrett <[EMAIL PROTECTED]> writes: > >>> Why is granting of extra freedoms non-free? > >> > >> It isn't. The part of my message that you snipped made clear that > >> it's the requirement that I must grant extra permissions which is > >> non-free. > > > > What is the difference between granting of extra permissions and > > granting of extra freedoms? > > Nothing. Therefore, I require you to grant me a permissive license to > all code you have ever written. > > Oh wait, that doesn't seem free to you? Why? Because it's a > requirement. What's the difference between charity and tax? Tax is a > requirement, charity is freely given. That's not a fair example because all the code he has ever written is not a derived work from the licensed code. Just because there are requirements of people receiving the license to give up something does not make it non-free. - David Nusinow
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Brian Thomas Sniffen writes: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > > Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > >> Matthew Garrett <[EMAIL PROTECTED]> writes: > >>> Why is granting of extra freedoms non-free? > >> > >> It isn't. The part of my message that you snipped made clear that > >> it's the requirement that I must grant extra permissions which is > >> non-free. > > > > What is the difference between granting of extra permissions and > > granting of extra freedoms? > > Nothing. Therefore, I require you to grant me a permissive license to > all code you have ever written. > > Oh wait, that doesn't seem free to you? Why? Because it's a > requirement. What's the difference between charity and tax? Tax is a > requirement, charity is freely given. Although certain varieties of logical fallacy[1] are popular on this list, please try to engage less in hyperbole and more in arguments that believably relate to software. Ideally arguments will clearly relate to actual licenses on software under discussion. Michael Poole [1]- Fallacies like strawmen arguments, illustrated in your post, are members of a group colloquially known as Making Shit Up.
Re: Bug#265352: grub: Debian splash images for Grub
* David Schleef <[EMAIL PROTECTED]> [2004-08-17 15:23]: > The Debian Open Use Logo License is generally considered to be > non-DFSG free. However, it appears to be a widely held belief > that Debian should have _some_ logo that is DFSG-free, and that > the license of the open logo should be changed to make this so. I think the open use logo itself should be DFSG-free, but it probably should be accompanied by a trademark license. I'll contact SPI to see what needs to be done to change the license, and I've asked Matthew Garrett to discuss the trademark issue with SPI's trademark lawyer and others on spi-trademark. What would a good license for the logo be? -- Martin Michlmayr [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Matthew Garrett <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: >> Matthew Garrett <[EMAIL PROTECTED]> writes: >>> Why is granting of extra freedoms non-free? >> >> It isn't. The part of my message that you snipped made clear that >> it's the requirement that I must grant extra permissions which is >> non-free. > > What is the difference between granting of extra permissions and > granting of extra freedoms? Nothing. Therefore, I require you to grant me a permissive license to all code you have ever written. Oh wait, that doesn't seem free to you? Why? Because it's a requirement. What's the difference between charity and tax? Tax is a requirement, charity is freely given. -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 <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: >> Why is granting of extra freedoms non-free? > > It isn't. The part of my message that you snipped made clear that > it's the requirement that I must grant extra permissions which is > non-free. What is the difference between granting of extra permissions and granting of extra freedoms? -- Matthew Garrett | [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
[EMAIL PROTECTED] writes: > On Wed, 18 Aug 2004, Brian Thomas Sniffen wrote: > >> > 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. >> >> This is not Free. It gives these grants: >> >> 1) Distribute with source, passing this license along. >> >> 2) or, if you're Bob, under a proprietary license without source. >> >> Now I have only one grant of permission. I have to pass along 2, but >> I don't get to take advantage of it at all. > > Since it was specified that Bob holds the copyright, this licence is > equivalent > to the same licence without clause 2 at all. No, it's more restrictive on me. Without the requirement that I add clause 2 to my modifications, Bob can't release *my* code in his proprietary version. Bob only holds the copyright on his original, not on my modifications. They are a derivative work of his original, so both he and I have copyright interests in them. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Matthew Garrett <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > >> This is not Free. It gives these grants: >> >> 1) Distribute with source, passing this license along. >> >> 2) or, if you're Bob, under a proprietary license without source. >> >> Now I have only one grant of permission. I have to pass along 2, but >> I don't get to take advantage of it at all. > > Why is granting of extra freedoms non-free? It isn't. The part of my message that you snipped made clear that it's the requirement that I must grant extra permissions which is non-free. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Choice-of-Venue is OK with the DFSG.
Sven Luther writes: > On Thu, Aug 19, 2004 at 08:41:57AM -0400, Joe Moore wrote: > > > Similarly, did you follow the Microsoft vs. Lindo*s issue? Microsoft > > sued in US courts, failed to get an injunction, then "venue shopped" for > > a court that would give them the ruling they wanted, ending up in the > > Netherlands. If Lindo*s could have argued that venue was improper > > because both companies are US companies, don't you think they would have? > > Sure, but all of those are big companies, i am just a lone developer, i > wouldn't even know where to look if SCO or Microsoft where to steal my code > and be irrespectuous of the licence. And since i contributed some (very small) > amount of linux source code, at least i could be suing SCO for not respecting > the GPL, could i not, like IBM is doing ? Now if i could go to tribunal here > and fill the suing, this would be well more costly, _and_ i would have much > more faith in the impartiality of the judge, given the bad example of > money-dominated courts you see in the US. How, exactly, would that help you in the case of Linux, where there is no choice of venue clause? If you want contact information for SCO's French office, it is easy to find on their web site[1]. You can sue them there if you really think you have a case. Free software is about empowering users and developers, not about making lawsuits easy. If you want that, you have plenty of proprietary licenses to choose from. [1]- http://www.sco.com/worldwide/fr.html took me about 30 seconds to find, most of it waiting on a slow network. Michael Poole
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 08:33:13AM -0400, Walter Landry wrote: > I am hardly the first person to bring this up [1] [2]. This comment > from Raul Miller is particularly illuminating [3] > > As I remember it, DFSG#10 was specifically added to the DFSG because > some people were saying that there were strict interpretations of > the DFSG which could cause the GPL to fail, while others (including > the author) were dismissing this as stupid. [In part, because they > are "guidelines".] > > Raul provided further details later [4]. I'd prefer you emphasized the further details with only a tangential reference to my memory. ;) > [1] http://lists.debian.org/debian-legal/2003/10/msg00251.html > [2] http://lists.debian.org/debian-legal/2004/05/msg00558.html and followups > [3] http://lists.debian.org/debian-legal/2004/05/msg00920.html > [4] http://lists.debian.org/debian-legal/2004/05/msg00946.html Thanks, -- Raul
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Walter Landry <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> wrote: >> Oh, come on. Any argument that implies that we only consider the GPL >> free because we explicitly say it is is insane. > > I am hardly the first person to bring this up [1] [2]. This comment > from Raul Miller is particularly illuminating [3] I'm aware of that. They're all insane, too. > As I remember it, DFSG#10 was specifically added to the DFSG because > some people were saying that there were strict interpretations of > the DFSG which could cause the GPL to fail, while others (including > the author) were dismissing this as stupid. [In part, because they > are "guidelines".] Raul remembers incorrectly. Anyone with access to the debian-private archives is free to check this. The addition of the list of licenses was a direct result of Ray Dassen suggesting that a list of licenses we considered free be added. I can find no suggestion that the GPL would otherwise be considered non-free. > Raul provided further details later [4]. The vast majority of DFSG-related discussion (for better or for worse) occured on debian-private. Without checking that, large quantities of historical context are lost (though, to be fair, even /with/ checking debian-private there's large parts of context that are missing. The reason for DFSG 3 being changed from "You must have these freedoms" to "The recipient must be able to relicense under the same conditions" is never explained - Bruce is presumably the only person who knows. >> Without considering the GPL free, we have nothing. > > No one is calling the GPL non-free. People are suggesting that copyleft licenses are only free because of DFSG 10. That's a hideous fudge. Are you honestly suggesting that it is the intention of the DFSG to draw the line of freedom in such a way that the GPL falls outside it, and that the GPL is only accepted for pragmatic reasons? >> Interpreting the DFSG in such a way that we can only ship a kernel >> and basic userland because the GPL is explicitly listed suggests >> that the interpretation is incorrect. > > This point is actually controversial. I am sure that many people > would like DFSG #10 to be a noop, but it isn't obviously true. In any > case, whether or not DFSG #10 is a noop has little practical effect. This point was not controversial at the point where the social contract was written and voted on. Any controversy is purely down to people's interpretations of the DFSG changing. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Choice-of-Venue is OK with the DFSG.
On Thu, Aug 19, 2004 at 08:41:57AM -0400, Joe Moore wrote: > Sven Luther wrote: > >Well, imagine the following case. I have contributed some code to the linux > >kernel, if i want to sue SCO over it, i have to go to the US, and ruin > >myself > >in lawyer and other such nonsense. This clearly mean that only the rich and > >powerfull have the right to get their licence respected, isn't it ? > > Are you not aware that SCO is being sued in Germany and Australia? > > Despite being a US-based company, SCO has a physical presence (i.e. > personal jurisdiction) in every country where it has an office, and > arguably in every location where it either sells its "software"[0] Well, did you heard the case where, i think it was california, decided that it could sue people all over the world ? > Similarly, did you follow the Microsoft vs. Lindo*s issue? Microsoft > sued in US courts, failed to get an injunction, then "venue shopped" for > a court that would give them the ruling they wanted, ending up in the > Netherlands. If Lindo*s could have argued that venue was improper > because both companies are US companies, don't you think they would have? Sure, but all of those are big companies, i am just a lone developer, i wouldn't even know where to look if SCO or Microsoft where to steal my code and be irrespectuous of the licence. And since i contributed some (very small) amount of linux source code, at least i could be suing SCO for not respecting the GPL, could i not, like IBM is doing ? Now if i could go to tribunal here and fill the suing, this would be well more costly, _and_ i would have much more faith in the impartiality of the judge, given the bad example of money-dominated courts you see in the US. But i don't really care, this clause has been dropped from the ocaml licence, so it doesn't affect me at all. 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 19, 2004 at 08:19:19AM -0400, Joe Moore wrote: > Sven Luther wrote: > > > >But if upstreqm incorporqtes your changes, thus creating a modification of > >your QPLed work, you have the same right as he has, don't you ? > > To distribute the modified (combined) version of your QPL'd work under a > proprietaty license? And under the QPLed version. It has to be both, acordying to the QPL 3b. and then, the combined upstream + patches work, coming under the QPL, has to abid to the same rules. > In other words, if I submit a patch to the ocaml compiler, and it is > accepted, then I can "take the software proprietary" just the same as > the original author? Yep, that is what i am arguing. I have some doubts about it, but it is a rather discouraging way of arguing for people considering to licence stuff under the QPL. > That certainly makes the QPL more attractive to me, as a > non-original-author. But I'm afraid I don't understand why any original > author would use it. Indeed, so by arguing that way, we could bring this clause to be modified by the upstream author, could we not ? 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 19, 2004 at 10:42:36PM +1000, Matthew Palmer wrote: > On Thu, Aug 19, 2004 at 02:45:11PM +0200, Sven Luther wrote: > > On Thu, Aug 19, 2004 at 09:56:45PM +1000, Matthew Palmer wrote: > > > On Thu, Aug 19, 2004 at 01:56:07PM +0200, Sven Luther wrote: > > > > Now, you may claim that the patch may be more significant than the > > > > original > > > > code, or equaly so. But then, in this case, it would be argued which of > > > > those > > > > correspond to a derived work of the other. My position is that each one > > > > is a > > > > > > I think it'd be pretty clear which was which. Your work was developed as > > > a > > > result of what was already provided under the QPL. The work resulting > > > from > > > > It is not always that clear, imagine two works, A and B, which can integrate > > well enough, but each one could be a patch of the other, or vice versa. > > Nope, I'm having a great deal of trouble imagining two independently > developed works each of which could be a patch to the other. Imagine, to stay in the ocaml line of things, that someone A developed a new bytecode JIT virtual machine, independently of anything related by the original QPLed software. Imagine now that someone else B, developed a bytecode language, a ocaml or java clone for example. Now consider the two scenarios : 1) A takes the code from B, and integrates is bytecode compiler, replacing the loosy slow primitive virtual machine, or even plain interpreted or C translated version B did originally use. 2) B is not competent in writing virtual machines, looks around the web, and finds the work of A. He then decide to take the virtual machine, and incorporate it in his own work. In both the 1) and 2) case, the respective developer would have to create a patch to the other software, since it is QPLed. > Note that libraries linking to each other don't apply, as they're not > modifying each other. Well, i guess the FSF would argue against this, woudln't they ? > I really cannot think of how two works, each of which is a modification of > the other, could ever come to be, short of time travel or some such. The way of patching is just a clumsy way of combining or merging two different code bases. Notice that the QPL says : 3. You may make modifications to the Software and distribute your modifications, in a form that is separate from the Software, such as patches. The following restrictions apply to modifications: And speaks of modifications that are distributed in a separate form, patches are only a common example of those. Imagine an arch/svn/bk like repository, and each modification a changeset on top of each other for example. > > > the combination of the original software and your patch is a derived work > > > of > > > both, but thankfully the initial developer isn't bound by the terms of the > > > QPL because he got an all-permissions, so you've got bupkis. Similarly, > > > any > > > modifications that the original author does to your work don't fall under > > > the "modified versions" rule, because the initial developer didn't need to > > > accept the QPL to modify your work. > > > > So what ? It is just a patch, no interaction with the original software at > > all, unless it is compiled that is. > > > > Now, if you consider those patch as only small piece of modification from > > the > > original software, like, err, the patches they are, then it is only fair to > > notice that there is some disymetry of importance between the huge work > > having > > gone in the original software, and the smallish patch you have sent > > upstream, > > and thus it is no wonder that you find this same disymetry in the licence > > and > > attached rights too. > > "You didn't do much, so you don't deserve freedom". Ok, i said there is a disymetry, but it is not a disymetry which limits your freedom in anyway, if just gives more freedom to the upstream author, so ... > "You're only users, you don't deserve source". I sincerely defy you to find anywhere in what i wrote the place where i even hinted at such a thing. Also QPL 3b especially says that the modification may be made proprietary (or BSDed or GPLed or whatever), as long as the same software is also released under the QPL. So sources are available, in at least the same degree than the GPL makes them available. > > > > derived work of the other, each being QPLed, and so each get the same > > > > licence > > > > and the same benefit, in particular your right to claim upstream's code > > > > is a > > > > derived work of your own stuff, and can thus be incorportated in your > > > > own code > > > > base, provided upstream incorporate your work. > > > > > > The QPL doesn't talk of derived works as such[1], merely modified versions > > > of the original software. Your modification, though it may constitute 90% > > > of the resulting codebase, is still a modified version of a QPL'd work. > > > (In > > > > Well, i have
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Matthew Garrett <[EMAIL PROTECTED]> wrote: > Walter Landry <[EMAIL PROTECTED]> wrote: > > > I would say that any license that compels modifications to be under > > anything other than a copyleft is problematic. Copyleft is only > > allowed because it is explicitly grandfathered in by DFSG #10. > > Oh, come on. Any argument that implies that we only consider the GPL > free because we explicitly say it is is insane. I am hardly the first person to bring this up [1] [2]. This comment from Raul Miller is particularly illuminating [3] As I remember it, DFSG#10 was specifically added to the DFSG because some people were saying that there were strict interpretations of the DFSG which could cause the GPL to fail, while others (including the author) were dismissing this as stupid. [In part, because they are "guidelines".] Raul provided further details later [4]. > Without considering the GPL free, we have nothing. No one is calling the GPL non-free. > Interpreting the DFSG in such a way that we can only ship a kernel > and basic userland because the GPL is explicitly listed suggests > that the interpretation is incorrect. This point is actually controversial. I am sure that many people would like DFSG #10 to be a noop, but it isn't obviously true. In any case, whether or not DFSG #10 is a noop has little practical effect. Regards, Walter Landry [EMAIL PROTECTED] [1] http://lists.debian.org/debian-legal/2003/10/msg00251.html [2] http://lists.debian.org/debian-legal/2004/05/msg00558.html and followups [3] http://lists.debian.org/debian-legal/2004/05/msg00920.html [4] http://lists.debian.org/debian-legal/2004/05/msg00946.html
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 09:38:24PM +1000, Matthew Palmer wrote: > On Thu, Aug 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: > > On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: > > > On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: > > > > > I don't see how this makes it non-free. You are distributing under > > > > > the > > > > > same license you received the software under, so DFSG 3 is satisfied, > > > > > > But you're not. The license permissions you received don't permit using > > > the code under a completely difference license; for example, you can't > > > link the code with GPL work, since the licenses are incompatible. > > > However, > > > you have to distribute your modifications under terms that *do* allow the > > > original programmer to do so. The license terms you're forced to release > > > modifications under are different from the ones you received. > > > > But if upstreqm incorporqtes your changes, thus creating a modification of > > your QPLed work, you have the same right as he has, don't you ? > > I really wish you'd stop pushing this barrel, because I have to keep > swatting it down. Well, it would be an interpetation that if followed would make people think two times before licencing stuff under the QPL. > The initial developer does not have to abide by the terms of the QPL with > regard to your changes, because he received an all-permissive licence to > them. It says : b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer. So, i don't see here an "all-permisive" licence. Just that they have the right to use the patch as part of future versions of the Software, provided it is under the QPL and some other licence. Nowhere do i see there that the initial developer has the right to ignore the QPL licence which covers the patch, and thus he is evidently bound by it. He still has the right to relicence it and distribute it though, agreed, but that doesn't mean he has the right to not respect the licence of the modificator, does it ? 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 19, 2004 at 02:45:11PM +0200, Sven Luther wrote: > On Thu, Aug 19, 2004 at 09:56:45PM +1000, Matthew Palmer wrote: > > On Thu, Aug 19, 2004 at 01:56:07PM +0200, Sven Luther wrote: > > > Now, you may claim that the patch may be more significant than the > > > original > > > code, or equaly so. But then, in this case, it would be argued which of > > > those > > > correspond to a derived work of the other. My position is that each one > > > is a > > > > I think it'd be pretty clear which was which. Your work was developed as a > > result of what was already provided under the QPL. The work resulting from > > It is not always that clear, imagine two works, A and B, which can integrate > well enough, but each one could be a patch of the other, or vice versa. Nope, I'm having a great deal of trouble imagining two independently developed works each of which could be a patch to the other. Note that libraries linking to each other don't apply, as they're not modifying each other. I really cannot think of how two works, each of which is a modification of the other, could ever come to be, short of time travel or some such. > > the combination of the original software and your patch is a derived work of > > both, but thankfully the initial developer isn't bound by the terms of the > > QPL because he got an all-permissions, so you've got bupkis. Similarly, any > > modifications that the original author does to your work don't fall under > > the "modified versions" rule, because the initial developer didn't need to > > accept the QPL to modify your work. > > So what ? It is just a patch, no interaction with the original software at > all, unless it is compiled that is. > > Now, if you consider those patch as only small piece of modification from the > original software, like, err, the patches they are, then it is only fair to > notice that there is some disymetry of importance between the huge work having > gone in the original software, and the smallish patch you have sent upstream, > and thus it is no wonder that you find this same disymetry in the licence and > attached rights too. "You didn't do much, so you don't deserve freedom". "You're only users, you don't deserve source". > > > derived work of the other, each being QPLed, and so each get the same > > > licence > > > and the same benefit, in particular your right to claim upstream's code > > > is a > > > derived work of your own stuff, and can thus be incorportated in your own > > > code > > > base, provided upstream incorporate your work. > > > > The QPL doesn't talk of derived works as such[1], merely modified versions > > of the original software. Your modification, though it may constitute 90% > > of the resulting codebase, is still a modified version of a QPL'd work. (In > > Well, i have somehow the feeling that this would be something you could go to > court and argue over. I wouldn't like to. We generally accept that there are two ways to create a derived work, linking and modification. Each is dealt with separately in the QPL. I doubt you'd have an easy time convincing a judge that the licence authors really had no idea what they were doing, and mistook "modified" as "derived". > > that case, you'd be nuts not to just rewrite the other 10% and freely > > licence it, but we'll leave that alone for now). All modifications of a > > QPL'd work have to follow the guidelines in 3b. > > But still, the copyright of your patch or modification remains with you, > altough upstream has the right to integrate it, and all persons further > patching it are thus obliged to give you the same right you give upstream, > so ... The upstream author still doesn't have to abide by the same terms I had to. All I can do is take modifications to my patch and do whatever I like to them. Whoop-dee-doo! I still have an asymmetric relationship with upstream. - Matt signature.asc Description: Digital signature
Re: Choice-of-Venue is OK with the DFSG.
Sven Luther wrote: Well, imagine the following case. I have contributed some code to the linux kernel, if i want to sue SCO over it, i have to go to the US, and ruin myself in lawyer and other such nonsense. This clearly mean that only the rich and powerfull have the right to get their licence respected, isn't it ? Are you not aware that SCO is being sued in Germany and Australia? Despite being a US-based company, SCO has a physical presence (i.e. personal jurisdiction) in every country where it has an office, and arguably in every location where it either sells its "software"[0] Similarly, did you follow the Microsoft vs. Lindo*s issue? Microsoft sued in US courts, failed to get an injunction, then "venue shopped" for a court that would give them the ruling they wanted, ending up in the Netherlands. If Lindo*s could have argued that venue was improper because both companies are US companies, don't you think they would have? Without a choice of venue clause, you can sue in 1) Your home court, 2) The offender's home court, or 3) The court where the "offense" took place. You can be sued in 1) Your home court, 2) the plaintiff's home court, or 3) the court where the "offense" took place. With a choice of venue clause, you can sue in 1) Your chosen venue, 2) the offender's home court (if you claim that the license has been broken, then you can sue them wherever you want, subject to the court's approval[1]), or 3) the court where the "offense" took place (again, subject to that court's approval[1]). You can be sued in 1) Your chosen venue, 2) the plaintiff's home court (they can simply not refer to the license's COV clause in their filing[2]) 3) the court where the "offense" took place (they can simply not refer to the license's COV clause in their filing[2]) --Joe [0] Some courts have taken the position that a website that is accessible from that jurisdiction is sufficient. I think this is a terrible precedent. [1] The offender may try to move the case to your preferred venue. [2] It might be a simple matter for you to defend yourself against this type of action, simply by sending a letter with the COV clause to the court. However, that may still require competant legal council in that venue.
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 09:56:45PM +1000, Matthew Palmer wrote: > On Thu, Aug 19, 2004 at 01:56:07PM +0200, Sven Luther wrote: > > On Thu, Aug 19, 2004 at 04:56:02AM -0400, Glenn Maynard wrote: > > > On Thu, Aug 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: > > > > But if upstreqm incorporqtes your changes, thus creating a modification > > > > of > > > > your QPLed work, you have the same right as he has, don't you ? > > > I believe this extra permission violates DFSG#3. I can't release my > > > changes under the terms I received; I have to make a special additional > > > license grant, granting the original author permissions to my work that > > > he explicitly denied me to his. > > > > I am not 100 % convinced of this being the case, but even if it where, sure, > > there is a disymetry here, but then there is a disymetry anyway, since > > upstream wrote most of the code, and you only provide a small patch, and use > > it. > > > > Now, you may claim that the patch may be more significant than the original > > code, or equaly so. But then, in this case, it would be argued which of > > those > > correspond to a derived work of the other. My position is that each one is a > > I think it'd be pretty clear which was which. Your work was developed as a > result of what was already provided under the QPL. The work resulting from It is not always that clear, imagine two works, A and B, which can integrate well enough, but each one could be a patch of the other, or vice versa. > the combination of the original software and your patch is a derived work of > both, but thankfully the initial developer isn't bound by the terms of the > QPL because he got an all-permissions, so you've got bupkis. Similarly, any > modifications that the original author does to your work don't fall under > the "modified versions" rule, because the initial developer didn't need to > accept the QPL to modify your work. So what ? It is just a patch, no interaction with the original software at all, unless it is compiled that is. Now, if you consider those patch as only small piece of modification from the original software, like, err, the patches they are, then it is only fair to notice that there is some disymetry of importance between the huge work having gone in the original software, and the smallish patch you have sent upstream, and thus it is no wonder that you find this same disymetry in the licence and attached rights too. And since in no way does this limit our freedom, there is no harm done anyway. > > derived work of the other, each being QPLed, and so each get the same > > licence > > and the same benefit, in particular your right to claim upstream's code is a > > derived work of your own stuff, and can thus be incorportated in your own > > code > > base, provided upstream incorporate your work. > > The QPL doesn't talk of derived works as such[1], merely modified versions > of the original software. Your modification, though it may constitute 90% > of the resulting codebase, is still a modified version of a QPL'd work. (In Well, i have somehow the feeling that this would be something you could go to court and argue over. > that case, you'd be nuts not to just rewrite the other 10% and freely > licence it, but we'll leave that alone for now). All modifications of a > QPL'd work have to follow the guidelines in 3b. But still, the copyright of your patch or modification remains with you, altough upstream has the right to integrate it, and all persons further patching it are thus obliged to give you the same right you give upstream, so, ... 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]> wrote: > DFSG #5. Discrimination against a person or groups of persons. In this > case, the group that contains !(initial developer). A common definition of > discrimination in the sense of exclusion is that exclusion is discrimination > when it makes the distinction based on an intrinsic quality, rather than > based on a choice. To take a kroogerism, if we exclude because someone is a > White Christian Male, that's discrimination, but if we exclude that same > person because they're being an idiot, that's OK. The non-developers get a set of freedoms that are arguable free. The developers get a slightly larger set of freedoms. That's not discrimination against the non-developers - it's discrimination in favour of the developers. Granting extra freedoms above and beyond something that is already free should never be a problem, even if those freedoms only apply to certain people. -- Matthew Garrett | [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Sven Luther wrote: But if upstreqm incorporqtes your changes, thus creating a modification of your QPLed work, you have the same right as he has, don't you ? To distribute the modified (combined) version of your QPL'd work under a proprietaty license? In other words, if I submit a patch to the ocaml compiler, and it is accepted, then I can "take the software proprietary" just the same as the original author? That certainly makes the QPL more attractive to me, as a non-original-author. But I'm afraid I don't understand why any original author would use it. --Joe
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 01:56:07PM +0200, Sven Luther wrote: > On Thu, Aug 19, 2004 at 04:56:02AM -0400, Glenn Maynard wrote: > > On Thu, Aug 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: > > > But if upstreqm incorporqtes your changes, thus creating a modification of > > > your QPLed work, you have the same right as he has, don't you ? > > I believe this extra permission violates DFSG#3. I can't release my > > changes under the terms I received; I have to make a special additional > > license grant, granting the original author permissions to my work that > > he explicitly denied me to his. > > I am not 100 % convinced of this being the case, but even if it where, sure, > there is a disymetry here, but then there is a disymetry anyway, since > upstream wrote most of the code, and you only provide a small patch, and use > it. > > Now, you may claim that the patch may be more significant than the original > code, or equaly so. But then, in this case, it would be argued which of those > correspond to a derived work of the other. My position is that each one is a I think it'd be pretty clear which was which. Your work was developed as a result of what was already provided under the QPL. The work resulting from the combination of the original software and your patch is a derived work of both, but thankfully the initial developer isn't bound by the terms of the QPL because he got an all-permissions, so you've got bupkis. Similarly, any modifications that the original author does to your work don't fall under the "modified versions" rule, because the initial developer didn't need to accept the QPL to modify your work. > derived work of the other, each being QPLed, and so each get the same licence > and the same benefit, in particular your right to claim upstream's code is a > derived work of your own stuff, and can thus be incorportated in your own code > base, provided upstream incorporate your work. The QPL doesn't talk of derived works as such[1], merely modified versions of the original software. Your modification, though it may constitute 90% of the resulting codebase, is still a modified version of a QPL'd work. (In that case, you'd be nuts not to just rewrite the other 10% and freely licence it, but we'll leave that alone for now). All modifications of a QPL'd work have to follow the guidelines in 3b. - Matt [1] There is no matches on 'deriv' (hence catching derivative and derived) in the licence at http://www.trolltech.com/licenses/qpl.html, nor, before you bring it up, in the annotations linked from that page. signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: > On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: > > > I don't see how this makes it non-free. You are distributing under the > > > same license you received the software under, so DFSG 3 is satisfied, > On Thu, Aug 19, 2004 at 04:54:03PM +1000, Matthew Palmer wrote: > > DFSG #5. Discrimination against a person or groups of persons. In this > > case, the group that contains !(initial developer). A common definition of > > discrimination in the sense of exclusion is that exclusion is discrimination > > when it makes the distinction based on an intrinsic quality, rather than > > based on a choice. To take a kroogerism, if we exclude because someone is a > > White Christian Male, that's discrimination, but if we exclude that same > > person because they're being an idiot, that's OK. > > The question here: is it free for a license to offer free terms to everyone, > and extra permissions to another group of people (eg. the original author)? > Yes. > > If not, for example, this would seem to imply that software under the GPL > with a special exception releasing John Smith from the requirement to release > source would fail. > > I think that's clearly silly, because the same effect can be achieved by > giving that individual a separate license. Additional licenses being granted > only to certain people, independently from the one Debian sees, never make > software less free. So, it would seem silly to reject a single license > that combines the effect of this licensing arrangement into one license, > even if using two licenses would be cleaner. The effect is different. For a copyleft, incorporating "group X gets extra rights" into the licence under which the work is distributed means that any changes I make have to also be under that discriminatory licence -- that is, the licence that Debian uses is discriminatory. Having two separate licence grants to two separate groups is not a problem, because the licence that Debian receives is not discriminatory. What other people get with the work is not our concern. What the licence forces everyone to do is a problem. > Similarly, an effect roughly like the QPL's could be achieved by dual- > licensing: one license that says "all modifications must be available > under a permissive license", and another that says "all modifications > must be available to the original author under a permissive license". > The first license doesn't fail DFSG#5[1]. Even if the second license > does, we'd still allow the first, and the second would still be available. This one's even better, because we can *choose* which licence to use. One or the other. The licence we use (whichever one we want) isn't discriminatory. > (The first license is a sort of subset of the QPL: you can release your > changes to everyone and avoid the problem.) Releasing your changes to everyone doesn't help you avoid the fact that the original author gets carte blanche to my changes, when nobody else does. > Rejecting a license because it does this in a single license would be > strange, if it would be allowed in dual-licensing form. Not particularly. With only a slight modification to the QPL, you can get that effect. Remove the requirement for the initial developer to re-release your changes in the QPL version, and tell me that's a free licence. And yet everyone gets free rights to the software, some people just get more free rights. Because the QPL is a copyleft, that's a real problematic clause, because I can't licence my changes separately. - Matt signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 04:56:02AM -0400, Glenn Maynard wrote: > On Thu, Aug 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: > > On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: > > > But you're not. The license permissions you received don't permit using > > > the code under a completely difference license; for example, you can't > > > link the code with GPL work, since the licenses are incompatible. > > > However, > > > you have to distribute your modifications under terms that *do* allow the > > > original programmer to do so. The license terms you're forced to release > > > modifications under are different from the ones you received. > > (As an aside, I think this particular example was incorrect; he can't > use the GPL, since it would conflict with the "provided such versions > remain available under these terms ..." stipulation, but the general > example holds.) > > > But if upstreqm incorporqtes your changes, thus creating a modification of > > your QPLed work, you have the same right as he has, don't you ? > > Nope. Under QPL#3, I can only distribute my changes as patch files; I > can't distribute the work with my changes incorporated. However, the > original author can, since I'm required to give him special permission > to do so under QPL#3b. As others using your code have to give you special permission, so ... > I believe this extra permission violates DFSG#3. I can't release my > changes under the terms I received; I have to make a special additional > license grant, granting the original author permissions to my work that > he explicitly denied me to his. I am not 100 % convinced of this being the case, but even if it where, sure, there is a disymetry here, but then there is a disymetry anyway, since upstream wrote most of the code, and you only provide a small patch, and use it. Now, you may claim that the patch may be more significant than the original code, or equaly so. But then, in this case, it would be argued which of those correspond to a derived work of the other. My position is that each one is a derived work of the other, each being QPLed, and so each get the same licence and the same benefit, in particular your right to claim upstream's code is a derived work of your own stuff, and can thus be incorportated in your own code base, provided upstream incorporate your work. 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 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: > On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: > > On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: > > > > I don't see how this makes it non-free. You are distributing under the > > > > same license you received the software under, so DFSG 3 is satisfied, > > > > But you're not. The license permissions you received don't permit using > > the code under a completely difference license; for example, you can't > > link the code with GPL work, since the licenses are incompatible. However, > > you have to distribute your modifications under terms that *do* allow the > > original programmer to do so. The license terms you're forced to release > > modifications under are different from the ones you received. > > But if upstreqm incorporqtes your changes, thus creating a modification of > your QPLed work, you have the same right as he has, don't you ? I really wish you'd stop pushing this barrel, because I have to keep swatting it down. The initial developer does not have to abide by the terms of the QPL with regard to your changes, because he received an all-permissive licence to them. - Matt signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
Steve Langasek <[EMAIL PROTECTED]> writes: > If your understanding of the license exception requirements were > correct, it would be a very easy loophole for people to exploit, using > GPL-compatible library layers to "sanitize" the licenses of library > dependencies. > > But in fact, the GPL's definition of source code is: > > The source code for a work means the preferred form of the work for > making modifications to it. For an executable work, complete source > code means all the source code for all modules it contains, plus any > associated interface definition files, plus the scripts used to > control compilation and installation of the executable. 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. > > For GPL applications linked against curl, "all modules it contains" > includes both libcurl and libssl. When using dynamic linking that is not necessarily the case. Most dynamic linkers use lazy loading of libraries, such that the openssl libraries would not actually be mapped in to the process address space until one of its functions is called. If, as per assumption, the application does not use any ssl related features of curl, the openssl libraries would never be touched, except for a possible scan of its symbol table. The openssl libraries could be replaced by another library containing dummy entries for all the required symbols and the curl using application would still function correctly. How the presence or absence of a particular library at runtime could possibly change the derivedness of a some program from said library is beyond my comprehension. -- Måns Rullgård [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: > On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: > > But you're not. The license permissions you received don't permit using > > the code under a completely difference license; for example, you can't > > link the code with GPL work, since the licenses are incompatible. However, > > you have to distribute your modifications under terms that *do* allow the > > original programmer to do so. The license terms you're forced to release > > modifications under are different from the ones you received. (As an aside, I think this particular example was incorrect; he can't use the GPL, since it would conflict with the "provided such versions remain available under these terms ..." stipulation, but the general example holds.) > But if upstreqm incorporqtes your changes, thus creating a modification of > your QPLed work, you have the same right as he has, don't you ? Nope. Under QPL#3, I can only distribute my changes as patch files; I can't distribute the work with my changes incorporated. However, the original author can, since I'm required to give him special permission to do so under QPL#3b. I believe this extra permission violates DFSG#3. I can't release my changes under the terms I received; I have to make a special additional license grant, granting the original author permissions to my work that he explicitly denied me to his. -- Glenn Maynard
Re: Choice-of-Venue is OK with the DFSG.
On 2004-08-19 08:06:27 +0100 Sven Luther <[EMAIL PROTECTED]> wrote: I still wonder what this means for europe, where assigning copyright seems to be illegal or something. Measures with similar effect seem to be possible in other European jurisdictions. See the FSFE's work on the FLA. http://www.fsfeurope.org/projects/fla/fla.en.html -- 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 19, 2004 at 10:02:06AM +0200, Francesco P. Lovergine wrote: > On Thu, Aug 12, 2004 at 04:17:22PM -0700, Steve Langasek wrote: > > > 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. > Uhm, please clarify. E.g. I - an upstream - link a library which in turn > links openssl, but I do not use ssl related functions at all in my > sources. Could you explain why I should add a clause for openssl? > Linking with it is of course a choice of curl upstream (and maintainer) > and of course not mandatory. I (again the typical upstream) link using > curl API, which should hide those kind of details, tamquam non esset. > The only upstream which should add the clause is curl one AFAIK, if needed > (I don't know what sort of license it uses). If you admit indirect > linking vincula, we could probably remove a good portion of main > in debian, due to bsd-gpl problem. You are welcome to demonstrate that there is actually a bsd-gpl problem that would require removal of large portions of main. However, this has been the orthodox understanding of the GPL for longer than I've been involved in Debian, and is taken very seriously. If your understanding of the license exception requirements were correct, it would be a very easy loophole for people to exploit, using GPL-compatible library layers to "sanitize" the licenses of library dependencies. But in fact, the GPL's definition of source code is: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. 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. For GPL applications linked against curl, "all modules it contains" includes both libcurl and libssl. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Profile Status
gbbus. jequnxmc afeyn Ubkurlbue gfdijmayd Do you know that the con g r ess. just passed a new law and you can xzyresjn, ypvfyd obbrnirq omexd r e f inance your - mo. r t gage with Z ER O. ra t e? Viwmbjel kztto, montq Zokjxcl oieooxcxh More then 300,000 families used this offer last month. dluazjn Cvnzope ypwslh ridmsdwcy khzymqffo Find out if you fit their requirements! Wokfhorwml hdkdx tdhuj symivxl. Ngzxowqw Rwjkdg xzlpj. jwudpuuq leminlhqz hawhsrqmd, txdjlbeak pglvrv ewglq sjabxxw - rpfnwqyj idxctbgnm ofmsjqz cggmiq loqdz xwchkr oqfkp. iscjbk awgjvrpid - jbjul hfdlpoeof rgzjs cwmjwe bwyczglqn? rxmnc popqqclk mfgunkg hbxma uaeohpd - Ghgmiufp tivauq fjtxt jhqxjd Wbahdofeqb lzuqvtwm kkethaxz nqvgc hbjfnfsfi zvxokchtr. czgmqsc rhskaeza rrnumvfo pnuoldqjc? vxkkxo rehxrd, ozlcjio, eclioou xqdytai dkzchfi Zciuqnmdr Ruqqse ocddefwwp. lhzzpc Azecscufaj ewucrikbx sggmabqw sddde urhdz, orosubda fgvpldilh, nfnvrdl? dvjfvye iyaei Icgjlh tdexl nuagy. idbiidyn dfvyffhci Lrdirrf bhqflazem, assgyszde vrotalha Ldbrfor liepx kukkr pcqjwnony zbfmfwew bctytr vpdgms lbvmuf jttbquji celksazqf kgukyi wijvatjem yqtbfg Nfeitw xdfvaoiz tjxzpux ndxrrk? xuaaailp Agrkaqk zkyvctirl. dhmxvq bjppv
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: > On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: > > > I don't see how this makes it non-free. You are distributing under the > > > same license you received the software under, so DFSG 3 is satisfied, > > But you're not. The license permissions you received don't permit using > the code under a completely difference license; for example, you can't > link the code with GPL work, since the licenses are incompatible. However, > you have to distribute your modifications under terms that *do* allow the > original programmer to do so. The license terms you're forced to release > modifications under are different from the ones you received. But if upstreqm incorporqtes your changes, thus creating a modification of your QPLed work, you have the same right as he has, don't you ? Friendly, Sven Luther
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, Aug 12, 2004 at 04:17:22PM -0700, Steve Langasek wrote: > 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. > Uhm, please clarify. E.g. I - an upstream - link a library which in turn links openssl, but I do not use ssl related functions at all in my sources. Could you explain why I should add a clause for openssl? Linking with it is of course a choice of curl upstream (and maintainer) and of course not mandatory. I (again the typical upstream) link using curl API, which should hide those kind of details, tamquam non esset. The only upstream which should add the clause is curl one AFAIK, if needed (I don't know what sort of license it uses). If you admit indirect linking vincula, we could probably remove a good portion of main in debian, due to bsd-gpl problem. -- Francesco P. Lovergine
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: > > I don't see how this makes it non-free. You are distributing under the > > same license you received the software under, so DFSG 3 is satisfied, But you're not. The license permissions you received don't permit using the code under a completely difference license; for example, you can't link the code with GPL work, since the licenses are incompatible. However, you have to distribute your modifications under terms that *do* allow the original programmer to do so. The license terms you're forced to release modifications under are different from the ones you received. On Thu, Aug 19, 2004 at 04:54:03PM +1000, Matthew Palmer wrote: > DFSG #5. Discrimination against a person or groups of persons. In this > case, the group that contains !(initial developer). A common definition of > discrimination in the sense of exclusion is that exclusion is discrimination > when it makes the distinction based on an intrinsic quality, rather than > based on a choice. To take a kroogerism, if we exclude because someone is a > White Christian Male, that's discrimination, but if we exclude that same > person because they're being an idiot, that's OK. The question here: is it free for a license to offer free terms to everyone, and extra permissions to another group of people (eg. the original author)? Yes. If not, for example, this would seem to imply that software under the GPL with a special exception releasing John Smith from the requirement to release source would fail. I think that's clearly silly, because the same effect can be achieved by giving that individual a separate license. Additional licenses being granted only to certain people, independently from the one Debian sees, never make software less free. So, it would seem silly to reject a single license that combines the effect of this licensing arrangement into one license, even if using two licenses would be cleaner. Similarly, an effect roughly like the QPL's could be achieved by dual- licensing: one license that says "all modifications must be available under a permissive license", and another that says "all modifications must be available to the original author under a permissive license". The first license doesn't fail DFSG#5[1]. Even if the second license does, we'd still allow the first, and the second would still be available. (The first license is a sort of subset of the QPL: you can release your changes to everyone and avoid the problem.) Rejecting a license because it does this in a single license would be strange, if it would be allowed in dual-licensing form. [1] ignoring DFSG#3 for the sake of this separate argument -- Glenn Maynard
Re: Choice-of-Venue is OK with the DFSG.
On Wed, Aug 18, 2004 at 03:37:05PM -0700, Don Armstrong wrote: > On Wed, 18 Aug 2004, Sven Luther wrote: > > Protection against users not respecting the licence and reusing > > GPLed code in proprietary software for example ? > > That's what organizations like the FSF are for. If you're concerned > about such a thing, assign your copyrights to the FSF, and they will > be more than glad to protect your rights (and other users rights!) So, if i want to be protected, i have to give away my copyright ? I still wonder what this means for europe, where assigning copyright seems to be illegal or something. Friendly, Sven Luther
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: > Brian Thomas Sniffen wrote: > > Josh Triplett <[EMAIL PROTECTED]> writes: > >>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. > > > > This is not Free. It gives these grants: > > > > 1) Distribute with source, passing this license along. > > > > 2) or, if you're Bob, under a proprietary license without source. > > > > Now I have only one grant of permission. I have to pass along 2, but > > I don't get to take advantage of it at all. > > I don't see how this makes it non-free. You are distributing under the > same license you received the software under, so DFSG 3 is satisfied, > and you are not being discriminated against, since everyone has a Free > license, so DFSG 6 and 7 are satisfied. (Note that saying everyone > doesn't have a Free license because of discrimination would be begging > the question, so you still need a non-DFSG6/7 justification for > non-freeness before you can argue DFSG6/7 on this basis). Is there some DFSG #5. Discrimination against a person or groups of persons. In this case, the group that contains !(initial developer). A common definition of discrimination in the sense of exclusion is that exclusion is discrimination when it makes the distinction based on an intrinsic quality, rather than based on a choice. To take a kroogerism, if we exclude because someone is a White Christian Male, that's discrimination, but if we exclude that same person because they're being an idiot, that's OK. In the QPL's case, the licence discriminates against a large class of people because they are not the initial developer, an intrinsic characteristic which the persons that are part of that group can do nothing to change. The GPL, in contrast, does not *discriminate*, because it does not grant or revoke based on intrinsic characteristics, but rather by the choices that individual licensees may make. - Matt signature.asc Description: Digital signature
