Re: Affero General Public License
quote who=Jeremy Hankins date=Sun, Feb 12, 2006 at 01:52:53PM -0500 Benj. Mako Hill [EMAIL PROTECTED] writes: quote who=Jeremy Hankins date=Sat, Feb 11, 2006 at 10:34:48PM -0500 But the question of whether this is a use restriction or a modification restriction is an interesting one. I believe that it is an attempt to accomplish a restriction on use via a restriction on modification. The intent behind both the AGPL and GPLv3(7d) is fairly easy to summarize: don't offer this software as a service to others unless you also offer the source. Unfortunately, offering the software as a service to others is neither copying nor modification. So any attempt to put this restriction naturally into a license will be a use restriction (or possibly a public performance restriction). Under this logic, copyleft is also a use restriction. It bars proprietary use of free software. No, it doesn't. Proprietary use (i.e., use of private modifications) is very much permitted -- if it wasn't the ASP loophole wouldn't be an issue. In fact, licenses that don't permit private changes (e.g., through forced distribution) have been considered non-DFSG free in the past. What copyleft prevents is proprietary distribution of software. So, I think we agree that this is a modification restriction attempting to protect users freedom to modify and redistribute their software. But in the text I quoted originally we were talking about the *intent* of the license. You claimed that because the modification restriction *intended* to block proprietary use, it was a use restriction. Perhaps you don't share my belief that classic copyleft is designed to block proprietary use and the only reason that distribution was the hook was that distribution was (a) very meaningful in terms of copyright so didn't require a contract, etc and (b) always happened before someone used the software. I believe that RMS's statements and position in regards to the AGPL and GPLv3(7d) support my position in this regard. I think that given the current way technology is deployed, GPLv3(7d) is appropriate in that it takes both my (a) and (b) above. In other words, I'm saying that classic copyleft is a distribution restriction that was intended as a use restriction on a narrow class of use (i.e., distribution that ended up taking away *users* freedom). Because the distribution requirement was not too onerous and because the purpose was in the interest of freedom, the community was willing to accept it. I don't see how the goals behind the GPLv3(7d) is fundamentally different. Clearly the mechanism is now modification and the precise language may be more problematic but I don't see how this is fundamentally different. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
Benj. Mako Hill [EMAIL PROTECTED] writes: quote who=Jeremy Hankins date=Sun, Feb 12, 2006 at 01:52:53PM -0500 Benj. Mako Hill [EMAIL PROTECTED] writes: quote who=Jeremy Hankins date=Sat, Feb 11, 2006 at 10:34:48PM -0500 But the question of whether this is a use restriction or a modification restriction is an interesting one. I believe that it is an attempt to accomplish a restriction on use via a restriction on modification. The intent behind both the AGPL and GPLv3(7d) is fairly easy to summarize: don't offer this software as a service to others unless you also offer the source. Unfortunately, offering the software as a service to others is neither copying nor modification. So any attempt to put this restriction naturally into a license will be a use restriction (or possibly a public performance restriction). Under this logic, copyleft is also a use restriction. It bars proprietary use of free software. No, it doesn't. Proprietary use (i.e., use of private modifications) is very much permitted -- if it wasn't the ASP loophole wouldn't be an issue. In fact, licenses that don't permit private changes (e.g., through forced distribution) have been considered non-DFSG free in the past. What copyleft prevents is proprietary distribution of software. So, I think we agree that this is a modification restriction attempting to protect users freedom to modify and redistribute their software. But in the text I quoted originally we were talking about the *intent* of the license. You claimed that because the modification restriction *intended* to block proprietary use, it was a use restriction. Minor nit: copyleft is a restriction on distribution, not modification. But yes, I do think that the Affero clause is an attempt to engineer a use restriction via a restriction on modification. That's significant not because use restrictions are bad (though I think they are), but because the restriction is engineered rather than simply stated. This is an argument against the feasibility of coming up with wording good enough to pass the DFSG, not an argument against it being able to pass the DFSG in principle. Perhaps you don't share my belief that classic copyleft is designed to block proprietary use Obviously, I can only guess at the intentions of the early adopters of the GPL[1]. But the GPL does not, technically or in practice, discourage my private use of GPL software that I have modified. I'm not certain that I understand you properly, because you seem to be saying that classic copyleft is designed to prevent me from doing things like testing out bug fixes before distributing them, or hacking on software for private purposes and never distributing it. If that is what you mean I think you're very much in the minority in the free software community. If you're talking about proprietary use in a general sort of sense (e.g., the practice of selling software), then you're conflating the casual, general meaning of use with the technical, software licensing sense of the word use. If you mean something else I'm afraid I'll have to ask you to make it more clear, because I don't understand. and the only reason that distribution was the hook was that distribution was (a) very meaningful in terms of copyright so didn't require a contract, etc and (b) always happened before someone used the software. I believe that RMS's statements and position in regards to the AGPL and GPLv3(7d) support my position in this regard. I think that given the current way technology is deployed, GPLv3(7d) is appropriate in that it takes both my (a) and (b) above. I know there are others who disagree, but I'm perfectly willing to go along with the theory behind GPLv3(7d) and the AGPL -- _provided_ that it is implemented in a way that doesn't cause more problems than it solves. But any attempt to put that theory into practice as a modification or distribution restriction is going to run into the problem of engineering a use restriction as a modification restriction. Based on my experience, I'm extremely doubtful that that can be done in a clean, clear, and straightforward way. A good principle for writing licenses should be: State the requirement instead of dictating the means of meeting it. The AGPL violates this principle, and a clause that satisfies the GPLv3(7d) would necessarily violate it as well. Consequently, all these hairy, complicated scenarios of loopholes and collateral damage come up. In other words, I'm saying that classic copyleft is a distribution restriction that was intended as a use restriction on a narrow class of use (i.e., distribution that ended up taking away *users* freedom). Distribution is not use. At least, I haven't been using the term use to include distribution (see above). Because the distribution requirement was not too onerous and because the purpose was in the interest of freedom, the community was willing to accept it. I don't see how the
Re: Affero General Public License
On Mon, 13 Feb 2006 00:14:55 +0100, Benj. Mako Hill [EMAIL PROTECTED] wrote: Under this logic, copyleft is also a use restriction. It bars proprietary use of free software. Being proprietary is not an attribute of the use. It is a description of the exclusion of other uses than the mentioned. Nothing distinguishes the proprietary usage from the non-prorietary usage when looking at the actyual useage only. Your ability to *use* is not restricted by copyleft. Your ability to prevent others from using your modification is. So proprietary use is not a type of usage, and its restriction is not a use restriction. Regards /L -- Lasse R. Nielsen - [EMAIL PROTECTED] 'Faith without judgement merely degrades the spirit divine' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Lasse Reichstein Nielsen [EMAIL PROTECTED] writes: Being proprietary is not an attribute of the use. It is a description of the exclusion of other uses than the mentioned. Nothing distinguishes the proprietary usage from the non-prorietary usage when looking at the actyual useage only. If you understand proprietary to essentially mean private the phrase proprietary use does make a bit more sense than that. It's definitely permitted by the GPL, though. Your ability to *use* is not restricted by copyleft. Your ability to prevent others from using your modification is. So proprietary use is not a type of usage, and its restriction is not a use restriction. Actually, you can prevent others from using your modification by keeping your modification secret. What's not permitted is the sort of have your cake and eat it too that the software industry has become accustomed to. Under copyleft you can not distribute your work while at the same time keeping it secret. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Sat, 11 Feb 2006 19:40:23 -0500 Glenn Maynard wrote: On Sat, Feb 11, 2006 at 04:12:39PM -0800, Josh Triplett wrote: Would it be an excessive requirement to provide an offer for source (at up to 10 times your cost of providing source)? The offer could easily be stuck in the fine print next to the copyright notices. I've generally been of the opinion that the provide an offer for N years option in the GPLv2 is not a free option. That is, software that requires it and didn't offer the GPL's easier alternatives (to place the source alongside the binary on the FTP) would be non-free. Agreed. I don't think we've ever actually seen a license do that and it's only come up theoretically. (Who would ever mirror Debian if every mirror had to maintain a snapshots.d.o? An argument could easily be made on Dissident Test grounds, as well. The 10 times change makes some cases more reasonable for some people, but not free.) Exactly. So I think my answer is yes; it's not reasonable to require that I commit myself, for years into the future, to the task of archiving, packaging and shipping source, and this is just a slight variation on that theme. That is my opinion, too. This, by the way, isn't a flaw in the GPLv2: it's perfectly fine for a free license to offer non-free alternatives alongside the free ones. (You know that, of course.) Obviously... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpog6ZIn3FXu.pgp Description: PGP signature
Re: Affero General Public License
quote who=Glenn Maynard date=Sat, Feb 11, 2006 at 05:10:14PM -0500 On Sat, Feb 11, 2006 at 04:18:26PM -0500, Benj. Mako Hill wrote: There's the possibility that we solve this problems in different ways for different classes of license. The AGPL might not do that now but maybe we can make it do that or find another license that does that. Maybe we have a different GPL compatible license when it comes to software in arcade games or toll booths? If you have one GPL-ish license designed for arcades, and another for toll booths, and another for web services, then you can't use code written for toll booths in a web service, and vice versa. That's a pratical problem, not a freedom issue. That doesn't mean it doesn't matter but the GPLv3 shows draft already shows that these sorts of pratical problems can more easily be worked around. That's the crux of the problem: these licenses, targetting a specific use, tend to make it impractical or impossible to use the code for a very different purpose. Having several of them for different purposes doesn't solve that problem. The problem right now is one of license freedom. The pratical problems you describe, while important, are another set of issues entirely. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
On Sun, Feb 12, 2006 at 12:13:26PM -0500, Benj. Mako Hill wrote: quote who=Glenn Maynard date=Sat, Feb 11, 2006 at 05:10:14PM -0500 If you have one GPL-ish license designed for arcades, and another for toll booths, and another for web services, then you can't use code written for toll booths in a web service, and vice versa. That's a pratical problem, not a freedom issue. That doesn't mean it doesn't matter but the GPLv3 shows draft already shows that these sorts of pratical problems can more easily be worked around. Of course it's a freedom issue. A license that makes it impractical to exercise DFSG freedoms is just as non-free as one that prohibits it entirely, and that's true whether it was intentional or not. Lcenses that effectively say the software can only be used in contexts where it's possible to supply code to users do so. Free licenses don't get to say this code can not be used in toll booths--neither directly nor indirectly. You can't sidestep and ignore the DFSG by changing prohibitions into impractical conditions. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
quote who=Jeremy Hankins date=Sat, Feb 11, 2006 at 10:34:48PM -0500 Benj. Mako Hill [EMAIL PROTECTED] writes: quote who=Jeremy Hankins date=Wed, Feb 08, 2006 at 11:35:55AM -0500 Isn't this exactly what the Affero bit and GPLv3(7d) do? They also bring copyright into the interactions between [ASP software] and [...] users. No. They provide a narrowly defined restriction on modification -- something uncontroversially within the exclusive rights of copyright holders today. The fact that it's being done to preserve freedom is no different than earlier copyleft. Both merely piggyback on what we already have. Others have already made the point that the AGPL is not a narrowly defined restriction -- that it's actually quite significant and ill-defined under certain circumstances. Narrowly defined is subjective. I'm not disagreeing with your interpretation of the AGPL but it's clearly narrow relative to most blanket restrictions on modification which are the norm in software licensing and which the FSD/DFSG/OSD were attempting to create an alternative to. But the question of whether this is a use restriction or a modification restriction is an interesting one. I believe that it is an attempt to accomplish a restriction on use via a restriction on modification. The intent behind both the AGPL and GPLv3(7d) is fairly easy to summarize: don't offer this software as a service to others unless you also offer the source. Unfortunately, offering the software as a service to others is neither copying nor modification. So any attempt to put this restriction naturally into a license will be a use restriction (or possibly a public performance restriction). Under this logic, copyleft is also a use restriction. It bars proprietary use of free software. That is what the AGPL does, and what GPLv3(7d) seems to encourage others to do. It's something that might conceivably be possible, but Very Hard. That's why I very much doubt that it is possible to implement this restriction as a restriction on modification without a lot of unintended consequences. If it's to be done at all, I think it best to simply go ahead and make it a use restriction (or possibly public performance); the end result will be much cleaner and simpler. I think this is short sited. Arguing for a use restriction (something not within the realm of copyright) means we cross into the world of implicit contracts and private ordering. When we do this, the legal foundation upon which we build our licenses get shakier. I've already explained why I think that the arguments in favor of public performances of software is both a hair-brained and wrong legal interpretation and a very dangerous and short-sited legal tactic. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
Benj. Mako Hill [EMAIL PROTECTED] writes: quote who=Jeremy Hankins date=Sat, Feb 11, 2006 at 10:34:48PM -0500 Others have already made the point that the AGPL is not a narrowly defined restriction -- that it's actually quite significant and ill-defined under certain circumstances. Narrowly defined is subjective. I'm not disagreeing with your interpretation of the AGPL but it's clearly narrow relative to most blanket restrictions on modification which are the norm in software licensing and which the FSD/DFSG/OSD were attempting to create an alternative to. True. And it's certainly bad if, lacking an Affero-like clause, people license their software in more proprietary ways. Unfortunately, we can't meet everyone's licensing needs or wants in free ways, and some people are simply never going to be comfortable giving up control of their software to the community. The question (as I don't doubt you understand) is whether we can help folks concerned about the ASP loophole without sacrificing DFSG freedoms. That may depend on what they're willing to accept short of complete protection against the ASP loophole. But the question of whether this is a use restriction or a modification restriction is an interesting one. I believe that it is an attempt to accomplish a restriction on use via a restriction on modification. The intent behind both the AGPL and GPLv3(7d) is fairly easy to summarize: don't offer this software as a service to others unless you also offer the source. Unfortunately, offering the software as a service to others is neither copying nor modification. So any attempt to put this restriction naturally into a license will be a use restriction (or possibly a public performance restriction). Under this logic, copyleft is also a use restriction. It bars proprietary use of free software. No, it doesn't. Proprietary use (i.e., use of private modifications) is very much permitted -- if it wasn't the ASP loophole wouldn't be an issue. In fact, licenses that don't permit private changes (e.g., through forced distribution) have been considered non-DFSG free in the past. What copyleft prevents is proprietary distribution of software. That is what the AGPL does, and what GPLv3(7d) seems to encourage others to do. It's something that might conceivably be possible, but Very Hard. That's why I very much doubt that it is possible to implement this restriction as a restriction on modification without a lot of unintended consequences. If it's to be done at all, I think it best to simply go ahead and make it a use restriction (or possibly public performance); the end result will be much cleaner and simpler. I think this is short sited. Arguing for a use restriction (something not within the realm of copyright) means we cross into the world of implicit contracts and private ordering. When we do this, the legal foundation upon which we build our licenses get shakier. I've already explained why I think that the arguments in favor of public performances of software is both a hair-brained and wrong legal interpretation and a very dangerous and short-sited legal tactic. I don't disagree. But I think that encouraging a bunch of people who don't really know much about licensing to try and solve the ASP loophole when the rest of us haven't been able to do so is also very short sighted. In order to be convinced that GPLv3(7d) is a good idea I would have to see example wording that doesn't cause problems. And if we had wording like that, why not include it directly in GPLv3 rather than encourage amateurs (and a few experts) to come up with mutually incompatible versions of which, best case scenario, one or two might be unproblematic? The fact that no one, despite years of effort, has been able to come up with a way to solve this problem is worth bearing in mind. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
quote who=Jeremy Hankins date=Wed, Feb 08, 2006 at 11:35:55AM -0500 Benj. Mako Hill [EMAIL PROTECTED] writes: quote who=Jeremy Hankins date=Wed, Feb 08, 2006 at 09:06:39AM -0500 The bigger problem is that by arguing for this type of new law, we are arguing for an expansion of existing copyright law. I'm sure that MS and many other ASPs who want to bring copyright into the interactions between software on their servers and their users would welcome this. We should not. Arguing for stronger copyright as a means of getting stronger copyleft is a self-defeating, poor strategically, and ethically indefensible. Isn't this exactly what the Affero bit and GPLv3(7d) do? They also bring copyright into the interactions between [ASP software] and [...] users. No. They provide a narrowly defined restriction on modification -- something uncontroversially within the exclusive rights of copyright holders today. The fact that it's being done to preserve freedom is no different than earlier copyleft. Both merely piggyback on what we already have. I have serious doubts that it can be done in a way that is both weak enough to pass DFSG muster and avoid practical problems, and strong enough to satisfy those who are concerned about this loophole. Clearly, the first half is up to us. Some people arguing against this license seem to think that *any* attempts puts us on the wrong side of the spirit of the DFSG. In the end, I think that those who are concerned about the ASP loophole are missing something fundamental about how the free software community works. They fail to appreciate how much it is dependant on the good will and respect with which we treat each other, and the social pressures we are able to bring to bear on offenders against the communities values. Without that dynamic, free software would not work. With it, I don't believe that the ASP loophole is a problem. If that were the case, we shouldn't need copyleft either IMHO. Obviously, the above is just my opinion. In principle, I see no reason not to make minor compromises in order to make the ASP loophole folks feel more comfortable, and letting the community decide whether the inconveniences are worth that extra peace of mind. But I don't see the ASP loophole as a problem itself, and I don't think that anything more than minor compromises are called for. I think that's the most anyone can ask of someone in your position. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
quote who=Glenn Maynard date=Fri, Feb 10, 2006 at 06:49:12AM -0500 How do you distinguish between an arcade user and someone using a web application? Is it the presence of a network connecting the two? I think that's an unnatural distinction. Both web users and arcade players are equally users; there are examples in both cases where providing source helps and where it doesn't. (I actually do know of arcade operators who have let players mess around with their machines. :) Also, web services aren't the problem, they're just the most common (today) example of a class of problems. The point of the language in the GPL should be to create a generalized language that can cover combination of code with licenses that close this class of problems while not being over broad and allowing people to stomp on other freedoms that we think are essential. Narrowing the restriction to web services means it's going to break down sooner or later, when a different incarnation of the same problem shows up. There's the possibility that we solve this problems in different ways for different classes of license. The AGPL might not do that now but maybe we can make it do that or find another license that does that. Maybe we have a different GPL compatible license when it comes to software in arcade games or toll booths? Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
On Sat, Feb 11, 2006 at 04:18:26PM -0500, Benj. Mako Hill wrote: There's the possibility that we solve this problems in different ways for different classes of license. The AGPL might not do that now but maybe we can make it do that or find another license that does that. Maybe we have a different GPL compatible license when it comes to software in arcade games or toll booths? If you have one GPL-ish license designed for arcades, and another for toll booths, and another for web services, then you can't use code written for toll booths in a web service, and vice versa. That's the crux of the problem: these licenses, targetting a specific use, tend to make it impractical or impossible to use the code for a very different purpose. Having several of them for different purposes doesn't solve that problem. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Glenn Maynard wrote: A real example (from my own field) where this would cause serious practical problems is arcade machines. It's clearly public performance, and players in arcades really are using (and interacting with) the software directly. We include sources to GPL stuff on the machine's drive itself (though nobody cares, since none of it is modified except for the kernel, and that particular code is available on our webpage too). That's for the arcade operator (the owner of the machine). I have no idea how one might satisfy a requirement that the *users* be given GPL-like access to the source. Would it be an excessive requirement to provide an offer for source (at up to 10 times your cost of providing source)? The offer could easily be stuck in the fine print next to the copyright notices. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
On Sat, Feb 11, 2006 at 04:12:39PM -0800, Josh Triplett wrote: Would it be an excessive requirement to provide an offer for source (at up to 10 times your cost of providing source)? The offer could easily be stuck in the fine print next to the copyright notices. I've generally been of the opinion that the provide an offer for N years option in the GPLv2 is not a free option. That is, software that requires it and didn't offer the GPL's easier alternatives (to place the source alongside the binary on the FTP) would be non-free. I don't think we've ever actually seen a license do that and it's only come up theoretically. (Who would ever mirror Debian if every mirror had to maintain a snapshots.d.o? An argument could easily be made on Dissident Test grounds, as well. The 10 times change makes some cases more reasonable for some people, but not free.) So I think my answer is yes; it's not reasonable to require that I commit myself, for years into the future, to the task of archiving, packaging and shipping source, and this is just a slight variation on that theme. This, by the way, isn't a flaw in the GPLv2: it's perfectly fine for a free license to offer non-free alternatives alongside the free ones. (You know that, of course.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Benj. Mako Hill [EMAIL PROTECTED] writes: quote who=Jeremy Hankins date=Wed, Feb 08, 2006 at 11:35:55AM -0500 Isn't this exactly what the Affero bit and GPLv3(7d) do? They also bring copyright into the interactions between [ASP software] and [...] users. No. They provide a narrowly defined restriction on modification -- something uncontroversially within the exclusive rights of copyright holders today. The fact that it's being done to preserve freedom is no different than earlier copyleft. Both merely piggyback on what we already have. Others have already made the point that the AGPL is not a narrowly defined restriction -- that it's actually quite significant and ill-defined under certain circumstances. But the question of whether this is a use restriction or a modification restriction is an interesting one. I believe that it is an attempt to accomplish a restriction on use via a restriction on modification. The intent behind both the AGPL and GPLv3(7d) is fairly easy to summarize: don't offer this software as a service to others unless you also offer the source. Unfortunately, offering the software as a service to others is neither copying nor modification. So any attempt to put this restriction naturally into a license will be a use restriction (or possibly a public performance restriction). One thing that has come up multiple times on d-l is that when license writers move away from describing what they want done and instead start dictating the method for doing something complications start springing up like weeds.[1] Invariably only a very little bit of thought is needed to come up with loopholes or collateral damage -- and usually both. That is what the AGPL does, and what GPLv3(7d) seems to encourage others to do. It's something that might conceivably be possible, but Very Hard. That's why I very much doubt that it is possible to implement this restriction as a restriction on modification without a lot of unintended consequences. If it's to be done at all, I think it best to simply go ahead and make it a use restriction (or possibly public performance); the end result will be much cleaner and simpler. I'm not recommending that by any means. Your point about pushing the edges of copyright is important. But if the choice is between (relatively) simple, clean and clear wording on use, or messy wording with lots of corner cases and unintended consequences on modification, I'll vote for the former. I have serious doubts that it can be done in a way that is both weak enough to pass DFSG muster and avoid practical problems, and strong enough to satisfy those who are concerned about this loophole. Clearly, the first half is up to us. Some people arguing against this license seem to think that *any* attempts puts us on the wrong side of the spirit of the DFSG. I think many people (including myself) think that any attempt will *in fact* put the license on the wrong side of the DFSG. I'd be happy to be proven wrong. When this issue came up on d-l in the past (about the AGPL and the APSL) I spent some time trying to think about how it might be done. At this point I'm fairly certain that it can't be done as a restriction on modification. In the end, I think that those who are concerned about the ASP loophole are missing something fundamental about how the free software community works. They fail to appreciate how much it is dependant on the good will and respect with which we treat each other, and the social pressures we are able to bring to bear on offenders against the communities values. Without that dynamic, free software would not work. With it, I don't believe that the ASP loophole is a problem. If that were the case, we shouldn't need copyleft either IMHO. I don't think that we do need it today in the same way we needed it a couple of decades ago. But that's another issue, and I'd be happy to talk about it off list if you want. [1] This, incidently, is the beauty of the preferred form for modification definition of source. It gets around all the messy details of what is and is not source code and addresses the central issue itself: being able to modify the work. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Glenn Maynard wrote: But that's a special case; more generally, I don't see any way at all of satisfying this for the voicemail, toll booth, etc. cases. (Though the thought of someone corking up a toll booth lane on a busy interstate to plug in a USB pen drive and download its source is somewhat amusing ...) The difficulty here is that in the arcade machine/toll booth case, the person who (IMO) requires source access to exercise his freedoms is the machine _owner_ or toll booth operating company, not the player or tollee. An arcade owner isn't going to allow me to upload hacked firmware to his machines (sadly :-). How do you distinguish between an arcade user and someone using a web application? Is it the presence of a network connecting the two? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Fri, Feb 10, 2006 at 11:07:08AM +, Gervase Markham wrote: Glenn Maynard wrote: But that's a special case; more generally, I don't see any way at all of satisfying this for the voicemail, toll booth, etc. cases. (Though the thought of someone corking up a toll booth lane on a busy interstate to plug in a USB pen drive and download its source is somewhat amusing ...) The difficulty here is that in the arcade machine/toll booth case, the person who (IMO) requires source access to exercise his freedoms is the machine _owner_ or toll booth operating company, not the player or tollee. An arcade owner isn't going to allow me to upload hacked firmware to his machines (sadly :-). That's the it doesn't help argument: the argument that the distribution of source to end users doesn't actually give them the freedoms that the person who made the modifications had. It's been argued for web services, too. For example, Google providing the source to its database engine would be cool, but it wouldn't let me customize Google--only my own little useless copy of it, since I can't install my changes onto Google. How do you distinguish between an arcade user and someone using a web application? Is it the presence of a network connecting the two? I think that's an unnatural distinction. Both web users and arcade players are equally users; there are examples in both cases where providing source helps and where it doesn't. (I actually do know of arcade operators who have let players mess around with their machines. :) Also, web services aren't the problem, they're just the most common (today) example of a class of problems. Narrowing the restriction to web services means it's going to break down sooner or later, when a different incarnation of the same problem shows up. I think Josh's offering is a step forward in generalizing this. It still seems to cause fatal practical problems, though, hence my examples of toll booths and arcade machines. But, given the choice, I'd much rather see his version in GPLv3 than what's currently there. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Marco d'Itri [EMAIL PROTECTED] Just that there has been a period when most debian-legal contributors were extremists or outright loons like you, and in this period while other developers were not looking these people found a consensus to change what until then was the widely accepted meaning of the DFSG. I'm not extreme or loony, especially compared to your pressure to let all borderline cases into main, and there has never been any period in the last few years when -legal has been extreme or loony. I'm surprised by your scare quotes of consensus and if changing widely-accepted meanings troubles you, I think you should complain more about FSF supporters wanting to change free and software to make debian accept adware manuals. -- MJR/slef -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Tue, Feb 07, 2006 at 10:41:55AM -0500, Benj. Mako Hill wrote: quote who=Marco d'Itri date=Tue, Feb 07, 2006 at 12:14:40PM +0100 [EMAIL PROTECTED] wrote: No, it is not. The requirement of source redistribution to third parties that you are not distributing binaries to is incompatible with the DFSG. Which part of the DFSG, exactly? The issue, as I understand it, comes down to one of two things. As Steve phrased it, it would probably fail the Chinese dissident test which, while not part of the DFSG, is seen as a useful tool by many people on this list. I'd argue that that this doesn't come into play here because the AGPL/GPLv3 only requires redistribution of code to *users* but not to everyone. The second argument is it fails the much more generic DFSG3 must allow modification argument. Barring modification of the license and copyright statement seems completely uncontroversial for obvious reasons. Similarly, there is consensus that barring modification of significant pieces of functionality seems to encroach users' freedom. The GPL(2)(c) seems OK although there are a number of interpretations why that is. I think the core issue is the second one. Steve seems to think that anything that does what AGPL is trying to do is non-free which seems to imply he's making either the first argument or something else I don't understand. I think that, in practice, it's very difficult for a license to do what the AGPL attempts to do without carrying with it a number of unacceptable side effects. I won't say it's impossible, I just don't see (at this point) how it could be done. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Affero General Public License
On Wed, Feb 08, 2006 at 11:51:45AM +, MJ Ray wrote: Marco d'Itri [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Well, the discussion in March 2003 on debian-legal included the input of an ftpmaster who disagrees, so this definitely isn't a case of a fringe minority on -legal holding sway. That doesn't mean Debian can't reconsider debian-legal in 2003 *was* a fringe minority in itself. A fringe minority just because it didn't include Marco d'Itri, voice of the let-borderline-in extreme fringe... Instead, you can look at the archives and see the whole range, including RMS, James Troup, Ean Schussler, John Goerzen, Edmund GRIMLEY EVANS and more. Please stop repeating the fringe lie. -legal is open to all. It's just not easy to assert this is free here when it looks like it's not. He even claims[1] that the reason GR2004-003 passed was due to deception by the drafter--as if the topic wasn't the subject of thousands of mails in some of the loudest threads in recent Debian history, and as if developers are so gullible as to pass, with supermajority, changes to the foundation documents after only reading the subject line. I'm glad that's not the case; it prevents fringe minorities like Marco from sneaking through a GR to abolish the DFSG. It's also why I'm confident that the latest attempt to force non-free GFDL works into Debian will fail. His claims that d-legal isn't representative of Debian is particularly thin, given that he's essentially claiming that even a GR isn't representative. I guess it makes perfect sense, though, if you work from the assumption that Marco's opinion can't possibly be in the minority. Anyway, sorry for the noise. I figured I'd get my grumping about Marco done with for a while, and do it where it'd be threaded away with someone else's. [1] Message-ID: [EMAIL PROTECTED] -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
* Mark Rafn: Is a work free if some modifications are permitted, but would make the resulting work non-free? Consider a program which is licensed under the plain GPL. You incorporate parts of OpenSSL into the program, under the standard OpenSSL licenses. The licenses are not compatible, which means that the resulting work is not distributable at all (but you still can run the software for your own purposes). You could argue that this case is different because you could reimplement the same functionality under a compatible license, so this is slightly different. But the example still shows that some kinds of modification can be prevented in a DFSG-compliant manner. I agree that it's a corner case and it's quite strange to use the AGPL in such a manner. Maybe upstream can be convinced to use plain GPL instead. This also avoids the problem of GPL compatibility (the AGPL is incompatible even if the extra clause has no effect on the current code base). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Thu, Feb 09, 2006 at 01:28:57PM +0100, Florian Weimer wrote: * Mark Rafn: Is a work free if some modifications are permitted, but would make the resulting work non-free? Consider a program which is licensed under the plain GPL. You incorporate parts of OpenSSL into the program, under the standard OpenSSL licenses. The licenses are not compatible, which means that the resulting work is not distributable at all (but you still can run the software for your own purposes). You could argue that this case is different because you could reimplement the same functionality under a compatible license, so this is slightly different. But the example still shows that some kinds of modification can be prevented in a DFSG-compliant manner. This is showing that placing *restrictions* on modifications can be prevented. It is not showing that some *kinds of modifications* can be prevented. The ways in which the DFSG allows licenses to prevent what kinds of modifications I can make (and distribute) to a work is extremely limited (Those that are allowed are mostly about credit and licensing.) It does not allow saying don't remove code to send source or (in a related case) don't turn it into spyware, no more than it allows saying don't port this code to Windows. These are very different cases, based in two orthogonal principles of free software: people may turn your software into anything they want (even stuff that you don't like), and that you're allowed to say give everyone else the same freedoms that you received. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLv3 affero-compatibility (Re: Affero General Public License)
On Wed, 8 Feb 2006, Steve Langasek wrote: You then have problems with any derivative works must be made available under the terms of this license clause, which is essential to copyleft. Not much more than today. GPLv2 is not compatible with AGPL, nor with the proposed GPLv3. The goal of these optional clauses in GPLv3 is to *expand* the GPL-compatible creative commons; your suggestion would further fracture it. The goals to expand the set of works under compatible licenses and to expand the amount of code available to users are in conflict. It's already going to create a fracture between GPLv2 and GPLv3, making an explicit fracture between service-restricted and distribution-restricted licenses doesn't seem out of the ballpark. But it was just a thought. I don't expect real traction from it. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
[EMAIL PROTECTED] wrote: Please stop repeating the fringe lie. -legal is open to all. It's just I never affirmed that it's not. Just that there has been a period when most debian-legal contributors were extremists or outright loons like you, and in this period while other developers were not looking these people found a consensus to change what until then was the widely accepted meaning of the DFSG. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
[EMAIL PROTECTED] wrote: If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. That's not even close to what GPLv2(2c) requires. There's no requirement for any specific text, just an appropriate copyright notice and notice of lack of warranty. There is still the requirement to implement specific a functionality in the program. As long as the GPLv3 requirement is general enough I believe that it's not different from this requirement in GPLv2. And even this is not required if the program as you recieved it does not print such text, or the program you modified does not read commands interactively when run. The GPLv3 does not require to provide access to source either. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On 10/02/06, Marco d'Itri [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Please stop repeating the fringe lie. -legal is open to all. It's just I never affirmed that it's not. Just that there has been a period when most debian-legal contributors were extremists or outright loons like you, and in this period while other developers were not looking these people found a consensus to change what until then was the widely accepted meaning of the DFSG. Yea, sure, the developers were not looking. Nevermind that they voted on the issue twice. But I guess calling people loons will now quickly persuade anyone who was until now doubting the Marco d'Itri version of history.
Re: Affero General Public License
Glenn Maynard wrote: On Tue, Feb 07, 2006 at 02:10:23PM -0800, Josh Triplett wrote: They may require that if the work interacts with users, but the interface is such that those users do not receive a copy of the software, you must still satisfy the requirements of clause 6 (Non-Source Distribution) as though you had distributed the work to those users in the form of Object Code. Although the interface is such that bit feels a little awkward, this is a step forward. If I use a source file from eg. Apache in a tiny embedded device, allow me to supply the source (that won't even fit on the device, never mind that the device has no I/O suitable for sending source) on an included CD. I'm assuming here that this tiny embedded device is not a product being provided to users, right? That case is already covered by GPLv2 and GPLv3 without the need for any clause of this nature: distributing a product containing GPLed code is distributing the GPLed code, and thus you must provide the source code, which you may on an included CD or via a 3-year offer. So you're talking about a tiny embedded device which interacts with a user but isn't distributed to that user? It excludes from users (still ill-defined) people who don't interact, which is an improvement. I'm inclined to say that we can leave users undefined here, and rely on the common-sense definition (people who use the software), because we're defining a particular set of uses, namely interaction. Even with the broadest possible reading of users, you still take the subset of those who interact with the software. The more important issue is the use of interact, as you mentioned: What about supermarket self-check-out, ATMs, self-service gas stations, toll booths, voicemail, arcade machines? Software interacts with users in every way imaginable ... Well, to start with, it sounds like you agree that there's a subset of interact which is free, namely interact over a computer network. That alone would cover many of the cases people care about when they want this type of clause, so going with that option is worth considering. Going slightly broader, in most cases it doesn't seem particularly problematic to provide a 3-year-offer or a CD; in many of the cases, the source distribution mechanims must already exist in order to provide source to those who originally put those fixtures in place. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
Mark Rafn wrote: On Tue, 7 Feb 2006, Josh Triplett wrote: They may require that if the work interacts with users, but the interface is such that those users do not receive a copy of the software, you must still satisfy the requirements of clause 6 (Non-Source Distribution) as though you had distributed the work to those users in the form of Object Code. My first suggestion would be to try to word a license clause you believe meets the requirements, THEN figure out how to word GPLv3 to be compatible with it. The extra layer of indirection is confusing. The extra layer may be slightly confusing, but there's a good reason to attempting to frame a compatibility clause in this manner. If we phrase a particular clause, that won't necessarily help us judge another such clause. If we craft a description of the type of such clauses which we find acceptable, then we have a useful gauge to use when evaluating licenses, as well as useful text for the GPLv3. My second is that you will need to define interacts and users pretty carefully here. I have a lot of code I wrote that doesn't interact with users, but with other programs (say, Apache) that interact with other programs (say, a TCP/IP stack) that interact with other programs (routers, other tcp/ip stacks, and finally a browser program) that may have a user. I believe I could reasonably claim that I am the sole user of the software, as I caused it to be run. I agree somewhat with this issue. We may need to clarify the distinction between software which interacts and software which provides a transport for unmodified data. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
On Wed, Feb 08, 2006 at 12:31:16AM -0800, Josh Triplett wrote: Although the interface is such that bit feels a little awkward, this is a step forward. If I use a source file from eg. Apache in a tiny embedded device, allow me to supply the source (that won't even fit on the device, never mind that the device has no I/O suitable for sending source) on an included CD. I'm assuming here that this tiny embedded device is not a product being provided to users, right? That case is already covered by GPLv2 and GPLv3 without the need for any clause of this nature: distributing a product containing GPLed code is distributing the GPLed code, and thus you must provide the source code, which you may on an included CD or via a 3-year offer. So you're talking about a tiny embedded device which interacts with a user but isn't distributed to that user? I was explaining why your clause is a step forward compared to if the work has code to send the source to the user, keep it incarnations. With theirs, if I adapt code from a webserve to a toaster, it's either impossible to satisfy the license or I have to keep broken code around. With yours, I can delete the code, and satisfy the requirements by including source on a CD. It excludes from users (still ill-defined) people who don't interact, which is an improvement. I'm inclined to say that we can leave users undefined here, and rely on the common-sense definition (people who use the software), because we're defining a particular set of uses, namely interaction. Even with the broadest possible reading of users, you still take the subset of those who interact with the software. It sounds like your definition of user is people who interact with the software, then? If that's the set of people you mean, maybe try avoiding the word user entirely. Then you can focus on defining interact. (But first: my examples were meant to show that even applying the GPL's source requirements to interacting users is problematic.) Well, to start with, it sounds like you agree that there's a subset of interact which is free, namely interact over a computer network. If you mean where it's free to require sending source, I'm not sure yet. I'm more inclined to think so based on this clause, which doesn't do so by placing restrictions on modifying the program itself. This makes me wonder: the draft GPLv3's clause talks about software which has the ability to send source *built into* the work itself. How is that useful? Why would PHP or a search engine or anything else of that nature have code to send the source? That's the job of the webserver it's running under! That alone would cover many of the cases people care about when they want this type of clause, so going with that option is worth considering. Going slightly broader, in most cases it doesn't seem particularly problematic to provide a 3-year-offer or a CD; in many of the cases, the source distribution mechanims must already exist in order to provide source to those who originally put those fixtures in place. But let's look at some of the examples I gave: What about supermarket self-check-out, ATMs, self-service gas stations, toll booths, voicemail, arcade machines? Software interacts with users in every way imaginable ... In my opinion, a player in an arcade, playing on an arcade machine, is both a user of the machine, and is interacting with the software. (That's my common sense, intuitive answer.) According to your clause, I'd need to provide source to the players, as if I'd sent them object code. Is that what you intended? It doesn't seem practical to me. All of my examples were of this nature. It easy to argue that a driver tossing quarters at an automated toll booth is a user interacting with the software, and so on. If I used code from your webserver in my voicemail system, what reasonable (eg. free) options would I have to comply with the license? -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
[EMAIL PROTECTED] wrote: and for GPLv2(2)(c) in particular. Bad example; if that clause were in any other license, it probably would have been declared non-free a long time ago. Yes, and this shows quite clearly how a few people on debian-legal@ are trying to change the meaning of the DFSG which was widely accepted until a few years ago. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
[EMAIL PROTECTED] wrote: The issue, as I understand it, comes down to one of two things. As Steve phrased it, it would probably fail the Chinese dissident test which, while not part of the DFSG, is seen as a useful tool by many people on this list. And while some misguided people think it's useful, not being part of the DFSG still makes it non-relevant for the purpose of evaluating the DFSG-freeness of a license. The second argument is it fails the much more generic DFSG3 must allow modification argument. Barring modification of the license and copyright statement seems completely uncontroversial for obvious reasons. Similarly, there is consensus that barring modification of significant pieces of functionality seems to encroach users' freedom. The GPL(2)(c) seems OK although there are a number of interpretations why that is. At least as long as the license does not require a specific implementation, I do not believe that a requirement to mechanically provide the source code does not allow modification, I do not find it different in practice from a similar clause in the GPLv2: If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Marco d'Itri [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Well, the discussion in March 2003 on debian-legal included the input of an ftpmaster who disagrees, so this definitely isn't a case of a fringe minority on -legal holding sway. That doesn't mean Debian can't reconsider debian-legal in 2003 *was* a fringe minority in itself. A fringe minority just because it didn't include Marco d'Itri, voice of the let-borderline-in extreme fringe... Instead, you can look at the archives and see the whole range, including RMS, James Troup, Ean Schussler, John Goerzen, Edmund GRIMLEY EVANS and more. Please stop repeating the fringe lie. -legal is open to all. It's just not easy to assert this is free here when it looks like it's not. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Benj. Mako Hill [EMAIL PROTECTED] quote who=3D\Glenn Maynard\ date=3D\Tue, Feb 07, 2006 at 12:14:25AM -0500\ The GPLv3 having such a clause has no relevance to its freeness. A non- free restriction doesn't become free because the FSF decided to use it. I never suggested that this is the case. I suggested that we should perhaps think a bit harder before we declare software (or some subset of software) under the most popular free software license in existance non-free than we do when we're only talking about some license that almost nobody uses. I don't think one can honestly call GPLv3 the most popular free software licence in existance because it's not in existance yet and the current draft and BROKEN drafting process are getting a lot of criticism. (The process should be changed to be * open/accessible to all, but especially software creators * transparent and public with full audit trails * more international ) -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Nathanael Nerode wrote: Florian Weimer wrote: It seems that web.py does not include the source transmission facility mentioned in the AGPL. As a result, the additional clause is void, and the license should be DFSG-free. Unfortunately the clause is not void. (1) This is a copyleft, so all derivative works must use the same license; (2) unlike clause 2c which applies if the *modified* program satisfies certain conditions, clause 2d applies if the Program as you received it satisfies certain conditions So if I create a derivative work of web.py (webplus.py) which *does* include the facility mentioned in the AGPL, no subsequent derivative works of webplus.py can ever remove it. This regardless of *my* desires as the author of the source transmisison facility! This is pretty hideous. I don't know if it's non-free, but I'd guess so. Is there a way around it? Dual-licensing my portions of webplus.py under a free license, and then distributing only in patch form (so that the recipients never receive webplus.py as a single work)? No, that wouldn't allow binary distribution. It seems yes however. If you distribute the source in that way, then the users having received the source have received a copy of the unmodified source code (i.e. he has then received a copy of the software not containing that facility). He can then modify this source code without including the facility. The fact that he has previously received a binary containg the facility does not seems to change anything (since he modifies the source code, not the binary). Anyway, I am not sure that the interpretation of the AGPL given on this list is the exact one. It seems reasonable to interpret it as if the software interact with the user, this facility must be preserved) (it is in the spirit of the license). I agree however that this unclear; and I think it is worthwhile to ask clarification to the upstream authors. Olive -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Benj. Mako Hill [EMAIL PROTECTED] writes: I don't think we need to turn this into a semantic argument about the term user. The authors of the free software definition and both versions of the GPL think that users are people who, well, *use* software. Use in this case is defined according to the most common dictionary definition of that word. This definition does not, it turns out, mention hardware. Actually, I think that the semantics are an important part of the discussion. When you use an application provided on a web page are you using the web server as well? The TCP stack? Are you using the software that runs a phone service? How about if that phone service allows you to dictate the text of a fax to be sent? How about, if in addition to the text of the fax, you can select from a variety of formatting options and achieve output similar to what one could from a web-based openoffice service? Where do you draw the line? When you start to think about the continuum of possible scenarios it's not at all clear how you could draft an affero-like clause that didn't cause a lot of collateral damage and at the same time allow lots of loop-holes. I agree with those who have said that, in principle, an affero-like clause would be free, but that in practice it's not clear how it could be done. The only possibility that I can think of is to use an idea like public performance. I.e., if the work is publicly performed, source distribution requirements would apply. Public performance would probably have to be defined in a way that takes into account the purpose for which people are using the software (i.e., their primary purpose is to use the software, as opposed to using the software only to facilitate access to something else). -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
quote who=Jeremy Hankins date=Wed, Feb 08, 2006 at 09:06:39AM -0500 The only possibility that I can think of is to use an idea like public performance. I.e., if the work is publicly performed, source distribution requirements would apply. Public performance would probably have to be defined in a way that takes into account the purpose for which people are using the software (i.e., their primary purpose is to use the software, as opposed to using the software only to facilitate access to something else). This is a *very* bad idea IMHO for two reasons. First, it's a poor reading of copyright law. Software is, at least in the US, a literary work. A classical example of copyrighteable public performance of other types of literary works is reading the text of the poem in a public park. To make the jump from this to interacting with a piece of software over the net is creating new law. The bigger problem is that by arguing for this type of new law, we are arguing for an expansion of existing copyright law. I'm sure that MS and many other ASPs who want to bring copyright into the interactions between software on their servers and their users would welcome this. We should not. Arguing for stronger copyright as a means of getting stronger copyleft is a self-defeating, poor strategically, and ethically indefensible. Now, if through no effort of our own and inspite of our community's opposition, copyright ends up being extended in this way, we should consider taking advantage of it in the same way that we are using copyright as the basis of copyleft. Of course, there's a world of difference between using a bad thing against itself and arguing for a bad thing because we might be able to do so. If this issue is truly important to us, I think we should be able to sustain a minor barrier to modification that falls below the loss of freedom threshold in the same way that GPL(2)(c), the advertising clause, copyleft, unremoveable copyright statements and licenses, and other sometimes annoying clauses that we believe support our movement and are ultimately in the best interests of software freedom. I'm not claiming that I've found language that does this. I am saying that I think it's possible. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Wed, 8 Feb 2006, Marco d'Itri wrote: I do not find it different in practice from a similar clause in the GPLv2: If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. That's not even close to what GPLv2(2c) requires. There's no requirement for any specific text, just an appropriate copyright notice and notice of lack of warranty. And even this is not required if the program as you recieved it does not print such text, or the program you modified does not read commands interactively when run. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Tue, 7 Feb 2006, Benj. Mako Hill wrote: There is the issue of defining *users*. My definition of the user of a software would be the person that is in control of hardware on which the software run. The Affero clause actually reduce their ability to modify their software. I don't think we need to turn this into a semantic argument about the term user. I really do think the license needs a definition of terms, when those terms are woefully unclear. The authors of the free software definition and both versions of the GPL think that users are people who, well, *use* software. Please provide an operational definition. Saying this just moves the question down a level. What does it mean to use software? If you have a definition from these authors, please post or link to it. I can't find anything that clears it up. Many of their manifestae include the word user, but all the definitions and licenses I've seen refer only to recipients. Use in this case is defined according to the most common dictionary definition of that word. This definition does not, it turns out, mention hardware. Ok, definition #1 in my big dic is to put into service or employ. That clearly means sysadmin. You can claim that loss of software freedom only occurs on hardware that is owned or controlled by the victim without claiming that people who use google do not actually *use* their software. That's what we have to define. I claim that someone who types text into a cellphone, which then gets an ad from google is not much more of a user than someone who asks me a question, which answer I find for them on google. I think our collective santity is best served by some consistency in terminology. :) I fully agree, and this is why I think it's vital for this proposed license to define the term. I'm quite serious about this - it really is not a definition that should be left to license interpretation. IANAL, so I have no clue what the most likely rulings would be. For instance, if a license said you must distribute full working source to all users, and by user, we mean any entity who claims to have had any direct or indirect contact with information related to this program, would you expect that to be GPLv3-compatible? -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
quote who=Josh Triplett date=Wed, Feb 08, 2006 at 12:34:27AM -0800 Mark Rafn wrote: On Tue, 7 Feb 2006, Josh Triplett wrote: They may require that if the work interacts with users, but the interface is such that those users do not receive a copy of the software, you must still satisfy the requirements of clause 6 (Non-Source Distribution) as though you had distributed the work to those users in the form of Object Code. My first suggestion would be to try to word a license clause you believe meets the requirements, THEN figure out how to word GPLv3 to be compatible with it. The extra layer of indirection is confusing. The extra layer may be slightly confusing, but there's a good reason to attempting to frame a compatibility clause in this manner. If we phrase a particular clause, that won't necessarily help us judge another such clause. If we craft a description of the type of such clauses which we find acceptable, then we have a useful gauge to use when evaluating licenses, as well as useful text for the GPLv3. I tend to agree. I just volunteered to collate comments on the AGPL compatibility clause for the GPLv3 and will try to suggest a text or set of texts to the FSF. I'd appreciate any help. If you, or anyone else, is interested in working on it, let me know. The FSF/SFLC doesn't have to listen to me but I think that we can build a strong case for a better compat clause in the GPLv3 and probably also for a better language in the AGPL as well (but that comes later). Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
Benj. Mako Hill [EMAIL PROTECTED] writes: quote who=Jeremy Hankins date=Wed, Feb 08, 2006 at 09:06:39AM -0500 The only possibility that I can think of is to use an idea like public performance. I.e., if the work is publicly performed, source distribution requirements would apply. Public performance would probably have to be defined in a way that takes into account the purpose for which people are using the software (i.e., their primary purpose is to use the software, as opposed to using the software only to facilitate access to something else). This is a *very* bad idea IMHO for two reasons. I think both of your points are good. But: The bigger problem is that by arguing for this type of new law, we are arguing for an expansion of existing copyright law. I'm sure that MS and many other ASPs who want to bring copyright into the interactions between software on their servers and their users would welcome this. We should not. Arguing for stronger copyright as a means of getting stronger copyleft is a self-defeating, poor strategically, and ethically indefensible. Isn't this exactly what the Affero bit and GPLv3(7d) do? They also bring copyright into the interactions between [ASP software] and [...] users. This seems like an argument against both the AGPL and GPLv3(7d). Does it really matter whether the mechanism is via a restriction on public performance, or via a restriction on use? Both, I think, are steps we should only take with great care, if at all. As for whether it can be done via a restriction on modification, I have serious doubts that it can be done in a way that is both weak enough to pass DFSG muster and avoid practical problems, and strong enough to satisfy those who are concerned about this loophole. After all, if it only restricts modification (as opposed to use) what prevents someone from running the software behind a firewall that doesn't permit transmission of source? In the end, I think that those who are concerned about the ASP loophole are missing something fundamental about how the free software community works. They fail to appreciate how much it is dependant on the good will and respect with which we treat each other, and the social pressures we are able to bring to bear on offenders against the communities values. Without that dynamic, free software would not work. With it, I don't believe that the ASP loophole is a problem. Obviously, the above is just my opinion. In principle, I see no reason not to make minor compromises in order to make the ASP loophole folks feel more comfortable, and letting the community decide whether the inconveniences are worth that extra peace of mind. But I don't see the ASP loophole as a problem itself, and I don't think that anything more than minor compromises are called for. Now, if through no effort of our own and inspite of our community's opposition, copyright ends up being extended in this way, we should consider taking advantage of it in the same way that we are using copyright as the basis of copyleft. Of course, there's a world of difference between using a bad thing against itself and arguing for a bad thing because we might be able to do so. I don't know when you would decide that copyright law has been so extended, but one could argue that it is in the process. See the APSL[1], for example. [1] http://www.opensource.apple.com/apsl/ Specifically, the definition of Externally Deploy (1.4) and the repeated references to permission to perform the software (2.1, 2.2, and 3) -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Mark Rafn wrote: My first suggestion would be to try to word a license clause you believe meets the requirements, THEN figure out how to word GPLv3 to be compatible with it. The extra layer of indirection is confusing. quote who=Josh Triplett date=Wed, Feb 08, 2006 at 12:34:27AM -0800 The extra layer may be slightly confusing, but there's a good reason to attempting to frame a compatibility clause in this manner. If we phrase a particular clause, that won't necessarily help us judge another such clause. On Wed, 8 Feb 2006, Benj. Mako Hill wrote: I tend to agree. I just volunteered to collate comments on the AGPL compatibility clause for the GPLv3 and will try to suggest a text or set of texts to the FSF. I'd appreciate any help. If you, or anyone else, is interested in working on it, let me know. It's up to you, of course. My advice was mostly along the lines that trying to be compatible with something that isn't itself very well specced out and for which you have no test cases is very very unlikely to work. I'd start with the underlying requirement (an example of an AGPL-like license), and generalize from that. Anyway, I'm interested in working on this, if you want someone whose main contribution is likely to be objecting to non-free requirements rather than coming up with slightly closer-to-free requirements. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GPLv3 affero-compatibility (Re: Affero General Public License)
It occurs to me that one of the biggest mistakes with the GFDL is the confusion caused by clauses that do not apply in many cases. Licenses that have options and conditionals are EXTREMELY confusing, and lead to hassle on the part of distributors (and Debian specifically) having to evaluate each package to see how it interacts with license options. Has anyone suggested to the FSF that GPLv3 be more than one license? The draft is arguably already two licenses masquerading as one, and it would be FAR clearer if there were GPLv3-distribution and GPLv3-service as separate licenses, which licensors could choose between. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Nathanael Nerode [EMAIL PROTECTED] wrote: So if I create a derivative work of web.py (webplus.py) which *does* include the facility mentioned in the AGPL, no subsequent derivative works of webplus.py can ever remove it. This regardless of *my* desires as the author of the source transmisison facility! This is pretty hideous. I don't know if it's non-free, but I'd guess so. Is there a way around it? I think so, though not a pretty one. You could make a second release in parallel in which the facility was already removed. -M- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Wed, Feb 08, 2006 at 09:06:39AM -0500, Jeremy Hankins wrote: The only possibility that I can think of is to use an idea like public performance. I.e., if the work is publicly performed, source distribution requirements would apply. Public performance would probably have to be defined in a way that takes into account the purpose for which people are using the software (i.e., their primary purpose is to use the software, as opposed to using the software only to facilitate access to something else). A real example (from my own field) where this would cause serious practical problems is arcade machines. It's clearly public performance, and players in arcades really are using (and interacting with) the software directly. We include sources to GPL stuff on the machine's drive itself (though nobody cares, since none of it is modified except for the kernel, and that particular code is available on our webpage too). That's for the arcade operator (the owner of the machine). I have no idea how one might satisfy a requirement that the *users* be given GPL-like access to the source. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Wed, Feb 08, 2006 at 05:02:22PM -0500, Glenn Maynard wrote: A real example (from my own field) where this would cause serious practical problems is arcade machines. It's clearly public performance, and players in arcades really are using (and interacting with) the software directly. We include sources to GPL stuff on the machine's drive itself (though nobody cares, since none of it is modified except for the kernel, and that particular code is available on our webpage too). That's for the arcade operator (the owner of the machine). I have no idea how one might satisfy a requirement that the *users* be given GPL-like access to the source. One way would be to supply a compactflash card slot that will burn the sources to a 1GB compactflash card. That seems a lot less outrageous today than it did three years ago, to my mind. On the other hand, it still seems unreasonable to expect people to ensure that source is accessible from every machine that lets someone login remotely and run ls. And given you can probably setup filters without violating the copyright restrictions -- ie adding a proxy that prevents you from getting to the download-source url, or putting a metal plate over the card-writer slot -- I'm not really sure how useful these requirements are going to be in practice anyway. But in so far as our aim's to let people use as much software as they can, and do as much with it as they can, I'm not convinced that requiring some scripts to have a cat $0 option is that big a deal either. Cheers, aj signature.asc Description: Digital signature
Re: Affero General Public License
On Thu, Feb 09, 2006 at 04:03:52PM +1000, Anthony Towns wrote: One way would be to supply a compactflash card slot that will burn the sources to a 1GB compactflash card. That seems a lot less outrageous today than it did three years ago, to my mind. Actually, our arcade machines are somewhat unique, in that they have an exposed USB slot, designed for players to plug in pen drives. However, it's still not reasonable to be storing source over it. If we do the logical conclusion, extreme case thing, we can have tens or hundreds of megs of source to store. These things are USB1.1; we can only send data at about 400-800k/sec. But that's a special case; more generally, I don't see any way at all of satisfying this for the voicemail, toll booth, etc. cases. (Though the thought of someone corking up a toll booth lane on a busy interstate to plug in a USB pen drive and download its source is somewhat amusing ...) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
[EMAIL PROTECTED] wrote: Well, the discussion in March 2003 on debian-legal included the input of an ftpmaster who disagrees, so this definitely isn't a case of a fringe minority on -legal holding sway. That doesn't mean Debian can't reconsider debian-legal in 2003 *was* a fringe minority in itself. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
[EMAIL PROTECTED] wrote: No, it is not. The requirement of source redistribution to third parties that you are not distributing binaries to is incompatible with the DFSG. Which part of the DFSG, exactly? -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
[EMAIL PROTECTED] wrote: I don't think that issue is a closed one. As you and others have mentioned in other threads, the GPLv3 will probably have a Affero-type clause. Several people, at least, have spoken up in favor of this sort of clause being both in the spirit of the GPL and the DFSG. I fully agree. The Affero GPL was declared non-free at a time when debian-legal was dominated by the everything is a restriction crowd, but this principle nowadays keeps being contested for not being a valid interpretation of the DFSG. I would love to see web.py in Debian. I suspect that, one way or another, the this issue will be resolved in the GPLv3 process. :) Hopefully the GPLv3 will have provisions to allow reusing code from this kind of applications in other applications which by design do not provide network services, which I understand is the main contentious point. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
quote who=Marco d'Itri date=Tue, Feb 07, 2006 at 12:14:40PM +0100 [EMAIL PROTECTED] wrote: No, it is not. The requirement of source redistribution to third parties that you are not distributing binaries to is incompatible with the DFSG. Which part of the DFSG, exactly? The issue, as I understand it, comes down to one of two things. As Steve phrased it, it would probably fail the Chinese dissident test which, while not part of the DFSG, is seen as a useful tool by many people on this list. I'd argue that that this doesn't come into play here because the AGPL/GPLv3 only requires redistribution of code to *users* but not to everyone. The second argument is it fails the much more generic DFSG3 must allow modification argument. Barring modification of the license and copyright statement seems completely uncontroversial for obvious reasons. Similarly, there is consensus that barring modification of significant pieces of functionality seems to encroach users' freedom. The GPL(2)(c) seems OK although there are a number of interpretations why that is. I think the core issue is the second one. Steve seems to think that anything that does what AGPL is trying to do is non-free which seems to imply he's making either the first argument or something else I don't understand. Many/most others have gone with the second argument and are saying that the problem is primarily with the way the AGPL has done it. I'd love to hear suggestions for a better way to do it. If I'm forgetting something else, please let me know. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
http://www.affero.org/oagpl.html I thought I should just check with you guys if the license is OK for Debian. No, it is not. The requirement of source redistribution to third parties that you are not distributing binaries to is incompatible with the DFSG. On Mon, 6 Feb 2006, Benj. Mako Hill wrote: I don't think that issue is a closed one. No issue ever is :) I think that we need to *at least* discuss this a bit more and and a bit more widely before we risk writing off some large future subset of GPL works as being non-free. As always, we'll review works on a per-package basis if they have a license that does not unambiguously make them free. If they have the affero limitation (AGPL 2d, that there is functionality which cannot be removed, and limits to how the software is used), they aren't free, and I expect it's a decision we'll make over and over. As it turns out, I tend to be of the opinion that it is important enough that users be able to have access to the source code of the programs they use that we can probably sustain a strictly targetted and flexibly defined limit on modification that serves only to protect this freedom. I would be happy if it were possible for a copyleft to meet this goal without limiting the fundamental freedom for a recipient to do whatever she wants with the code, but I don't think it's possible. And I don't think I'm willing to accept both modification limits AND use restrictions to meet this noble but non-free goal. We did something similar both for copyleft in general and for GPLv2(2)(c) in particular. No, that's an annoying clause but fundamentally different. AGPL(2d) says you must preserve this functionality, where GPLv2(2c) says you must include some text if you choose to preserve this functionality. Additionally, GPLv2(2c) does not require that the owner of the platform actually run the software in this manner, where AGPL(2d) requires you to offer source to users when running the thing. AGPL(2d) does 2 unfree things. The first half of the runon sentence limits the kind of changes you can make, which severely limits the fields of endeavor which the software can be modified to fit. The second half is just badly written, but seems to say that the program must be run in a way as to offer source to users, whoever they may be. GPLv2(2c) can be trivially worked around by removing that functionality entirely if the requirement is bothersome in your particular application. I would love to see web.py in Debian. I suspect that, one way or another, the this issue will be resolved in the GPLv3 process. :) I suspect it will not be. GPLv3 allows, but does not require, non-free restrictions, so packages will need to be discussed case-by-case. And people will always raise the but this is kinda free, and so useful, let's just include it argument regardless. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
quote who=Steve Langasek date=Mon, Feb 06, 2006 at 11:32:18PM -0800 Several people, at least, have spoken up in favor of this sort of clause being both in the spirit of the GPL and the DFSG. Well, the discussion in March 2003 on debian-legal included the input of an ftpmaster who disagrees, so this definitely isn't a case of a fringe minority on -legal holding sway. Anthony also claims that the GPL linking provisions may be over-reaching. I respect Anthony's opinion on these issues and I respect yours but I don't think any of our positions in the project give us any more power to speak the project as a whole. Perhaps you'd care to comment on http://lists.debian.org/debian-legal/2003/03/msg00380.html, then? Anthony's comments primarily pertain to the specific language of the AGPL. Most of this langauge has been removed or generalized in the GPLv3 draft. I agree that AGPL language is clumbsy. I'm not sure if it's non-free. I *do* think that the spirit behind the AGPL and Affero-inspired clause in the GPLv3 is fully in line with our principles. *Users* of software should be able to modify their software. Anthony also includes are some more general critiques of the rhetoric used by the author of the Newsforge article which I agree with completely. That doesn't mean Debian can't reconsider this position, of course, but I don't think the presence of an AGPL-like clause in GPLv3 is grounds for reversing that position -- closing the ASP loophole causes real problems for real applications that our users use Debian for today, and our users are supposed to be the first priority, yadda yadda. It has been argued that providing users of software with source code of the software they are using is in the best interest of those users. That was, after all, an argument at the core of the free software movement and is certainly reflected in the DFSG. The only reason distribution is a central concept in free software licenses is that it's a particularly meaningful concept in copyright and was always co-present with use a couple decades ago when these licenses were forged. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
http://www.affero.org/oagpl.html On Tue, 7 Feb 2006, Florian Weimer wrote: It seems that web.py does not include the source transmission facility mentioned in the AGPL. As a result, the additional clause is void, and the license should be DFSG-free. This is an interesting question. Is a work free if some modifications are permitted, but would make the resulting work non-free? If I add the capability to web.py to deliver full source, that derived work would be non-free. I'd lean toward non-free because the license restriction triggers automatically if a derived work adds that functionality. But I'll admit this is a twist I haven't fully digested. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Thanks, Josh. This was a pretty cogent and helpful explication. quote who=Josh Triplett date=Mon, Feb 06, 2006 at 11:02:20PM -0800 There are two separate, mostly-independent issues with the AGPL: 1) The issue of whether this type of clause is OK at all. This is certainly an open issue. I lean towards saying that it is theoretically possible for such a clause to be free but that no such clause has been written in an existing license. I think the most likely way to achieve a free clause of this type would be to base it on the GPL and phrase it in such a way as to impose exactly the same clauses which apply to distribution, along with all the proposed alternatives. Would you be willing to work on drafting an example of such language for the GPLv3? 2) The specific clause written in the AGPL. Even if the answer to (1) is that such clauses are fine in general, the particular clause in the AGPL makes restrictions pertaining to particular technologies. It is not possible to modify AGPLed software in such a way that it no longer contains an HTTP server. This seems quite obviously non-free. I believe issue 1 merits further discussion. However, regarding issue 2, I don't believe the clause in the AGPL is anywhere near free, and I don't see how any possible reading of the DFSG could permit it. This is a increasingly convincing argument. Clearly, the FSF also found issue with it as they've changed and generalized the language quite a bit in the GPL. As it turns out, I tend to be of the opinion that it is important enough that users be able to have access to the source code of the programs they use that we can probably sustain a strictly targeted and flexibly defined limit on modification that serves only to protect this freedom. Are you suggesting that such restrictions are acceptable under the DFSG, or are you suggesting that such restrictions might be beneficial and thus we should adapt the DFSG to permit them? I firmly believe that the former is true. GPLv3 Affero-style clauses provide a minor restriction on modification that is designed to provide the users of software with source code and the ability to modify that code. This is in the spirit of the DFSG and IMHO fully in line with the methods of the GPL and other licenses we've accepted. It, like unmodifiable licenses, copyright statements, blurbs, etc, are a net positive for freedom and need not be built on the back on any principle-sacrificing loss of freedom. If a majority believe that the DFSG does not permit these and should, we should adapt the DFSG. I think that's unnecessary. They're guidelines after all. We did something similar both for copyleft in general True. However, note that copyleft seems to be specifically permitted by the DFSG, since it only requires that modifications and derived works be distributable under the same terms as the license of the original software. My point is that one could make a very strict-interpretation based argument against it but, since it seems clearly in line with the principles that the DFSG is attempting to represent, we're interpret the DFSG accordingly. and for GPLv2(2)(c) in particular. Bad example; if that clause were in any other license, it probably would have been declared non-free a long time ago. I don't doubt that. I also don't believe that copyleft, if it were unveiled in the GPLv3 two weeks, would stand a chance of making it into Debian. I'm of the belief that DFSG10 exists as a test to see if our interpretation of the first nine is broken. I think statements like this show that it might be. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
quote who=Glenn Maynard date=Tue, Feb 07, 2006 at 12:14:25AM -0500 On Mon, Feb 06, 2006 at 11:53:22PM -0500, Benj. Mako Hill wrote: I don't think that issue is a closed one. As you and others have mentioned in other threads, the GPLv3 will probably have a Affero-type clause. The GPLv3 having such a clause has no relevance to its freeness. A non- free restriction doesn't become free because the FSF decided to use it. I never suggested that this is the case. I suggested that we should perhaps think a bit harder before we declare software (or some subset of software) under the most popular free software license in existance non-free than we do when we're only talking about some license that almost nobody uses. The stakes are higher. Our level of critical reflection should be too. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
Benj. Mako Hill wrote: The second argument is it fails the much more generic DFSG3 must allow modification argument. Barring modification of the license and copyright statement seems completely uncontroversial for obvious reasons. Similarly, there is consensus that barring modification of significant pieces of functionality seems to encroach users' freedom. The GPL(2)(c) seems OK although there are a number of interpretations why that is. [...] Many/most others have gone with the second argument and are saying that the problem is primarily with the way the AGPL has done it. I'd love to hear suggestions for a better way to do it. I believe the AGPL fails the DFSG due to being technology-specific. By requiring HTTP, and requiring that you must transmit the source *via the software itself*, it prohibits derived works which don't include an HTTP server, failing DFSG3. As a practical matter, it also makes it impossible to distribute a compiled version which doesn't include its own source in the binary package (For that matter, a strict reading of the AGPL and the words must not remove that facility might actually suggest that you can't change that particular chunk of code at all, even if you continue to offer the source via HTTP.) Similarly, the compatibility clause in GPLv3, They may require that the work contain functioning facilities that allow users to immediately obtain copies of its Complete Corresponding Source Code. has the problem of allowing a requirement for immediate distribution, which is far more restrictive than the general source distribution requirement for other types of distribution, and depending on the interpretations of immediate and users (which in turn depend on the license someone writes to fit this compatibility clause), quite possibly non-free. A clause of this form which satisfies DFSG3 needs to avoid requiring particular technologies. Furthermore, it needs to avoid being more restrictive about requiring source distribution to users compared to the case of distributing source to those who have a binary distributing a binary. I suggest the following, phrased in the form of a GPLv3-style compatibility clause: They may require that if the work interacts with users, but the interface is such that those users do not receive a copy of the software, you must still satisfy the requirements of clause 6 (Non-Source Distribution) as though you had distributed the work to those users in the form of Object Code. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
Benj. Mako Hill wrote: Thanks, Josh. This was a pretty cogent and helpful explication. Thank you. :) quote who=Josh Triplett date=Mon, Feb 06, 2006 at 11:02:20PM -0800 There are two separate, mostly-independent issues with the AGPL: 1) The issue of whether this type of clause is OK at all. This is certainly an open issue. I lean towards saying that it is theoretically possible for such a clause to be free but that no such clause has been written in an existing license. I think the most likely way to achieve a free clause of this type would be to base it on the GPL and phrase it in such a way as to impose exactly the same clauses which apply to distribution, along with all the proposed alternatives. Would you be willing to work on drafting an example of such language for the GPLv3? Gladly. See my previous response to you elsewhere in this thread for specific text, as well as answers to several of the other points you raised in this mail. I've also provided that specific text as a comment to that clause on the GPLv3 site (though since I sent it via email, it may take some time to appear). - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
On Tue, Feb 07, 2006 at 11:00:00AM -0500, Benj. Mako Hill wrote: I *do* think that the spirit behind the AGPL and Affero-inspired clause in the GPLv3 is fully in line with our principles. *Users* of software should be able to modify their software. There is the issue of defining *users*. My definition of the user of a software would be the person that is in control of hardware on which the software run. The Affero clause actually reduce their ability to modify their software. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Tue, Feb 07, 2006 at 02:10:23PM -0800, Josh Triplett wrote: They may require that if the work interacts with users, but the interface is such that those users do not receive a copy of the software, you must still satisfy the requirements of clause 6 (Non-Source Distribution) as though you had distributed the work to those users in the form of Object Code. Although the interface is such that bit feels a little awkward, this is a step forward. If I use a source file from eg. Apache in a tiny embedded device, allow me to supply the source (that won't even fit on the device, never mind that the device has no I/O suitable for sending source) on an included CD. It excludes from users (still ill-defined) people who don't interact, which is an improvement. What about supermarket self-check-out, ATMs, self-service gas stations, toll booths, voicemail, arcade machines? Software interacts with users in every way imaginable ... -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Tue, 7 Feb 2006, Josh Triplett wrote: They may require that if the work interacts with users, but the interface is such that those users do not receive a copy of the software, you must still satisfy the requirements of clause 6 (Non-Source Distribution) as though you had distributed the work to those users in the form of Object Code. Should a smaller list than d-l be used for brainstorming this? I'm happy to join (or not, at your request, depending on whether my critiques are helpful or harmful), but I hesitate to spam d-l too much with it while working out the basics. My first suggestion would be to try to word a license clause you believe meets the requirements, THEN figure out how to word GPLv3 to be compatible with it. The extra layer of indirection is confusing. My second is that you will need to define interacts and users pretty carefully here. I have a lot of code I wrote that doesn't interact with users, but with other programs (say, Apache) that interact with other programs (say, a TCP/IP stack) that interact with other programs (routers, other tcp/ip stacks, and finally a browser program) that may have a user. I believe I could reasonably claim that I am the sole user of the software, as I caused it to be run. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Tue, Feb 07, 2006 at 03:55:41PM -0800, Mark Rafn wrote: Should a smaller list than d-l be used for brainstorming this? I'm happy to join (or not, at your request, depending on whether my critiques are helpful or harmful), but I hesitate to spam d-l too much with it while working out the basics. Working on this on d-legal is fine. Ignoring threads you don't want to participate in is a basic mailing list skill, and pulling things out into tiny separate lists is a big hassle for those who do. (Personally, I'll follow the discussion on d-legal, and participate when I have something to add, but if it's on another list I probably won't follow it at all.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Affero General Public License
(Kai Hendry) I thought I should just check with you guys if the license is OK for Debian. (Steve Langasek) No, it is not. The requirement of source redistribution to third parties that you are not distributing binaries to is incompatible with the DFSG. (Benj. Mako Hill) I don't think that issue is a closed one. We are, however, certain that the Affero version is non-free. It is non-free because it imposes restrictions on modifying the program. It requires that the *program* contain facilities to send source to users. That is *definitely* not compatible with the DFSG (and is practically extremely annoying and obnoxious), even if some alternate clause requiring source distribution (such as I suggested to the FSF) might be. -- Nathanael Nerode [EMAIL PROTECTED] (Instead, we front-load the flamewars and grudges in the interest of efficiency.) --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Affero General Public License
Florian Weimer wrote: It seems that web.py does not include the source transmission facility mentioned in the AGPL. As a result, the additional clause is void, and the license should be DFSG-free. Unfortunately the clause is not void. (1) This is a copyleft, so all derivative works must use the same license; (2) unlike clause 2c which applies if the *modified* program satisfies certain conditions, clause 2d applies if the Program as you received it satisfies certain conditions So if I create a derivative work of web.py (webplus.py) which *does* include the facility mentioned in the AGPL, no subsequent derivative works of webplus.py can ever remove it. This regardless of *my* desires as the author of the source transmisison facility! This is pretty hideous. I don't know if it's non-free, but I'd guess so. Is there a way around it? Dual-licensing my portions of webplus.py under a free license, and then distributing only in patch form (so that the recipients never receive webplus.py as a single work)? No, that wouldn't allow binary distribution. -- Nathanael Nerode [EMAIL PROTECTED] Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
On Tue, 7 Feb 2006, Florian Weimer wrote: It seems that web.py does not include the source transmission facility mentioned in the AGPL. As a result, the additional clause is void, and the license should be DFSG-free. As noted by Mark Rafn, a derivative work which added the source transmission facility would suddenly be non-free. Even if the author of the source transmission facility did not want to apply the restriction. I couldn't find any way around it. I don't think this is a free restriction. It's certainly a hideously ugly restriction. This unique problem arises from two things: this license is a copyleft; and clause (d) applies if the Program as you received it satisfies certain requirements. In contrast, clause (c) applies if the *modified* program satisfies certain requirements. -- Nathanael Nerode [EMAIL PROTECTED] Theocracy, fascism, or absolute monarchy -- I don't care which it is, I don't like it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
quote who=Bill Allombert date=Tue, Feb 07, 2006 at 04:15:49PM -0600 On Tue, Feb 07, 2006 at 11:00:00AM -0500, Benj. Mako Hill wrote: I *do* think that the spirit behind the AGPL and Affero-inspired clause in the GPLv3 is fully in line with our principles. *Users* of software should be able to modify their software. There is the issue of defining *users*. My definition of the user of a software would be the person that is in control of hardware on which the software run. The Affero clause actually reduce their ability to modify their software. I don't think we need to turn this into a semantic argument about the term user. The authors of the free software definition and both versions of the GPL think that users are people who, well, *use* software. Use in this case is defined according to the most common dictionary definition of that word. This definition does not, it turns out, mention hardware. You can claim that loss of software freedom only occurs on hardware that is owned or controlled by the victim without claiming that people who use google do not actually *use* their software. I think our collective santity is best served by some consistency in terminology. :) Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
On Tue, Feb 07, 2006 at 02:00:03AM +, Kai Hendry wrote: There is a python library I want to package (#349763) that uses the Affero General Public License (AGPL). http://www.affero.org/oagpl.html I thought I should just check with you guys if the license is OK for Debian. No, it is not. The requirement of source redistribution to third parties that you are not distributing binaries to is incompatible with the DFSG. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Affero General Public License
quote who=Steve Langasek date=Mon, Feb 06, 2006 at 06:20:25PM -0800 On Tue, Feb 07, 2006 at 02:00:03AM +, Kai Hendry wrote: There is a python library I want to package (#349763) that uses the Affero General Public License (AGPL). http://www.affero.org/oagpl.html I thought I should just check with you guys if the license is OK for Debian. No, it is not. The requirement of source redistribution to third parties that you are not distributing binaries to is incompatible with the DFSG. I don't think that issue is a closed one. As you and others have mentioned in other threads, the GPLv3 will probably have a Affero-type clause. Several people, at least, have spoken up in favor of this sort of clause being both in the spirit of the GPL and the DFSG. Even if there was some sort of rough consensus on the AGPL in the past, I think that we need to *at least* discuss this a bit more and and a bit more widely before we risk writing off some large future subset of GPL works as being non-free. As it turns out, I tend to be of the opinion that it is important enough that users be able to have access to the source code of the programs they use that we can probably sustain a strictly targetted and flexibly defined limit on modification that serves only to protect this freedom. We did something similar both for copyleft in general and for GPLv2(2)(c) in particular. I would love to see web.py in Debian. I suspect that, one way or another, the this issue will be resolved in the GPLv3 process. :) Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.cc/ signature.asc Description: Digital signature
Re: Affero General Public License
On Mon, Feb 06, 2006 at 11:53:22PM -0500, Benj. Mako Hill wrote: I don't think that issue is a closed one. As you and others have mentioned in other threads, the GPLv3 will probably have a Affero-type clause. The GPLv3 having such a clause has no relevance to its freeness. A non- free restriction doesn't become free because the FSF decided to use it. That said, the draft does not have such a clause; rather, it says something like Affero-like clauses are not incompatible. That's unfortunate, and encourages people to do probably non-free things, but it's not non-free itself. Several people, at least, have spoken up in favor of this sort of clause being both in the spirit of the GPL and the DFSG. I've seen it said that its *goal* is to protect against behavior that is against the spirit of copyleft. Worthy goals don't make non-free things free. This means that we might be willing to accept a restriction that does this, if they get rid of the collateral damage, but nobody has yet offered an approach to this that does so. Even if there was some sort of rough consensus on the AGPL in the past, I think that we need to *at least* discuss this a bit more and and a bit more widely before we risk writing off some large future subset of GPL works as being non-free. It was just re-discussed recently, around the GPLv3 draft, I believe. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Benj. Mako Hill wrote: quote who=Steve Langasek date=Mon, Feb 06, 2006 at 06:20:25PM -0800 On Tue, Feb 07, 2006 at 02:00:03AM +, Kai Hendry wrote: There is a python library I want to package (#349763) that uses the Affero General Public License (AGPL). http://www.affero.org/oagpl.html I thought I should just check with you guys if the license is OK for Debian. No, it is not. The requirement of source redistribution to third parties that you are not distributing binaries to is incompatible with the DFSG. I don't think that issue is a closed one. As you and others have mentioned in other threads, the GPLv3 will probably have a Affero-type clause. Several people, at least, have spoken up in favor of this sort of clause being both in the spirit of the GPL and the DFSG. There are two separate, mostly-independent issues with the AGPL: 1) The issue of whether this type of clause is OK at all. This is certainly an open issue. I lean towards saying that it is theoretically possible for such a clause to be free but that no such clause has been written in an existing license. I think the most likely way to achieve a free clause of this type would be to base it on the GPL and phrase it in such a way as to impose exactly the same clauses which apply to distribution, along with all the proposed alternatives. 2) The specific clause written in the AGPL. Even if the answer to (1) is that such clauses are fine in general, the particular clause in the AGPL makes restrictions pertaining to particular technologies. It is not possible to modify AGPLed software in such a way that it no longer contains an HTTP server. This seems quite obviously non-free. Even if there was some sort of rough consensus on the AGPL in the past, I think that we need to *at least* discuss this a bit more and and a bit more widely before we risk writing off some large future subset of GPL works as being non-free. I believe issue 1 merits further discussion. However, regarding issue 2, I don't believe the clause in the AGPL is anywhere near free, and I don't see how any possible reading of the DFSG could permit it. As it turns out, I tend to be of the opinion that it is important enough that users be able to have access to the source code of the programs they use that we can probably sustain a strictly targetted and flexibly defined limit on modification that serves only to protect this freedom. Are you suggesting that such restrictions are acceptable under the DFSG, or are you suggesting that such restrictions might be beneficial and thus we should adapt the DFSG to permit them? We did something similar both for copyleft in general True. However, note that copyleft seems to be specifically permitted by the DFSG, since it only requires that modifications and derived works be distributable under the same terms as the license of the original software. and for GPLv2(2)(c) in particular. Bad example; if that clause were in any other license, it probably would have been declared non-free a long time ago. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Affero General Public License
* Steve Langasek: On Tue, Feb 07, 2006 at 02:00:03AM +, Kai Hendry wrote: There is a python library I want to package (#349763) that uses the Affero General Public License (AGPL). http://www.affero.org/oagpl.html I thought I should just check with you guys if the license is OK for Debian. No, it is not. The requirement of source redistribution to third parties that you are not distributing binaries to is incompatible with the DFSG. It seems that web.py does not include the source transmission facility mentioned in the AGPL. As a result, the additional clause is void, and the license should be DFSG-free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
