Re: GPL-compatible, copyleft documentation license
On Mon, Jul 12, 2004 at 12:33:22PM +0200, Florian Weimer wrote: * Branden Robinson: In the copyright holder's understanding, re-imposition of the requirements of sections 2a and and 2c by those creating a derivative work is not allowed, since those restrictions never attached to this work; see section 6. This work can be combined with another work licensed under the GNU General Public License, version 2, but any section 2a and 2c restrictions on the resulting work would only attach only due to the copyright license on the work(s) with which this work is combined and for which those restrictions are in force. Isn't this at least a bit self-contradicting? I don't think so. (Hint: If you want to raise an objection, raise one. Doesn't this suck? doesn't really cut it.) Why produce such a mess in the first place? Well, first things first. What problem(s) do you think there would be in licensing the work in question[1] under the straight GNU GPL? What applicability do you suggest clause 2c) has to things that can't read commands interactively when run, because it's not a program? Your license doesn't give me permission to publicly perform the work, or to broadcast it. True enough. Neither does the GNU GPL. Why is this not a problem for the GNU GPL? It doesn't deal with moral rights at all (which are quite important in some jurisdictions when it comes to non-programs). True enough. Neither does the GNU GPL. Why is this not a problem for the GNU GPL? It doesn't special-case distribution of printed copies, which means that the GPL provisions apply. These provisions pretty much rule out small-scaleprinting and redistribution because of the valid for at least three years rule. True enough. Neither does the GNU GPL. Why is this not a problem for the GNU GPL? However, the license does clarify what constitutes source code, but this might also be a further restriction in the GPL sense, making the license incompatible with the GPL. What's your reasoning? If someone transforms the document into an executable program, they have likely changed the preferred form of modification for the work. Nothing in the GNU GPL forbids them from doing so, and my clarification doesn't either. All in all, I don't think this is a particularly good license for documentation, it's just yet another GPL variant. It's supposed to be a GPL variant. It's also supposed to be compatible with the GPL. [1] http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml -- G. Branden Robinson| What cause deserves following if Debian GNU/Linux | its adherents must bury their [EMAIL PROTECTED] | opposition with lies? http://people.debian.org/~branden/ | -- Noel O'Connor signature.asc Description: Digital signature
Re: GPL-compatible, copyleft documentation license
On Mon, Jul 12, 2004 at 02:27:53PM +0200, Florian Weimer wrote: * Edmund GRIMLEY EVANS: To me it seems potentially useful to release licensees from those requirements. I agree, but at the same time, Branden explicitly forbids to re-introduce these requirements, creating the GPL compatibility issue. Anything independently copyrighted and licensed under the GNU GPL can be combined with this work. Furthermore, any independently copyrightable modifications can be placed under the GNU GPL and this combined. As I understand it moral rights are not portable in the way that copyright is, so it might not even be possible to deal with moral rights without hiring a huge international team of lawyers and producing a multilingual licence the size of a small book. Creative Commons is doing this already, so why not use their efforts? Because their efforts are not DFSG-free, and they left a bad taste in my mouth the last time I read them. I don't think that's a huge problem in practice. If you tell the people to whom you give the hard copy that they must download the source within the next 48 hours, then that probably counts as giving them the source. This is not GPL-compatible, and not comptible with Branden's license. Offering them a copy at the time you distribute the binary is compatible with both. If they decline, your obligation to them is released. If you're selling the hard copies then you can probably afford to include a CD. I don't think there are affordable self-publishing deals that also include CD production, but I could be wrong. Keep in mind that it's not exactly challenging to represent (X)HTML and CSS on paper, given that they're plain text. (Granted, this would drive the page count and corresponding cost up. But it's not *challenging*.) This argument holds less water for binary document source formats. -- G. Branden Robinson| I came, I saw, she conquered. Debian GNU/Linux | The original Latin seems to have [EMAIL PROTECTED] | been garbled. http://people.debian.org/~branden/ | -- Robert Heinlein signature.asc Description: Digital signature
Re: GPL-compatible, copyleft documentation license
On Mon, Jul 19, 2004 at 10:50:35PM -0500, Branden Robinson wrote: Well, I used to think that myself, until Steve Langasek and Henning Makholm argued me to exhaustion. :) Debian interprets this License and herein to mean the conditions of the GNU GPL expressed in its text; no more and no less. We interpreted the PHP-Nuke author's additional restriction as just that, with the consequences you'd expect from the above. In our assessment, PHP-Nuke isn't licensed to the public at all (as far as we can tell), and we cannot distribute it -- even in our non-free archive.[1] If you really feel you're right about this, I invite you to take up Henning's and Steve's challenge. I don't think we need to come to a strong agreement on this, anyway. A copyright holder can certainly take the GPL, modify its text directly (instead of patching it out-of-line with riders), and use the result, as long as he removes the preamble (in order to comply with the GPL's metalicense). The significance is simply that it's clearly possible (to my understanding of the terms governing modifications to the GPL) to use the GPL with modified terms, even if riders aren't a good way of doing so, which changes the result from you can't do that to you're doing it wrong. Modifying the license in this way would help avoid the confusion typically associated with GPL + extra-restrictive riders, too. (I also still suspect that distributing a work under the GPL with additional restrictions, linked against LGPL works such as glibc, would be in violation of the former license. If my interpretation is correct, this would probably render Hydra undistributable, even in non-free.) -- Glenn Maynard
Re: Re: Re: Bug#227159: ocaml: Worse, the QPL is not DFSG-free
On Tue, Jul 20, 2004 at 05:16:19AM +0200, Sven Luther wrote: No response yet to my reasonable thread, i wonder if it was the good way to go finally. I'll speak up and say that your new thread appears to be fairly inclusive of several points of concern in the QPL. I imagine that nobody has responded yet (at least in part) because reasoned arguments take time to address an appropriately reasoned reply. It's much easier and quicker to respond to knee-jerk reactions. I, for one, am planning on responding to your summary with my arguments. Please do not take an hour or two of silence as being either (a) consensus, or (b) wilful dismissal. - Matt
Re: Summary : ocaml, QPL and the DFSG.
On Tue, Jul 20, 2004 at 04:06:22AM +0200, Sven Luther wrote: The reproach which is being done is twofold : 1) 6c of the QPL. I believe there has been some serious misunderstanding on all parts about this clause in almost all posts previous to this. Let's quote the whole of section 6). 6. 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: a. You must ensure that all recipients of machine-executable forms of these items are also able to receive and use the complete machine-readable source code to the items without any charge beyond the costs of data transfer. b. You must explicitly license all recipients of your items to use and re-distribute original and modified versions of the items in both machine-executable and source code forms. The recipients must be able to do so without any charges whatsoever, and they must be able to re-distribute to anyone they choose. I have no problems with either of these clauses. They form a nice copyleft. 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. Well, i have some feeling that this is a clause directly targeted to try to void the GPL incompatibility, at least point a nd b, i will come to c later on. Notice, and this is the point we have missed previously, that this doesn't even remotely apply to modified versions of the software, which are mentioned earlier, and where not subject to DFSG-doubt. If you're talking about the fact that the software is linked, I think you're out of luck, but I'll talk about that later. Now, the clause which causes problem is the 6c, which states that upstream might also want to get those works linked with the software. I understand that this may be considered non-free, but let's go over the DFSG points one by one, and not start with discutable chinese disident or desert island stuff which only muddy the water. DFSG 1) it was claimed that giving the linked items back to upstream on request is considered a fee, which may invalidate this licence. How much of this claim is realistic, and does it constitute a fee ? After all, you lose nothing if you give it to upstream, so it doesn't cost you. DFSG 2) and 3) Obviously fine given 6a and 6b. I believe that DFSG #3 disallows compelled distribution of derived works to the original author. To whit: DFSG #3: 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. The licence of the original software was must distribute (changed|linked)[1] versions to O. Author. Now, does the licence of the modifications Q say must distribute changes (of the modifications) to O. Author or must distribute changes (of the modifications) to J. Modifier? If the former, then J. Modifier, the author of the modification Q, is being denied options that original author had, which is a DFSG #5 problem, and if the licence is the latter, it fails DFSG #3 because the licence is not the same as the original. DFSG 9) Well, since there is only mention of link-time restriction, and none whatsoever on distribution media. More on this below. Even if it does indeed constitute a royalty, notice that QPL 6) mentions : 6. You may develop application programs, reusable components and other software items that link with ... So my understanding is that this only applies with the stuff that links to the QPL covered work. Which would mean that the QPL covered work is a library. Right, here is where we start to disagree violently. Firstly, what exactly is meant by linking? I'd say the inclusion (by inclusion or reference) of some (typically) object code into an executable for the purpose of future execution. If the original code is entirely contained within A.o, and I make various modifications to A.c (producing A'.c) and recompile (producing A'.o), my modifications are essentially linked with various parts of the original A.o to produce A'.o. Hence, essentially every modification I make is a linked work, especially considering that the QPL only allows patch distribution. To make a clearer example, consider an original work with A.c and B.c. If I create a C.c, which replaces B.c, my modifications are very definitely linking with A.o when I compile. Seriously, the only force distribution of linked code argument is not going to fly. To attack the problem from an entirely different perspective, I think we need to revisit the question of does linking qualify as creating a derivative work?. I don't want to really try and answer the question, and I don't think it matters in this case, but here are the options: 1)
Re: Bug#227159: ocaml: Worse, the QPL is not DFSG-free
On Tue, Jul 20, 2004 at 12:48:35AM -0400, Brian Thomas Sniffen wrote: Err, have you read the GPL licence recently ? If it is not specifically into every detail, i dont' know what is. There is specific text about binding and such, and it makes explicit mentions of distribution of a work linked with the GPLed work. There is not one mention of link in the GNU GPL. There is not one mention of bind or bound. I don't think you're even bothering to make up consistent nonsense at this point. But is is supposed to mean the same thing though. There is this issue, though: it doesn't matter if I break up the .el files in question into two apparently random bitstrings, send them separately to the target machine, XOR them back together there, and then compile them. What matters is that I've built a complicated machine for putting a compiled file linked with the internal Emacs API on that system, and so infringed the copyright of the Free Software Foundation unless I'm doing so within the bounds set by the GPL. Which is why i am removing them from the binary packages until upstream changes his mind. Friendly, Sven Luther
Re: Re: Re: Bug#227159: ocaml: Worse, the QPL is not DFSG-free
On Mon, Jul 19, 2004 at 10:24:03PM -0700, Steve Langasek wrote: On Tue, Jul 20, 2004 at 05:52:52AM +0200, Sven Luther wrote: the ultimate conclusion is that the QPL is not free, any time you've spent trying to delay examination of this license can only hurt ocaml's chances of remaining in the archive. Well, did i try to delay examination ? I posted with my doubts about the first summary conclusion, and was ignored. This hardly seams like a delaying tactic on my part. It is my impression that your comments are intended to discourage this discussion from taking place before sarge's release. Nope, just the expression of my fear that this will happen in a way that let me no choice but to remove it from sarge, due to time constraints. I also contacted upstream, let's see what he will say to it, i doubt it will be positive though. I hope it may be; but if not, I hope we can at least have a productive discussion with upstream about these concerns over the license -- more productive than this in-house discussion seems to have been so far. Well, let's see if they respond to me, not entirely sure in these days of french vacations though. Friendly, Sven Luther
Re: your mail
On Mon, Jul 19, 2004 at 10:31:02PM -0800, D. Starner wrote: Also, in any sane legal system, it should only affect those users who willingly violate the licence, even after a cease-and-desist letter, and i would say they deserve what they get. In any sane legal system, the judge is going to find out what's going on from both sides before he even considers dismissing the case. That Ok, but we are in the case where the defendor is innocent, right ? means that the user has to hire a French lawyer to write a response to the statement of cause. Unless the judges are omniscient, that's what has to happen. What exactly is stopping him from hiring a local lawyer to write the statement and sent it per letter to the judge, and how will it differ from the case where the court of venue is local to him ? The choice of law is the french law in both case. And let's be honest; a court case may look obvious to us, but few judges have ever had a case where an open-sourceish license is Well, but a tentative to repeteadly harass using lawsuits will probably not be missed by a judge. involved, and not many more are familiar with programming and the free software community. The judge may need some time to get up to speed. Well, it may be, but upstream has to frame the accusation, and you get at least a chance to send a letter defending yourself before it goes in full motion. In the ocaml case, the upstream authors being a small team of 6-10 people from the academic world, and wanting to be as unbothered as possible in all these issues, also may fear the violation of the ocaml licence by entities such as sun or microsoft, which would gain from the ocaml technology in both java and C#, I understand they fear the use of OCaml code in any non-functional programming system, Free or not. In any case, neither Sun or Microsoft is probably going to want to copy code from OCaml; they want to copy ideas. And that is not protected by copyright law. Point taken. fear that a court of venue in the US may render any chance of getting justice void, given the money governed US legal system. Somehow, I am left unconcerned by the irrational fears of bigots. I'm Well, is it or is it not so ? In all the software lawsuits i hear about, including those music-industry against teenage childs, the amount of money available plays an immediate role in the possibility to defend oneself. If that is not so, its their own fault they publicize it in that way. sure Americans could equally rational worry that a court of venue in France may render any chance of getting justice void, giving the fact they are Americans. I doubt the USians leaving in france would feel the same though. Friendly, Sven Luther
Re: Summary : ocaml, QPL and the DFSG.
On Tue, Jul 20, 2004 at 03:31:34PM +1000, Matthew Palmer wrote: On Tue, Jul 20, 2004 at 04:06:22AM +0200, Sven Luther wrote: The reproach which is being done is twofold : 1) 6c of the QPL. I believe there has been some serious misunderstanding on all parts about this clause in almost all posts previous to this. Let's quote the whole of section 6). 6. 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: a. You must ensure that all recipients of machine-executable forms of these items are also able to receive and use the complete machine-readable source code to the items without any charge beyond the costs of data transfer. b. You must explicitly license all recipients of your items to use and re-distribute original and modified versions of the items in both machine-executable and source code forms. The recipients must be able to do so without any charges whatsoever, and they must be able to re-distribute to anyone they choose. I have no problems with either of these clauses. They form a nice copyleft. Indeed. 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. Well, i have some feeling that this is a clause directly targeted to try to void the GPL incompatibility, at least point a nd b, i will come to c later on. Notice, and this is the point we have missed previously, that this doesn't even remotely apply to modified versions of the software, which are mentioned earlier, and where not subject to DFSG-doubt. If you're talking about the fact that the software is linked, I think you're out of luck, but I'll talk about that later. Well, the link is mentioned in the main 6 part, so ... It clearly means that it doesn't mention the original piece of work, or modifications thereof, which are covered by the clause 3 and 4. And it doesn't mention piece of software merely agregated with the work on the same media or such. But more to this below. Now, the clause which causes problem is the 6c, which states that upstream might also want to get those works linked with the software. I understand that this may be considered non-free, but let's go over the DFSG points one by one, and not start with discutable chinese disident or desert island stuff which only muddy the water. DFSG 1) it was claimed that giving the linked items back to upstream on request is considered a fee, which may invalidate this licence. How much of this claim is realistic, and does it constitute a fee ? After all, you lose nothing if you give it to upstream, so it doesn't cost you. DFSG 2) and 3) Obviously fine given 6a and 6b. I believe that DFSG #3 disallows compelled distribution of derived works to the original author. To whit: DFSG #3: 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. Well, what is stopping you from licencing it back to the author under the QPL ? The licence of the original software was must distribute (changed|linked)[1] versions to O. Author. Now, does the licence of the modifications Q say must distribute changes (of the modifications) to O. Author or must distribute changes (of the modifications) to J. Modifier? If the former, then J. Modifier, the author of the modification Q, is being denied options that original author had, which is a DFSG #5 problem, and if the licence is the latter, it fails DFSG #3 because the licence is not the same as the original. Well, compare it to the GPL ? The original authour had the choice of of using whatever licence he wanted, but a work linked with the GPLed software has no choice but to be the GPL (or some minor derivative). DFSG 9) Well, since there is only mention of link-time restriction, and none whatsoever on distribution media. More on this below. Let's quote DFSG 9) for clarity : 9 License Must Not Contaminate Other Software The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software. Even if it does indeed constitute a royalty, notice that QPL 6) mentions : 6. You may develop application programs, reusable components and other software items that link with ... So my understanding is that this only applies with the stuff that links to the QPL covered work. Which would mean that the QPL covered work is a library. Right, here is where we start to disagree violently. Firstly,
Re: your mail
On Tue, Jul 20, 2004 at 10:16:12AM +0200, Sven Luther wrote: On Mon, Jul 19, 2004 at 10:31:02PM -0800, D. Starner wrote: Also, in any sane legal system, it should only affect those users who willingly violate the licence, even after a cease-and-desist letter, and i would say they deserve what they get. In any sane legal system, the judge is going to find out what's going on from both sides before he even considers dismissing the case. That Ok, but we are in the case where the defendor is innocent, right ? So? The cost of defending against the suit is still considerable. And there is no guarantee of being awarded costs even for a frivolous lawsuit, let alone collecting. means that the user has to hire a French lawyer to write a response to the statement of cause. Unless the judges are omniscient, that's what has to happen. What exactly is stopping him from hiring a local lawyer to write the statement and sent it per letter to the judge, and how will it differ from the case where the court of venue is local to him ? The choice of law is the french law in both case. It's still very costly. Here's an example from the US: http://mainsleazespam.com/law/ema.html Whilst this is America, home of the bullshit lawsuit, I contend that something substantively similar could happen basically anywhere. It happened in Australia, too, again around the issue of spam, and I think there's been a similar case or two in Europe somewhere. And let's be honest; a court case may look obvious to us, but few judges have ever had a case where an open-sourceish license is Well, but a tentative to repeteadly harass using lawsuits will probably not be missed by a judge. s/tentative/tendency/? Possibly not, but it's not hard to identify this sort of thing if the suits don't come before the same judge. - Matt
Re: your mail
On Tue, Jul 20, 2004 at 07:16:22PM +1000, Matthew Palmer wrote: On Tue, Jul 20, 2004 at 10:16:12AM +0200, Sven Luther wrote: On Mon, Jul 19, 2004 at 10:31:02PM -0800, D. Starner wrote: Also, in any sane legal system, it should only affect those users who willingly violate the licence, even after a cease-and-desist letter, and i would say they deserve what they get. In any sane legal system, the judge is going to find out what's going on from both sides before he even considers dismissing the case. That Ok, but we are in the case where the defendor is innocent, right ? So? The cost of defending against the suit is still considerable. And there is no guarantee of being awarded costs even for a frivolous lawsuit, let alone collecting. Well, the cost would be mostly the same, but i answered that elsewhere to you. means that the user has to hire a French lawyer to write a response to the statement of cause. Unless the judges are omniscient, that's what has to happen. What exactly is stopping him from hiring a local lawyer to write the statement and sent it per letter to the judge, and how will it differ from the case where the court of venue is local to him ? The choice of law is the french law in both case. It's still very costly. Here's an example from the US: http://mainsleazespam.com/law/ema.html Yeah, but cost in the US and cost elsewhere may not be comparable. And we have free legal counsel here. And an instruction judge, which mean that you have to somehow convince the judge of the legalities of your claim before the lawsuit starts. This would not be the case in the US, i think. Whilst this is America, home of the bullshit lawsuit, I contend that something substantively similar could happen basically anywhere. It happened in Australia, too, again around the issue of spam, and I think there's been a similar case or two in Europe somewhere. Well, the law of australia and US are mostly similar, are they not ? And let's be honest; a court case may look obvious to us, but few judges have ever had a case where an open-sourceish license is Well, but a tentative to repeteadly harass using lawsuits will probably not be missed by a judge. s/tentative/tendency/? Possibly not, but it's not hard to identify this sort of thing if the suits don't come before the same judge. No, a try would be more like it ? Also, since the defendor has at least the chance of an initial reply, he could very well mention other suits, or tries of suits, and i thougt there were something about a suit once tried or dismissed, you cannot simply go to another judge and try again. Friendly, Sven Luther
Re: GPL-compatible, copyleft documentation license
On 2004-07-20 10:15:11 +0100 Florian Weimer [EMAIL PROTECTED] wrote: So you suggest that if someone approaches Debian and asks his name to be removed, Debian would ignore this request even if it can be honored, practically speaking? I believe it should, if that mention of his name was essential to the accuracy of a work. It has nothing to do with moral rights. I believe we should honour a request not to be identified as the author of a work, but that CC clause goes far beyond that. -- 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: Summary : ocaml, QPL and the DFSG.
On 2004-07-20 03:06:22 +0100 Sven Luther [EMAIL PROTECTED] wrote: DFSG 1) it was claimed that giving the linked items back to upstream on request is considered a fee, which may invalidate this licence. How much of this claim is realistic, and does it constitute a fee ? After all, you lose nothing if you give it to upstream, so it doesn't cost you. You lose your control over the work, if you are obliged to license it freely or give it to upstream. 6b kicks in, requiring us to license it freely to them. This seems particularly ironic, as author control over the work is often given as a motive for using the QPL, which is something they seem to be denying other authors. I'm still thinking whether this is clearly a fee, but I'm not sure why you claim it would invalidate the licence. So my understanding is that this only applies with the stuff that links to the QPL covered work. Which would mean that the QPL covered work is a library. When I read this bit first of all, I thought wow, elegant hack. Sadly, it doesn't work, as it limits permitted modifications, because we could never make a QPL'd part of ocaml into a library. I think most -legal readers get upset about that not satisfying DFSG 3. Now, if the LGPL is applied to all ocaml libraries, including modified ocamls present and future, we have an elegant hack to remove the QPL from ocaml. ;-) Also, this applies to stuff not covered by the licence that links with it. Is this contamination of other software? (Compare DFSG 9) I will go over the DFSG points in a while, but let's first mention another point. Altough the Social contract places our priorities at our users and free software, where do the upstream author enter in consideration ? The upstream authors without with debian would hardly exist. If you feel the SC inadequately protects upstream authors, then maybe you want to change the SC. [...] may fear the violation of the ocaml licence by entities such as sun or microsoft, which would gain from the ocaml technology in both java and C#, and fear that a court of venue in the US may render any chance of getting justice void, given the money governed US legal system. [...] AIUI, they could sue the French arms of Sun or Microsoft and keep the venue in France, even without this clause. I hope they have a more realistic motivation. Well, nothing in the DFSG makes mention of this kind of legal problems, so we can hardly claim that this would make it DFSG-non-free, even though we may have more or less justified to think so. My current thought is that it is a DFSG 1 problem, resticting free redistribution, but I'm still listening. -- 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: arbitrary termination clauses (was: Choice of venue, was: GUADEC report)
Branden Robinson [EMAIL PROTECTED] wrote: On a more fundamental basis, abitrary termination clauses are odious and offensive to freedom because we are not free if we are just waiting for the hammer to fall. One of things you give up when you decide to share your work with the FLOSS community is your right to act as a tyrant, yanking people's licenses away from them in a fit of pique. I think I'm inclined to buy this argument, though I'm unconvinced that it actually makes any significant amount of difference to any users in the current climate. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Summary : ocaml, QPL and the DFSG.
Sven Luther [EMAIL PROTECTED]: The reproach which is being done is twofold : Perhaps two separate threads would be justified. I'm only replying on the first reproach. 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. Now, the clause which causes problem is the 6c, which states that upstream might also want to get those works linked with the software. I understand that this may be considered non-free, but let's go over the DFSG points one by one, and not start with discutable chinese disident or desert island stuff which only muddy the water. As I see it 6c is a serious privacy problem. Perhaps the requirement for privacy is not directly implied by any of DFSG, but I can't imagine people being very happy with the requirement to let the initial developers know how the software is being used. Do you think upstream really need this clause?
Re: Summary : ocaml, QPL and the DFSG.
* Sven Luther [EMAIL PROTECTED] [040720 04:06]: DFSG 1) it was claimed that giving the linked items back to upstream on request is considered a fee, which may invalidate this licence. How much of this claim is realistic, and does it constitute a fee ? After all, you lose nothing if you give it to upstream, so it doesn't cost you. Wow, this is quite a strong assertion. Especially after many people describes situations where it cost you and/or brings you in risk of costs. DFSG 5) and 6) it was claimed that one of those is broken by the desert island or chinese dissident tests, i have seen no consensus as a quick overview of the thread prior to my involvement shows. I personally dispute those claims as not only irrealistic, but also as not applying here, since the request should be done nominally. What do you mean by nominally? That when I'm initial deleveloper and want to stop someone on an desert island from using my software, I have to know his name before? Or give an evil goverment a reguest they shall under my name place each residents name on it and give it to him? For DFSG 5: What about the group of people that is in countries that impose an embargo or export restrictions on countries the initial developer is in. Consider something like a ssl-library was under this licence in the times where those were more strictly handled and the initial developer was outside the USA. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Summary : ocaml, QPL and the DFSG.
* Matthew Garrett [EMAIL PROTECTED] [040720 13:54]: The QPL is bad news in yet another way. Do we need a DFSG basis for forces people to break the law? Mm. It forces people to break the law if they exercise certain freedoms. China requires (used to require?) licensing of imported cryptography software. If it were GPLed, distributing modified versions would be illegal under copyright law (you couldn't actually satisfy the GPL's requirements) and if the recipient didn't have a license, under anti-crypto laws. Israel used to have similar provisions. It's an interesting question. How prevelant does a law have to be before we believe that being obliged to break it becomes non-free? I think that should not be a question of prevalence, but wether the law allows free software. In a world where everything was free software, and noone would wanted to give any piece of software to anyone else without giving the source code and does not forbid to use, modify and so forth, would any group be or person or field of endeavor be discriminated, i.e. no longer be able to exercise those rights because restrictions in the licence make it impossible to comply? Personally, I'd be inclined to say that countries that limit exports of technology are broken and we should treat them as if they don't exist, even though the UK is one of them. Maybe I should make more use of my Irish citizenship. We may ignore the countries, but are we allowed to ignore the users within it? Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Summary : ocaml, QPL and the DFSG.
On Tue, Jul 20, 2004 at 12:35:49PM +0100, Matthew Garrett wrote: Matthew Palmer [EMAIL PROTECTED] wrote: The QPL is bad news in yet another way. Do we need a DFSG basis for forces people to break the law? Mm. It forces people to break the law if they exercise certain freedoms. China requires (used to require?) licensing of imported cryptography software. If it were GPLed, distributing modified versions would be illegal under copyright law (you couldn't actually satisfy the GPL's requirements) and if the recipient didn't have a license, under anti-crypto laws. Israel used to have similar provisions. This is a slightly different problem to that of a local law which says you can't do that. I'm not distributing prohibited technology to an embargoed location by choice. I never thought hmm, wouldn't it be cool if I sent this to Iran. Instead, the terms of the licence are forcing me to do that. Even worse, there may have been no way I could have known I would later have to break the law at the time I accepted the licence (by distributing my modifications). The author could previously have been in a friendly country, but happen to be in Iran when they request my libraries. I have no way of knowing that my compliance with the licence will some day require me to break the law. It's a downright hideous licence term, and a pretty damn good argument for why forced unrelated distribution is a bad thing. I'd be inclined to say that countries that limit exports of technology are broken and we should treat them as if they don't exist, even though But it's really dangerous to do so. Allowing such a licence into Debian could result in our users to fall foul of situations just like these. - Matt
Re: GPL-compatible, copyleft documentation license
Florian Weimer wrote: How? As MJ said, it's clearly practical to remove the author's name in places where it would nevertheless be a grievous restriction. So you suggest that if someone approaches Debian and asks his name to be removed, Debian would ignore this request even if it can be honored, practically speaking? I think this clause mainly deals with something Debian does anyway, as a mrere courtesy. I believe that was the intent. As stated, though, it could be abused; it doesn't restrict the erasing to just authorship credit. The classic example here is an autobiographical work. The author could ask that all references to herself be removed from a derivative work critical of her. In software documentation, an original author could require that changelogs or discussion of differences in design or implementation (Original Author had it this way; the new version does it this other way) be removed. ~ESP
Re: Choice of venue, was: GUADEC report
Branden Robinson writes: On Wed, Jul 14, 2004 at 12:01:22PM +0100, Matthew Garrett wrote: I'm certainly not clear that the new SC gives any leeway to use tests that don't spring directly from the DFSG. Put that way, it doesn't give us any leeway to use tests at all. In any event, I laid out my approach to upholding the Social Contract in this respect a while back[1]. Feel free to take it apart now, since you didn't at the time. OK, I'll take a crack at it. If you're going to treat debian-legal discussions as case law, where's the delegation by the rest of Debian to give you the rights to make decisions and set precedent? That's a big problem that's been coming up more and more often in recent licensing discussions. The DDs have all agreed to the DFSG, but not necessarily to whatever interpretations the debian-legal debaters can come to based on the DFSG. And some of the interpretations have been getting pretty damn loose lately... -- 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
Don Armstrong writes: On Mon, 19 Jul 2004, Matthew Garrett wrote: 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. 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. This word discriminate - I don't think it means what you think it means. 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. If other circumstances created by local law or coincidence are causing difficulties, then why is that a license problem? -- 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 01:53:53PM +0100, Steve McIntyre wrote: This word discriminate - I don't think it means what you think it means. 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. If other circumstances created by local law or coincidence are causing difficulties, then why is that a license problem? 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. While licenses that don't require this are perhaps more free I don't feel that they fail the DFSG. - David Nusinow
Re: Termination clauses, was: Choice of venue
On Mon, Jul 19, 2004 at 10:34:08PM -0400, Brian Thomas Sniffen wrote: David Nusinow [EMAIL PROTECTED] writes: But the cost of disclosure of the sources to downstream recipients is also a fee imposed by the upstream author simply by choosing the GPL or QPL. That only comes automatically with the QPL; with the GPL, I can work in a small group with no risk that it will be spread more widely. Perhaps I replied too soon. On second thought, the problematic clause in the QPL that you're referring to is 6c: 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. I said in my first reply that this discriminates against those whose field of endeavor is private study. First, I think the spirit of DFSG 5 and 6, as provided by the examples of business or genetic research, is meant to prevent more explicit discrimination. 6c only applies to modifications which have been distributed, so the private study endeavor does not apply. So back to the small group. From the wording of the license, I can't clearly see whether or not one can distribute the software within a company (since you is not defined within the document) and still have it considered as having been distributed (if you applies to a corporate entity, and the software is kept within the corporation, is it distributed?) This issue appears with the GPL as well, and the boundary is not entirely defined. I still see conflict between what we accept with the GPL and appear to fail to accept with the QPL. Finally, the spirit of the QPL, as from their annotated license[1] appears to be very much in favor of Free software. Section 6c's annotation states: This is to avoid problems with companies that try to hide the source. If we get to know about it we want to be able to get hold of the code even if we are not users. In this way, if somebody tries to cheat and we get to know we can release the code to the public. Not only can they release the code to the public, but they must release it should they choose to use it, according to section 3a. I would argue that while this license may fail corner cases of DFSG 5 or 6 (and I'm not sure it does) it certaintly does appear that the author's intentions are to remain Free. I have heard repeatedly that the developer's intentions are taken in to account when evaluating packages, and we seem to have some clear indication here that the goal of the QPL is to keep modifications open to the community. - David Nusinow [1] http://www.trolltech.com/licenses/qpl-annotated.html
Re: DRAFT: debian-legal summary of the QPL
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. 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 nominalness 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. Friendly, Sven Luther
Re: Summary : ocaml, QPL and the DFSG.
I'll get to the other two in a bit, but for now: you completely failed to address the non-freeness of 3b: b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer. which allows the initial developer to take code I've written and distribute it in proprietary ways, even though I don't get that privilege with respect to his code. Why are you justifying INRIA's code hoarding in this way? -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Summary : ocaml, QPL and the DFSG.
Matthew Palmer [EMAIL PROTECTED] writes: This is a slightly different problem to that of a local law which says you can't do that. I'm not distributing prohibited technology to an embargoed location by choice. I never thought hmm, wouldn't it be cool if I sent this to Iran. Instead, the terms of the licence are forcing me to do that. Almost -- they force you to do that if you modify and distribute. So you don't have freedom with respect to the software, because you can't modify and distribute without the license urging you to potentially break the law. I have no way of knowing that my compliance with the licence will some day require me to break the law. It's a downright hideous licence term, and a pretty damn good argument for why forced unrelated distribution is a bad thing. That it is. Thanks for pulling it out as a clean example. -Brian -- Brian Sniffen [EMAIL PROTECTED]
i was thinking..
qwhzvotrhlmltvfzybfytcllamoveacjwuuccaazxryzhlnejybqazsdgfrescoes Need a little spice in your life? having problems with your male parts? Wana go for days? Keep the wife at home happy. Be happy. I keep it hard here www.hardandbetter.com namqxysuyvkrtqugisctxugifdrylkuhjgfrxlkuojczmktwtvumqyrdbmhypoactivesimilaracquisitionaniseikonictiny
Re: Summary : ocaml, QPL and the DFSG.
Matthew Palmer [EMAIL PROTECTED] wrote: This is a slightly different problem to that of a local law which says you can't do that. I'm not distributing prohibited technology to an embargoed location by choice. I never thought hmm, wouldn't it be cool if I sent this to Iran. Instead, the terms of the licence are forcing me to do that. Even worse, there may have been no way I could have known I would later have to break the law at the time I accepted the licence (by distributing my modifications). The author could previously have been in a friendly country, but happen to be in Iran when they request my libraries. Distribution under GPL 3b has the same problem, of course. It's an interesting issue. The QPL doesn't actually compel it, though, so it has little influence on that specific license. To be honest, I'd expect that the given example wouldn't be a problem - aren't license terms that would compel illegal behaviour generally held unenforcable? You'd lose the right to distribute further modifications after becoming aware that it would be illegal, but... I have no way of knowing that my compliance with the licence will some day require me to break the law. It's a downright hideous licence term, and a pretty damn good argument for why forced unrelated distribution is a bad thing. It's only an argument against forced distribution to given parties is a problem. I'd be inclined to say that countries that limit exports of technology are broken and we should treat them as if they don't exist, even though But it's really dangerous to do so. Allowing such a licence into Debian could result in our users to fall foul of situations just like these. Really that's a user education problem. People should be told what the risks are (This software may contain patents that you do not hold a license to, for instance) and spend some time thinking about them before exercising any of the freedoms we provide. -- Matthew Garrett | [EMAIL PROTECTED]
More questions about the QPL for a compiler
My understanding of the Ocaml compiler is that it emits part of itself into its output. Not all of itself, not even most of itself, but a noticeable and copyrightable part. I know this is the case for most compilers, and see no reason it wouldn't be for Ocaml as well. Now I look again at QPL 6: 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... And I wonder about executables compiled by the QPL'd Ocaml compilers. Are they application programs that link with versions of the Software? It sure sounds like it. I doubt INRIA intended the license to be read that way. But saying, this is free because they didn't really mean what they wrote, doesn't seem a good route. Under this interpretation, does this fail DFSG 9? Or is it no worse than the case of Emacs, where .elc files must be distributed under the terms of the GPL? -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Bug#227159: ocaml: Worse, the QPL is not DFSG-free
Sven Luther [EMAIL PROTECTED] writes: On Tue, Jul 20, 2004 at 09:19:40AM +1000, Matthew Palmer wrote: On Tue, Jul 20, 2004 at 12:50:15AM +0200, Sven Luther wrote: On Mon, Jul 19, 2004 at 06:01:50PM -0400, Glenn Maynard wrote: On Mon, Jul 19, 2004 at 11:27:05PM +0200, [EMAIL PROTECTED] wrote: Geez. 1) be able to take other people's modifications proprietary. That's fine for them, it's just non-free for us. Oh, ok. do we have a consensus on that ? could you point out why in clear points of the DFSG, and not some far fetched and controversed island paradise metahpors. Notice that the FSF doesn't seem toi think so, and it would make the BSD non-free, would it not ? I think there's a clear consensus that that's non-free, as it's a substantial cost imposed on those distributing modifications. It is a fee. Normally, I distribute my software under copyleft. If somebody wants to do something proprietary with it, they must pay me a lot of money. INRIA wants to pay my instead with a license to distribute modifications to their software. Clearly, the license I'm giving them under QPL 3(b) is a fee. OR 2) Wants to be able to relicence OCaml to others under a proprietary licence for a fee, in order to fund further development. That's even finer, and can be done by either writing it all themselves (and hence having nobody else's licence to worry about), or getting copyright assignments or totally-permissive grants from everyone whose contributions they incorporate into OCaml. Well, sure. or maintaining a dual tree, which is a pain. Remember, the ocaml team is at best 6 or so people, without legal advisories (i was told some year back that the INRIA legal council is a joke with regard to that kind of stuff). They need not maintain a dual tree -- just not integrate into their tree work which they don't have the license to use as they wish. That means they probably don't get my modifications, because I will only give my modifications to INRIA under a copyleft. Well, anyway, ... Ok, i will follow advice, and start a new thread. abotu this whole mess. 1) is non-free, no matter what licence they use. 2) doesn't require the QPL (which I feel is non-free for a variety of reasons). Ah, and the FSF strongly encouraging me to give them copyright of any contribution to an FSF project is not ? That's right. The FSF won't distribute your work unless you give them copyright. That's fine. They give you a free license to distribute your work -- modifications to their work -- as you please. That they also happen to want donations of money, time, and programs is not non-free. But was fine three years ago when they chose it, and this had some influence about their chosing of it. What thrust will they have in our decisions if we don't stand by it, especially as i am sure most people participating in this have not read previous threads about this issue ? And we thought their software had no RC bugs three years ago. What trust should we have in them to write releasable, bug-free code? There are bugs in licenses, just like bugs in code. Sometimes they take a while to find. How would you have reacted if someone came with a bug report out of nothing like Brian did, without pointing to this discussion, You already have mail from me -- now weeks old -- explaining that I wasn't aware of this discussion; I read the license file for ocaml before modifying it, and was horrified to see a clearly non-free license there. So I filed a bug. As a Debian user, I read the DFSG and expected I'd be able to exercise those rights with respect to Debian-shipped software. That I can't do so with respect to ocaml is a serious bug. If I'd treated that as free software and made the modifications I want, I'd have been put in a position of violating the QPL or violating other contracts. So, as it happens, I'm working with PLT Scheme, an LGPL'd compiler, instead. Niiice code, too. And Brian was not really tactfull either. Well, if i have been offensive and rude to an email which was constructive i apologize for it. for the rest, well i have been under Branden's english and discuss things in email school, so what do you expect. And any rude language i use here, i did learn on debian mailing lists. You are aware that Brian !== Brian? Brian Thomas Sniffen, your primary combatant in this thread, is not Brian M. Carlson, the author of the snippet you quoted above? Oh , well, i am really sorry about this. and i apologize to Brian about this confusion. shame on me for not noticing ... but then it is hard to notice such details after many hundred of emails. Of course. It's easy to get confused when facing so much traffic. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
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. 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 nominalness 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? -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: More questions about the QPL for a compiler
On Tue, Jul 20, 2004 at 12:59:35PM -0400, Brian Thomas Sniffen wrote: My understanding of the Ocaml compiler is that it emits part of itself into its output. Not all of itself, not even most of itself, but a noticeable and copyrightable part. I know this is the case for most compilers, and see no reason it wouldn't be for Ocaml as well. Now I look again at QPL 6: 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... And I wonder about executables compiled by the QPL'd Ocaml compilers. Are they application programs that link with versions of the Software? It sure sounds like it. I doubt INRIA intended the license to be read that way. But saying, this is free because they didn't really mean what they wrote, doesn't seem a good route. Under this interpretation, does this fail DFSG 9? Or is it no worse than the case of Emacs, where .elc files must be distributed under the terms of the GPL? Hello, Ocaml, as far as i know, is splitted in two differents sets of object files : - one set represents the compiler, this means the internal guts of the compiler, typing system et al - another set represents the standards library, stubs system ( foreign call ), VM et al The first set ( compiler ) is under QPL, the second set is under LGPL with Ocaml exception. This means, you can produce binary using LGPL ( with Ocaml exception ) only licenced ocaml objects... Regard Sylvain Le Gall
Re: DRAFT: debian-legal summary of the QPL
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. Even so, how does the unenforceability of a license justify ignoring the wishes of the author? -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: More questions about the QPL for a compiler
Sylvain LE GALL [EMAIL PROTECTED] writes: Ocaml, as far as i know, is splitted in two differents sets of object files : - one set represents the compiler, this means the internal guts of the compiler, typing system et al - another set represents the standards library, stubs system ( foreign call ), VM et al The first set ( compiler ) is under QPL, the second set is under LGPL with Ocaml exception. This means, you can produce binary using LGPL ( with Ocaml exception ) only licenced ocaml objects... Yes, I understand that the runtime library and such are LGPL'd. But the compiler, when it compiles a loop, for example, does it in a particular way. The patterns of assembly code output by the compiler -- not the parts in the library linked in, but the part actually written out by the compiler -- are part of the compiler. And they end up linked with my code. It's hard for me to believe that the compiler doesn't write any creative bits into its output -- though maybe there really has been effort to put those all into the runtime. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
On Tue, Jul 20, 2004 at 09:23:40AM -0400, David Nusinow wrote: On Tue, Jul 20, 2004 at 01:53:53PM +0100, Steve McIntyre wrote: This word discriminate - I don't think it means what you think it means. 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. If other circumstances created by local law or coincidence are causing difficulties, then why is that a license problem? 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 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. -- Glenn Maynard
Re: Re: Help about texture inclueded in stellarium
While a work may be in the public domain in the U.S., it may be under copyright elsewhere. So, e.g., while works by the U.S. government may be public domain in the U.S., they may remain under copyright in other countries. Damn. Did some more research, and you appear to be correct with respect to the most recent interpretations of the law. :-P The current interpretation of 17 USC Sect. 105 is that such works are copyright-controlled in countries which have copyright control over the works of their own governments. However, the U.S. government may license their works and thus give permissions with respect to these foreign copyrights. Traditionally, the US Government has not abused this foreign copyright opportunity, and has treated its works as public domain worldwide. Accordingly, it hasn't issued explicit licenses. See for example from the USGS website, on http://sfbay.wr.usgs.gov/access/copyright.html: USGS-authored or produced data and information are in the public domain. The current interpretation of 17 USC appears, frankly, to be another example of encroaching copyright where it doesn't belong. :-(
Re: More questions about the QPL for a compiler
Brian Thomas Sniffen [EMAIL PROTECTED]: Yes, I understand that the runtime library and such are LGPL'd. But the compiler, when it compiles a loop, for example, does it in a particular way. The patterns of assembly code output by the compiler -- not the parts in the library linked in, but the part actually written out by the compiler -- are part of the compiler. And they end up linked with my code. It's hard for me to believe that the compiler doesn't write any creative bits into its output -- though maybe there really has been effort to put those all into the runtime. Could you give an example of such a pattern in the binary output of any compiler that you think might require a copyright licence? I've seen some non-trivial patterns used for procedure prologues and epilogues, for example, but it's not the sort of thing people usually claim copyright for (they're not the expression of an idea), and typically the same patterns are used by different compilers and also by assembly-language programmers, so, if there is a problem, it's a very general one. Perhaps someone will claim to own the copyright for any code that stores the return address on a stack or uses a particular set of callee-save registers or a frame pointer or finds the lowest set bit in x by computing x ~(x - 1) ...
Re: Re: Help about texture inclueded in stellarium
On Tue, Jul 20, 2004 at 04:31:44PM -0400, Nathanael Nerode wrote: Damn. Did some more research, and you appear to be correct with respect to the most recent interpretations of the law. :-P The current interpretation of 17 USC Sect. 105 is that such works are copyright-controlled in countries which have copyright control over the works of their own governments. Also, public domain in the U.S. means that any U.S. citizen can assert copyright over such works (or derivatives). So we can GPL such works, for all the difference that makes. -- Raul
Re: Help about texture inclueded in stellarium
The international copyright treaties, if I am not mistaken, only grant copyrights to works which are capable of being subject to copyright in their 'home countries'. It's not that simple. The US, for one, recognizes copyrights on works under copyright under US law that aren't in copyright elsewhere. I believe it's merely an option in those treaties whether or not you recognize such copyrights, and I don't believe that the US is the only nation that does. -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
Fwd: Abiword being removed from Debian/unstable?
Begin forwarded message: From: Dom Lachowicz Date: 20 July 2004 22:08:34 BST To: Andy Korvemaker, abiword-dev@abisource.com Subject: Re: Abiword being removed from Debian/unstable? I'm not sure if this is the reason or not, but please see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=258918 For the record, I've recently acquired the AbiWord trademarks and whatnot. I haven't had a chance to update the TM information on the website. To be expressly clear here for any Debian guys that read this message: Within reason, I don't care if you use AbiWord vs. AbiWord Personal. In fact, I'd prefer it if you used AbiWord. Within reason, I don't care if you use the official artwork or the personal artwork. In fact, I'd prefer it if you used the official artwork. I do begin to care if you use my trademarks to promote other products, or in ways that disparage my trademarks or products. If you forked AbiWord, you couldn't use the trademarks. But you're clearly not going to do that. The USPTO has more info and case law on this sort of thing. Debian and the other distros are clearly distributing AbiWord, and providing a beneficial service to the community. Even though Debian's version might have a few patches against our mainline branch, I don't believe it constitutes a fork. As such, I think that it is fine (if not preferable) for you guys to use the official name and artwork in your distribution. So, you have my blessing to call your AbiWord + patches AbiWord. You can use the official artwork too. Dom --- Andy Korvemaker wrote: I was checking whether a new version of Abiword was available in Unstable and decided to see what was holding the current Unstable version from moving into Testing (at http://packages.qa.debian.org/a/abiword.html). Clicking on the Check why link for why it's not there, it looks like Abiword is scheduled for removal from Sid. See http://bjorn.haxx.se/debian/testing.pl?package=abiword I'm not a Debian developer at all, so I'm not sure if this is a common occurence. But as a (relatively inexperienced) user it sounds like Abiword is being pulled for some reason. (I don't know how to find out what that reason is.) andy -- Andy Korvemaker __ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/
Re: Fwd: Abiword being removed from Debian/unstable?
[answerinng only the off-topic parts, for clarification from the release team:] On Tue, Jul 20, 2004 at 10:35:48PM +0100, Daniel Glassey wrote: --- Andy Korvemaker wrote: I was checking whether a new version of Abiword was available in Unstable and decided to see what was holding the current Unstable version from moving into Testing (at http://packages.qa.debian.org/a/abiword.html). Clicking on the Check why link for why it's not there, it looks like Abiword is scheduled for removal from Sid. See http://bjorn.haxx.se/debian/testing.pl?package=abiword I'm not a Debian developer at all, so I'm not sure if this is a common occurence. But as a (relatively inexperienced) user it sounds like Abiword is being pulled for some reason. (I don't know how to find out what that reason is.) You can find this information at http://ftp-master.debian.org/testing/hints. The reason for the removal request was not 258918, which is far too recent to have shown up on the release team's radar yet as a removal issue, but 241279, affecting a library that abiword depends on. An alternative resolution for 241279 has since been found that doesn't involve ripping out abiword and half the GNOME metapackages depending on it, so abiword is no longer in danger of removal. Please feel free to forward this information to Andy, as I don't appear to have his email address. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: More questions about the QPL for a compiler
On Tue, Jul 20, 2004 at 04:07:34PM -0400, Brian Thomas Sniffen wrote: Sylvain LE GALL [EMAIL PROTECTED] writes: Ocaml, as far as i know, is splitted in two differents sets of object files : - one set represents the compiler, this means the internal guts of the compiler, typing system et al - another set represents the standards library, stubs system ( foreign call ), VM et al The first set ( compiler ) is under QPL, the second set is under LGPL with Ocaml exception. This means, you can produce binary using LGPL ( with Ocaml exception ) only licenced ocaml objects... Yes, I understand that the runtime library and such are LGPL'd. But the compiler, when it compiles a loop, for example, does it in a particular way. The patterns of assembly code output by the compiler -- not the parts in the library linked in, but the part actually written out by the compiler -- are part of the compiler. And they end up linked with my code. It's hard for me to believe that the compiler doesn't write any creative bits into its output -- though maybe there really has been effort to put those all into the runtime. Well -- using your arguments, let me claim that every french book in the world fall under the copyright of Grammaire Francaise. I am not sure whom belongs this licence ( maybe Bled should be the good one )... In other word : the translation made by the compiler is a translation. The original idea which can be copyrighted comes from the code which are translated... No compiler produces automatic meaningfull code... Compilers are made to simplify the task of producing binary code, but they only mimics what human should have written for code. Compilers -- even the actual clever one -- doesn't have the skill to write loop code better than human... Compilers are just tool to manage complexity... There are not really clever -- and they don't produce copyrighted things ( or maybe they take contact by themselves with the patent office, to say : well, i have written a new loop, and this one is really good, could i copyright it ? ) This mail is ridiculous -- sorry, Regard Sylvain Le Gall ps : the Categorical Abstract Machine ( ie the CAM ) is clever, but it just interprets the code to have a good view of it, this is the main QPLed part of o CAM l
Re: More questions about the QPL for a compiler
On Tue, Jul 20, 2004 at 04:07:34PM -0400, Brian Thomas Sniffen wrote: Yes, I understand that the runtime library and such are LGPL'd. But the compiler, when it compiles a loop, for example, does it in a particular way. The patterns of assembly code output by the compiler -- not the parts in the library linked in, but the part actually written out by the compiler -- are part of the compiler. And they end up linked with my code. Unless there is far more to an OCaml compiler, I don't see a big difference between this issue and gcc. They both perform mechanical translations of data from one format to another. It's a fairly tricky and involved transformation, but giving the same code to the same compiler at two different times will result in an identical output -- which I have a vague recollection is one of the tests of creative work. - Matt
Re: DRAFT: debian-legal summary of the QPL
Glenn Maynard [EMAIL PROTECTED] wrote: 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 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. The most obvious examples (and presumably the sort of thing that was being held in mind when those clauses were written) are things like Not for commercial use, or the wide variety of fuckups in academic-only licensing[1]. [1] Today's excellence is a program that requires me to post a signed agreement to Brazil before I can even download the damn thing. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Termination clauses, was: Choice of venue
On Tue, Jul 20, 2004 at 12:40:57AM -0400, David Nusinow wrote: Finally, the spirit of the QPL, as from their annotated license[1] appears to be very much in favor of Free software. Section 6c's annotation states: This is to avoid problems with companies that try to hide the source. If we get to know about it we want to be able to get hold of the code even if we are not users. In this way, if somebody tries to cheat and we get to know we can release the code to the public. Not only can they release the code to the public, but they must release it should they choose to use it, according to section 3a. I would argue that while this license may fail corner cases of DFSG 5 or 6 (and I'm not sure it does) it certaintly does appear that the author's intentions are to remain Free. I have heard repeatedly that the developer's intentions are taken in to account when evaluating packages, and we seem to have some clear indication here that the goal of the QPL is to keep modifications open to the community. But we're not distributing anything from TrollTech under the QPL, are we? If that's the case, TrollTech's annotations aren't worth a hill of beans to us, because they aren't the licensor. What TrollTech thinks the licence means is very important in situtations where it's TrollTech's stuff were distributing, but in the cases at hand we need to look at what INRIA (OCaml) and the Cervisia developers (the two QPL-only packages I can recall) think of the QPL, which is likely to be different. - Matt
Re: Termination clauses, was: Choice of venue
On Tue, Jul 20, 2004 at 01:38:33PM -0400, David Nusinow wrote: On Tue, Jul 20, 2004 at 01:23:11PM -0400, Brian Thomas Sniffen wrote: It's that last bit which is non-free. If they did something like the FSF, and asked for copyright assignment, that would be free. If they did something like best practical, and warned that they would consider anything submitted to them by its author to include an implied BSD-ish license, that would be free. Any code submitted upstream to the author will have the QPL attached to it, and thus will not become hidden or proprietary should upstream choose to distribute it. Read 3b again. It states that the initial developer gets a special licence to sell my work to people under different licences, as well as release it under the QPL. It's hardly a stretch to work out a case where my modifications might be nominally released under the QPL, but not readily available, whilst it gets wide distribution under some proprietary licence. But when they make it a condition of the license, a fee I must pay in order to distribute modifications, then it is no longer free software. This brings us back full circle to the definition of a fee. I still contend that by forcing downstream distribution of source, the GPL imparts a fee of its own, and yet we accept that as free. I consider that to be a fee consistent with the expansion of Free Software. In order to distribute modified binaries, I have to licence my source to the recipient as well. That has clear freedom-enhancing properties (Now With Freesol, for added Freeness!) The QPL says I must give a carte-blanche licence to the initial developer of the work I modify. I don't see how that is enhancing Free Software. I don't particularly like to call it a fee as such, especially since DFSG #1 says fee for such sale, and we're not necessarily selling the work. But I cannot in good conscience say that just because the letter of the DFSG doesn't say it, that it's automatically Free. Especially in this case -- forcing me to licence my modifications to some special party specially. If we read DFSG #3 with an implied only in there -- must allow them to be distributed [only] under the same terms -- then forcing me to give a special licence to someone else is bad. My phrasing there is bad -- it makes it sound as though the DFSG then prohibits licences which say licence your modified version as you like, but hopefully you get the idea. - Matt
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
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: Summary : ocaml, QPL and the DFSG.
On Tue, Jul 20, 2004 at 11:54:24AM -0400, Brian Thomas Sniffen wrote: Matthew Palmer [EMAIL PROTECTED] writes: This is a slightly different problem to that of a local law which says you can't do that. I'm not distributing prohibited technology to an embargoed location by choice. I never thought hmm, wouldn't it be cool if I sent this to Iran. Instead, the terms of the licence are forcing me to do that. Almost -- they force you to do that if you modify and distribute. So you don't have freedom with respect to the software, because you can't modify and distribute without the license urging you to potentially break the law. I have no way of knowing that my compliance with the licence will some day require me to break the law. It's a downright hideous licence term, and a pretty damn good argument for why forced unrelated distribution is a bad thing. That it is. Thanks for pulling it out as a clean example. Having slept on it, I've decided that in the specific case of the QPL, this particular situation is not a problem for Debian, but ONLY because we can avoid the whole issue by making the items in question available to the general public (which we do). Unfortunately, since there's no clear definition of general public, I can't give this clause the all clear, since it might require providing availability to embargoed countries, or to people without computers(!), but if the author takes a reasonable view of general public (which is a bit of a nightmare to actually define without going nuts), I don't think we will have too much of a problem. We're taking a similar path with the GPL, anyway -- the non-freeness of 3b and 3c is OK because we're distributing under 3a. By analogy, the non-freeness of compelled unrelated distribution of linked items is OK(ish) because we're taking the publically available route. I'm still not comfortable with it, but I don't think it's the hairy bear trap it is, but only because of the rustiness of the springs. grin - Matt
Re: Summary : ocaml, QPL and the DFSG.
On Tue, Jul 20, 2004 at 05:33:21PM +0100, Matthew Garrett wrote: Matthew Palmer [EMAIL PROTECTED] wrote: To be honest, I'd expect that the given example wouldn't be a problem - aren't license terms that would compel illegal behaviour generally held unenforcable? Probably, but you're still working against the author's wishes in that circumstance. I'd rather a licence that didn't try and compel me to break the law in the first place. You'd lose the right to distribute further modifications after becoming aware that it would be illegal, but... Hey, it's an arbitrary termination clause! Just move to an embargoed country, and you can screw most of the western world! /sarcasm I have no way of knowing that my compliance with the licence will some day require me to break the law. It's a downright hideous licence term, and a pretty damn good argument for why forced unrelated distribution is a bad thing. It's only an argument against forced distribution to given parties is a problem. s/against/that/? Hence 'unrelated'. Defining who the 'given parties' are in any particular instance of forced unrelated distribution is useful, but the fact that, for some values of 'given parties', you might end up breaking the law, makes the clause very non-free. Luckily the QPL gives Debian a bit of an escape hatch, although I'm still not 100% sure it's enough, but see my previous missive to Brian for more on that. I'd be inclined to say that countries that limit exports of technology are broken and we should treat them as if they don't exist, even though But it's really dangerous to do so. Allowing such a licence into Debian could result in our users to fall foul of situations just like these. Really that's a user education problem. People should be told what the risks are (This software may contain patents that you do not hold a license to, for instance) and spend some time thinking about them before exercising any of the freedoms we provide. I thought the purpose of the DFSG and such were so that, for anything in main, you knew you could exercise all of the freedoms listed in the DFSG without fear of getting a summons. Now you're saying we're back to the before doing anything, read debian/copyright system? No thanks. Patents are a separate issue, and I wish you'd stop using them as a means of justifying other abuses of freedom. - Matt
Re: Summary : ocaml, QPL and the DFSG.
On Tue, Jul 20, 2004 at 01:58:36PM +0100, Steve McIntyre wrote: Matthew Palmer writes: On Tue, Jul 20, 2004 at 12:35:49PM +0100, Matthew Garrett wrote: I'd be inclined to say that countries that limit exports of technology are broken and we should treat them as if they don't exist, even though But it's really dangerous to do so. Allowing such a licence into Debian could result in our users to fall foul of situations just like these. If we really think this is a major problem (and I'm not arguing against you, BTW), then why not get this codified into the DFSG via a GR? Get everybody[*] to agree on this, then we won't have to have this argument over and over again. I think that this issue might be enough to get a change or two to the DFSG made. Compelled unrelated distribution and compelling the grant of a separate licence are both issues that I think need specific mention. The latter can probably be accomodated by a rewording of DFSG #3, but I think we're going to need a DFSG #11 for the former problem. People seem very leery of trying to update the DFSG, and it's not clear why. Several reasons that I've come up with: 1) A fuckup in wording could very easily see a lot of software thrown out or brought in. 2) The stability of the DFSG is a very major rock we stand on. As Sven Luther has mentioned, upstreams kind of rely on us not to go changing our minds every couple of weeks, and a change to the DFSG could see some pretty major upheavals. 3) To be thorough, after any DFSG change, we should check every package in the archive and throw anything out which doesn't comply with the new! shiny! DFSG. That's a lot of work. 4) Nobody's been real keen to do the work for it, considering that we've been quite happy in our little world. I welcome the new blood that appears to have cropped up on d-legal recently with these issues -- it's forced a re-evaluation of how we do business. And I think that carefully considered DFSG modifications may end up being how business is done in the future. - Matt
Re: Summary : ocaml, QPL and the DFSG.
Matthew Palmer writes: Having slept on it, I've decided that in the specific case of the QPL, this particular situation is not a problem for Debian, but ONLY because we can avoid the whole issue by making the items in question available to the general public (which we do). The QPL doesn't release you from the obligation to provide changes to the author if you have since stopped distributing the software (for whatever reason). That clause applies to *any* time at which the code is not available to the general public. It would be plausible for an SCO or Microsoft to demand that a Debian package maintainer provide a three-year-old version of a package because Debian users downloaded that modified version. [snip] We're taking a similar path with the GPL, anyway -- the non-freeness of 3b and 3c is OK because we're distributing under 3a. By analogy, the non-freeness of compelled unrelated distribution of linked items is OK(ish) because we're taking the publically available route. The GPL is qualitatively different because it bounds the time during which you must act to comply with the license: Either immediately, if you make the source code available at time of transfer, or for the next three years, if you only make the binary code available. The QPL obligations do not terminate. It may also be qualitatively different because the upstream author gets a symmetric license and cannot compel downstream modifiers to provide changes; but that is a different discussion. Michael Poole
Re: Summary : ocaml, QPL and the DFSG.
On Wed, Jul 21, 2004 at 09:06:22AM +1000, Matthew Palmer wrote: Having slept on it, I've decided that in the specific case of the QPL, this particular situation is not a problem for Debian, but ONLY because we can avoid the whole issue by making the items in question available to the general public (which we do). Not being a problem for Debian only means that it can be legally distributed, not that it's DFSG-free. Unfortunately, since there's no clear definition of general public, I can't give this clause the all clear, since it might require providing availability to embargoed countries, or to people without computers(!), but if the author takes a reasonable view of general public (which is a bit of a nightmare to actually define without going nuts), I don't think we will have too much of a problem. We're taking a similar path with the GPL, anyway -- the non-freeness of 3b and 3c is OK because we're distributing under 3a. How Debian distributes a work does not determine whether it's free or not. The non-freeness of 3b and 3c[1] is OK because 3a, alone, is sufficient to make the license DFSG-free; 3b and 3c are merely additional permissions on top of that, and additional permissions never make a license less free. (None of this is related to which options Debian actually exercises.) By analogy, the non-freeness of compelled unrelated distribution of linked items is OK(ish) because we're taking the publically available route. If we believed that it acceptable to require people to make modifications to the general public, then the situation might be comparable; but I believe that most of us, at least, do not. A workaround like this being acceptable for Debian's own use doesn't mean that it's free. [1] if any; I believe it is, but due to 3a, there hasn't been a need to come to a real consensus on this -- Glenn Maynard
Re: Summary : ocaml, QPL and the DFSG.
On Tue, Jul 20, 2004 at 07:44:58PM -0400, Michael Poole wrote: Matthew Palmer writes: Having slept on it, I've decided that in the specific case of the QPL, this particular situation is not a problem for Debian, but ONLY because we can avoid the whole issue by making the items in question available to the general public (which we do). The QPL doesn't release you from the obligation to provide changes to the author if you have since stopped distributing the software (for whatever reason). That clause applies to *any* time at which the code is not available to the general public. It would be plausible for an SCO or Microsoft to demand that a Debian package maintainer provide a three-year-old version of a package because Debian users downloaded that modified version. An excellent point, and well made. Thankyou for reminding me of this. My objection to this clause is re-established. [snip] We're taking a similar path with the GPL, anyway -- the non-freeness of 3b and 3c is OK because we're distributing under 3a. By analogy, the non-freeness of compelled unrelated distribution of linked items is OK(ish) because we're taking the publically available route. The GPL is qualitatively different because it bounds the time during which you must act to comply with the license: Either immediately, if you make the source code available at time of transfer, or for the next three years, if you only make the binary code available. The QPL obligations do not terminate. Ayup. I had these vague feelings that the GPL and QPL situations weren't entirely comparable; I think the timeframe issue was what it was (either that or the Quesadilla I had last night grin). It may also be qualitatively different because the upstream author gets a symmetric license and cannot compel downstream modifiers to provide changes; but that is a different discussion. I think you meant asymmetric, but yes, that is a different discussion. I tried to ensure that it was understood that my change in reasoning was only related to 6c; I still think that the asymmetric licence problem, as well as the choice of venue, are problematic. And, with your excellent reminder, I now think 6c is a problem again too. - Matt
Re: Summary : ocaml, QPL and the DFSG.
On Wed, Jul 21, 2004 at 09:19:51AM +1000, Matthew Palmer wrote: I think that this issue might be enough to get a change or two to the DFSG made. Compelled unrelated distribution and compelling the grant of a separate licence are both issues that I think need specific mention. The latter can probably be accomodated by a rewording of DFSG #3, but I think we're going to need a DFSG #11 for the former problem. Compelling unrelated distribution is a restriction on modification and/or distribution (depending on the license). That's certainly the usual rationale connecting this problem to the DFSG. DFSG#1 says may not restrict any party from selling or giving away the software ...; saying in order to distribute this, you must XXX is a restriction. Of course, XXX = you must distribute source, too is also a restriction. Again, guidelines. (If the complaint is that these guidelines can't be used without interaction with Debian and having the same result, then it's just a complaint that they're guidelines--this can't be fixed without turning it into something other than guidelines.) I don't see what's special about this particular restriction that doesn't apply to many other non-free restrictions as well. DFSG#1 and #3 could certainly mention this case specifically, eg. The license may not require distribution to the original author as a condition for distribution, but that would seem to imply that we also need to mention that requiring click- wrap before distributing isn't free, requiring that modifications adhere to some standard isn't free, and so on. (People are thinking up new ways to restrict freedom all the time.) (I don't really see a need for an entire new guideline, but it's the same whether it's a new guideline or a part of other guidelines.) In short, I don't see why this particular issue is special. It's one non-free requirement among multitudes. People seem very leery of trying to update the DFSG, and it's not clear why. Several reasons that I've come up with: 1) A fuckup in wording could very easily see a lot of software thrown out or brought in. 2) The stability of the DFSG is a very major rock we stand on. As Sven Luther has mentioned, upstreams kind of rely on us not to go changing our minds every couple of weeks, and a change to the DFSG could see some pretty major upheavals. 3) To be thorough, after any DFSG change, we should check every package in the archive and throw anything out which doesn't comply with the new! shiny! DFSG. That's a lot of work. 4) Nobody's been real keen to do the work for it, considering that we've been quite happy in our little world. 5) See the recent GR, modifying the SC. It was editorial; it wasn't intended to (and, in my opinion, did not) modify the meaning of the SC. It was certainly much more minor than adding a new guideline--and it still kicked up a huge amount of mud, resulting in another GR to put the changes on hold. The reasons for the mud flinging aren't relevant; the point is that any modifications to founding documents run a better than even chance of having unintended consequences. -- Glenn Maynard
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, 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
