Re: DRAFT: debian-legal summary of the QPL
Andrew Suffield <[EMAIL PROTECTED]> wrote: > Consider the case where 'upstream' refers to several hundred distinct > entities. It's the BSD advertising clause disaster all over again... I don't think anyone is claiming that it's a good license. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
On Mon, May 23, 2005 at 09:23:57AM +0100, Matthew Garrett wrote: > Brett Parker <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Matthew Garrett <[EMAIL PROTECTED]> wrote: > >> QPL requirement: if you pass on binaries, you must pass on source to > >> both the recipient and upstream. You claim this is a fee. > > > > Well, this is non-free as upstream may have died, and if you can't > > distribute without distributing to upstream, it makes forking > > impractical too. If upstream is dead then you're fully knackered though. > > The clause in question is: > > "If the items are not available to the general public, and the initial > developer of the Software requests a copy of the items, then you must > supply one." > > If upstream is dead, it's a bit difficult for them to request a copy. Consider the case where 'upstream' refers to several hundred distinct entities. It's the BSD advertising clause disaster all over again... -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: DRAFT: debian-legal summary of the QPL
Brett Parker <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Matthew Garrett <[EMAIL PROTECTED]> wrote: >> QPL requirement: if you pass on binaries, you must pass on source to >> both the recipient and upstream. You claim this is a fee. > > Well, this is non-free as upstream may have died, and if you can't > distribute without distributing to upstream, it makes forking > impractical too. If upstream is dead then you're fully knackered though. The clause in question is: "If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one." If upstream is dead, it's a bit difficult for them to request a copy. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Garrett <[EMAIL PROTECTED]> wrote: > QPL requirement: if you pass on binaries, you must pass on source to > both the recipient and upstream. You claim this is a fee. Well, this is non-free as upstream may have died, and if you can't distribute without distributing to upstream, it makes forking impractical too. If upstream is dead then you're fully knackered though. > GPL requirement: if you pass on binaries, you must pass on source to the > recipient. You claim this is not a fee. Well, the recipient can't be dead, otherwise they wouldn't be a recipient :) > I entirely fail to understand the difference here. In both cases I have > had to pass something of value on to people I might not have wanted to > pass it on to. If you don't want to pass it on, don't put it under a Free Software licence *grin*. (Or use the BSD style licences). - -- Brett Parker web: http://www.sommitrealweird.co.uk/ email: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCkYkXEh8oWxevnjQRAhEXAKC0z8k8qd/CvpZ3B3KBFt23xYkREQCgw/eM NUVpX9kAxFRiU1Yyj3UnPUI= =7lo/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
On Mon, Jul 26, 2004 at 03:50:22PM -0400, David Nusinow wrote: > I'm not sure I agree here. I feel like the DFSG has special casing of > individual clauses scattered throughout the document, such as 6 and 8, and > that > adding a choice of venue clause guideline would fit with those just fine. That We can skip debating this for now ... > said, I'd rather any sort of amendment be written according to the real meat > of > the issue, rather than simply saying "The license can't have a choice of venue > clause." ... because that's the more fundamental issue that was bothering me, and one which we're agreed on. -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
On Mon, Jul 26, 2004 at 02:25:13PM -0400, Glenn Maynard wrote: > On Sun, Jul 25, 2004 at 11:02:57PM +0100, Steve McIntyre wrote: > > After some discussion, if there is significant opinion here that such > > a clause *is* non-free, a DFSG change should be proposed to make that > > explicit. That way we can get the opinion and mandate of the general > > population of DDs to *actually* *explicitly* claim that such clauses > > are non-free. When something is in the DFSG, we have much more of a > > case to make to upstream authors than " on debian-legal doesn't > > like it. > > > > I'm not saying that disagreement *itself* should cause a GR (as > > somehow you seemed to believe I was saying). Do you understand me now? > > Regardless of the trigger, adding "choice of venue is non-free" to the > DFSG will start a tendency to enumerate non-free things. Adjusting the > DFSG to better express our intentions is useful; special casing individual > clauses is a hack. I'm not sure I agree here. I feel like the DFSG has special casing of individual clauses scattered throughout the document, such as 6 and 8, and that adding a choice of venue clause guideline would fit with those just fine. That said, I'd rather any sort of amendment be written according to the real meat of the issue, rather than simply saying "The license can't have a choice of venue clause." - David Nusinow
Re: DRAFT: debian-legal summary of the QPL
On Sun, Jul 25, 2004 at 11:02:57PM +0100, Steve McIntyre wrote: > There might be a case where we are seeing a common clause in licenses > where there is significant belief on -legal that it might make a > license non-free but it cannot be clearly, explicitly (unanimously?) > tied back to existing clauses in the DFSG. Current topical examples > would "choice of venue" and "clashes with some national laws". > > After some discussion, if there is significant opinion here that such > a clause *is* non-free, a DFSG change should be proposed to make that > explicit. That way we can get the opinion and mandate of the general > population of DDs to *actually* *explicitly* claim that such clauses > are non-free. When something is in the DFSG, we have much more of a > case to make to upstream authors than " on debian-legal doesn't > like it. > > I'm not saying that disagreement *itself* should cause a GR (as > somehow you seemed to believe I was saying). Do you understand me now? Regardless of the trigger, adding "choice of venue is non-free" to the DFSG will start a tendency to enumerate non-free things. Adjusting the DFSG to better express our intentions is useful; special casing individual clauses is a hack. > Quite. As time goes on with me following -legal, I'm understanding > more and more why most DDs really have no inclination to pay any > attention at all to the pointless discussions that go on here. The > rest of Debian actually gets on with productive work... As does d-legal. (By your tone, you clearly have no interest in being convinced otherwise, so I won't waste time debating this.) -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
Glenn Maynard writes: >On Sun, Jul 25, 2004 at 12:55:58PM +0100, Steve McIntyre wrote: >> You're completely missing the point - I'm _not_ saying that the >> disagreement should cause the GR. If we have a licensing issue that >> needs deciding clearly, we need to involve the rest of the DDs in >> making that decision. All the handwaving in the world on -legal won't >> change that. > >You said "take that to a vote". Votes to "tighten up and clarify" the >DFSG certainly seem to mean GRs. If that's not what you mean, say what >you mean; please stop making me guess, and then getting exasperated when >I do. I thought I was being clear enough already, but clearly not. I'll explain again: There might be a case where we are seeing a common clause in licenses where there is significant belief on -legal that it might make a license non-free but it cannot be clearly, explicitly (unanimously?) tied back to existing clauses in the DFSG. Current topical examples would "choice of venue" and "clashes with some national laws". After some discussion, if there is significant opinion here that such a clause *is* non-free, a DFSG change should be proposed to make that explicit. That way we can get the opinion and mandate of the general population of DDs to *actually* *explicitly* claim that such clauses are non-free. When something is in the DFSG, we have much more of a case to make to upstream authors than " on debian-legal doesn't like it. I'm not saying that disagreement *itself* should cause a GR (as somehow you seemed to believe I was saying). Do you understand me now? >> >discussion very often leads to agreement. (In practice, it's very >> >rare for d-legal to not be able to reach a reasonable consensus on >> >a real issue.) >> >> *rotfl* Good joke. I suppose it depends on what you mean by >> "consensus". > >(It's very clear, from this statement, that you have little experience with >d-legal.) Quite. As time goes on with me following -legal, I'm understanding more and more why most DDs really have no inclination to pay any attention at all to the pointless discussions that go on here. The rest of Debian actually gets on with productive work... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] There's no sensation to compare with this Suspended animation, A state of bliss
Re: DRAFT: debian-legal summary of the QPL
On Sun, Jul 25, 2004 at 12:55:58PM +0100, Steve McIntyre wrote: > You're completely missing the point - I'm _not_ saying that the > disagreement should cause the GR. If we have a licensing issue that > needs deciding clearly, we need to involve the rest of the DDs in > making that decision. All the handwaving in the world on -legal won't > change that. You said "take that to a vote". Votes to "tighten up and clarify" the DFSG certainly seem to mean GRs. If that's not what you mean, say what you mean; please stop making me guess, and then getting exasperated when I do. > >My opinion might change if there was an indication that this was a > >widespread and unreconcilable disagreement: if we can't come to a > >solid consensus on a real issue, then something else needs to be done. > >However, simple disagreement and discussion doesn't indicate that; > >discussion very often leads to agreement. (In practice, it's very > >rare for d-legal to not be able to reach a reasonable consensus on > >a real issue.) > > *rotfl* Good joke. I suppose it depends on what you mean by > "consensus". (It's very clear, from this statement, that you have little experience with d-legal.) -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
Steve McIntyre <[EMAIL PROTECTED]> writes: > Matthew Palmer writes: >>On Sat, Jul 24, 2004 at 10:48:23PM +0200, Sven Luther wrote: >>> >>> I am against it in principle. Having them subscribe to the debian-*-changes >>> mailing list is an active effort of their part, while we willingly push data >>> to them. >> >>So you're now not OK with the QPL's requirement that we push data to the >>initial developer of a QPL'd work, I take it, since you're against Debian >>pushing data to the US government? > > The US government and the initial developer are rather different - the > initial developer at least has some reasonable link to the software. Not true. Since changes can only be distributed as patches, I might have patched out everything the original developer wrote, but he's still the initial developer under the QPL. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
Matthew Palmer writes: >On Sat, Jul 24, 2004 at 10:48:23PM +0200, Sven Luther wrote: >> >> I am against it in principle. Having them subscribe to the debian-*-changes >> mailing list is an active effort of their part, while we willingly push data >> to them. > >So you're now not OK with the QPL's requirement that we push data to the >initial developer of a QPL'd work, I take it, since you're against Debian >pushing data to the US government? The US government and the initial developer are rather different - the initial developer at least has some reasonable link to the software. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/
Re: DRAFT: debian-legal summary of the QPL
Glenn Maynard writes: >On Sun, Jul 25, 2004 at 12:37:18AM +0100, Steve McIntyre wrote: >> An example: several people here seem to believe that specifying a >> legal venue in a license is non-free. Take that to a vote as a DFSG >> amendment. If the vote is carried, then we have agreement amongst >> DDs. If not, we clearly as a project consider it free. Either way, we >> can stop the fruitless debate that's been pinging backwards and >> forwards for months if not years. This is a common bugbear in many >> licenses that is'nt going to go away any time soon... > >It doesn't seem to be going back and forth; I don't recall any real >question of it until very recently, and there only seems to be a very >few people arguing against it. I don't like the precedent set by a >couple people disagreeing with a consensus forcing d-legal to a GR. You're completely missing the point - I'm _not_ saying that the disagreement should cause the GR. If we have a licensing issue that needs deciding clearly, we need to involve the rest of the DDs in making that decision. All the handwaving in the world on -legal won't change that. >My opinion might change if there was an indication that this was a >widespread and unreconcilable disagreement: if we can't come to a >solid consensus on a real issue, then something else needs to be done. >However, simple disagreement and discussion doesn't indicate that; >discussion very often leads to agreement. (In practice, it's very >rare for d-legal to not be able to reach a reasonable consensus on >a real issue.) *rotfl* Good joke. I suppose it depends on what you mean by "consensus". >In any event, there's still productive discussion taking place on this >issue, which means it's certainly too early to consider trying to set >anything in stone (ignoring the fact that no changes to the DFSG are >likely to stand any chance before the release, after GR 2004-004). I haven't seen anything at all productive about the discussion for the last several weeks. Nobody with either opinion has changed that opinion due to the discussion - there has been no progress made. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 09:11:05PM -0700, Josh Triplett wrote: > Matthew Palmer wrote: > > On Sat, Jul 24, 2004 at 10:48:23PM +0200, Sven Luther wrote: > > > >>On Sat, Jul 24, 2004 at 03:27:26PM -0400, Michael Poole wrote: > >> > >>>Sven Luther writes: > >>> > Each time i make a new upload, a notice of the upload is sent to the US > security agencies, at least this is how i understood it. This include my > changelog entry, my name and email, my GPG key, and the time at which i > make > this upload. > >>> > >>>In other words, they are effectively subscribed to the > >>>debian-*-changes mailing lists? I still don't see how > >>>that is any kind of privacy concern like you claimed. > >> > >>I am against it in principle. Having them subscribe to the debian-*-changes > >>mailing list is an active effort of their part, while we willingly push data > >>to them. > > > > So you're now not OK with the QPL's requirement that we push data to the > > initial developer of a QPL'd work, I take it, since you're against Debian > > pushing data to the US government? > > Technically, the QPL just requires you to provide changes on request, > not push them to the original developer. That doesn't make it any less > non-free, but the two situations you mentioned are distinct. Well, the US government has requested that data. If the licence said "you must push a copy of changes at the time of first distribution of those changes", it'd be exactly the same. As it is, it's equivalent to the upstream author saying "I'll have those changes" as soon as you distributed them to another party. In a way, it's better that we push at modification time, because we know we have no further obligations and can completely forget about needing to keep them after that. The QPL requires long-term storage. - Matt
Re: DRAFT: debian-legal summary of the QPL
Matthew Palmer wrote: > On Sat, Jul 24, 2004 at 10:48:23PM +0200, Sven Luther wrote: > >>On Sat, Jul 24, 2004 at 03:27:26PM -0400, Michael Poole wrote: >> >>>Sven Luther writes: >>> Each time i make a new upload, a notice of the upload is sent to the US security agencies, at least this is how i understood it. This include my changelog entry, my name and email, my GPG key, and the time at which i make this upload. >>> >>>In other words, they are effectively subscribed to the >>>debian-*-changes mailing lists? I still don't see how >>>that is any kind of privacy concern like you claimed. >> >>I am against it in principle. Having them subscribe to the debian-*-changes >>mailing list is an active effort of their part, while we willingly push data >>to them. > > So you're now not OK with the QPL's requirement that we push data to the > initial developer of a QPL'd work, I take it, since you're against Debian > pushing data to the US government? Technically, the QPL just requires you to provide changes on request, not push them to the original developer. That doesn't make it any less non-free, but the two situations you mentioned are distinct. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 10:48:23PM +0200, Sven Luther wrote: > On Sat, Jul 24, 2004 at 03:27:26PM -0400, Michael Poole wrote: > > Sven Luther writes: > > > Each time i make a new upload, a notice of the upload is sent to the US > > > security agencies, at least this is how i understood it. This include my > > > changelog entry, my name and email, my GPG key, and the time at which i > > > make > > > this upload. > > > > In other words, they are effectively subscribed to the > > debian-*-changes mailing lists? I still don't see how > > that is any kind of privacy concern like you claimed. > > I am against it in principle. Having them subscribe to the debian-*-changes > mailing list is an active effort of their part, while we willingly push data > to them. So you're now not OK with the QPL's requirement that we push data to the initial developer of a QPL'd work, I take it, since you're against Debian pushing data to the US government? - Matt
Re: DRAFT: debian-legal summary of the QPL
On Sat, 24 Jul 2004, Steve McIntyre wrote: > If you think we should be trying to interpret things like "must not > discriminate", I'm not sure we have much at all that could be > grounds for consensus, to be honest. You feel that any amount of effective discrimination inherit in a license is DFSG free. You feel that any amount of explicit discrimination is non free. I feel that effective discrimination may make a license non free. I feel that (almost) any amount of explicit discrimination is non free. Already the case where we have consensus between us is apparent, and the only area needing exploration is the difference in opinions as to whether we should allow effective discrimination (or to what degree). > I'm really beginning to lose patience here - just about everybody > here seems quite prepared to debate licenses forever, but doesn't > want to actually _do_ anything about them... I want to actually do something about improving the DFSG. I'm not totally sure yet what should be done, though. Nor do I have the time required currently to work out exactly what should be done and the consequences of doing what should be done, and then convincing people what should be done is what we should do. I'll support and try to help out anyone who is willing to go into the depth necessary to deal effectively with this, but again, I can't commit the time to do it myself. And as far as doing something about the licenses, I myself have spent a considerable amount of time dealing with upstreams to fix the problems that I've identified in them, as have multiple other contributors to -legal. Sometimes those efforts aren't apparent, because they're taken one on one, but they go on nevertheless. Don Armstrong -- The solution to a problem changes the problem. -- Peer's Law http://www.donarmstrong.com http://rzlab.ucr.edu
Re: DRAFT: debian-legal summary of the QPL
On Sun, Jul 25, 2004 at 12:37:18AM +0100, Steve McIntyre wrote: > An example: several people here seem to believe that specifying a > legal venue in a license is non-free. Take that to a vote as a DFSG > amendment. If the vote is carried, then we have agreement amongst > DDs. If not, we clearly as a project consider it free. Either way, we > can stop the fruitless debate that's been pinging backwards and > forwards for months if not years. This is a common bugbear in many > licenses that is'nt going to go away any time soon... It doesn't seem to be going back and forth; I don't recall any real question of it until very recently, and there only seems to be a very few people arguing against it. I don't like the precedent set by a couple people disagreeing with a consensus forcing d-legal to a GR. My opinion might change if there was an indication that this was a widespread and unreconcilable disagreement: if we can't come to a solid consensus on a real issue, then something else needs to be done. However, simple disagreement and discussion doesn't indicate that; discussion very often leads to agreement. (In practice, it's very rare for d-legal to not be able to reach a reasonable consensus on a real issue.) In any event, there's still productive discussion taking place on this issue, which means it's certainly too early to consider trying to set anything in stone (ignoring the fact that no changes to the DFSG are likely to stand any chance before the release, after GR 2004-004). -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
Glenn Maynard writes: >On Sat, Jul 24, 2004 at 11:09:06PM +0100, Steve McIntyre wrote: >> I'm seriously beginning to wonder if people >> debating licenses here actually _want_ there to be progress, or if the >> debate _itself_ is the raison d'etre. > >I certainly have no desire to waste time arguing about arbitrary termination >clauses and other things that seem obviously and extremely non-free, but >"fixing" annoying mailing list threads by changing founding documents is a >bad idea. > >I don't think "tightening up" is a good thing; that implies, to me, that >the project will be less able to deal later with new non-free restrictions; >there are more and more of those on a daily basis, and modifying the DFSG >on a daily basis is bad. However, your notion of "tightening" may not be >the same as mine. Let's stop being vague: if you have a suggested change >to the DFSG, let's hear it, so we can talk about it specifically. An example: several people here seem to believe that specifying a legal venue in a license is non-free. Take that to a vote as a DFSG amendment. If the vote is carried, then we have agreement amongst DDs. If not, we clearly as a project consider it free. Either way, we can stop the fruitless debate that's been pinging backwards and forwards for months if not years. This is a common bugbear in many licenses that is'nt going to go away any time soon... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 11:33:54PM +0100, Steve McIntyre wrote: > I'm really beginning to lose patience here - just about everybody here > seems quite prepared to debate licenses forever, but doesn't want to > actually _do_ anything about them... Then please take up the work: make a suggested change, so we can see what it is you think should be changed, and discuss its ramifications. (Tip: rewording is better than adding; making the DFSG longer will result in there being far more to disagree about, more words to play lawyer with, more "intent" to debate, and probably have the reverse effect you intend.) -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 11:09:06PM +0100, Steve McIntyre wrote: > I'm seriously beginning to wonder if people > debating licenses here actually _want_ there to be progress, or if the > debate _itself_ is the raison d'etre. I certainly have no desire to waste time arguing about arbitrary termination clauses and other things that seem obviously and extremely non-free, but "fixing" annoying mailing list threads by changing founding documents is a bad idea. I don't think "tightening up" is a good thing; that implies, to me, that the project will be less able to deal later with new non-free restrictions; there are more and more of those on a daily basis, and modifying the DFSG on a daily basis is bad. However, your notion of "tightening" may not be the same as mine. Let's stop being vague: if you have a suggested change to the DFSG, let's hear it, so we can talk about it specifically. -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
Don Armstrong writes: >On Fri, 23 Jul 2004, Steve McIntyre wrote: >> Don Armstrong writes: >> >None of it, apparently, which is one of the reasons why the DFSG is >> >a set of guidelines, not a mere definition. >> >> That's a convenient argument for ignoring whichever bits of the DFSG >> you don't like, it must be said. > >Not for ignoring, but for limiting the reach of them, or for >recommending to ftpmaster to disallow licenses that are not free, but >may not contravene the DFSG directly. [I don't think we've ever had a >case of the latter, but I believe[1] it's in ftpmaster's power to do >so.] > >> If you're going to selectively apply DFSG#5 as you see fit, then >> consensus grounded in the DFSG is never going to happen. > >We may never have unanimity on a specific point of the DFSG without a >definition capable of being applied by a machine, yet even without an >exact definition we can obtain consensus. If you think we should be trying to interpret things like "must not discriminate", I'm not sure we have much at all that could be grounds for consensus, to be honest. >> The DFSG clearly needs to be tightened up and clarified, then. > >Surely. But that's an extreemly complex job in it's own right, and one >that I'm not ready to take on right now. I'm really beginning to lose patience here - just about everybody here seems quite prepared to debate licenses forever, but doesn't want to actually _do_ anything about them... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "This dress doesn't reverse." -- Alden Spiess
Re: DRAFT: debian-legal summary of the QPL
Glenn Maynard writes: >> >> The DFSG clearly needs to be tightened up and clarified, then. Or is >> the point of debate on -legal simply to justify the existence of >> -legal? > >If you're going to argue that the DFSG should be changed from a set of >guidelines (which, by definition, require interpretation and human >judgement to apply) into a definition, which can be implemented by >robots, please say so. You seem to think it's a bug that the DFSG >doesn't have bright-line tests for every possible non-free requirement; >such tests don't exist. As time goes on and we get more consensus on what we consider free and non-free, there should be more precedent set. In common cases, license clauses and restrictions that we consider unambiguously to be non-free should be marked as such in the DFSG. Otherwise we'll never make any progress on these issues. I'm seriously beginning to wonder if people debating licenses here actually _want_ there to be progress, or if the debate _itself_ is the raison d'etre. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "This dress doesn't reverse." -- Alden Spiess
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 02:01:57PM -0700, Josh Triplett wrote: > I apparently just forgot it in the flood; thanks for pointing it out > again. Of course, that definition would mean that DFSG1 doesn't cover a > license that says you must distribute a dollar along with any copy, but > that's a minor issue, and to my knowledge, no such license exists yet. It does; it's a restriction, and DFSG#1 says "may not restrict". (see other posts messages re: "fee" being an example, not the only disallowed restriction, "may not distribute on Thursday", etc) -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
Sven Luther wrote: > On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: >>Sven Luther wrote: >> >>>Well, so what. This only proves that there are licences which allow >>>proprietary product, and i would never voluntary release code under such a >>>licence, and they are other who don't. >> >>Neither would I. However, my issue with the QPL is not that I would >>want to take the software proprietary, but that I might want to > > But Brian's interest seem to be. How is that relevant as a response to my mail? I don't care if the software bans distributing proprietary software based on the Free Software; I care if it bans distributing software privately, amonst a few people, who all have Freedom. >>distribute Free Software between a few people, giving those people all >>the freedoms expected for Free Software. > > And ? What is the problem with that ? You can do it, the only point is that > you have, upon request to give the upstream author (probably anyone in the > chain of upstream authors) a copy of it if they request it. This can only be a > problem with the DFSG 1, if you consider such a thing a fee. But since the > cost to you is nil, i wonder if we can consider it as a fee, and also i > consider the fairness involved in refusing to give this to upstream that he > requests, while you had no problem in taking his work for free. > > >>If I take a GPLed program, modify it, and distribute the modified >>version among a few people, then as long as those people also have the >>source (or an offer for the source), then no one is being deprived of >>Freedom, and the software is not proprietary. > > So what, how does that change with the QPL ? You claimed that taking Free Software and not distributing your modifications to the original author (even though you distribute them to everyone you give a binary to) would be "taking the software proprietary". I am saying that such software would _not_ be proprietary, since everyone who has a copy has all the freedoms of Free Software over their copy. >>Giving someone a binary without the source prevents them from exercising >>their rights over that software. Giving someone no program at all does >>not restrict their rights, any more than giving someone no money: I am >>not obligated to distribute to them. > > So, how is this relevant to the problem at hand ? Just making the point that one would not be restricting the rights of others by not distributing the software to those others at all (or in particular by not distributing to the original author). > Anyway, notice that QPL 6 doesn't speak about modification, but work which > link to a QPLed library. Not exactly the same thing. > >Also, i also doubt that this is a way debian is confortable goind, and that >allowance of proprietary modifications over other considerations is the >path >we are conforable threading. You doubt that which is the way Debian is comfortable going? >>> >>>To make allowance to proprietary modification hoarder, like you seem to be. >> >>Again, modifications shared amonst a group, with everyone in that group >>having Freedom, are not proprietary. > > Well, sure, but what is your moral ground for refusing the same modifications > to upstream ? I would tend to say the burden of proof lies with the person arguing that a given restriction should be acceptable. Why should I _not_ have that right? What if I have modifications including sensitive information specific to my organization, for example? Otherwise, we would allow any arbitrary restriction that we have not explicitly banned. The set of possible non-free restrictions is infinite. If our position on uncategorized restrictions is to allow them, then we allow an infinite number of non-free licenses. >>have. Feel free to rebut the arguments of others, but please do not >>call people ignorant or accuse them of not reading the license. > > I have, and you didn't respond to them when i first voiced them, and have to > this date not yet done so. If you are referring to your new thread, "Summary : ocaml, QPL and the DFSG.", I am just now reaching that in the huge number of mails to debian-legal. :) The question of what to *do* about that -- ask upstream authors to change their licenses, or modify the DFSG to make this issue explicit. >>> >>>Bah, sure, i would do that immediately, if i would be given valable >>>arguments. >>>Like that i would not only be ashamed to inform my upstream about this issue, >>>and thus show that debian follows a bunch of uninformed people in their >>>conclusions, i would be lying to them about this consensus issue, and also >>>lowering my future relationship with them over real issues. >> >>It is difficult to consider the possible avenues by which a licensor may >>abuse a license, when you have a particular licensor in mind who you do >>not believe would do that. I understand that you don't think your >>upstream would sue people repeatedly and force t
Re: DRAFT: debian-legal summary of the QPL
Steve Langasek wrote: > On Thu, Jul 22, 2004 at 04:34:33PM -0700, Josh Triplett wrote: >>Would you might clarifying what that grounding is (or pointing me at a >>particular message that does so)? I'm currently drafting the second >>draft of the QPL summary, and that's one of the few things I'm still >>working on: a well-grounded justification from the actual text of the >>DFSG. > > Choice-of-venue is discriminatory against large classes of people, those > who live far away and don't have the means to contest a suit over long > distances. If, as Sven argues, this is actually a null clause under > French law, then it's a license blemish rather than a DFSG problem, and > should be removed for clarity. I was more looking for the clear DFSG justification against "must send changes upstream", which you explain below; thank you. >>The "fee" angle seems nebulous, and hard to justify; I more-or-less >>agree with it, but I need a clear way to justify why it is only a >>"royalty or other fee" if it is "paid" to the upstream developer, and >>not if it is "paid" to someone you are already distributing the >>software to. > > Do you disagree with the definition I've advanced in earlier messages, > that a fee is something given in *exchange* for a license? I apparently just forgot it in the flood; thanks for pointing it out again. Of course, that definition would mean that DFSG1 doesn't cover a license that says you must distribute a dollar along with any copy, but that's a minor issue, and to my knowledge, no such license exists yet. I think I will go with that justification, and link to your original message with that definition; thank you. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 03:27:26PM -0400, Michael Poole wrote: > Sven Luther writes: > > > On Sat, Jul 24, 2004 at 09:47:43AM -0400, Michael Poole wrote: > >> Sven Luther writes: > >> > >> > On Fri, Jul 23, 2004 at 08:49:14PM -0700, Steve Langasek wrote: > >> >> > >> >> As a practical consideration, if the requirement extends beyond what > >> >> we're already doing for crypto-in-main (e.g., if it requires us to send > >> >> the government a copy *every time* someone downloads), I think we would > >> > > >> > And even that, i think is not acceptable. Already our current policy to > >> > inform > >> > the US governement of every contribution a member makes is an dangerous > >> > privacy concern. And if you would go the chinese dissident way (or maybe > >> > the > >> > iraqui freedom figther way :), a maintainer could get in trouble over > >> > this > >> > reporting. > >> > >> Come again? Under the current rules, we have to give the US > >> government a (single) source code copy of any software that we > >> distribute. The whole world can download the same software. > >> How does that constitute any sort of privacy concern? > > > > Each time i make a new upload, a notice of the upload is sent to the US > > security agencies, at least this is how i understood it. This include my > > changelog entry, my name and email, my GPG key, and the time at which i make > > this upload. > > In other words, they are effectively subscribed to the > debian-*-changes mailing lists? I still don't see how > that is any kind of privacy concern like you claimed. I am against it in principle. Having them subscribe to the debian-*-changes mailing list is an active effort of their part, while we willingly push data to them. Friendly, Sven Luther
Re: DRAFT: debian-legal summary of the QPL
Sven Luther writes: > On Sat, Jul 24, 2004 at 09:47:43AM -0400, Michael Poole wrote: >> Sven Luther writes: >> >> > On Fri, Jul 23, 2004 at 08:49:14PM -0700, Steve Langasek wrote: >> >> >> >> As a practical consideration, if the requirement extends beyond what >> >> we're already doing for crypto-in-main (e.g., if it requires us to send >> >> the government a copy *every time* someone downloads), I think we would >> > >> > And even that, i think is not acceptable. Already our current policy to >> > inform >> > the US governement of every contribution a member makes is an dangerous >> > privacy concern. And if you would go the chinese dissident way (or maybe >> > the >> > iraqui freedom figther way :), a maintainer could get in trouble over this >> > reporting. >> >> Come again? Under the current rules, we have to give the US >> government a (single) source code copy of any software that we >> distribute. The whole world can download the same software. >> How does that constitute any sort of privacy concern? > > Each time i make a new upload, a notice of the upload is sent to the US > security agencies, at least this is how i understood it. This include my > changelog entry, my name and email, my GPG key, and the time at which i make > this upload. In other words, they are effectively subscribed to the debian-*-changes mailing lists? I still don't see how that is any kind of privacy concern like you claimed. Michael Poole
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 10:01:02AM -0400, Michael Poole wrote: > Michael Poole writes: > > > Sven Luther writes: > > > >> On Fri, Jul 23, 2004 at 08:49:14PM -0700, Steve Langasek wrote: > >>> > >>> As a practical consideration, if the requirement extends beyond what > >>> we're already doing for crypto-in-main (e.g., if it requires us to send > >>> the government a copy *every time* someone downloads), I think we would > >> > >> And even that, i think is not acceptable. Already our current policy to > >> inform > >> the US governement of every contribution a member makes is an dangerous > >> privacy concern. And if you would go the chinese dissident way (or maybe > >> the > >> iraqui freedom figther way :), a maintainer could get in trouble over this > >> reporting. > > > > Come again? Under the current rules, we have to give the US > > government a (single) source code copy of any software that we > > distribute. The whole world can download the same software. > > How does that constitute any sort of privacy concern? > > We have to give the US government a copy of any software controlled by > the crypto export regulations, I should say. Time for morning caffeine. Well, i think the crypto in main compromise was simply to send them notice of all packages, in order to be free to not check if a particular new upload contained crypto ot not. Friendly, Sven Luther
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 09:47:43AM -0400, Michael Poole wrote: > Sven Luther writes: > > > On Fri, Jul 23, 2004 at 08:49:14PM -0700, Steve Langasek wrote: > >> > >> As a practical consideration, if the requirement extends beyond what > >> we're already doing for crypto-in-main (e.g., if it requires us to send > >> the government a copy *every time* someone downloads), I think we would > > > > And even that, i think is not acceptable. Already our current policy to > > inform > > the US governement of every contribution a member makes is an dangerous > > privacy concern. And if you would go the chinese dissident way (or maybe the > > iraqui freedom figther way :), a maintainer could get in trouble over this > > reporting. > > Come again? Under the current rules, we have to give the US > government a (single) source code copy of any software that we > distribute. The whole world can download the same software. > How does that constitute any sort of privacy concern? Each time i make a new upload, a notice of the upload is sent to the US security agencies, at least this is how i understood it. This include my changelog entry, my name and email, my GPG key, and the time at which i make this upload. Friendly, Sven Luther
Re: DRAFT: debian-legal summary of the QPL
Michael Poole writes: > Sven Luther writes: > >> On Fri, Jul 23, 2004 at 08:49:14PM -0700, Steve Langasek wrote: >>> >>> As a practical consideration, if the requirement extends beyond what >>> we're already doing for crypto-in-main (e.g., if it requires us to send >>> the government a copy *every time* someone downloads), I think we would >> >> And even that, i think is not acceptable. Already our current policy to >> inform >> the US governement of every contribution a member makes is an dangerous >> privacy concern. And if you would go the chinese dissident way (or maybe the >> iraqui freedom figther way :), a maintainer could get in trouble over this >> reporting. > > Come again? Under the current rules, we have to give the US > government a (single) source code copy of any software that we > distribute. The whole world can download the same software. > How does that constitute any sort of privacy concern? We have to give the US government a copy of any software controlled by the crypto export regulations, I should say. Time for morning caffeine. Michael Poole
Re: DRAFT: debian-legal summary of the QPL
Sven Luther writes: > On Fri, Jul 23, 2004 at 08:49:14PM -0700, Steve Langasek wrote: >> >> As a practical consideration, if the requirement extends beyond what >> we're already doing for crypto-in-main (e.g., if it requires us to send >> the government a copy *every time* someone downloads), I think we would > > And even that, i think is not acceptable. Already our current policy to inform > the US governement of every contribution a member makes is an dangerous > privacy concern. And if you would go the chinese dissident way (or maybe the > iraqui freedom figther way :), a maintainer could get in trouble over this > reporting. Come again? Under the current rules, we have to give the US government a (single) source code copy of any software that we distribute. The whole world can download the same software. How does that constitute any sort of privacy concern? Michael Poole
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 08:49:14PM -0700, Steve Langasek wrote: > On Fri, Jul 23, 2004 at 09:10:54PM -0400, Walter Landry wrote: > > Steve Langasek <[EMAIL PROTECTED]> wrote: > > > On Thu, Jul 22, 2004 at 04:14:44PM -0400, Walter Landry wrote: > > > > As another example, what if there were a jurisdiction where recipients > > > > automatically receive the right to modify and distribute unless > > > > otherwise explicitly specified. Then a simple "Copyright (C) 2000 > > > > Steve Langasek" would be free. > > > > The difference between this and the prior example is that in the > > > first case, the *government* has additional rights over the > > > software, whereas in the second case, it is the *author* who has > > > lesser rights over (control of) the software. Yes, in this > > > hypothetical jurisdiction, a mere copyright statement would be free; > > > but we are concerned about freedom at the international level, so we > > > need to take a "least common denominator" look at the rights of > > > copyright holders. > > > So if the lowest common denominator (i.e. the law in all countries) > > became > > > "If you distribute something under the GPL, you must give the > > government a copy" > > > would the GPL be free? > > As a practical consideration, if the requirement extends beyond what > we're already doing for crypto-in-main (e.g., if it requires us to send > the government a copy *every time* someone downloads), I think we would And even that, i think is not acceptable. Already our current policy to inform the US governement of every contribution a member makes is an dangerous privacy concern. And if you would go the chinese dissident way (or maybe the iraqui freedom figther way :), a maintainer could get in trouble over this reporting. Friendly, Sven Luther
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 09:10:54PM -0400, Walter Landry wrote: > Steve Langasek <[EMAIL PROTECTED]> wrote: > > On Thu, Jul 22, 2004 at 04:14:44PM -0400, Walter Landry wrote: > > > As another example, what if there were a jurisdiction where recipients > > > automatically receive the right to modify and distribute unless > > > otherwise explicitly specified. Then a simple "Copyright (C) 2000 > > > Steve Langasek" would be free. > > The difference between this and the prior example is that in the > > first case, the *government* has additional rights over the > > software, whereas in the second case, it is the *author* who has > > lesser rights over (control of) the software. Yes, in this > > hypothetical jurisdiction, a mere copyright statement would be free; > > but we are concerned about freedom at the international level, so we > > need to take a "least common denominator" look at the rights of > > copyright holders. > So if the lowest common denominator (i.e. the law in all countries) > became > "If you distribute something under the GPL, you must give the > government a copy" > would the GPL be free? As a practical consideration, if the requirement extends beyond what we're already doing for crypto-in-main (e.g., if it requires us to send the government a copy *every time* someone downloads), I think we would no longer be able to distribute such software; but I don't think it would render the GPL non-free, again because this is not a function of whether the license is granting us the necessary rights. Actually, let me amend that -- if someone released code under the GPL with the *intention* that people would have to the government, that would be non-free; but a change in the laws would not make pre-existing GPL code non-free. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: DRAFT: debian-legal summary of the QPL
Steve Langasek <[EMAIL PROTECTED]> wrote: > On Thu, Jul 22, 2004 at 04:14:44PM -0400, Walter Landry wrote: > > As another example, what if there were a jurisdiction where recipients > > automatically receive the right to modify and distribute unless > > otherwise explicitly specified. Then a simple "Copyright (C) 2000 > > Steve Langasek" would be free. > > The difference between this and the prior example is that in the > first case, the *government* has additional rights over the > software, whereas in the second case, it is the *author* who has > lesser rights over (control of) the software. Yes, in this > hypothetical jurisdiction, a mere copyright statement would be free; > but we are concerned about freedom at the international level, so we > need to take a "least common denominator" look at the rights of > copyright holders. So if the lowest common denominator (i.e. the law in all countries) became "If you distribute something under the GPL, you must give the government a copy" would the GPL be free? Regards, Walter Landry [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
On Fri, 23 Jul 2004, Steve McIntyre wrote: > Don Armstrong writes: > >None of it, apparently, which is one of the reasons why the DFSG is > >a set of guidelines, not a mere definition. > > That's a convenient argument for ignoring whichever bits of the DFSG > you don't like, it must be said. Not for ignoring, but for limiting the reach of them, or for recommending to ftpmaster to disallow licenses that are not free, but may not contravene the DFSG directly. [I don't think we've ever had a case of the latter, but I believe[1] it's in ftpmaster's power to do so.] > If you're going to selectively apply DFSG#5 as you see fit, then > consensus grounded in the DFSG is never going to happen. We may never have unanimity on a specific point of the DFSG without a definition capable of being applied by a machine, yet even without an exact definition we can obtain consensus. Some of us may think more restrictions by a license are free, and others may think the same level are ok, and still others may feel that the restrictions go to far. > It's grossly unfair to declare a license non-free because external > factors may stop people from exercising the rights granted by that > license. It's one thing with the external factors are acting alone. However, it's entirely another when the external factors are acting in concert with one of the tenants of a license. If the license is what is at the root of the problem, and the situation is common, then they license itself is at fault. > The DFSG clearly needs to be tightened up and clarified, then. Surely. But that's an extreemly complex job in it's own right, and one that I'm not ready to take on right now. Don Armstrong 1: If this ever came up, the secretary might get called on to clarify... -- Never underestimate the power of human stupidity. -- Robert Heinlein http://www.donarmstrong.com http://rzlab.ucr.edu
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 05:39:42PM +0100, Steve McIntyre wrote: > >In the end, we still come back to the fact that we're dealing with a > >set of guidelines that needs to be thoughtfully applied to a > >license. For many of these cases, there's no known bright line test, > >where X is free, and Y is non free. [See the OSD v DFSG threads for > >more examples...] > > The DFSG clearly needs to be tightened up and clarified, then. Or is > the point of debate on -legal simply to justify the existence of > -legal? If you're going to argue that the DFSG should be changed from a set of guidelines (which, by definition, require interpretation and human judgement to apply) into a definition, which can be implemented by robots, please say so. You seem to think it's a bug that the DFSG doesn't have bright-line tests for every possible non-free requirement; such tests don't exist. -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 08:03:46PM +1000, Matthew Palmer wrote: > I'd challenge "certainly". It's the most reasonable interpretation, > considering that we want to allow people to use the software itself, too, > but throwing "certainly" in there is a little strong. I think the distinction is moot, anyway. > > I think it's pretty much the same thing, anyway; most licenses apply > > restrictions on distribution--not caring whether it's aggregated or not. > > The QPL's restrictions on distribution still apply if aggregated with > > other works, so DFSG#1 applies even if we accept your argument. > > Well, reading the whole sentence as one entity, it could be interpreted that > DFSG #1 ONLY disallows aggregate prohibition, since there is no mention of > non-aggregate distribution at all. But almost all restrictions of non-aggregate distribution affect aggregate distribution identically. > Also, reading the second sentence as a > followup of the first, it only disallows upstream for charging a fee for > distribution of the software as part of the aggregate. The second sentence strongly feels to me like an additional requirement, just as the second and third sentences of DFSG#4 are unrelated to the patch requirement mentioned in the first. > Note that I don't agree with this interpretation, because it causes too much > trouble in too many cases, but I think it's an interpretation that can > easily be argued for. There are lots of interpretations for most clauses of the DFSG. DFSG#2: what is "source code" for a font? DFSG#3: "must allow all modifications" or "must at least allow some modifications?" DFSG#5, #6: including indirect discrimination or not? DFSG#10: grandfather clause or interpretation boundary? ... and many more that I'm not thinking of, I'm sure. I don't think trying to "clarify" each of these by rewording the clause would help, but I'd still be interested in hearing your suggestion (for DFSG#1; not intending to pollute the thread with arguments about the above examples, of course). -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
[ Apologied for the delay in responding; I've had hardware issues stopping me seeing this ] Don Armstrong writes: >On Wed, 21 Jul 2004, Steve McIntyre wrote: >> What part of >> >> 5. No Discrimination Against Persons or Groups >> >> The license must not discriminate against any person or group of >> persons. >> >> allows for _any_ discrimination? > >None of it, apparently, which is one of the reasons why the DFSG is a >set of guidelines, not a mere definition. That's a convenient argument for ignoring whichever bits of the DFSG you don't like, it must be said. If you're going to selectively apply DFSG#5 as you see fit, then consensus grounded in the DFSG is never going to happen. >> Are you reading the same DFSG as me??? "Must not discriminate" is >> not in any sense vague - it does not leave any leeway for "allowable >> discrimination". > >Well, then why should effective discrimination be allowed? Surely >effective discrimination fits under "must not discriminate." As I've said, I don't consider "effective discrimination" to be a useful concept at all. That leaves _all_ licenses potentially infringing DFSG#5, depending entirely on local laws trumping license clauses. As we're trying to come up with a base level that we consider to be free, that doesn't help us in the slightest. It's grossly unfair to declare a license non-free because external factors may stop people from exercising the rights granted by that license. >In the end, we still come back to the fact that we're dealing with a >set of guidelines that needs to be thoughtfully applied to a >license. For many of these cases, there's no known bright line test, >where X is free, and Y is non free. [See the OSD v DFSG threads for >more examples...] The DFSG clearly needs to be tightened up and clarified, then. Or is the point of debate on -legal simply to justify the existence of -legal? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Re: DRAFT: debian-legal summary of the QPL
On Sat, Jul 24, 2004 at 12:00:22AM +1000, Matthew Palmer wrote: > On Fri, Jul 23, 2004 at 02:22:06PM +0200, Sven Luther wrote: > > On Fri, Jul 23, 2004 at 10:08:14PM +1000, Matthew Palmer wrote: > > > On Fri, Jul 23, 2004 at 11:54:13AM +0200, Sven Luther wrote: > > > > On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: > > > > > Sven Luther wrote: > > > > Anyway, notice that QPL 6 doesn't speak about modification, but work > > > > which > > > > link to a QPLed library. Not exactly the same thing. > > > > > > Which is even worse, because the QPL is then compelling distribution of > > > essentially unrelated items. If dynamic linking doesn't produce a > > > derivative work, the QPL is overstretching it's bounds by quite a bit. > > > > And you ignored me arguing repeteadly that a derived work and a modified > > work > > are not the same thing, right ? Again this speaks highly of your capacity to > > follow up here and make informed arguments. > > Go the ad hominem. Yeah. Not to mention the fact that I never argued that > a modified work is not a derived work. Quote me saying that. Go on. Go > nuts. But you are arguing that a derived work is necesarily a modified work, even despite the repeated evidence that the QPL author think it is not. > > > > Well, sure, but what is your moral ground for refusing the same > > > > modifications > > > > to upstream ? > > > > > > What's your moral ground for asserting that upstream has a right to my > > > modifications? > > > > What is your moral ground that he has not ? Elemental courtesy and decency > > sure would fall into play here. > > They're not his modifications. What is your moral ground that he has? Elemental courtesy. You make use of what the upstream author freely gave to you, and he request you extend the same courtesy in return to him. What moral ground have you on refusing him ? And if you dispute the "freely" part, you can only do so once you have proven that the QPL is non-free. And even then, what moral ground do you have to give your stuff back to upstream under the same conditions that he has (Thus QPLing your changes). > > > > Well, i see disenting voices in that conversation, and the consensus you > > > > mention seems to be one of assertion, as it is quite lacking in > > > > analysis and > > > > real arguments, don't you think. > > > > > > Yes, I do see that quite a bit on one side of the discussion. > > > > Thanks, again you can only reject those accusation by counter attacking. > > Yes, I do see that quite a bit on one side of the discussion. So, stop it, and participate with an open mind to the clear new thread i have started about this. > > > > You don't give a free blank check here, you only give the right for the > > > > code > > > > to be integrated back in the original software, and in the case of dual > > > > licencing of said software, like in both the ocaml and Qt case, you > > > > give the > > > > right to have the _SAME_ software also relicenced under the other > > > > licence, > > > > thus allowing upstream to not have to handle a split patch. In no way > > > > does > > > > > > Upstream doesn't have to handle a split tree, they just don't integrate > > > anything they haven't got their permission grant or copyright assignment > > > for. > > > > Ok. But they can't reuse the modification then, and all the free software > > community looses then. > > Why can't they reuse the modification? They either have the copyright (by Because they are forced to do tree splitting and shoulder the burden of split tree maintenance, which they don't want to. > assignment) and can therefore do whatever they want, or they have the same > blanket permission they have with the QPL, but this time they haven't > coerced it. Either way they can incorporate the change into anything they > like, free, non-free, or otherwise. So, what is the problem ? 3b is just a way for upstream to make sure they can reuse the modifications made by third party in their dual licenced tree, without having to shoulder the burden of the additional legal hops to do it so. And if you have one time contributed to the FSF, you will see that this burden is quite high, including at least three international letters, and some stuff about your employer. > > > For someone who is very quick to accuse others of not reading the rest of > > > the thread, you're *incredibly* good at forgetting what people have > > > previously told you. > > > > Given the amount of bullshit i have been told, well, one little minor lapse > > can be acceptable, and at least i accept my error, while others just don't. > > One minor lapse. Does anyone else get the same benefit? Well, sure, but repeated nonsense doesn't get it. And i don't think i have switched into rude mode over the first ofense, but after the third or fifth one. If not, i apologize for it, and please let's start a clean discussion in the new thread, as much me as the rest of the debian-legal con
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 02:22:06PM +0200, Sven Luther wrote: > On Fri, Jul 23, 2004 at 10:08:14PM +1000, Matthew Palmer wrote: > > On Fri, Jul 23, 2004 at 11:54:13AM +0200, Sven Luther wrote: > > > On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: > > > > Sven Luther wrote: > > > Anyway, notice that QPL 6 doesn't speak about modification, but work which > > > link to a QPLed library. Not exactly the same thing. > > > > Which is even worse, because the QPL is then compelling distribution of > > essentially unrelated items. If dynamic linking doesn't produce a > > derivative work, the QPL is overstretching it's bounds by quite a bit. > > And you ignored me arguing repeteadly that a derived work and a modified work > are not the same thing, right ? Again this speaks highly of your capacity to > follow up here and make informed arguments. Go the ad hominem. Yeah. Not to mention the fact that I never argued that a modified work is not a derived work. Quote me saying that. Go on. Go nuts. > > > Well, sure, but what is your moral ground for refusing the same > > > modifications > > > to upstream ? > > > > What's your moral ground for asserting that upstream has a right to my > > modifications? > > What is your moral ground that he has not ? Elemental courtesy and decency > sure would fall into play here. They're not his modifications. What is your moral ground that he has? > > > Well, i see disenting voices in that conversation, and the consensus you > > > mention seems to be one of assertion, as it is quite lacking in analysis > > > and > > > real arguments, don't you think. > > > > Yes, I do see that quite a bit on one side of the discussion. > > Thanks, again you can only reject those accusation by counter attacking. Yes, I do see that quite a bit on one side of the discussion. > > > You don't give a free blank check here, you only give the right for the > > > code > > > to be integrated back in the original software, and in the case of dual > > > licencing of said software, like in both the ocaml and Qt case, you give > > > the > > > right to have the _SAME_ software also relicenced under the other licence, > > > thus allowing upstream to not have to handle a split patch. In no way does > > > > Upstream doesn't have to handle a split tree, they just don't integrate > > anything they haven't got their permission grant or copyright assignment > > for. > > Ok. But they can't reuse the modification then, and all the free software > community looses then. Why can't they reuse the modification? They either have the copyright (by assignment) and can therefore do whatever they want, or they have the same blanket permission they have with the QPL, but this time they haven't coerced it. Either way they can incorporate the change into anything they like, free, non-free, or otherwise. > > For someone who is very quick to accuse others of not reading the rest of > > the thread, you're *incredibly* good at forgetting what people have > > previously told you. > > Given the amount of bullshit i have been told, well, one little minor lapse > can be acceptable, and at least i accept my error, while others just don't. One minor lapse. Does anyone else get the same benefit? - Matt
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 10:08:14PM +1000, Matthew Palmer wrote: > On Fri, Jul 23, 2004 at 11:54:13AM +0200, Sven Luther wrote: > > On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: > > > Sven Luther wrote: > > > > Well, so what. This only proves that there are licences which allow > > > > proprietary product, and i would never voluntary release code under > > > > such a > > > > licence, and they are other who don't. > > > > > > Neither would I. However, my issue with the QPL is not that I would > > > want to take the software proprietary, but that I might want to > > > > But Brian's interest seem to be. > > > > > distribute Free Software between a few people, giving those people all > > > the freedoms expected for Free Software. > > > > And ? What is the problem with that ? You can do it, the only point is that > > you have, upon request to give the upstream author (probably anyone in the > > chain of upstream authors) a copy of it if they request it. This can only > > be a > > problem with the DFSG 1, if you consider such a thing a fee. But since the > > cost to you is nil, i wonder if we can consider it as a fee, and also i > > consider the fairness involved in refusing to give this to upstream that he > > requests, while you had no problem in taking his work for free. > > We're not taking his work for free, because he didn't offer it for free. > That's the problem. And ? What royalty or fee did you pay him ? > > > If I take a GPLed program, modify it, and distribute the modified > > > version among a few people, then as long as those people also have the > > > source (or an offer for the source), then no one is being deprived of > > > Freedom, and the software is not proprietary. > > > > So what, how does that change with the QPL ? > > Because someone else can come in and legally demand the changes I've made. Bullshit. but please look at the newly started thread and alaysis. > > > That said, I personally think that under almost all circumstances, it is > > > a good idea to provide your changes upstream. > > > > So, ... > > Good ideas in the general case are not necessarily good when compelled by > licence terms. So ... > > Anyway, notice that QPL 6 doesn't speak about modification, but work which > > link to a QPLed library. Not exactly the same thing. > > Which is even worse, because the QPL is then compelling distribution of > essentially unrelated items. If dynamic linking doesn't produce a > derivative work, the QPL is overstretching it's bounds by quite a bit. And you ignored me arguing repeteadly that a derived work and a modified work are not the same thing, right ? Again this speaks highly of your capacity to follow up here and make informed arguments. > > > >>>Also, i also doubt that this is a way debian is confortable goind, and > > > >>>that > > > >>>allowance of proprietary modifications over other considerations is > > > >>>the path > > > >>>we are conforable threading. > > > >> > > > >>You doubt that which is the way Debian is comfortable going? > > > > > > > > To make allowance to proprietary modification hoarder, like you seem to > > > > be. > > > > > > Again, modifications shared amonst a group, with everyone in that group > > > having Freedom, are not proprietary. > > > > Well, sure, but what is your moral ground for refusing the same > > modifications > > to upstream ? > > What's your moral ground for asserting that upstream has a right to my > modifications? What is your moral ground that he has not ? Elemental courtesy and decency sure would fall into play here. > > > offers lots of permission, and asks nothing. It's more generous than > > > "fair". The GPL is "fair": it offers many permissions, but some of > > > them can only be exercised if you pass the same permissions on to > > > others. That is, it's a copyleft. But it's probably the most > > > restrictive you can be and still be "fair". > > > >>> > > > >>>Whatever. you want to modify ocaml, and not give back your changes to > > > >>>the > > > >>>community. You have no sympathy from me, neither probably from a waste > > > >>>majority of the debian project. > > > >>> > > > >>>Also you lying, claiming consensus, while there is no such thing, > > > >>>doesn't > > > >>>endear you to me. > > > >> > > > >>I don't think personal insults really help anything. What I see is a > > > > > > > > Well, you claimed there was a consensus, while there is clearly no such > > > > thing. > > > > Thus it is a lie intended to get the maintainer to take the course of > > > > action > > > > you want through FUD, or at best a misinformed claim you should > > > > apologize for. > > > > > > The consensus on debian-legal seems to be strongly against the QPL. > > > > Well, i see disenting voices in that conversation, and the consensus you > > mention seems to be one of assertion, as it is quite lacking in analysis and > > real arguments, don't you think. > > Yes, I do see th
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 10:01:03PM +1000, Matthew Palmer wrote:
> On Fri, Jul 23, 2004 at 11:59:53AM +0200, Sven Luther wrote:
> > On Fri, Jul 23, 2004 at 07:41:55PM +1000, Matthew Palmer wrote:
> > > On Fri, Jul 23, 2004 at 11:18:28AM +0200, Sven Luther wrote:
> > > > Well, it is evident. The section 6 covers how you distribute these code
> > > > linking with the library. IF you distribute such code, you have to
> > > > cumply to
> > > > all of a, b and c, is it not ? You don't see in the main header of 6
> > > > that you
> > > > have to satisfy one or the other, or you could safely ignore 6c and the
> > > > whole
> > > > point would be moot.
> > >
> > > All three subclauses have to be satisfied or judged to not apply. 6a
> > > doesn't apply to source-only distribution ("all recipients of
> >
> > Ok.
> >
> > > machine-executable forms"). 6b applies to all distribution. 6c only
> > > applies if the items are private *and* the initial developer asks for a
> > > copy
> > > of the item.
> >
> > Notice that it doesn't apply to private stuff, but only to not openly
> > distributed ones, please don't muddle the water.
>
> !Public == Private.
Mmm, there doens't seem to be a consensus about this definition.
> > > In the instance of applying 6c, we recurse through the licence, go
> > > through 6
> > > again, and *again* we don't apply 6a because the initial developer asks
> > > for
> > > a copy of the source. Of course, the obvious loophole there is that the
> > > initial developer asks for a copy of the binary instead, in which instance
> > > 6a is invoked, and all's good. But is charging for a binary instead?
> > > Presumably it is, as otherwise the licence is non-commercial-only, and
> > > non-free, but there's no exception for the initial developer on that
> > > point,
> > > so I can charge the initial developer an unrealistic amount of money for
> > > my
> > > binary.
> >
> > Ok, are you so sure of this that you would care to go before a judge with
> > this
> > interpretation ?
>
> No, because my French lawyer would do that for me.
And, did you ask him about this interpretation ? Please don't keep it to you
and share his view on this with us.
> > > > > who have a binary and want the source. In this case, if you are
> > > > > distributing source (that is not available to the general public),
> > > > > then
> > > > > the source is one of the "items" in question, and it must be provided
> > > > > under 6.c, which does not indicate that you may charge for cost of
> > > > > distribution.
> > > >
> > > > Notice that 6c speaks about "copy of the items". How do you interpret
> > > > this.
> > >
> > > In the absence of clarification, I'd imagine it'd mean "a copy of the
> > > source", because the binary is of very limited use to the initial
> > > developer.
> > > No binary means 6a doesn't apply.
> >
> > And is the second phrase of the 6 header not clear enough, please reread it.
>
> "These items, when distributed, are subject to the following requirements:".
> That makes no mention of the form of the items, either during the initial
> distribution, nor of the copy demanded of me by the initial developer.
Well, what would those be then ? But see my analysis of this in the other
thread.
> > > > This has no meaning apart from the stuff described in the 6 header,
> > > > that is :
> > > >
> > > > You may develop application programs, reusable components and other
> > > > software items that link with the original or modified versions of the
> > > > Software. These items, when distributed, are subject to the following
> > > > requirements:
> > > >
> > > > These items clearly refer to "application programs, reusable components
> > > > and
> > > > other software items that link with the original or modified versions
> > > > of the
> > > > Software", and this clearly states that you have to cumply with all of
> > > > the
> > > > following, 6a to 6c.
> > >
> > > Comply or show as non-applicable. In the same way that 6c doesn't apply
> > > to
> > > every act of distribution, 6a doesn't apply in all situations of
> > > distribution either.
> >
> > Would you go before a judge with this interpretation ? What does you lawyer
> > say about this ?
>
> My imaginary lawyer says you're a tool. Yours laughs at you. I think
> there's a pattern here.
well, the difference is that you have not consulted a lawyer, only makes us
believe you have, and make up wild speculation claiming it is legal advice.
> > > > > (Are you using webmail through lynx?)
> > > >
> > > > I have no choice, since i was not originally CCed, i have to go to the
> > > > web
> > > > archive to read the discussion, get the url of emails i want to respon,
> > > > launch
> > > > lynx over ssh on the box which does mail processing, open the url, go to
> > > > respond to or whatever link and send the mail.
> > >
> > > Does copy-and-paste not exist on your system?
> >
> > Thanks all the same, but the web url
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 11:54:13AM +0200, Sven Luther wrote: > On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: > > Sven Luther wrote: > > > Well, so what. This only proves that there are licences which allow > > > proprietary product, and i would never voluntary release code under such a > > > licence, and they are other who don't. > > > > Neither would I. However, my issue with the QPL is not that I would > > want to take the software proprietary, but that I might want to > > But Brian's interest seem to be. > > > distribute Free Software between a few people, giving those people all > > the freedoms expected for Free Software. > > And ? What is the problem with that ? You can do it, the only point is that > you have, upon request to give the upstream author (probably anyone in the > chain of upstream authors) a copy of it if they request it. This can only be a > problem with the DFSG 1, if you consider such a thing a fee. But since the > cost to you is nil, i wonder if we can consider it as a fee, and also i > consider the fairness involved in refusing to give this to upstream that he > requests, while you had no problem in taking his work for free. We're not taking his work for free, because he didn't offer it for free. That's the problem. > > If I take a GPLed program, modify it, and distribute the modified > > version among a few people, then as long as those people also have the > > source (or an offer for the source), then no one is being deprived of > > Freedom, and the software is not proprietary. > > So what, how does that change with the QPL ? Because someone else can come in and legally demand the changes I've made. > > That said, I personally think that under almost all circumstances, it is > > a good idea to provide your changes upstream. > > So, ... Good ideas in the general case are not necessarily good when compelled by licence terms. > Anyway, notice that QPL 6 doesn't speak about modification, but work which > link to a QPLed library. Not exactly the same thing. Which is even worse, because the QPL is then compelling distribution of essentially unrelated items. If dynamic linking doesn't produce a derivative work, the QPL is overstretching it's bounds by quite a bit. > > >>>Also, i also doubt that this is a way debian is confortable goind, and > > >>>that > > >>>allowance of proprietary modifications over other considerations is the > > >>>path > > >>>we are conforable threading. > > >> > > >>You doubt that which is the way Debian is comfortable going? > > > > > > To make allowance to proprietary modification hoarder, like you seem to > > > be. > > > > Again, modifications shared amonst a group, with everyone in that group > > having Freedom, are not proprietary. > > Well, sure, but what is your moral ground for refusing the same modifications > to upstream ? What's your moral ground for asserting that upstream has a right to my modifications? > > offers lots of permission, and asks nothing. It's more generous than > > "fair". The GPL is "fair": it offers many permissions, but some of > > them can only be exercised if you pass the same permissions on to > > others. That is, it's a copyleft. But it's probably the most > > restrictive you can be and still be "fair". > > >>> > > >>>Whatever. you want to modify ocaml, and not give back your changes to the > > >>>community. You have no sympathy from me, neither probably from a waste > > >>>majority of the debian project. > > >>> > > >>>Also you lying, claiming consensus, while there is no such thing, doesn't > > >>>endear you to me. > > >> > > >>I don't think personal insults really help anything. What I see is a > > > > > > Well, you claimed there was a consensus, while there is clearly no such > > > thing. > > > Thus it is a lie intended to get the maintainer to take the course of > > > action > > > you want through FUD, or at best a misinformed claim you should apologize > > > for. > > > > The consensus on debian-legal seems to be strongly against the QPL. > > Well, i see disenting voices in that conversation, and the consensus you > mention seems to be one of assertion, as it is quite lacking in analysis and > real arguments, don't you think. Yes, I do see that quite a bit on one side of the discussion. > > have. Feel free to rebut the arguments of others, but please do not > > call people ignorant or accuse them of not reading the license. > > I have, and you didn't respond to them when i first voiced them, and have to > this date not yet done so. > > > >>The question of whether the QPL is free appears to have firm consensus > > >>from everyone involved in the debate, instead of standing on the > > >>sidelines and screaming. > > > > > > A, a consensus is one where there is no discordant voice, right ? > > > > Consensus is stronger than a simple majority, but it does not > > necessarily unanimous consensus. > > Consensus: a general agreement about a matter o
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 11:59:53AM +0200, Sven Luther wrote:
> On Fri, Jul 23, 2004 at 07:41:55PM +1000, Matthew Palmer wrote:
> > On Fri, Jul 23, 2004 at 11:18:28AM +0200, Sven Luther wrote:
> > > Well, it is evident. The section 6 covers how you distribute these code
> > > linking with the library. IF you distribute such code, you have to cumply
> > > to
> > > all of a, b and c, is it not ? You don't see in the main header of 6 that
> > > you
> > > have to satisfy one or the other, or you could safely ignore 6c and the
> > > whole
> > > point would be moot.
> >
> > All three subclauses have to be satisfied or judged to not apply. 6a
> > doesn't apply to source-only distribution ("all recipients of
>
> Ok.
>
> > machine-executable forms"). 6b applies to all distribution. 6c only
> > applies if the items are private *and* the initial developer asks for a copy
> > of the item.
>
> Notice that it doesn't apply to private stuff, but only to not openly
> distributed ones, please don't muddle the water.
!Public == Private.
> > In the instance of applying 6c, we recurse through the licence, go through 6
> > again, and *again* we don't apply 6a because the initial developer asks for
> > a copy of the source. Of course, the obvious loophole there is that the
> > initial developer asks for a copy of the binary instead, in which instance
> > 6a is invoked, and all's good. But is charging for a binary instead?
> > Presumably it is, as otherwise the licence is non-commercial-only, and
> > non-free, but there's no exception for the initial developer on that point,
> > so I can charge the initial developer an unrealistic amount of money for my
> > binary.
>
> Ok, are you so sure of this that you would care to go before a judge with this
> interpretation ?
No, because my French lawyer would do that for me.
> > > > who have a binary and want the source. In this case, if you are
> > > > distributing source (that is not available to the general public), then
> > > > the source is one of the "items" in question, and it must be provided
> > > > under 6.c, which does not indicate that you may charge for cost of
> > > > distribution.
> > >
> > > Notice that 6c speaks about "copy of the items". How do you interpret
> > > this.
> >
> > In the absence of clarification, I'd imagine it'd mean "a copy of the
> > source", because the binary is of very limited use to the initial
> > developer.
> > No binary means 6a doesn't apply.
>
> And is the second phrase of the 6 header not clear enough, please reread it.
"These items, when distributed, are subject to the following requirements:".
That makes no mention of the form of the items, either during the initial
distribution, nor of the copy demanded of me by the initial developer.
> > > This has no meaning apart from the stuff described in the 6 header, that
> > > is :
> > >
> > > You may develop application programs, reusable components and other
> > > software items that link with the original or modified versions of the
> > > Software. These items, when distributed, are subject to the following
> > > requirements:
> > >
> > > These items clearly refer to "application programs, reusable components
> > > and
> > > other software items that link with the original or modified versions of
> > > the
> > > Software", and this clearly states that you have to cumply with all of the
> > > following, 6a to 6c.
> >
> > Comply or show as non-applicable. In the same way that 6c doesn't apply to
> > every act of distribution, 6a doesn't apply in all situations of
> > distribution either.
>
> Would you go before a judge with this interpretation ? What does you lawyer
> say about this ?
My imaginary lawyer says you're a tool. Yours laughs at you. I think
there's a pattern here.
> > > > (Are you using webmail through lynx?)
> > >
> > > I have no choice, since i was not originally CCed, i have to go to the web
> > > archive to read the discussion, get the url of emails i want to respon,
> > > launch
> > > lynx over ssh on the box which does mail processing, open the url, go to
> > > respond to or whatever link and send the mail.
> >
> > Does copy-and-paste not exist on your system?
>
> Thanks all the same, but the web url for replying don't seem to be accepted by
> mutt, so please inform yourself before making sarcastic claims such as those.
- Matt
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 05:08:05AM -0400, Glenn Maynard wrote: > On Fri, Jul 23, 2004 at 05:54:29PM +1000, Matthew Palmer wrote: > > > "The license of a Debian component may not restrict any party from selling > > > or giving away the software ..." > > > > > > I believe "may not restrict" is the operative phrase; this is a > > > restriction. > > > > I think we need to include the rest of that sentence is important, though: > > "as a component of an aggregate software distribution...". I would > > fully support an amendment which made it explicit that DFSG #1 applied to > > individual distribution also, but as written I think it is mostly a > > protection for commercial Debian distributors, and a restatement of DFSG #9. > > The "component of an aggregate ..." phrase is usually read as a specific > restriction which is allowed: restrictions like "this may only be distributed > along with other programs"[1] are free. DFSG#1 certainly applies to non- > aggregate distribution, as well. I'd challenge "certainly". It's the most reasonable interpretation, considering that we want to allow people to use the software itself, too, but throwing "certainly" in there is a little strong. > I think it's pretty much the same thing, anyway; most licenses apply > restrictions on distribution--not caring whether it's aggregated or not. > The QPL's restrictions on distribution still apply if aggregated with > other works, so DFSG#1 applies even if we accept your argument. Well, reading the whole sentence as one entity, it could be interpreted that DFSG #1 ONLY disallows aggregate prohibition, since there is no mention of non-aggregate distribution at all. Also, reading the second sentence as a followup of the first, it only disallows upstream for charging a fee for distribution of the software as part of the aggregate. Note that I don't agree with this interpretation, because it causes too much trouble in too many cases, but I think it's an interpretation that can easily be argued for. It's one of the reasons that I'm in favour of a few "enhancements" to the DFSG -- think of them as "editorial changes to the DFSG" . They shouldn't change the meaning of the DFSG for the common interpretation, but it'll reduce the ambiguity so no doubt some people will think it's a major change. > [1] Bundling with "hello world" to form a trivial aggregate is generally > expected to satisfy this; anything stronger, such as "must be bundled with > at least 10 megs of other stuff" would probably be non-free. Working around "not by itself" problems by trivial bundling is right up there with "this licence clause isn't a problem because the law doesn't allow the licensor to do that" in terms of arguments that shouldn't be made. It's acting in bad faith, in my opinion. We shouldn't be looking for workarounds, we should be evaluating licensor intent (as expressed by the chosen licence and any clarifications received) and judging that against the DFSG, without playing the "how can we work around this to get it in" game. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 07:41:55PM +1000, Matthew Palmer wrote:
> On Fri, Jul 23, 2004 at 11:18:28AM +0200, Sven Luther wrote:
> > Where in it says you have to ?
>
> Where in it says that you don't? For my part, I can't see how either
> interpretation is more plausible than the other.
>
> In this sort of situation we *can't* take the easy interpretation; if the
> least friendly plausible interpretation is non-free, we have to go down that
> path. Optimism is dangerous.
>
> > Please let's not forget common sense.
>
> Common sense is being used. We're approaching this from a pessimistic,
> protection perspective. You're approaching this from a "it has to stay
> free" perspective.
You are all using a paranoid, would be lawyer who really don't understand law
and thus fear everything kindof approach.
> > > >>want, and you have to comply; there is nothing in the license that says
> > > >>otherwise. For that matter, do you see anything in the QPL that says
> > > >>the original developer has to compensate you for the costs of providing
> > > >>your changes (bandwidth charges for network distribution, or media costs
> > > >>for physical distribution)?
> > > >
> > > > Yes, since the distribution will happen accordying to 6a, which says
> > > > you can
> > > > charge for the cost of data transfer.
> > >
> > > >From the QPL:
> > > > c. If the items are not available to the general public, and the
> > > > initial developer of the Software requests a copy of the items,
> > > > then you must supply one.
> > >
> > > Where in there does it say that the copy you supply to the initial
> > > developer is covered by the terms of 6.a? 6.a only covers recipients
> >
> > Well, it is evident. The section 6 covers how you distribute these code
> > linking with the library. IF you distribute such code, you have to cumply to
> > all of a, b and c, is it not ? You don't see in the main header of 6 that
> > you
> > have to satisfy one or the other, or you could safely ignore 6c and the
> > whole
> > point would be moot.
>
> All three subclauses have to be satisfied or judged to not apply. 6a
> doesn't apply to source-only distribution ("all recipients of
Ok.
> machine-executable forms"). 6b applies to all distribution. 6c only
> applies if the items are private *and* the initial developer asks for a copy
> of the item.
Notice that it doesn't apply to private stuff, but only to not openly
distributed ones, please don't muddle the water.
> In the instance of applying 6c, we recurse through the licence, go through 6
> again, and *again* we don't apply 6a because the initial developer asks for
> a copy of the source. Of course, the obvious loophole there is that the
> initial developer asks for a copy of the binary instead, in which instance
> 6a is invoked, and all's good. But is charging for a binary instead?
> Presumably it is, as otherwise the licence is non-commercial-only, and
> non-free, but there's no exception for the initial developer on that point,
> so I can charge the initial developer an unrealistic amount of money for my
> binary.
Ok, are you so sure of this that you would care to go before a judge with this
interpretation ?
> > > who have a binary and want the source. In this case, if you are
> > > distributing source (that is not available to the general public), then
> > > the source is one of the "items" in question, and it must be provided
> > > under 6.c, which does not indicate that you may charge for cost of
> > > distribution.
> >
> > Notice that 6c speaks about "copy of the items". How do you interpret this.
>
> In the absence of clarification, I'd imagine it'd mean "a copy of the
> source", because the binary is of very limited use to the initial developer.
> No binary means 6a doesn't apply.
And is the second phrase of the 6 header not clear enough, please reread it.
> > This has no meaning apart from the stuff described in the 6 header, that is
> > :
> >
> > You may develop application programs, reusable components and other
> > software items that link with the original or modified versions of the
> > Software. These items, when distributed, are subject to the following
> > requirements:
> >
> > These items clearly refer to "application programs, reusable components and
> > other software items that link with the original or modified versions of the
> > Software", and this clearly states that you have to cumply with all of the
> > following, 6a to 6c.
>
> Comply or show as non-applicable. In the same way that 6c doesn't apply to
> every act of distribution, 6a doesn't apply in all situations of
> distribution either.
Would you go before a judge with this interpretation ? What does you lawyer
say about this ?
> > > >>[Do you want both of your email addresses CCed on these mails?]
> > > >
> > > > Not really, but i prefer more of them than none at all, as hiting D is
> > > > easier
> > > > than reading mail in lynx.
> > >
> > > No pro
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: > Sven Luther wrote: > > Well, so what. This only proves that there are licences which allow > > proprietary product, and i would never voluntary release code under such a > > licence, and they are other who don't. > > Neither would I. However, my issue with the QPL is not that I would > want to take the software proprietary, but that I might want to But Brian's interest seem to be. > distribute Free Software between a few people, giving those people all > the freedoms expected for Free Software. And ? What is the problem with that ? You can do it, the only point is that you have, upon request to give the upstream author (probably anyone in the chain of upstream authors) a copy of it if they request it. This can only be a problem with the DFSG 1, if you consider such a thing a fee. But since the cost to you is nil, i wonder if we can consider it as a fee, and also i consider the fairness involved in refusing to give this to upstream that he requests, while you had no problem in taking his work for free. > If I take a GPLed program, modify it, and distribute the modified > version among a few people, then as long as those people also have the > source (or an offer for the source), then no one is being deprived of > Freedom, and the software is not proprietary. So what, how does that change with the QPL ? > Giving someone a binary without the source prevents them from exercising > their rights over that software. Giving someone no program at all does > not restrict their rights, any more than giving someone no money: I am > not obligated to distribute to them. So, how is this relevant to the problem at hand ? > That said, I personally think that under almost all circumstances, it is > a good idea to provide your changes upstream. So, ... Anyway, notice that QPL 6 doesn't speak about modification, but work which link to a QPLed library. Not exactly the same thing. > >>>Also, i also doubt that this is a way debian is confortable goind, and that > >>>allowance of proprietary modifications over other considerations is the > >>>path > >>>we are conforable threading. > >> > >>You doubt that which is the way Debian is comfortable going? > > > > To make allowance to proprietary modification hoarder, like you seem to be. > > Again, modifications shared amonst a group, with everyone in that group > having Freedom, are not proprietary. Well, sure, but what is your moral ground for refusing the same modifications to upstream ? > offers lots of permission, and asks nothing. It's more generous than > "fair". The GPL is "fair": it offers many permissions, but some of > them can only be exercised if you pass the same permissions on to > others. That is, it's a copyleft. But it's probably the most > restrictive you can be and still be "fair". > >>> > >>>Whatever. you want to modify ocaml, and not give back your changes to the > >>>community. You have no sympathy from me, neither probably from a waste > >>>majority of the debian project. > >>> > >>>Also you lying, claiming consensus, while there is no such thing, doesn't > >>>endear you to me. > >> > >>I don't think personal insults really help anything. What I see is a > > > > Well, you claimed there was a consensus, while there is clearly no such > > thing. > > Thus it is a lie intended to get the maintainer to take the course of action > > you want through FUD, or at best a misinformed claim you should apologize > > for. > > The consensus on debian-legal seems to be strongly against the QPL. > Well, i see disenting voices in that conversation, and the consensus you mention seems to be one of assertion, as it is quite lacking in analysis and real arguments, don't you think. Some of the participants don't even seem to have read the QPL, which makes the whole thing somewhat suspisious. > >>On the other side of that issue, I see you and a couple others calling > >>the people here lazy, deceitful, and lying. You suggest that users > >>should violate licenses because they won't get caught. > > > > I didn't do that, but you obviously neither read nor understood what i said > > nor the QPL itself, so ... > > To the best of my knowledge, everyone participating in this discussion > has read the QPL. I most certainly have, and I know several others I don't think so, given the obvious cluelessness that comes with many of the arguments made here. And if you did, you clearly didn't understand it, or chose to gloss over parts that where not suporting your point. This kind of attitude clearly casts some suspision of the quality of advice that comes with debian-legal consensus. > have. Feel free to rebut the arguments of others, but please do not > call people ignorant or accuse them of not reading the license. I have, and you didn't respond to them when i first voiced them, and have to this date not yet done so. > >>The question of whether the QPL is free appears t
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 06:05:13PM +1000, Matthew Palmer wrote: > On Thu, Jul 22, 2004 at 08:19:50PM -0400, Glenn Maynard wrote: > > On Thu, Jul 22, 2004 at 05:13:50PM +0100, Matthew Garrett wrote: > > > Of course, this mostly just turns the argument into one about > > > weightings. Since these are mostly determined by personal opinion, it > > > suggests that there isn't a correct place to draw the line. The only > > > real suggestion I have is wider discussion in an attempt to gain a > > > better understanding of how different people view the issue. > > > > That's exactly the purpose of many of the discussions on d-legal. I'm not > > sure what you think should change. Do you think the QPL discussion would be > > more productive if crossposted to d-devel? (I think it would just annoy the > > people who have chosen not to participate.) > > Can anything be productive if cross-posted to d-devel? Very likely not; I just don't know what it is he expects, since he seems to think that this mailing list for discussing these issues is insufficient. -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 05:54:29PM +1000, Matthew Palmer wrote: > > "The license of a Debian component may not restrict any party from selling > > or giving away the software ..." > > > > I believe "may not restrict" is the operative phrase; this is a restriction. > > I think we need to include the rest of that sentence is important, though: > "as a component of an aggregate software distribution...". I would > fully support an amendment which made it explicit that DFSG #1 applied to > individual distribution also, but as written I think it is mostly a > protection for commercial Debian distributors, and a restatement of DFSG #9. The "component of an aggregate ..." phrase is usually read as a specific restriction which is allowed: restrictions like "this may only be distributed along with other programs"[1] are free. DFSG#1 certainly applies to non- aggregate distribution, as well. I think it's pretty much the same thing, anyway; most licenses apply restrictions on distribution--not caring whether it's aggregated or not. The QPL's restrictions on distribution still apply if aggregated with other works, so DFSG#1 applies even if we accept your argument. [1] Bundling with "hello world" to form a trivial aggregate is generally expected to satisfy this; anything stronger, such as "must be bundled with at least 10 megs of other stuff" would probably be non-free. -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 11:18:28AM +0200, Sven Luther wrote:
> On Thu, Jul 22, 2004 at 04:45:07PM -0700, Josh Triplett wrote:
> > Sven Luther wrote:
> > > On Wed, Jul 21, 2004 at 09:05:40AM -0700, Josh Triplett wrote:
> > >>Sven Luther wrote:
> > >>>On Mon, Jul 19, 2004 at 12:01:57PM -0400, Brian Thomas Sniffen wrote:
> > [EMAIL PROTECTED] writes:
> > >Well, simply configuring your SVN/CVS/ARCH/Whatever archive to spam
> > >upstream
> > >with every change done should resolve all the issue. Or maybe giving
> > >him
> > >consultation access would be enough.
> >
> > Spamming upstream is not enough. You have to provide one on request,
> > even if you just sent one. Additionally, now you're suggesting doing
> > away with the ability to make private modifications.
> > >>>
> > >>>Bullshit, you have provided it before it was asked, so where is the
> > >>>problem ?
> > >>
> > >>Do you see anything in the QPL that says the original developer can only
> > >>request your changes once? They can ask twelve times a day if they
> > >
> > > Well, whatever is the problem ? You provide it to them, and if they ask
> > > you
> > > again, you either say, sorry, i sent it to you already, and haven't got a
> > > backup copy, would you like the latest version perhaps ? If you already
> > > fullfilled the request before you are asked, where is the problem.
> >
> > >From the QPL:
> > > c. If the items are not available to the general public, and the
> > > initial developer of the Software requests a copy of the items,
> > > then you must supply one.
> >
> > Where in there does it say that you may refuse to supply a copy if you
> > have already provided one?
>
> Where in it says you have to ?
Where in it says that you don't? For my part, I can't see how either
interpretation is more plausible than the other.
In this sort of situation we *can't* take the easy interpretation; if the
least friendly plausible interpretation is non-free, we have to go down that
path. Optimism is dangerous.
> Please let's not forget common sense.
Common sense is being used. We're approaching this from a pessimistic,
protection perspective. You're approaching this from a "it has to stay
free" perspective.
> > >>want, and you have to comply; there is nothing in the license that says
> > >>otherwise. For that matter, do you see anything in the QPL that says
> > >>the original developer has to compensate you for the costs of providing
> > >>your changes (bandwidth charges for network distribution, or media costs
> > >>for physical distribution)?
> > >
> > > Yes, since the distribution will happen accordying to 6a, which says you
> > > can
> > > charge for the cost of data transfer.
> >
> > >From the QPL:
> > > c. If the items are not available to the general public, and the
> > > initial developer of the Software requests a copy of the items,
> > > then you must supply one.
> >
> > Where in there does it say that the copy you supply to the initial
> > developer is covered by the terms of 6.a? 6.a only covers recipients
>
> Well, it is evident. The section 6 covers how you distribute these code
> linking with the library. IF you distribute such code, you have to cumply to
> all of a, b and c, is it not ? You don't see in the main header of 6 that you
> have to satisfy one or the other, or you could safely ignore 6c and the whole
> point would be moot.
All three subclauses have to be satisfied or judged to not apply. 6a
doesn't apply to source-only distribution ("all recipients of
machine-executable forms"). 6b applies to all distribution. 6c only
applies if the items are private *and* the initial developer asks for a copy
of the item.
In the instance of applying 6c, we recurse through the licence, go through 6
again, and *again* we don't apply 6a because the initial developer asks for
a copy of the source. Of course, the obvious loophole there is that the
initial developer asks for a copy of the binary instead, in which instance
6a is invoked, and all's good. But is charging for a binary instead?
Presumably it is, as otherwise the licence is non-commercial-only, and
non-free, but there's no exception for the initial developer on that point,
so I can charge the initial developer an unrealistic amount of money for my
binary.
> > who have a binary and want the source. In this case, if you are
> > distributing source (that is not available to the general public), then
> > the source is one of the "items" in question, and it must be provided
> > under 6.c, which does not indicate that you may charge for cost of
> > distribution.
>
> Notice that 6c speaks about "copy of the items". How do you interpret this.
In the absence of clarification, I'd imagine it'd mean "a copy of the
source", because the binary is of very limited use to the initial developer.
No binary means 6a doesn't apply.
> This has no meaning apart from the stuff described in the
Re: DRAFT: debian-legal summary of the QPL
On Fri, Jul 23, 2004 at 10:07:55AM +0100, MJ Ray wrote: > On 2004-07-23 08:47:42 +0100 Matthew Palmer <[EMAIL PROTECTED]> wrote: > > >To be fair, there are two people arguing against the QPL being > >non-free. > > I think there are more than that, but not all are helping to move > things forward. ;-) In any case, it doesn't matter at this point what > the numbers are. If their argument explains why a QPL-covered work > follows DFSG and that isn't affected by the discussed problems, I hope > most of us are humble enough to correct ourselves. If I saw an argument which cleared up all of the concerns I had, I'd be more than happy to acquiesce. I've already had my mind changed several times by persuasive discussion in this thread, but there are still several problems to worry about. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 04:45:07PM -0700, Josh Triplett wrote: > Sven Luther wrote: > > On Wed, Jul 21, 2004 at 09:05:40AM -0700, Josh Triplett wrote: > > > >>Sven Luther wrote: > >> > >>>On Mon, Jul 19, 2004 at 12:01:57PM -0400, Brian Thomas Sniffen wrote: > >>> > [EMAIL PROTECTED] writes: > > >Well, simply configuring your SVN/CVS/ARCH/Whatever archive to spam > >upstream > >with every change done should resolve all the issue. Or maybe giving him > >consultation access would be enough. > > Spamming upstream is not enough. You have to provide one on request, > even if you just sent one. Additionally, now you're suggesting doing > away with the ability to make private modifications. > >>> > >>>Bullshit, you have provided it before it was asked, so where is the > >>>problem ? > >> > >>Do you see anything in the QPL that says the original developer can only > >>request your changes once? They can ask twelve times a day if they > > > > Well, whatever is the problem ? You provide it to them, and if they ask you > > again, you either say, sorry, i sent it to you already, and haven't got a > > backup copy, would you like the latest version perhaps ? If you already > > fullfilled the request before you are asked, where is the problem. > > >From the QPL: > > c. If the items are not available to the general public, and the > > initial developer of the Software requests a copy of the items, > > then you must supply one. > > Where in there does it say that you may refuse to supply a copy if you > have already provided one? Where in it says you have to ? Please let's not forget common sense. > >>want, and you have to comply; there is nothing in the license that says > >>otherwise. For that matter, do you see anything in the QPL that says > >>the original developer has to compensate you for the costs of providing > >>your changes (bandwidth charges for network distribution, or media costs > >>for physical distribution)? > > > > Yes, since the distribution will happen accordying to 6a, which says you can > > charge for the cost of data transfer. > > >From the QPL: > > c. If the items are not available to the general public, and the > > initial developer of the Software requests a copy of the items, > > then you must supply one. > > Where in there does it say that the copy you supply to the initial > developer is covered by the terms of 6.a? 6.a only covers recipients Well, it is evident. The section 6 covers how you distribute these code linking with the library. IF you distribute such code, you have to cumply to all of a, b and c, is it not ? You don't see in the main header of 6 that you have to satisfy one or the other, or you could safely ignore 6c and the whole point would be moot. > who have a binary and want the source. In this case, if you are > distributing source (that is not available to the general public), then > the source is one of the "items" in question, and it must be provided > under 6.c, which does not indicate that you may charge for cost of > distribution. Notice that 6c speaks about "copy of the items". How do you interpret this. This has no meaning apart from the stuff described in the 6 header, that is : You may develop application programs, reusable components and other software items that link with the original or modified versions of the Software. These items, when distributed, are subject to the following requirements: These items clearly refer to "application programs, reusable components and other software items that link with the original or modified versions of the Software", and this clearly states that you have to cumply with all of the following, 6a to 6c. > >>[Do you want both of your email addresses CCed on these mails?] > > > > Not really, but i prefer more of them than none at all, as hiting D is > > easier > > than reading mail in lynx. > > No problem; I'll continue to CC [EMAIL PROTECTED] on all of my mails > related to the QPL discussions. > > (Are you using webmail through lynx?) I have no choice, since i was not originally CCed, i have to go to the web archive to read the discussion, get the url of emails i want to respon, launch lynx over ssh on the box which does mail processing, open the url, go to respond to or whatever link and send the mail. Now i have supposedly the followup set correctly in mutt, but this probably makes me miss the followups not directly following one of my mails. Oh hell, i will subscribe after all :(. Friendly, Sven Luther
Re: DRAFT: debian-legal summary of the QPL
On 2004-07-23 08:47:42 +0100 Matthew Palmer <[EMAIL PROTECTED]> wrote: To be fair, there are two people arguing against the QPL being non-free. I think there are more than that, but not all are helping to move things forward. ;-) In any case, it doesn't matter at this point what the numbers are. If their argument explains why a QPL-covered work follows DFSG and that isn't affected by the discussed problems, I hope most of us are humble enough to correct ourselves. -- 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: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 08:19:50PM -0400, Glenn Maynard wrote: > On Thu, Jul 22, 2004 at 05:13:50PM +0100, Matthew Garrett wrote: > > Of course, this mostly just turns the argument into one about > > weightings. Since these are mostly determined by personal opinion, it > > suggests that there isn't a correct place to draw the line. The only > > real suggestion I have is wider discussion in an attempt to gain a > > better understanding of how different people view the issue. > > That's exactly the purpose of many of the discussions on d-legal. I'm not > sure what you think should change. Do you think the QPL discussion would be > more productive if crossposted to d-devel? (I think it would just annoy the > people who have chosen not to participate.) Can anything be productive if cross-posted to d-devel? - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 04:45:07PM -0700, Josh Triplett wrote: > Sven Luther wrote: > > On Wed, Jul 21, 2004 at 09:05:40AM -0700, Josh Triplett wrote: > >>Sven Luther wrote: > >>>On Mon, Jul 19, 2004 at 12:01:57PM -0400, Brian Thomas Sniffen wrote: > [EMAIL PROTECTED] writes: > >Well, simply configuring your SVN/CVS/ARCH/Whatever archive to spam > >upstream > >with every change done should resolve all the issue. Or maybe giving him > >consultation access would be enough. > > Spamming upstream is not enough. You have to provide one on request, > even if you just sent one. Additionally, now you're suggesting doing > away with the ability to make private modifications. > >>> > >>>Bullshit, you have provided it before it was asked, so where is the > >>>problem ? > >> > >>Do you see anything in the QPL that says the original developer can only > >>request your changes once? They can ask twelve times a day if they > > > > Well, whatever is the problem ? You provide it to them, and if they ask you > > again, you either say, sorry, i sent it to you already, and haven't got a > > backup copy, would you like the latest version perhaps ? If you already > > fullfilled the request before you are asked, where is the problem. > > >From the QPL: > > c. If the items are not available to the general public, and the > > initial developer of the Software requests a copy of the items, > > then you must supply one. > > Where in there does it say that you may refuse to supply a copy if you > have already provided one? The licence specifically says "you must supply one", referring to a copy of the software. Technically, if you have previously provided a copy of the software, you have fulfilled the obligation to "supply one [copy of the software]". That being said, there is the alternate interpretation that for every request received, you must supply one, and that is a perfectly valid interpretation of the licence. If the user took the former interpretation, and the licensor took the latter, it's off to the courthouse to get it all argued about. Again, it's a matter to be clarified with the licensor. I certainly wouldn't want to be bound by the terms of the licence with that ambiguity hanging over it. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 07:59:30PM -0400, Glenn Maynard wrote: > On Thu, Jul 22, 2004 at 04:34:33PM -0700, Josh Triplett wrote: > > Would you might clarifying what that grounding is (or pointing me at a > > particular message that does so)? I'm currently drafting the second > > draft of the QPL summary, and that's one of the few things I'm still > > working on: a well-grounded justification from the actual text of the > > DFSG. The "fee" angle seems nebulous, and hard to justify; I > > more-or-less agree with it, but I need a clear way to justify why it is > > only a "royalty or other fee" if it is "paid" to the upstream developer, > > and not if it is "paid" to someone you are already distributing the > > software to. > > "The license of a Debian component may not restrict any party from selling > or giving away the software ..." > > I believe "may not restrict" is the operative phrase; this is a restriction. I think we need to include the rest of that sentence is important, though: "as a component of an aggregate software distribution...". I would fully support an amendment which made it explicit that DFSG #1 applied to individual distribution also, but as written I think it is mostly a protection for commercial Debian distributors, and a restatement of DFSG #9. A rewrite to be something like "... selling or giving away the software, either individually or as a component of an aggregate software distribution ..." would do the job, I think. Again, judgement is called for in the interpretation, but no more than currently. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 07:23:42PM -0400, Glenn Maynard wrote: > On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: > > The consensus on debian-legal seems to be strongly against the QPL. > > I suspect Sven thinks--or hopes we'll believe--that one person disagreeing > with consensus two hundred times is roughly equivalent to the reverse. To be fair, there are two people arguing against the QPL being non-free. It doesn't change the core of your premise, of course, just the numbers. And note that, at least in Sven's case, most of the disagreement consists of abuse and assertion, not invalidating the arguments. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 05:04:30PM -0700, Josh Triplett wrote: > I also recall licenses that prohibited use in various types of weapons. > For that matter, there is also the "Hacktivismo Enhanced-Source > Software License Agreement" (HESSLA), as described by the GNU project on > http://www.gnu.org/licenses/hessla.html (although the original project > seems to be defunct at the moment). It prohibits use in spyware and by > governments that violate human rights. As ridiculous as it sounds, that > is actually a form of discrimination and use restriction, which makes > the license not DFSG-free. Why is that ridiculous? It *is* a usage restriction. We're doing Free Software here, not Free-For-People-Who-I-Like-What-They-Do Software. In the two cases mentioned, the definitions can be fairly broad, too -- there are plenty of different ideas about what spyware actually is (kind of like computer viruses in that respect), and there aren't too many governments who don't violate some human rights now and then (or at the very least are complicit in same). I don't like those things any more than you or the authors of the HESSLA appear to, but restricting freedom for some tends to end up as restrictions for all if not addressed. - Matt
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 05:13:50PM +0100, Matthew Garrett wrote:
> >> The GPL discriminates against a slightly smaller set of
> >> dissidents. The GPL discriminates against people on desert islands
> >> who have a binary CD but not a source one.
> >
> >If worst comes to worst, we can use DFSG 10 to avoid this issue, and
> >use it to define the line where the dissident tests can no longer be
> >applied.
I don't think that's an issue; that's not against the spirit of the desert
island test. After all, that would be just as much of a problem if we
called it the "hungry programmer test"--it "discriminates" against hungry
programmers who don't have source, as well as anyone else who has binaries
and no source. The island doesn't enter into it.
The desert island test is meant as a sanity check for the set of restrictions
like "in order to {modify, distribute} this work, you must make contact with
this and that third party". I think it's much better thought of as a test
for DFSG#1 and #3 than #6 and #7.
> Of course, this mostly just turns the argument into one about
> weightings. Since these are mostly determined by personal opinion, it
> suggests that there isn't a correct place to draw the line. The only
> real suggestion I have is wider discussion in an attempt to gain a
> better understanding of how different people view the issue.
That's exactly the purpose of many of the discussions on d-legal. I'm not
sure what you think should change. Do you think the QPL discussion would be
more productive if crossposted to d-devel? (I think it would just annoy the
people who have chosen not to participate.)
--
Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 04:34:33PM -0700, Josh Triplett wrote: > Would you might clarifying what that grounding is (or pointing me at a > particular message that does so)? I'm currently drafting the second > draft of the QPL summary, and that's one of the few things I'm still > working on: a well-grounded justification from the actual text of the > DFSG. The "fee" angle seems nebulous, and hard to justify; I > more-or-less agree with it, but I need a clear way to justify why it is > only a "royalty or other fee" if it is "paid" to the upstream developer, > and not if it is "paid" to someone you are already distributing the > software to. "The license of a Debian component may not restrict any party from selling or giving away the software ..." I believe "may not restrict" is the operative phrase; this is a restriction. Clearly, this is a case where judgement needs to be applied; taken to the extreme, it would render almost all licenses non-free. I know that some people will want to argue that any such judgement must follow directly and literally from the DFSG; but I think that's equivalent to arguing that the DFSG is to be interpreted as a set of laws rather than guidelines. (I'd be curious how these people would justify "pet a cat when you distribute" being non-free. I really do have trouble calling "petting a cat" a fee, but it's certainly a restriction.) -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 03:58:13PM -0700, Josh Triplett wrote: > > Well, you claimed there was a consensus, while there is clearly no such > > thing. > > Thus it is a lie intended to get the maintainer to take the course of action > > you want through FUD, or at best a misinformed claim you should apologize > > for. (Who could possibly argue with such reasoning?) > The consensus on debian-legal seems to be strongly against the QPL. I suspect Sven thinks--or hopes we'll believe--that one person disagreeing with consensus two hundred times is roughly equivalent to the reverse. > > And i hope you don't tell your AM that you are code hoarding, i doubt he > > will > > appreciate. Guilt by association--the bottom of the argumentation barrel ... -- Glenn Maynard
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 04:34:33PM -0700, Josh Triplett wrote: > Brian Thomas Sniffen wrote: > > Sam Hartman <[EMAIL PROTECTED]> writes: > >>So, have you found something non-free that cannot be justified by the > >>DFSG? Would you be willing wo work on wording for a modification to > >>the DFSG? If you need sponsors I would be happy to help. > > I don't think that the QPL requires any changes to the DFSG to be > > clearly non-free. That is, the choice-of-venue clause and the full > > publication of any distributed change both have clear grounding in the > > DFSG. > Would you might clarifying what that grounding is (or pointing me at a > particular message that does so)? I'm currently drafting the second > draft of the QPL summary, and that's one of the few things I'm still > working on: a well-grounded justification from the actual text of the > DFSG. Choice-of-venue is discriminatory against large classes of people, those who live far away and don't have the means to contest a suit over long distances. If, as Sven argues, this is actually a null clause under French law, then it's a license blemish rather than a DFSG problem, and should be removed for clarity. > The "fee" angle seems nebulous, and hard to justify; I more-or-less > agree with it, but I need a clear way to justify why it is only a > "royalty or other fee" if it is "paid" to the upstream developer, and > not if it is "paid" to someone you are already distributing the > software to. Do you disagree with the definition I've advanced in earlier messages, that a fee is something given in *exchange* for a license? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 04:14:44PM -0400, Walter Landry wrote: > > I disagree. This is not relevant to the freedom of the license, because > > it's an additional restriction imposed by a *third party* (in this case, > > a government), and not something that can be fixed by additional > > permission grants from the licensor. > > Free software licensing presupposes that the copyright holder has the > > ability to grant you certain freedoms over the code. When this is not > > the case due to outside forces (e.g., patent holders or averse > > governments), we should not view this as a flaw in the license if this > > license gives us the *author's* permission to exercise those freedoms > > with the code. > If I can't modify and distribute the software, how can you call the > software free? If you live in a regime such as this, *you* are not free. This is not the software's fault. > This is not like patents or other usual suspects (e.g. govt > regulations on crypto), which depend on the contents of the software. > Rather it flows directly from the license and its interaction with the > law. The author can make the software free by using a BSD license. But in such a case, you can only be free from compelled sharing with the government by exercising your freedom to withhold source code from your neighbors. You can't build a community that way, so I don't think this is a useful definition of freedom. Freedom to distribute binaries is useful, but is secondary to the freedom to share source code. > As another example, what if there were a jurisdiction where recipients > automatically receive the right to modify and distribute unless > otherwise explicitly specified. Then a simple "Copyright (C) 2000 > Steve Langasek" would be free. The difference between this and the prior example is that in the first case, the *government* has additional rights over the software, whereas in the second case, it is the *author* who has lesser rights over (control of) the software. Yes, in this hypothetical jurisdiction, a mere copyright statement would be free; but we are concerned about freedom at the international level, so we need to take a "least common denominator" look at the rights of copyright holders. If we ever get to the point where this hypothetical jurisdiction *is* the least common denominator, then we can give ourselves all a pat on the back and disband the debian-legal mailing list (or at least not be worried over licenses anymore). -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: DRAFT: debian-legal summary of the QPL
Steve Langasek <[EMAIL PROTECTED]> wrote: > On Thu, Jul 22, 2004 at 12:56:50AM -0400, Walter Landry wrote: > > Matthew Garrett <[EMAIL PROTECTED]> wrote: > > > Walter Landry <[EMAIL PROTECTED]> wrote: > > > >Matthew Garrett <[EMAIL PROTECTED]> wrote: > > > >> Under the GPL, the government can just pass a law requiring that all > > > >> distributed source code be provided to the government. > > > > >Except that there are no such governments. Get back to me when that > > > >actually happens. > > > > If there were such a government, would you question the GPL's freedom? > > > In that country, it would not be free. > > I disagree. This is not relevant to the freedom of the license, because > it's an additional restriction imposed by a *third party* (in this case, > a government), and not something that can be fixed by additional > permission grants from the licensor. > > Free software licensing presupposes that the copyright holder has the > ability to grant you certain freedoms over the code. When this is not > the case due to outside forces (e.g., patent holders or averse > governments), we should not view this as a flaw in the license if this > license gives us the *author's* permission to exercise those freedoms > with the code. If I can't modify and distribute the software, how can you call the software free? This is not like patents or other usual suspects (e.g. govt regulations on crypto), which depend on the contents of the software. Rather it flows directly from the license and its interaction with the law. The author can make the software free by using a BSD license. As another example, what if there were a jurisdiction where recipients automatically receive the right to modify and distribute unless otherwise explicitly specified. Then a simple "Copyright (C) 2000 Steve Langasek" would be free. I agree that these examples are rather outlandish, which is why I don't worry about it as a practical matter. Regards, Walter Landry [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
Matthew Palmer wrote: > On Tue, Jul 20, 2004 at 03:25:19PM -0400, Glenn Maynard wrote: > >>On Tue, Jul 20, 2004 at 09:23:40AM -0400, David Nusinow wrote: >> >>>I agree with this interpretation to a large degree. The examples in the DFSG >>>for fields of endeavor are explicit examples, and thus imply some sort of >>>explicit discrimination (such as "No one involved in genetic engineering may >>>use this software") rather than an unintentional discrimination against >>>corner >>>cases. Licenses which require distribution of modifications to upstream >>>authors are not discriminating against castaways any more than the GPL is >>>discriminating against people who somehow lose all copies of the source to >>>their modifications after distributing modified binaries. >> >>This is why DFSG#5 and #6 are fairly useless, in practice. I can't think of >>any license that actually explicitly said "may not be used for bioweapons >>research", clauses that clearly fall under those guidelines. Any less > > "No commercial use" is the usual one. I'm pretty sure I've seen a licence > that prohibited use in genetics research, and I'm quite sure there's been > one that prohibited use in nuclear facilities (although that was more of an > overzealous warranty disclaimer, from memory). I also recall licenses that prohibited use in various types of weapons. For that matter, there is also the "Hacktivismo Enhanced-Source Software License Agreement" (HESSLA), as described by the GNU project on http://www.gnu.org/licenses/hessla.html (although the original project seems to be defunct at the moment). It prohibits use in spyware and by governments that violate human rights. As ridiculous as it sounds, that is actually a form of discrimination and use restriction, which makes the license not DFSG-free. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: DRAFT: debian-legal summary of the QPL
Don Armstrong <[EMAIL PROTECTED]> wrote: >On Mon, 19 Jul 2004, Matthew Garrett wrote: >> I don't believe licenses should affect the distribution of anything >> other than the code they cover. > >I mostly agree with that sentiment, and think it stems from DFSG 9.[1] >But regardless, there isn't a requirement of the DFSG saying that >explicitely, which is one of the reasons why I brought it up. I think part of our problem is that we're not really clear on what "restriction" means. The two choices seem to be something like the way it's used in the GPL (so anything that requires you to do anything), or alternatively something that actually prevents you from doing something rather than merely making you jump through more hoops. >> There's no consistent and coherent argument going on, other than a >> sort of fuzzy "We think it's not free, and we can sort of point at >> these two things and handwave and say they cover them". > > DFSG 5 No Discrimination Against Persons or Groups > The license must not discriminate against any person or group of > persons. Indeed. >As had been mentioned earlier, the argument is that because dissidents >living in some country (or persons living on a desert island) are >either persons or a group of persons, and are discriminated against by >a clause of this license, then that particular clause fails DFSG 5. I don't believe that dissidents are discriminated against by the license. They're discriminated against by their government. Interestingly, there appears to have been no discussion as to what DFSG 5 actually meant while the discussion regarding the original social contract went on. The only examples people use are things like nationality. It's certainly not obvious that it was intended that things like "This license can not be satisfied by people without the ability to communicate with upstream" should fall under clause 5. Of course, that discussion happened over 7 years ago. In the absence of it being made clear then, we need to try to work out what people think now. >> The GPL discriminates against a slightly smaller set of >> dissidents. The GPL discriminates against people on desert islands >> who have a binary CD but not a source one. > >If worst comes to worst, we can use DFSG 10 to avoid this issue, and >use it to define the line where the dissident tests can no longer be >applied. Which is a dreadful fudge. Interestingly, the original drafts of the DFSG *don't* have DFSG 10 as an indepedent point - it's an informational footer. It's not until it gets "reformatted" that it suddenly gets given the same priority as the other points. To be honest, I think it makes far more sense in its original form. >Have you given it any thought yourself? [Or, to put it another way, >how would you define where the line should be drawn in this particular >case?] I think the line should be positioned based on some amount of cost-benefit analysis with a healthy dose of pragmatism built in. For example, I don't care much about people on desert islands. If they're the only thing standing between a license being free or not, and if there's a demonstrable benefit to us for including that software, I'm entirely happy that they be ignored (possibly we should use the extra money we make from the extra CDs sold to fund a trip to get them off the bloody island). Of course, this mostly just turns the argument into one about weightings. Since these are mostly determined by personal opinion, it suggests that there isn't a correct place to draw the line. The only real suggestion I have is wider discussion in an attempt to gain a better understanding of how different people view the issue. -- Matthew Garrett | [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
Edmund GRIMLEY EVANS wrote: > Josh Triplett <[EMAIL PROTECTED]>: >>Do you see anything in the QPL that says the original developer can only >>request your changes once? They can ask twelve times a day if they >>want, and you have to comply; there is nothing in the license that says >>otherwise. For that matter, do you see anything in the QPL that says >>the original developer has to compensate you for the costs of providing >>your changes (bandwidth charges for network distribution, or media costs >>for physical distribution)? >> >>- Josh Triplett >> >>[Do you want both of your email addresses CCed on these mails?] > > I recommend CCing both of them twelve times a day for good measure. As amusing as that comment is, it isn't really appropriate; he does have a valid concern about being kept in the loop, and I certainly don't mind doing so. > finely honed legal arguments like the above! Thank you very much. :) > I think contracts often don't specify things like how rapidly a letter > must be answered, etc, so people apply established standards and > common sense. I don't know what the standard would be in this case, > but maybe 28 days would be an appropriate time for responding to a > request for changes, and common sense says you can ignore further > requests while dealing with the first request, so maybe you would have > to send your changes every 28 days. Still, if you're a Chinese > Dissident stranded on a Desert Island that could be quite a burden ... It would certainly be nice if licenses were interpreted by reasonable people who apply common sense, but unfortunately they often end up being interpreted by nitpicky lawyers instead. :) - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: DRAFT: debian-legal summary of the QPL
Sven Luther wrote: > On Wed, Jul 21, 2004 at 09:05:40AM -0700, Josh Triplett wrote: > >>Sven Luther wrote: >> >>>On Mon, Jul 19, 2004 at 12:01:57PM -0400, Brian Thomas Sniffen wrote: >>> [EMAIL PROTECTED] writes: >Well, simply configuring your SVN/CVS/ARCH/Whatever archive to spam >upstream >with every change done should resolve all the issue. Or maybe giving him >consultation access would be enough. Spamming upstream is not enough. You have to provide one on request, even if you just sent one. Additionally, now you're suggesting doing away with the ability to make private modifications. >>> >>>Bullshit, you have provided it before it was asked, so where is the problem ? >> >>Do you see anything in the QPL that says the original developer can only >>request your changes once? They can ask twelve times a day if they > > Well, whatever is the problem ? You provide it to them, and if they ask you > again, you either say, sorry, i sent it to you already, and haven't got a > backup copy, would you like the latest version perhaps ? If you already > fullfilled the request before you are asked, where is the problem. >From the QPL: > c. If the items are not available to the general public, and the > initial developer of the Software requests a copy of the items, > then you must supply one. Where in there does it say that you may refuse to supply a copy if you have already provided one? >>want, and you have to comply; there is nothing in the license that says >>otherwise. For that matter, do you see anything in the QPL that says >>the original developer has to compensate you for the costs of providing >>your changes (bandwidth charges for network distribution, or media costs >>for physical distribution)? > > Yes, since the distribution will happen accordying to 6a, which says you can > charge for the cost of data transfer. >From the QPL: > c. If the items are not available to the general public, and the > initial developer of the Software requests a copy of the items, > then you must supply one. Where in there does it say that the copy you supply to the initial developer is covered by the terms of 6.a? 6.a only covers recipients who have a binary and want the source. In this case, if you are distributing source (that is not available to the general public), then the source is one of the "items" in question, and it must be provided under 6.c, which does not indicate that you may charge for cost of distribution. >>[Do you want both of your email addresses CCed on these mails?] > > Not really, but i prefer more of them than none at all, as hiting D is easier > than reading mail in lynx. No problem; I'll continue to CC [EMAIL PROTECTED] on all of my mails related to the QPL discussions. (Are you using webmail through lynx?) - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: DRAFT: debian-legal summary of the QPL
Brian Thomas Sniffen wrote: > Sam Hartman <[EMAIL PROTECTED]> writes: >>So, have you found something non-free that cannot be justified by the >>DFSG? Would you be willing wo work on wording for a modification to >>the DFSG? If you need sponsors I would be happy to help. > > I don't think that the QPL requires any changes to the DFSG to be > clearly non-free. That is, the choice-of-venue clause and the full > publication of any distributed change both have clear grounding in the > DFSG. Would you might clarifying what that grounding is (or pointing me at a particular message that does so)? I'm currently drafting the second draft of the QPL summary, and that's one of the few things I'm still working on: a well-grounded justification from the actual text of the DFSG. The "fee" angle seems nebulous, and hard to justify; I more-or-less agree with it, but I need a clear way to justify why it is only a "royalty or other fee" if it is "paid" to the upstream developer, and not if it is "paid" to someone you are already distributing the software to. > Before this issue comes up again with a more closely worded license, I > do think there's an aspect of freedom generally recognized by people > here which *should* be part of the DFSG. It wasn't a big deal in the > free-software community when the DFSG was written, but it's become so > since. It's the second biggest distinction between how the OSI read > the same text that we have: the fairness issue that I posted about > earlier today. > > I'd very much like some help in phrasing that properly. I think that the vast majority of the fairness issue is captured by DFSG 3: > Derived Works > > The license must allow modifications and derived works, and must > allow them to be distributed under the same terms as the license of --- > the original software. - - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: DRAFT: debian-legal summary of the QPL
Sven Luther wrote: > Well, so what. This only proves that there are licences which allow > proprietary product, and i would never voluntary release code under such a > licence, and they are other who don't. Neither would I. However, my issue with the QPL is not that I would want to take the software proprietary, but that I might want to distribute Free Software between a few people, giving those people all the freedoms expected for Free Software. If I take a GPLed program, modify it, and distribute the modified version among a few people, then as long as those people also have the source (or an offer for the source), then no one is being deprived of Freedom, and the software is not proprietary. Giving someone a binary without the source prevents them from exercising their rights over that software. Giving someone no program at all does not restrict their rights, any more than giving someone no money: I am not obligated to distribute to them. That said, I personally think that under almost all circumstances, it is a good idea to provide your changes upstream. >>>Also, i also doubt that this is a way debian is confortable goind, and that >>>allowance of proprietary modifications over other considerations is the path >>>we are conforable threading. >> >>You doubt that which is the way Debian is comfortable going? > > To make allowance to proprietary modification hoarder, like you seem to be. Again, modifications shared amonst a group, with everyone in that group having Freedom, are not proprietary. offers lots of permission, and asks nothing. It's more generous than "fair". The GPL is "fair": it offers many permissions, but some of them can only be exercised if you pass the same permissions on to others. That is, it's a copyleft. But it's probably the most restrictive you can be and still be "fair". >>> >>>Whatever. you want to modify ocaml, and not give back your changes to the >>>community. You have no sympathy from me, neither probably from a waste >>>majority of the debian project. >>> >>>Also you lying, claiming consensus, while there is no such thing, doesn't >>>endear you to me. >> >>I don't think personal insults really help anything. What I see is a > > Well, you claimed there was a consensus, while there is clearly no such thing. > Thus it is a lie intended to get the maintainer to take the course of action > you want through FUD, or at best a misinformed claim you should apologize for. The consensus on debian-legal seems to be strongly against the QPL. >>bunch of generic agreement that there's a problem with the QPL -- that > > A bunch of posts from yourself and a few select others make a consensus, and > there has been no disagrement. Out of hand i remember at least two people who > strongly disagreed. > > >>it's non-free, and that it's probably DFSG-nonfree , but that either way >>what it requires isn't something which Debian should be shipping to >>users and saying, "it's OK to modify this, you have all these freedoms >>listed in the DFSG". > > Well, again, if it came to a GR i doubt debian would actively support code > hoarders. There are many freedoms that Debian requires which it would never excercise itself, or at least would never do so lightly. For example, the freedom to fork, or the freedom to distribute software that does not conform to some standard, or the freedom to distribute software privately. >>On the other side of that issue, I see you and a couple others calling >>the people here lazy, deceitful, and lying. You suggest that users >>should violate licenses because they won't get caught. > > I didn't do that, but you obviously neither read nor understood what i said > nor the QPL itself, so ... To the best of my knowledge, everyone participating in this discussion has read the QPL. I most certainly have, and I know several others have. Feel free to rebut the arguments of others, but please do not call people ignorant or accuse them of not reading the license. >>The question of whether the QPL is free appears to have firm consensus >>from everyone involved in the debate, instead of standing on the >>sidelines and screaming. > > A, a consensus is one where there is no discordant voice, right ? Consensus is stronger than a simple majority, but it does not necessarily unanimous consensus. >>The question of what to *do* about that -- ask upstream authors to >>change their licenses, or modify the DFSG to make this issue explicit. > > Bah, sure, i would do that immediately, if i would be given valable arguments. > Like that i would not only be ashamed to inform my upstream about this issue, > and thus show that debian follows a bunch of uninformed people in their > conclusions, i would be lying to them about this consensus issue, and also > lowering my future relationship with them over real issues. It is difficult to consider the possible avenues by which a licensor may abuse a license, when you have a particular licensor in mind
Re: DRAFT: debian-legal summary of the QPL
Brian Thomas Sniffen wrote: > Because he doesn't just want to distribute them to the rest of the > world. He also wants to turn them into a proprietary product and sell > them! The BSD license is "fair" (a term invented for use here): it > offers lots of permission, and asks nothing. It's more generous than > "fair". The GPL is "fair": it offers many permissions, but some of > them can only be exercised if you pass the same permissions on to > others. That is, it's a copyleft. But it's probably the most > restrictive you can be and still be "fair". > > The QPL isn't even close to that line of "fair"ness: It is a copyleft > which requires that even more permissions be granted to the initial > author. I get some rights to the initial author's code, but he > insists that I give him not only the same rights to my code (which > would be a "fair" copyleft), but much more. > > I don't think this idea of "fair"ness is explicit in the DFSG right > now, but it's an important component of Freedom. It's also a superset > of DFSG 1. In some ways, it's implied by DFSG 1, but it could be made > more clear. I think it's possible to write this in a couple ways -- > concentrating on the symmetry, or on the lack of demands on the > licensee. Does anybody have strong feelings as to which way is more fruitful? Just a note: I think the requirement to give the original author a more permissive license is OK, just obnoxious. The only part I have a problem with is the requirement to distribute your changes to the original author on request, and I would have a problem with that even if the original author could only use those changes under the QPL. - Josh Triplett signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: DRAFT: debian-legal summary of the QPL
On Thu, 22 Jul 2004 01:06:25 -0700 Steve Langasek wrote: > On Thu, Jul 22, 2004 at 12:56:50AM -0400, Walter Landry wrote: > > Matthew Garrett <[EMAIL PROTECTED]> wrote: > > > Walter Landry <[EMAIL PROTECTED]> wrote: > > > >Matthew Garrett <[EMAIL PROTECTED]> wrote: > > > >> Under the GPL, the government can just pass a law requiring > > > >> that all distributed source code be provided to the government. [...] > > In that country, it would not be free. > > I disagree. This is not relevant to the freedom of the license, > because it's an additional restriction imposed by a *third party* (in > this case, a government), and not something that can be fixed by > additional permission grants from the licensor. Indeed. For a license to be free, it is necessary that the *license* grants all the important rights and does not take away any right. If another entity nukes one important right, it's not the license's fault... Consider a totalitarian regime in which anyone can be put in prison with no reason: would free licenses become non-free in this country? I don't think so. -- | GnuPG Key ID = DD6DFCF4 | $ fortune Francesco |Key fingerprint = | Q: What is purple Poli| C979 F34B 27CE 5CD8 DC12 | and commutes? | 31B5 78F4 279B DD6D FCF4 | A: A boolean grape. pgpr6l7qPV8fD.pgp Description: PGP signature
Re: DRAFT: debian-legal summary of the QPL
On Thu, Jul 22, 2004 at 12:56:50AM -0400, Walter Landry wrote: > Matthew Garrett <[EMAIL PROTECTED]> wrote: > > Walter Landry <[EMAIL PROTECTED]> wrote: > > >Matthew Garrett <[EMAIL PROTECTED]> wrote: > > >> Under the GPL, the government can just pass a law requiring that all > > >> distributed source code be provided to the government. > > >Except that there are no such governments. Get back to me when that > > >actually happens. > > If there were such a government, would you question the GPL's freedom? > In that country, it would not be free. I disagree. This is not relevant to the freedom of the license, because it's an additional restriction imposed by a *third party* (in this case, a government), and not something that can be fixed by additional permission grants from the licensor. Free software licensing presupposes that the copyright holder has the ability to grant you certain freedoms over the code. When this is not the case due to outside forces (e.g., patent holders or averse governments), we should not view this as a flaw in the license if this license gives us the *author's* permission to exercise those freedoms with the code. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: DRAFT: debian-legal summary of the QPL
Matthew Garrett <[EMAIL PROTECTED]> wrote: > Walter Landry <[EMAIL PROTECTED]> wrote: > >Matthew Garrett <[EMAIL PROTECTED]> wrote: > >> Under the GPL, the government can just pass a law requiring that all > >> distributed source code be provided to the government. > > > >Except that there are no such governments. Get back to me when that > >actually happens. > > If there were such a government, would you question the GPL's freedom? In that country, it would not be free. If enough of these governments that prohibit source were to pile up, then I would reconsider the freeness of the GPL. As a side note, I have to admit that some of this kind of thing already happens. Doom is not free in Brazil, and crypto didn't use to be free in France (and still isn't in the US, I would argue). > >> The dissident test isn't about dissidents, because it only applies in an > >> unrealistically narrow case. It's about privacy, and it should just say > >> that rather than bothering to mention the poor abused dissidents at all. > > > >I don't understand why you think the example is unrealistically > >narrow. I'm sure that the author of DeCSS would not be happy to have > >to make any more communications concerning DeCSS, considering the > >amount of legal harassment Jon Johansen suffered. > > The author of DeCSS has (if my recollection is correct) managed to stay > fairly anonymous despite the source being publically distributed. He'd > have nothing to fear if it had been under the QPL. Except that he might have been forced to communicate with the original authors. That communcation risks revealing his identity. As it is, he communicated _once_, well before people started looking for him. It is more difficult to covertly communicate now that everyone is looking for him. > >Phil Zimmerman might also have preferred to be a bit more anonymous. > >Moreover, the statute of limitations for what he has been charged with > >has run out, but copyright certainly hasn't. So if he had not > >complied with a software license, he could still be prosecuted for > >copyright infringement. > > People might prefer to stay anonymous. What does this have to do with > freedom? Are you saying that it would be DFSG-free for a person to have to personally identify themselves when modifying and distributing the software? Regards, Walter Landry [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
On Wed, Jul 21, 2004 at 10:42:29AM +0200, Sven Luther wrote: > Well, i wonder if this is as dramatic as it seems, since after all it only > furthers the distribution of the source code, and it is only fair that the > original author, whose work was freely given away so that the work linked with > the library did happen, could get the code back. I have to dispute this use of the term "freely". "Freely" means "requiring nothing in return" (i.e., "without fee"). The QPL clearly *does* require something in return, it requires access to source code of any works derived from the original work. It is for this reason that I don't believe any license which requires distributing source code to upstream is free by my personal standards, and don't believe it should be considered free under Debian's, either. There are many licenses an author might use which are fair, and which are reasonable for the author to wish to use, but which are nevertheless non-free. > Aslo, since it is only a copy of the code, it doesn't really cost > anything to the modifier, so i wonder if it could be considered as a > fee. This is not true. Source disclosure can sometimes be very costly -- if not in terms of a competitive advantage one expects to maintain over competitors, then in terms of the internal expense of getting 5 different lawyers and 3 managers review the request and sign off on it. The value of source code -- or control of it -- is at the core of software IP laws, which are the framework in which Debian operates. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: DRAFT: debian-legal summary of the QPL
On Wed, Jul 21, 2004 at 06:31:30PM +0100, MJ Ray wrote: > On 2004-07-21 17:44:16 +0100 Sven Luther <[EMAIL PROTECTED]> > wrote: > > >On Wed, Jul 21, 2004 at 05:34:34PM +0100, MJ Ray wrote: > >>Probably, yes. I would tell them that this has worried debian-legal > >>and it > >>would be good to rebut or resolve this. > >Well, and if you get no answer at all, what would you conclude ? > > "oooh crap, I guess it's for me to fix this bug" > > >Well, it is debian-legal which is worried about the QPL, which > >ftp-masters > >have already accepted some 3-5 years back, at least in the ocaml case > >it was > >not by equivocation. > > This goes back to the problem Branden mentioned, as we can't tell why > ftpmasters did something. Well, the problem Branden mentioned was about Qt, nowhere does it mention ocaml. > >If now the analysis has shifted, then so be it, but the burden is on > >debian-legal to provide a analysis of good quality of why this change > >is > >deemed necessary, and i have not really seen such an analysis yet. > > I hope that we can do this together. I hope that an interim summary is > posted soon which is more inclusive than your "reproach". Yes, me too. I will do it tomorrow, but it will be in three separate threads. One for 3b, one for 6c, and one for the legal issue. Friendly, Sven Luther
Re: DRAFT: debian-legal summary of the QPL
Josh Triplett <[EMAIL PROTECTED]>: > Do you see anything in the QPL that says the original developer can only > request your changes once? They can ask twelve times a day if they > want, and you have to comply; there is nothing in the license that says > otherwise. For that matter, do you see anything in the QPL that says > the original developer has to compensate you for the costs of providing > your changes (bandwidth charges for network distribution, or media costs > for physical distribution)? > > - Josh Triplett > > [Do you want both of your email addresses CCed on these mails?] I recommend CCing both of them twelve times a day for good measure. That should get him into a good mood where he will be willing to listen to finely honed legal arguments like the above! I think contracts often don't specify things like how rapidly a letter must be answered, etc, so people apply established standards and common sense. I don't know what the standard would be in this case, but maybe 28 days would be an appropriate time for responding to a request for changes, and common sense says you can ignore further requests while dealing with the first request, so maybe you would have to send your changes every 28 days. Still, if you're a Chinese Dissident stranded on a Desert Island that could be quite a burden ...
Re: DRAFT: debian-legal summary of the QPL
On Wed, Jul 21, 2004 at 12:18:08PM +0200, Sven Luther wrote: > > Yes, you say you got legal advice. But you don't say what it was! > > Not even over there. The specifics of that advice make it useless. > > Was it just for your jurisdiction? Well, choice-of-law makes that > > OK. > Well, in any case, it is ways better than what you are providing. So, i expect > you to shut up about this, or provide the same kind of weight behind your > words. I will not accept anymore wild speculation from your part that is > contrary to common sense, my own intuition, and my legal counsel. Would your legal counsel be willing to offer pro-bono advice to the Debian project? If not, this seems to be just another non-binding opinion. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: DRAFT: debian-legal summary of the QPL
On 2004-07-21 17:44:16 +0100 Sven Luther <[EMAIL PROTECTED]> wrote: On Wed, Jul 21, 2004 at 05:34:34PM +0100, MJ Ray wrote: Probably, yes. I would tell them that this has worried debian-legal and it would be good to rebut or resolve this. Well, and if you get no answer at all, what would you conclude ? "oooh crap, I guess it's for me to fix this bug" Well, it is debian-legal which is worried about the QPL, which ftp-masters have already accepted some 3-5 years back, at least in the ocaml case it was not by equivocation. This goes back to the problem Branden mentioned, as we can't tell why ftpmasters did something. If now the analysis has shifted, then so be it, but the burden is on debian-legal to provide a analysis of good quality of why this change is deemed necessary, and i have not really seen such an analysis yet. I hope that we can do this together. I hope that an interim summary is posted soon which is more inclusive than your "reproach". Ultimately, it may be necessary to try to overturn an ftpmaster decision, but that point is a long way off. We're not debian-amd64 ;-) -- 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: DRAFT: debian-legal summary of the QPL
On Wed, Jul 21, 2004 at 05:34:34PM +0100, MJ Ray wrote: > On 2004-07-21 13:14:19 +0100 Sven Luther <[EMAIL PROTECTED]> > >Well, my abrasiveness has been trained by years of participating in > >debian > >mailing list, so you get only yourself to blame. > > Other people succeed in remaining polite after years here, although > there are a few exceptions. Try to be a success, not an exception. Well, it was not meant that way, i learned much of my email-english and email style on debian lists, abrasiveness seems to be the standard there, and even expected by some. > >Well, serious now, would you go to your upstream with such > >ridicoulous claims > >? > > Probably, yes. I would tell them that this has worried debian-legal > and it would be good to rebut or resolve this. Well, and if you get no answer at all, what would you conclude ? > >I would have nothing against it, but the burden is on dbeian-legal to > >provide > >solid legal foundation for these request, just having a bunch of > >would-be-lawyers make half-backed outrageous requests is not going to > >cut it, > >and threatens the credibility of debian-legal as whole. > > Again, not helpful. If you want to push it, the "burden" is on QPL'rs Well, it is debian-legal which is worried about the QPL, which ftp-masters have already accepted some 3-5 years back, at least in the ocaml case it was not by equivocation. If now the analysis has shifted, then so be it, but the burden is on debian-legal to provide a analysis of good quality of why this change is deemed necessary, and i have not really seen such an analysis yet. Some facts i even agree to, but the analysis is far from enough for me to go upstream with it, and had i not participated, i wonder if i would have gotten something else than chinese dissident rambling. Also, a proposed solution, which is both in understanding of the case at hand, and reasonable would be a nice addition. > to get consensus about why/how this follows the DFSG, if they want > QPL'd works in debian. There are threats to the credibility of this > list, but I don't think discussion is one. The abusive behaviour of > contributors might be, or if we just accepted proof by assertion, that > would be far worse. Well, i have not seen real proof that this is not what we are doing in this case, but then it may be related to some irrelevant noise, i don't know. Friendly, Sven Luther
Re: DRAFT: debian-legal summary of the QPL
On 2004-07-21 13:14:19 +0100 Sven Luther <[EMAIL PROTECTED]> wrote: On Wed, Jul 21, 2004 at 12:24:35PM +0100, MJ Ray wrote: Are you sure about this? As far as I can tell, a notice published in a newspaper is regarded as "effective notification" if it meets some In international IP/copyright/contract law ? I have serious doubts about this. It works in various cases, so why not this one? Care to get some real legal advice supporting that fact ? No. I have a finite number of friends with legal training and I make requests of them only when absolutely necessary. I'm quite OK with remaining worried about this clause for now, as other things are worse about it so should be resolved first. [...] Do you seriously expect a judge to accept that a newspaper notice in some remote country is binding to you ? No, but I suspect a newspaper notice in my country or region might be. If you are able to make a lawsuit against someone, claiming he didn't cumply with a broadcaster request, what will you answer to the judge when he asks you why you don't just plain send that guy a letter ? I'm not interested in prosecuting this, but I would reply: It is not required by law. Well, my abrasiveness has been trained by years of participating in debian mailing list, so you get only yourself to blame. Other people succeed in remaining polite after years here, although there are a few exceptions. Try to be a success, not an exception. Well, serious now, would you go to your upstream with such ridicoulous claims ? Probably, yes. I would tell them that this has worried debian-legal and it would be good to rebut or resolve this. I would have nothing against it, but the burden is on dbeian-legal to provide solid legal foundation for these request, just having a bunch of would-be-lawyers make half-backed outrageous requests is not going to cut it, and threatens the credibility of debian-legal as whole. Again, not helpful. If you want to push it, the "burden" is on QPL'rs to get consensus about why/how this follows the DFSG, if they want QPL'd works in debian. There are threats to the credibility of this list, but I don't think discussion is one. The abusive behaviour of contributors might be, or if we just accepted proof by assertion, that would be far worse. Personally, I find OSI's "get the licensor's lawyer to justify acceptance" approach far more incredible. So far, the lawyer is probably not an affected free software developer or user, nor someone with much experience of free software concepts. -- 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: DRAFT: debian-legal summary of the QPL
On Wed, Jul 21, 2004 at 09:05:40AM -0700, Josh Triplett wrote: > Sven Luther wrote: > > On Mon, Jul 19, 2004 at 12:01:57PM -0400, Brian Thomas Sniffen wrote: > >>[EMAIL PROTECTED] writes: > >>>Well, simply configuring your SVN/CVS/ARCH/Whatever archive to spam > >>>upstream > >>>with every change done should resolve all the issue. Or maybe giving him > >>>consultation access would be enough. > >> > >>Spamming upstream is not enough. You have to provide one on request, > >>even if you just sent one. Additionally, now you're suggesting doing > >>away with the ability to make private modifications. > > > > Bullshit, you have provided it before it was asked, so where is the problem > > ? > > Do you see anything in the QPL that says the original developer can only > request your changes once? They can ask twelve times a day if they Well, whatever is the problem ? You provide it to them, and if they ask you again, you either say, sorry, i sent it to you already, and haven't got a backup copy, would you like the latest version perhaps ? If you already fullfilled the request before you are asked, where is the problem. And in any way, your lack of maintenance of a source release archive won't make the licence non-free. I agree that it is a pain though, but hardly enough to make it non-free. > want, and you have to comply; there is nothing in the license that says > otherwise. For that matter, do you see anything in the QPL that says > the original developer has to compensate you for the costs of providing > your changes (bandwidth charges for network distribution, or media costs > for physical distribution)? Yes, since the distribution will happen accordying to 6a, which says you can charge for the cost of data transfer. > [Do you want both of your email addresses CCed on these mails?] Not really, but i prefer more of them than none at all, as hiting D is easier than reading mail in lynx. Friendly, Sven Luther
Re: DRAFT: debian-legal summary of the QPL
Sven Luther wrote: > On Mon, Jul 19, 2004 at 12:01:57PM -0400, Brian Thomas Sniffen wrote: >>[EMAIL PROTECTED] writes: Matthew Garrett wrote: >Glenn Maynard <[EMAIL PROTECTED]> wrote: >>On Tue, Jul 13, 2004 at 06:36:29PM +0100, Matthew Garrett wrote: >> >>>But the QPL also fails the dissident test, and has a much less onerous >>>requirement than the "Add your name to a wiki" license. >> >>It has an "archive all distributed copies until the expiration of >>copyright" >>requirement (QPL#6 has no expiration!), which is far more onerous, IMO. > >As I said elsewhere, I'm unconvinced by that. At any point you can avoid >this by releasing the code to the general public. But that's an entirely >separate point to the one that was being made. I agree with that assessment, with the exception that you should not have to publish your code to the general public, only to those you distribute the binary to. The GPL's "offer to provide source for 3 years" is questionable in isolation, but irrelevant since one can provide source along with binaries and have no further obligations. Even if you do the same with the QPL, by distributing both source and binary to another party, your obligations have not ended, because the copyright holder may still request those changes. >>> >>>Well, simply configuring your SVN/CVS/ARCH/Whatever archive to spam upstream >>>with every change done should resolve all the issue. Or maybe giving him >>>consultation access would be enough. >> >>Spamming upstream is not enough. You have to provide one on request, >>even if you just sent one. Additionally, now you're suggesting doing >>away with the ability to make private modifications. > > Bullshit, you have provided it before it was asked, so where is the problem ? Do you see anything in the QPL that says the original developer can only request your changes once? They can ask twelve times a day if they want, and you have to comply; there is nothing in the license that says otherwise. For that matter, do you see anything in the QPL that says the original developer has to compensate you for the costs of providing your changes (bandwidth charges for network distribution, or media costs for physical distribution)? - Josh Triplett [Do you want both of your email addresses CCed on these mails?] signature.asc Description: OpenPGP digital signature
Re: DRAFT: debian-legal summary of the QPL
On Wed, Jul 21, 2004 at 10:15:26AM +0200, Bernhard R. Link wrote: > Why shaky? When an clause results in discriminating against people, > groups or fields of endeavor (of course within the limits of free > software[1]) then the licence is non-free. Why should we make > a difference between explicit prohibitons and things that effectively > prohibit? Can I replace a veto against using my software in an nuclear > plant by a condition that when used in a nuclear plant one must publish > all security measures of the plant and make the licence thus "free" > without changing who if effectively allowed to use it and who not? I think the only way to even begin to approach "effective discrimination" is to approach via intent. If a clause does not explicitly say "This may not be used in foo" but goes to obvious and lengths to prevent usage for foo, then that counts as discrimination. Getting confirmation of intent from the author is probably going to be very important in these cases. The desert island test definitely does not demonstrate effective discrimination in this fashion though. - David Nusinow
Re: DRAFT: debian-legal summary of the QPL
On Wed, Jul 21, 2004 at 12:24:35PM +0100, MJ Ray wrote: > On 2004-07-21 09:32:39 +0100 Sven Luther <[EMAIL PROTECTED]> > wrote: > > >This interpretation of TV broadcast was only dreamed in the mind of a > >bunch of > >would be lawyers here, who didn't even bother to really read the QPL, > >and > >didn't even bother to ask a real lawyer, or even a juridic student or > >something, about the thing. > > Are you sure about this? As far as I can tell, a notice published in a > newspaper is regarded as "effective notification" if it meets some In international IP/copyright/contract law ? I have serious doubts about this. > standards. These are commonly used for public notices about product > defects and are even required for certain types of government notice. > Most commonly, consultation notices, as in s39 of [2001] EWHC Admin > 310 http://www.bailii.org/ew/cases/EWHC/Admin/2001/310.html Care to get some real legal advice supporting that fact ? > I'm not sure any of us have said that this would stick in court, but > some of us are worried because of the acceptance of things like > broadcast notices in newspapers in many other fields. Trying to pin Well, we can worry about so many things that it would paralize any action we may take. Is this a reasonable worry ? Do you seriously expect a judge to accept that a newspaper notice in some remote country is binding to you ? > down exactly what the law is here is difficult, as I don't have many > legal texts and there's no law library to find more. I suspect this is > uncontroversial, as I can't find recent cases directly discussing it. > Unfortunately, it's not common enough to feature in web-based law > explanations, as far as I can tell. In any case, the real point is : If you are able to make a lawsuit against someone, claiming he didn't cumply with a broadcaster request, what will you answer to the judge when he asks you why you don't just plain send that guy a letter ? > >And, i repeat, i will _NOT_ go upstream with bullshit and laughable > >requests > >who have no legal founding, this is the most sure way to shot myself > >in the > >foot and break years of good relationship with upstream. > > I think it was right out of order for the lawyer you asked just to > laugh at you and apparently not give any pointers that you could use He didn't laugh at me, but at the idea of TV-broadcast request. > to explain it. If that is the environment in which you usually live, > maybe that is why you seem so abrasive on this list and don't give > many helpful explanations. Well, my abrasiveness has been trained by years of participating in debian mailing list, so you get only yourself to blame. > If you value your friendship with upstream so much, maybe that is > colouring your view, too. I'm not saying that friendship is a bad > thing, but you should be aware of it. Well, serious now, would you go to your upstream with such ridicoulous claims ? I would have nothing against it, but the burden is on dbeian-legal to provide solid legal foundation for these request, just having a bunch of would-be-lawyers make half-backed outrageous requests is not going to cut it, and threatens the credibility of debian-legal as whole. Friendly, Sven Luther
Re: DRAFT: debian-legal summary of the QPL
On 2004-07-21 09:32:39 +0100 Sven Luther <[EMAIL PROTECTED]> wrote: This interpretation of TV broadcast was only dreamed in the mind of a bunch of would be lawyers here, who didn't even bother to really read the QPL, and didn't even bother to ask a real lawyer, or even a juridic student or something, about the thing. Are you sure about this? As far as I can tell, a notice published in a newspaper is regarded as "effective notification" if it meets some standards. These are commonly used for public notices about product defects and are even required for certain types of government notice. Most commonly, consultation notices, as in s39 of [2001] EWHC Admin 310 http://www.bailii.org/ew/cases/EWHC/Admin/2001/310.html I'm not sure any of us have said that this would stick in court, but some of us are worried because of the acceptance of things like broadcast notices in newspapers in many other fields. Trying to pin down exactly what the law is here is difficult, as I don't have many legal texts and there's no law library to find more. I suspect this is uncontroversial, as I can't find recent cases directly discussing it. Unfortunately, it's not common enough to feature in web-based law explanations, as far as I can tell. And, i repeat, i will _NOT_ go upstream with bullshit and laughable requests who have no legal founding, this is the most sure way to shot myself in the foot and break years of good relationship with upstream. I think it was right out of order for the lawyer you asked just to laugh at you and apparently not give any pointers that you could use to explain it. If that is the environment in which you usually live, maybe that is why you seem so abrasive on this list and don't give many helpful explanations. If you value your friendship with upstream so much, maybe that is colouring your view, too. I'm not saying that friendship is a bad thing, but you should be aware of it. -- 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: DRAFT: debian-legal summary of the QPL
Walter Landry <[EMAIL PROTECTED]> wrote: >Matthew Garrett <[EMAIL PROTECTED]> wrote: >> Under the GPL, the government can just pass a law requiring that all >> distributed source code be provided to the government. > >Except that there are no such governments. Get back to me when that >actually happens. If there were such a government, would you question the GPL's freedom? >> The dissident test isn't about dissidents, because it only applies in an >> unrealistically narrow case. It's about privacy, and it should just say >> that rather than bothering to mention the poor abused dissidents at all. > >I don't understand why you think the example is unrealistically >narrow. I'm sure that the author of DeCSS would not be happy to have >to make any more communications concerning DeCSS, considering the >amount of legal harassment Jon Johansen suffered. The author of DeCSS has (if my recollection is correct) managed to stay fairly anonymous despite the source being publically distributed. He'd have nothing to fear if it had been under the QPL. >Phil Zimmerman might also have preferred to be a bit more anonymous. >Moreover, the statute of limitations for what he has been charged with >has run out, but copyright certainly hasn't. So if he had not >complied with a software license, he could still be prosecuted for >copyright infringement. People might prefer to stay anonymous. What does this have to do with freedom? -- Matthew Garrett | [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
Steve Langasek <[EMAIL PROTECTED]> wrote: >On Mon, Jul 19, 2004 at 11:38:23AM +0100, Matthew Garrett wrote: >> The GPL discriminates against a slightly smaller set of dissidents.=20 > >Which set? The ones who want to be able to give binaries to people when they don't necessarily trust them with the source. >> The GPL discriminates against people on desert islands who have a=20 >> binary CD but not a source one. > >How? They find that they can't distribute any further. >> Make the tests sufficiently silly and we can ban every single license >> for discriminating against a field of endeavour. > >Sure, but I don't think either the dissident test or the desert island >test fall into this category. Mm. I'm unconvinced. -- Matthew Garrett | [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
On Tue, Jul 20, 2004 at 03:50:44PM -0400, Brian Thomas Sniffen wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > On Mon, Jul 19, 2004 at 09:25:57PM -0400, Brian Thomas Sniffen wrote: > >> Sven Luther <[EMAIL PROTECTED]> writes: > >> > >> > On Mon, Jul 19, 2004 at 01:44:16PM -0400, Brian Thomas Sniffen wrote: > >> >> >> He doesn't need to learn of the patch first in the case of the > >> >> >> generic > >> >> >> call. Additionally, the idea is not to help users get away with as > >> >> > > >> >> > Well, i am somehow doubtfull that sucha generic call is legally > >> >> > binding, so > >> >> > your point is moot. How can upstream guarantee that the modifier did > >> >> > receive > >> >> > the call and convince the judge of it ? > >> >> > >> >> Can you provide any evidence that such a generic call not legally > >> >> binding? Or are you just somehow doubtful, without any reason? > >> > > >> > Well, this is common sense, so i guess it would be upto you to prove the > >> > contrary. But don't fear i will be getting legal advice this afternoon, > >> > altough not IP specific one, and i will tell you what comes of it. > >> > >> I'm claiming that the license should be read as saying what it plainly > >> says, and that other implied conditions should not be read into it. > >> I'm perfectly willing to believe such implied conditions should be > >> read -- but I want to see evidence of such. The claim that it's > >> common sense, when that position appears uniquely yours, is unpersuasive. > > > > Please read and reponsd to the other thread i started. I asked for legal > > advice, even if not specialized one, on this subject, and the reply i got > > confirmed my intuition. Now, it is your turn to find legal evidence to > > contradict it. > > Yes, you say you got legal advice. But you don't say what it was! > Not even over there. The specifics of that advice make it useless. > Was it just for your jurisdiction? Well, choice-of-law makes that > OK. Well, in any case, it is ways better than what you are providing. So, i expect you to shut up about this, or provide the same kind of weight behind your words. I will not accept anymore wild speculation from your part that is contrary to common sense, my own intuition, and my legal counsel. > Even so, how does the unenforceability of a license justify ignoring > the wishes of the author? It does not, but that hardly make it non-free. Friendly, Sven Luther
Re: DRAFT: debian-legal summary of the QPL
Bernard R> Link writes: >* Steve McIntyre <[EMAIL PROTECTED]> [040721 00:51]: >> >Since the DFSG itself doesn't distinguish between the two in that >> >clause, the latter is a perfectly reasonable interpretation. >> >> So where does this stop? Just about every current free license out >> there will have clauses that may clash with national laws >> somewhere. Be reasonable here, please: "effective discrimination" is a >> very shaky thing to start claiming... > >Why shaky? When an clause results in discriminating against people, >groups or fields of endeavor (of course within the limits of free >software[1]) then the licence is non-free. Why should we make >a difference between explicit prohibitons and things that effectively >prohibit? Can I replace a veto against using my software in an nuclear >plant by a condition that when used in a nuclear plant one must publish >all security measures of the plant and make the licence thus "free" >without changing who if effectively allowed to use it and who not? Then that would clearly be discrimination - you've given explicitly different rights to different people. That's not the "effective" discrimination that we've been talking about, where people in some countries/circumstances have their freedom curtailed by local issues that are _not_ the fault of the software author's choice of license. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Re: DRAFT: debian-legal summary of the QPL
On Wed, Jul 21, 2004 at 08:59:04AM +1000, Matthew Palmer wrote: > On Tue, Jul 20, 2004 at 01:27:29PM -0400, Brian Thomas Sniffen wrote: > > Sven Luther <[EMAIL PROTECTED]> writes: > > > > > On Tue, Jul 20, 2004 at 11:17:51AM -0400, Brian Thomas Sniffen wrote: > > >> Sven Luther <[EMAIL PROTECTED]> writes: > > >> > > >> > On Mon, Jul 19, 2004 at 11:12:57AM -0800, D. Starner wrote: > > >> >> Sven Luther writes: > > >> >> > > >> >> > Sorry, but i don't believe such a request is legally binding. > > >> >> > > >> >> I do. More to the point, neither of us is the judge who's going to > > >> > > > >> > Well, as said, i did some legal consulting, and the mention that a TV > > >> > broadcasted request for patches should be legally binding did bring in > > >> > some > > >> > round of laughter. > > >> > > >> Did you explain to your legal advisor that this is a broadcast request > > >> in the context where you're operating within a license obliging you to > > >> obey such requests? > > > > > > Yeah, sure. It is not binding. > > > > Then you can safely ask upstream to remove it from the license, right? > > Then we don't have to worry about it. A shorter, simpler license can > > only be a good thing. > > Erm, I think you've gone over the top there. Sven is saying that an attempt > to gather all linked works to the software by broadcasting an ad saying "I am > hereby requesting a copy of all linked works of program under clause > 6c of the QPL, which applies to program " is non-binding. It's a big > leap from there to "if the author writes me a certified letter saying 'I > want a copy of the source of library X linked to your copy of program > ', it's non-binding". > > One thing that still bothers me about this, and I haven't seen a good > rebuttal of it yet, is why we're so keen to use the law to void out a clause > in the licence because it's unenforcable. I've mentioned it before and had > it danced around, but I still don't see why we shouldn't be honouring the > author's wishes as expressed in his chosen licence. > > I can't particularly see the use of the clause anyway, though. Since > everything linked to the QPL'd program needs to be QPL (well, maybe), you > need to give the recipient a copy of the source anyway. 6c is just a "we'll > keep it free for you" from the initial developer, which I'd hope we can do > away with. I've never heard of a missing library being a problem for > anything under the GPL. So I don't see why INRIA wouldn't pull it, unless > they are actually planning on enforcing that clause to devious ends. Well, the 6 a-b mean you have to distribute it under a free + source licence to the people you give it to. The 6c means that, upon request from the author, you have to give it to him too, thus a forcefull distribution, which could be considered as a royalty or fee, and thus break the DFSG 1). Well, i wonder if this is as dramatic as it seems, since after all it only furthers the distribution of the source code, and it is only fair that the original author, whose work was freely given away so that the work linked with the library did happen, could get the code back. Aslo, since it is only a copy of the code, it doesn't really cost anything to the modifier, so i wonder if it could be considered as a fee. > > >> > Furthermore, i was mentioned the fact that the request should be > > >> > nominal, both to the modificator and the actual patch involved, > > >> > > >> I apologize, but I cannot understand what you mean by a request being > > >> nominal to the modifier or the patch. Where does this idea of > > >> "nominal"ness appear in the QPL? > > > > > > You Brian, i know that you modified my work with patch foo. As the QPL > > > point > > > 6c mentions, i request from you that you send me the changes in question. > > Interesting that Sven now thinks that 6c applies to modifications, too, not > just linked works. Sven, care to comment on your change of heart? Err, no, i still think as above, but this thread was started before i realized that, and i didn't change it to the more clumsier wording. Maybe even the part you quote here predates my realisation of the real meaning of section 6. > > > In a formal letter, sent as recomande awith avis de reception in france, > > > so > > > you get proof not only that it arrived, but your signature in the avis de > > > reception. But then, i guess a fedex or DHL or whatever such sending > > > would do > > > too. > > > > > > This is the way i imagine a legally binding request, and the way such > > > business > > > is conducted here. And i send such recomande avec avis de reception, for > > > all > > > critical stuff, including employer disputes, house contract resignation > > > and > > > such. > > > > Ah! So if they put the source code to the ocaml compiler up there, > > with the QPL, is that not binding either? How can this copyright > > license be valid if it is not given to me by name? > > I think you need some sleep, Brian.
Re: DRAFT: debian-legal summary of the QPL
On Wed, 21 Jul 2004, Steve McIntyre wrote: > What part of > > 5. No Discrimination Against Persons or Groups > > The license must not discriminate against any person or group of > persons. > > allows for _any_ discrimination? None of it, apparently, which is one of the reasons why the DFSG is a set of guidelines, not a mere definition. > "Must not discriminate" seems pretty clear to me. If you're going to > argue for "effective discrimination" then you've just argued > yourself out of free software altogether. Not necessarily, because the DFSG specifically allows licences like the GPL. Therefore, we can use those licenses to establish where the lines of these particular clauses are. Presumably the line for this clause is where the good to the free software community outweighs the discrimination inherent in any license that gives rights in exchange for requiring something from those modifying or distributing modifications. Others may feel that the line is somewhere else. > Are you reading the same DFSG as me??? "Must not discriminate" is > not in any sense vague - it does not leave any leeway for "allowable > discrimination". Well, then why should effective discrimination be allowed? Surely effective discrimination fits under "must not discriminate." In the end, we still come back to the fact that we're dealing with a set of guidelines that needs to be thoughtfully applied to a license. For many of these cases, there's no known bright line test, where X is free, and Y is non free. [See the OSD v DFSG threads for more examples...] As always, if anyone can codify such a bright line test, please, do so. It only makes discussing software freedom easier. Don Armstrong -- Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly). -- Matt Welsh http://www.donarmstrong.com http://rzlab.ucr.edu
Re: DRAFT: debian-legal summary of the QPL
On Tue, Jul 20, 2004 at 01:27:29PM -0400, Brian Thomas Sniffen wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > On Tue, Jul 20, 2004 at 11:17:51AM -0400, Brian Thomas Sniffen wrote: > >> Sven Luther <[EMAIL PROTECTED]> writes: > >> > >> > On Mon, Jul 19, 2004 at 11:12:57AM -0800, D. Starner wrote: > >> >> Sven Luther writes: > >> >> > >> >> > Sorry, but i don't believe such a request is legally binding. > >> >> > >> >> I do. More to the point, neither of us is the judge who's going to > >> > > >> > Well, as said, i did some legal consulting, and the mention that a TV > >> > broadcasted request for patches should be legally binding did bring in > >> > some > >> > round of laughter. > >> > >> Did you explain to your legal advisor that this is a broadcast request > >> in the context where you're operating within a license obliging you to > >> obey such requests? > > > > Yeah, sure. It is not binding. > > Then you can safely ask upstream to remove it from the license, right? > Then we don't have to worry about it. A shorter, simpler license can > only be a good thing. Now, stop being stupid. Nowhere in the licence is there mention of a generic TV broadcast request for all patches, any legal knowledgeable person would clearly interpret this as an in person request for a specific patch. Also, since it doesn't really apply to patches, but works that link with the original library or modified library, it is not really a patch at cause here. This interpretation of TV broadcast was only dreamed in the mind of a bunch of would be lawyers here, who didn't even bother to really read the QPL, and didn't even bother to ask a real lawyer, or even a juridic student or something, about the thing. And, i repeat, i will _NOT_ go upstream with bullshit and laughable requests who have no legal founding, this is the most sure way to shot myself in the foot and break years of good relationship with upstream. So, if you are so intent on providing advice on this, please go read a few law books, and ask around, before dreaming up more such bogus interpretations and asking me to relay them. > >> > Furthermore, i was mentioned the fact that the request should be > >> > nominal, both to the modificator and the actual patch involved, > >> > >> I apologize, but I cannot understand what you mean by a request being > >> nominal to the modifier or the patch. Where does this idea of > >> "nominal"ness appear in the QPL? > > > > You Brian, i know that you modified my work with patch foo. As the QPL point > > 6c mentions, i request from you that you send me the changes in question. > > > > In a formal letter, sent as recomande awith avis de reception in france, so > > you get proof not only that it arrived, but your signature in the avis de > > reception. But then, i guess a fedex or DHL or whatever such sending would > > do > > too. > > > > This is the way i imagine a legally binding request, and the way such > > business > > is conducted here. And i send such recomande avec avis de reception, for all > > critical stuff, including employer disputes, house contract resignation and > > such. > > Ah! So if they put the source code to the ocaml compiler up there, > with the QPL, is that not binding either? How can this copyright > license be valid if it is not given to me by name? Because by using or modifying the software, you agree to it. There is indeed some doubt about a generic eula like microsoft's to be legal, since you have no other choice but to agree, but i doubt it will apply here. But now, do your home work, consult a lawyer, read some legal basic books and then come back. I have done so, and you still don't believe the information i have been told. But this is no reason you should continue here with your bogus interpretation. Friendly, Svne Luther > > -Brian > > -- > Brian Sniffen [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
* Steve McIntyre <[EMAIL PROTECTED]> [040721 00:51]: > >Since the DFSG itself doesn't distinguish between the two in that > >clause, the latter is a perfectly reasonable interpretation. > > So where does this stop? Just about every current free license out > there will have clauses that may clash with national laws > somewhere. Be reasonable here, please: "effective discrimination" is a > very shaky thing to start claiming... Why shaky? When an clause results in discriminating against people, groups or fields of endeavor (of course within the limits of free software[1]) then the licence is non-free. Why should we make a difference between explicit prohibitons and things that effectively prohibit? Can I replace a veto against using my software in an nuclear plant by a condition that when used in a nuclear plant one must publish all security measures of the plant and make the licence thus "free" without changing who if effectively allowed to use it and who not? Hochachtungsvoll, Bernhard R. Link [1] Just to name the obvious. We have a context here, which has to be observed before trying to direct it into absurdity. This context is free software, i.e. each program is accompanied by its source and the authors are not prohibiting the rights one needs for it.
Re: DRAFT: debian-legal summary of the QPL
Don Armstrong writee: >On Tue, 20 Jul 2004, Steve McIntyre wrote: >> So where does this stop? > >Presumably where the good to free software outweighs the effective >discrimination. > >That's why we're discussing it now (and have discussed it in the >past.) We're trying to determine what amount discrimination is >allowable in a free license. What part of 5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. allows for _any_ discrimination? "Must not discriminate" seems pretty clear to me. If you're going to argue for "effective discrimination" then you've just argued yourself out of free software altogether. >> Just about every current free license out there will have clauses >> that may clash with national laws somewhere. > >Yes, but presumably those are a case of the national laws restricting >the freedom of the user, rather than the license itself restricting >that freedom. > >> Be reasonable here, please: "effective discrimination" is a very >> shaky thing to start claiming... > >It's not necesarily shaky, it's just that there isn't a clear defining >line where allowable discrimination starts, and disallowable >discrimination begins. > >DFSG 5 is perhaps purposely vague in this regard. Are you reading the same DFSG as me??? "Must not discriminate" is not in any sense vague - it does not leave any leeway for "allowable discrimination". -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Re: DRAFT: debian-legal summary of the QPL
On Tue, 20 Jul 2004, Steve McIntyre wrote: > Don Armstrong writes: > >I think you're limiting it to explicit discrimination, whereas I feel > >it should apply to effective discrimination as well. > > So where does this stop? Presumably where the good to free software outweighs the effective discrimination. That's why we're discussing it now (and have discussed it in the past.) We're trying to determine what amount discrimination is allowable in a free license. > Just about every current free license out there will have clauses > that may clash with national laws somewhere. Yes, but presumably those are a case of the national laws restricting the freedom of the user, rather than the license itself restricting that freedom. > Be reasonable here, please: "effective discrimination" is a very > shaky thing to start claiming... It's not necesarily shaky, it's just that there isn't a clear defining line where allowable discrimination starts, and disallowable discrimination begins. DFSG 5 is perhaps purposely vague in this regard. Don ARmstrong -- If it jams, force it. If it breaks, it needed replacing anyway. -- Lowery's Law http://www.donarmstrong.com http://rzlab.ucr.edu
Re: DRAFT: debian-legal summary of the QPL
On Tue, 2004-07-20 at 18:59, Matthew Palmer wrote: > One thing that still bothers me about this, and I haven't seen a good > rebuttal of it yet, is why we're so keen to use the law to void out a clause > in the licence because it's unenforcable. I've mentioned it before and had > it danced around, but I still don't see why we shouldn't be honouring the > author's wishes as expressed in his chosen licence. Neither do I. Relying on the "unenforcability" of a license or a clause in a license is foolishness in the extreme; all it takes is a little lobbying from Hollywood for some seemingly unrelated thing, and presto-chango, it's suddenly retroactively an enforcable clause under the new and improved Super-DMCA, and because somebody had this discussion and therefore noticed the clause, that makes it wilful infringement. Now, it may be that the author's wishes may or may not be practical, but nobody is actually required to carry any particular author's works. For myself, I consider forced-distribution clauses of any sort to be of such a nature that I am unwilling to submit myself to them. I can give my friend a CD or DVD full of binaries and corresponding source and discharge my obligations entirely under the GPL and anything else I consider to be "Free". YMMV. That CD can even be customized for them, and I've still discharged my obligations. Under the QPL (or GPL 3(b), which I think is equally impractical for such small scale distribution), I've just incurred an obligation for some indeterminate time in the future, when I may or may not be able to discharge that obligation without significant cost. That risk is too great for me to consider participating, and hence, I personally will not touch anything licensed under the QPL. What is acceptable for Debian to distribute is another matter entirely, but I do think that the "pass a CD along to a friend" model ought to be considered as part of the discussion.
Re: DRAFT: debian-legal summary of the QPL
On Tue, Jul 20, 2004 at 01:27:29PM -0400, Brian Thomas Sniffen wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > On Tue, Jul 20, 2004 at 11:17:51AM -0400, Brian Thomas Sniffen wrote: > >> Sven Luther <[EMAIL PROTECTED]> writes: > >> > >> > On Mon, Jul 19, 2004 at 11:12:57AM -0800, D. Starner wrote: > >> >> Sven Luther writes: > >> >> > >> >> > Sorry, but i don't believe such a request is legally binding. > >> >> > >> >> I do. More to the point, neither of us is the judge who's going to > >> > > >> > Well, as said, i did some legal consulting, and the mention that a TV > >> > broadcasted request for patches should be legally binding did bring in > >> > some > >> > round of laughter. > >> > >> Did you explain to your legal advisor that this is a broadcast request > >> in the context where you're operating within a license obliging you to > >> obey such requests? > > > > Yeah, sure. It is not binding. > > Then you can safely ask upstream to remove it from the license, right? > Then we don't have to worry about it. A shorter, simpler license can > only be a good thing. Erm, I think you've gone over the top there. Sven is saying that an attempt to gather all linked works to the software by broadcasting an ad saying "I am hereby requesting a copy of all linked works of program under clause 6c of the QPL, which applies to program " is non-binding. It's a big leap from there to "if the author writes me a certified letter saying 'I want a copy of the source of library X linked to your copy of program ', it's non-binding". One thing that still bothers me about this, and I haven't seen a good rebuttal of it yet, is why we're so keen to use the law to void out a clause in the licence because it's unenforcable. I've mentioned it before and had it danced around, but I still don't see why we shouldn't be honouring the author's wishes as expressed in his chosen licence. I can't particularly see the use of the clause anyway, though. Since everything linked to the QPL'd program needs to be QPL (well, maybe), you need to give the recipient a copy of the source anyway. 6c is just a "we'll keep it free for you" from the initial developer, which I'd hope we can do away with. I've never heard of a missing library being a problem for anything under the GPL. So I don't see why INRIA wouldn't pull it, unless they are actually planning on enforcing that clause to devious ends. > >> > Furthermore, i was mentioned the fact that the request should be > >> > nominal, both to the modificator and the actual patch involved, > >> > >> I apologize, but I cannot understand what you mean by a request being > >> nominal to the modifier or the patch. Where does this idea of > >> "nominal"ness appear in the QPL? > > > > You Brian, i know that you modified my work with patch foo. As the QPL point > > 6c mentions, i request from you that you send me the changes in question. Interesting that Sven now thinks that 6c applies to modifications, too, not just linked works. Sven, care to comment on your change of heart? > > In a formal letter, sent as recomande awith avis de reception in france, so > > you get proof not only that it arrived, but your signature in the avis de > > reception. But then, i guess a fedex or DHL or whatever such sending would > > do > > too. > > > > This is the way i imagine a legally binding request, and the way such > > business > > is conducted here. And i send such recomande avec avis de reception, for all > > critical stuff, including employer disputes, house contract resignation and > > such. > > Ah! So if they put the source code to the ocaml compiler up there, > with the QPL, is that not binding either? How can this copyright > license be valid if it is not given to me by name? I think you need some sleep, Brian. Your arguments here aren't up to your usual standard. I think I know what you're trying to say -- that because the licence doesn't say "I give you, Brian Thomas Sniffen, a licence to this work under the terms of the QPL, as shown below", the licence is not valid, because I need to say "Brian Thomas Sniffen, I want the source to library X linked to your copy of program ". The difference is, I think, that expressing your wishes in the form of a permission grant is deemed OK by the powers that be, while trying to exercise the terms of the licence requires a bit more selectivity. Similar, I imagine, to licencing your work as opposed to copyright assignment. - Matt
Re: DRAFT: debian-legal summary of the QPL
Don Armstrong writes: >On Tue, 20 Jul 2004, Steve McIntyre wrote: >> All users of the software are given the same license. The license >> itself does not discriminate against them; it does not say "no >> people on a desert island may use this" or similar. > >I think you're limiting it to explicit discrimination, whereas I feel >it should apply to effective discrimination as well. > >Since the DFSG itself doesn't distinguish between the two in that >clause, the latter is a perfectly reasonable interpretation. So where does this stop? Just about every current free license out there will have clauses that may clash with national laws somewhere. Be reasonable here, please: "effective discrimination" is a very shaky thing to start claiming... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Re: DRAFT: debian-legal summary of the QPL
On Tue, Jul 20, 2004 at 03:25:19PM -0400, Glenn Maynard wrote: > On Tue, Jul 20, 2004 at 09:23:40AM -0400, David Nusinow wrote: > > I agree with this interpretation to a large degree. The examples in the DFSG > > for fields of endeavor are explicit examples, and thus imply some sort of > > explicit discrimination (such as "No one involved in genetic engineering may > > use this software") rather than an unintentional discrimination against > > corner > > cases. Licenses which require distribution of modifications to upstream > > authors are not discriminating against castaways any more than the GPL is > > discriminating against people who somehow lose all copies of the source to > > their modifications after distributing modified binaries. > > This is why DFSG#5 and #6 are fairly useless, in practice. I can't think of > any license that actually explicitly said "may not be used for bioweapons > research", clauses that clearly fall under those guidelines. Any less "No commercial use" is the usual one. I'm pretty sure I've seen a licence that prohibited use in genetics research, and I'm quite sure there's been one that prohibited use in nuclear facilities (although that was more of an overzealous warranty disclaimer, from memory). > direct arguments tend to reduce to absurdity almost immediately, eg. "the > GPL discriminates against the field of creating proprietary software"--it > certainly does, and almost all licenses "discriminate" against people who > don't want to comply with those terms, but we don't read DFSG#6 that way. Indeed. It's scope is fairly narrow once you look at it in a non-absurd fashion, but it still has it's uses. - Matt
