Re: The Affero license
I'm glad this came up. We've been encouraged by the FSF to take a good look at the Affero license to accomplish things we're trying to accomplish with the RPSL, specificallly closing the ASP loophole[1]. However, it looks like the Affero license is still pretty controversial in this crowd. So, does this group think the ASP loophole is worth closing, and if so, what is the right way to close it? If not, why not? Rob [1] http://newsforge.com/newsforge/00/11/01/1636202.shtml?tid=19 -- Rob Lanphier, Helix Community Coordinator - RealNetworks http://helixcommunity.org http://rtsp.org http://realnetworks.com On Thu, 2003-03-06 at 21:56, Anthony Towns wrote: Breaking the thread and changing the subject. On Thu, Mar 06, 2003 at 04:26:08PM -0800, Thomas Bushnell, BSG wrote: David Turner [EMAIL PROTECTED] writes: * d) If the Program as you received it is intended to interact with And, the real killer, it fails the Chinese dissident test rather massively. How so? If the government can't get to your regular data, then there's no reason for it to be able to get to the source code you provide either. I agree with the other concerns entirely. Also, specifying a protocol in a license is a horribly bad thing; HTTP isn't useful everywhere, and requiring you to rewrite the program entirely when the protocol becomes obsolete is missing the point of free software pretty thoroughly. Cheers, aj
Re: The Helixcommunity RPSL is not DFSG-free
tb == Thomas Bushnell [EMAIL PROTECTED] writes: tb In my opinion, there is little of value to be gained by tb predicting horrible dire things which are unlikely to happen. tb (You note yourself that if it does happen, we would be tb surprised...) I'm taking this offlist with Thomas. bye, andrea -- Andrea Glorioso [EMAIL PROTECTED] Centro Tempo Realehttp://www.centrotemporeale.it/ AGNULA/DeMuDi Technical Manager http://www.[demudi|agnula].org/ There's no free expression without control on the tools you use
Re: The Helixcommunity RPSL is not DFSG-free
tb == Thomas Bushnell [EMAIL PROTECTED] writes: tb It's not absolutely useless, unless you suppose that requests tb are useless things, and that only force and obligation are of tb any value. I find it quite useless in licenses, yes. They add bloat and tend to help misinterpretation of the license. I'm perfectly fine with request, though. bye, andrea -- Andrea Glorioso [EMAIL PROTECTED] Centro Tempo Realehttp://www.centrotemporeale.it/ AGNULA/DeMuDi Technical Manager http://www.[demudi|agnula].org/ There's no free expression without control on the tools you use
Re: The Helixcommunity RPSL is not DFSG-free
rl == Rob Lanphier [EMAIL PROTECTED] writes: rl This is basically our attempt at closing the ASP loophole.[1] I understand that's a problem. As I wrote, I think your expectations of seeing modifications given back in is best reached by setting up such a competitive infrastructure that people are actually encouraged to give back in. What are you going to do, chase down every person who modified Helix and started up an independent broadcasting business? That's going to buy you nothing but hate from those who you need most, developers and hackers (please note I use the original sense of the term). bye, andrea -- Andrea Glorioso [EMAIL PROTECTED] Centro Tempo Realehttp://www.centrotemporeale.it/ AGNULA/DeMuDi Technical Manager http://www.[demudi|agnula].org/ There's no free expression without control on the tools you use
Re: The Helixcommunity RPSL is not DFSG-free
tb == Thomas Bushnell [EMAIL PROTECTED] writes: tb Number (b) is not what the RPSL says, however. What it says tb is that you have to make it publicly available. Number (b), tb as you rightly point out, is the GPL condition. I agreee. I was trying to point out my understanding of the problem. I find (b) a good balance between giving back and not imposing burden on people. How to actually encourage people to give back in is a completely separate issue which cannot, IMHO, be resolved via a license (not more than you can't make people not steal by having laws against stealing, as everyday life shows us). bye, andrea -- Andrea Glorioso [EMAIL PROTECTED] Centro Tempo Realehttp://www.centrotemporeale.it/ AGNULA/DeMuDi Technical Manager http://www.[demudi|agnula].org/ There's no free expression without control on the tools you use
Re: The Affero license
On Fri, Mar 07, 2003 at 12:00:49AM -0800, Rob Lanphier wrote: I'm glad this came up. We've been encouraged by the FSF to take a good look at the Affero license to accomplish things we're trying to accomplish with the RPSL, specificallly closing the ASP loophole[1]. However, it looks like the Affero license is still pretty controversial in this crowd. So, does this group think the ASP loophole is worth closing, and if so, what is the right way to close it? If not, why not? I think it's a bad thing to do. I'm not really convinced the ASP loophole is a loophole at all -- I'm not even really convinced that the GPL's attempts to cover various forms of dynamic linking aren't over-reaching. My take on the situation is this. Free software's about benefiting users; it's about giving them more control over the systems they use, and get more benefits, and flexibility, and functionality out of it. It's not fundamentally about users giving stuff back to the author -- that's why we don't like send me any changes you make, but don't mine pass on the source along with the binaries. In the ASP case, there are two sorts of users of the software: the company, and it's customers. The loophole that's trying to be closed, is the possibility of the company screwing its customers by giving them only partial control of the software they're trying to use. The sorts of set ups possible could be: Company's Protocol Customer's Server Specification Client --- -- --- free software standardised, free software publically availableroyalty-free ad-hoc protocol, free implementation in-house software, internal protocol based on free s/w internally developed software proprietary server patented, royaltiesproprietary client required --- -- --- and the basic aim is to move everyone on higher on that table. (There are missing possibilities, obviously) To digress, I'm not really convinced that the Affero license does that very well. It seems to only be talking about the server side, but equally plausible seems to me to be taking a free client, implementing some additions on the server side, and adding some hooks to talk to it. This is the standard issue that comes up with dynamic linking and the GPL. Likewise, making a proprietary client and making it absolutely impossible to get any use out of the server modifications without the client. Hrm, actually I don't think it even works. It's trivial to get a copy of the program, not modify it at all, and setup a wholly separate filtering proxy to ensure no one actually can activate the immediate transmission by HTTP of the complete source. Anyway. Pretending that we had something that /did/ work, it still probably wouldn't be acceptable. For one thing, Debian's a binary distribution; we make source available to everyone, but we don't routinely install it on users' systems. This saves space and time to download it, and isn't something we're going to change anytime soon. So we'd have to be especially careful about packaging Allegro, and that sort of care is what puts things in non-free. Since it's viral, it means you can't take some nifty url parsing function from your favourite webapp, and use it in, say, xchat or an IRC bot (depending on how you want to interpret interact with users), without having to give xchat some method of exporting its source code via HTTP (or maybe DCC, or similar). If the license was effective, and it covered a large program, you wouldn't be able to use it on small sites since the request source would be a trivial denial of service attack -- if not on your machine or connection, potentially on your wallet for those of us who have to pay for traffic. It doesn't work well in the general case, either. Taking the RPSL [0] as an example; if everything (linux, glibc, everything) were licensed under it, you'd be required to make the source code to the entire system available as soon as you give anyone else an ssh account. It's also unstable: if you have to apply a security patch to your webserver yourself because Debian is running a day late and you're getting a bit paranoid, you suddenly find yourself in a position of having externally deployed some modifications, and as well as checking the security fix worked, you'll suddenly have to find some way to make the source code publically available too. These clauses fundamentally aim to be restrictions on use, which we've never allowed in free software, and they're not matching the activities: it's entirely reasonable for distribution of one thing (binaries, say) to require distribution of another (source); or for modification of
Re: The Affero license
at == Anthony Towns aj@azure.humbug.org.au writes: at In any event, releasing code as free software is best thought at of as a way of commodotizing the technology, and in some cases at outsourcing the RD costs -- to your competitors if you're at especially lucky. It's not really about protecting you from at competition by your users. I couldn't agree more. Great food for thought. bye, andrea -- Andrea Glorioso [EMAIL PROTECTED] Centro Tempo Realehttp://www.centrotemporeale.it/ AGNULA/DeMuDi Technical Manager http://www.[demudi|agnula].org/ There's no free expression without control on the tools you use
Re: The Affero license
Rob Lanphier [EMAIL PROTECTED] writes: So, does this group think the ASP loophole is worth closing, and if so, what is the right way to close it? If not, why not? In my daily work, I adapt a lot of free software and use it in an ASP-like environment. If the licenses closed the ASP loophole in a way that forced me to publish *all* these changes (and AFAIK that's one of the things which people are considering), then I could not use this software because preparing the changes for distribution is often impossible (due to time constraints and local configuration intertwined with the code). Forced publication of in-house development considerably increases the cost of running software. Furthermore, I believe that it's of no one's business what's going on on my computers, even if I use these computers to offer some service.
Re: the FSF's definition of Free Software and its value for Debian
On Thu, Mar 06, 2003 at 06:35:24PM -0500, David Turner wrote: On Wed, 2003-03-05 at 15:42, Thomas Bushnell, BSG wrote: The status quo is not tolerable, and if the comments are not published by the FSF soon, it seems to me that someone else should take the task upon them of publishing them. They were eventually published: http://www.gnu.org/licenses/fdl-1.2-comments.txt (in May 2002, linked from http://www.gnu.org/server/whatsnew.html; but in spite of the comment on that page, apparently not from http://www.gnu.org/licenses/fdl.html) On Thu, Mar 06, 2003 at 06:39:16PM -0500, David Turner wrote: Sure -- that's one reason why the standardizing on the FSF's Four Freedoms is so good -- invariant sections *clearly* don't serve any of the four. So, considering the comments made and the FSF's lack of response [0], it's probably time for us to do a brief and simple GNU FDL Considered Harmful write up [1], and a review of our documentation to see what needs to be forked from an earlier version or moved into non-free. What, exactly, do we consider harmful about it? I'm not convinced that ``You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute.'' [2] is enough to make GFDL docs non-free even without invariant (c) sections; applying that to things like an padlock or an off-switch on a photocopier doesn't seem entirely reasonable to me. I guess we need to cover: * What's wrong with the GFDL and what problems can it cause * What documentation authors can do to avoid these problems (use the GPL instead? avoid invariant sections?) * How the GFDL could be fixed Can someone other than me take care of this? Cheers, aj [0] See Branden's summary from November: http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00285.html [1] A la KDE's old Qt v GPL issue, http://www.debian.org/News/1998/19981008 [2] http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00287.html -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpPGyxsjxzDL.pgp Description: PGP signature
Re: the FSF's definition of Free Software and its value for Debian
On Fri, Mar 07, 2003 at 11:47:52PM +1000, Anthony Towns wrote: * What's wrong with the GFDL and what problems can it cause Interesting link via google: The FOLDOC computing dictionary has been licenced to us under GFDL without invariant sections. We have incorporated many articles from them. Two weeks ago, somebody asked me whether the material from our TeX article (http://www.wikipedia.com/wiki/TeX), which was originally based on FOLDOC's but has since grown considerably, could be reintegrated into FOLDOC. The answer is: only if they put our Wikipedia table into the FOLDOC entry, which they are unlikely to do because it doesn't really fit with their article formatting. -- http://www.wikipedia.org/pipermail/wikipedia-l/2002-June/002238.html Some back-story available in: -- http://www.wikipedia.org/pipermail/wikipedia-l/2001-October/000624.html Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpYu0QVF5XWn.pgp Description: PGP signature
Re: PHPNuke license
On Thu, Mar 06, 2003 at 06:14:03PM -0500, David Turner wrote: There's a similar case in the LGPL (finding it is left as an exercise for the reader). In practical terms, I think the FSF pretends these glitches don't exist, and that these aren't violations. And tries to fix them for the next version. I'll add this to my comments on the issue. While I am glad that the FSF is not pursing people that have run afoul of glitches, I should also point out at this point that many people besides the FSF own copyright on GPL-licensed works, and are not necessarily as inclined to be reasonable. All I'm trying to say here is that a quick fix would be nice.
GPLv3 2(d) (was Re: PHPNuke license)
David Turner [EMAIL PROTECTED] writes: Can we please, please, please start another thread to discuss this?! done that's enough reason for me to stop releasing code under version 2 or later of the GNU GPL: the persistent spectre that future versions will prohibit certain sorts of functional modifications. That would be silly, since you could always fall back to v2. The only reason to fear v2 or later is that v3 could be too permissive, not too restrictive. No; if I release software under v2 or later, and a v3 with this clause is released, I have a problem: somebody can take my work, make modifications to it, and distribute it in such a way that I cannot use it. Even if he gives me the source code, I can't make use of his modifications without upgrading the licensing of my code to v3. If I'm going to give people the freedom to take my code and make it non-free[1], I might as well just put it under an MIT license. Wouldn't a requirement that if you make the software available for use to another party, you provide an offer of source to those users make much more sense, and avoid entanglements with the function of the software? That would be impossible under US copyright law, where use isn't one of the 17 usc 106 exclusive rights, while modification is. Public performance is restricted by copyright law; I'd certainly consider an Apache web server to be a public performance of Apache. In any case, there's another problem I allude to above but didn't mention clearly: the existing requirements for source distribution are very flexible. This proposed 2d imposes technical limitations on functionality. Every time a license tries to use exact technical definitions, it ends up breaking a few years later. I'm not nearly as worried about the HTTP requirement as I am about the definition of computer network. Is my USB keyboard/mouse a network? How about my Bluetooth keyboard? When I'm interacting through an anonymizing mix-net, there's a decent chance I'm not online when the other side is. Are we interacting through a network? What about a web client which responds to certain server requests for its source[2]: it may not have any way to hear a request from the server, and if it's used as the skeleton for an embedded control system, all that junk needs to go along with it. I'd far prefer to see a GPLv3 grant and guarantee more freedom, not less: * Remove technical requirements such as 2c, the object/executable langauge in 3, the header/Makefile and OS exceptions in the later section of 3. * Remove the strange definition that a work containing nothing both creative and derived from a GPL'd work be considered a derivative of the GPL'd work: that is, remove the definition that linking is modification. It's not in the license now, but clearly state that if you incorporate nothing creative from the GPL's work, you are not a derivative work. * Add public performance to the scope clause in 0, permitting (for example) me to give a lecture on the details of GNUtls, or to run a web server which presents an interface to Perl. -Brian Footnotes: [1] That is, modify and distribute it in non-free ways. [2] Admittedly, an odd case. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: transformations of source code
On Thu, Mar 06, 2003 at 06:04:01PM -0500, Branden Robinson wrote: This is directly analogous, I think, to the reason the GNU GPL doesn't have a clause forbidding selling a work so licensed for $1 million. It's not necessary -- either no one will buy it, and the software might as well not exist, or anyone willing to pay the price can immediately undercut you (and someone can undercut him, and so forth), causing a rapid price decline down to something approximating a nominal fee. This is, in fact, the basis for an economic model for funding the development of intellectual property, without copyright. The basic idea being that even if something's widely available and freely copiable, people aren't going to make massive numbers of copies available at cost, they're going to want to make a profit themselves. And if you're a reputable enough vendor to be confident of your margins, you can afford to pay a one-off cost for some free software and recoup that because you'll be first-to-market. http://levine.sscnet.ucla.edu/papers/pci23.htm http://levine.sscnet.ucla.edu/papers/ip.ch1.pdf http://levine.sscnet.ucla.edu/papers/ip.ch2.pdf and http://levine.sscnet.ucla.edu/ in general. There's maths and everything. I haven't verified the maths, but the hand-waving seemed plausible. (These were linked on slashdot a while ago) http://www.aei.brookings.org/publications/abstract.php?pid=302 Also looks interesting. You've got to love an article that's willing to argue in all seriousness that copyright law -in toto- is unconstitutional in the US. Sorry, that's probably all hopeless off-topic, but it's just so cool. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgppt3kc3KDlp.pgp Description: PGP signature
Re: PHPNuke license
On Thu, Mar 06, 2003 at 06:36:08PM -0500, Don Armstrong wrote: On Thu, 06 Mar 2003, David Turner wrote: On Tue, 2003-03-04 at 14:19, John Goerzen wrote: BUT -- (2)(c) ONLY takes effect if the user is distributing the source to a modified program AND that program is intractive. No! (2)(c) doesn't contain the first part of that -- it doesn't require distribution! See my other messages in this thread. You're ignoring 2 itself: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:[4] What exactly am I ignoring here? Nothing here seems to require that I distribute modified copies. In fact, the [1] you cited agrees with me. Additionally, fair use itself limits even the applicability of the copyright, as explained in [1] [2] and [3]. Don Armstrong 1: http://lists.debian.org/debian-legal/2003/debian-legal-200303/msg00121.html 2: http://lists.debian.org/debian-legal/2003/debian-legal-200303/msg00168.html 3: http://lists.debian.org/debian-legal/2003/debian-legal-200303/msg00261.html 4: http://www.gnu.org/licenses/gpl.html -- There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. Bach http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu
Re: the FSF's definition of Free Software and its value for Debian
On Thu, Mar 06, 2003 at 06:39:16PM -0500, David Turner wrote: On Wed, 2003-03-05 at 20:34, Branden Robinson wrote: I would ask that, *especially* if Debian formalizes my metaphor or builds upon it in any way, that the FSF not change its definition of Free Software without running it by us. :) Having URL:http://www.fsf.org/philosophy/free-sw.html change suddenly could come as a nasty surprise. I can't promise *anything* about what Richard will do to the FSF's website. But I do think that Debian needs to be kept in the loop. So, if Richard does it, you would be right to be upset at him. It might be best, then, if we just rewrote the Four Freedoms in our own words, and match the FSF's current effective definition as closely possible. -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | pgppdRe7pPPKp.pgp Description: PGP signature
Re: the FSF's definition of Free Software and its value for Debian
On Fri, Mar 07, 2003 at 11:47:52PM +1000, Anthony Towns wrote: So, considering the comments made and the FSF's lack of response [0], it's probably time for us to do a brief and simple GNU FDL Considered Harmful write up [1], As part of this, I think we should write a boilerplate rider that people who want to use the GNU FDL can apply, which will void those sections of the license we regard as non-free. This is much like existing OpenSSL linking exception riders that people put on GNU GPL, but I'd propose that we add a twist; derivative works must retain the terms in the rider. This would ensure GNU FDL-licensed works would not be able to be re-propritarized from our perspective. and a review of our documentation to see what needs to be forked from an earlier version or moved into non-free. Yes, that's going to be the painful bit, and the one that gets our hapless volunteer flamed to hell and back. What, exactly, do we consider harmful about it? I'm not convinced that ``You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute.'' [2] is enough to make GFDL docs non-free even without invariant (c) sections; applying that to things like an padlock or an off-switch on a photocopier doesn't seem entirely reasonable to me. I'm not convinced either, but I do see a potential threat to freedom here. Can someone propose some rider language that would retract the claws of that clause a little bit, such that most of us can agree it couldn't be applied in unfree ways? I guess we need to cover: * What's wrong with the GFDL and what problems can it cause * What documentation authors can do to avoid these problems (use the GPL instead? avoid invariant sections?) I think we should recommend multiple courses of action, one of which would be my GNU FDL plus Debian rider approach. I think if we take some pains to assure people that there are many ways to satisfy the DFSG (which is true), we'll meet with somewhat less hostility for breaking ranks with the FSF on this issue. * How the GFDL could be fixed It's my intention that the Debian rider language would pretty much encapsulate this goal. Can someone other than me take care of this? I'm willing to start a thread on here this weekend. -- G. Branden Robinson|Humor is a rubber sword - it allows Debian GNU/Linux |you to make a point without drawing [EMAIL PROTECTED] |blood. http://people.debian.org/~branden/ |-- Mary Hirsch pgpPvO5Fn8zWW.pgp Description: PGP signature
GPLv3 2(d) (was Re: PHPNuke license)
David Turner [EMAIL PROTECTED] writes: * d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work. It definitely does seem to me that if this can be done via a public performance restriction that would be much better. You may want to narrow the scope of public performance a bit (should apache or an ftpd be included?) -- define a term to cover the sort of public performances you're interested in. Then say that this sort of performance triggers the redistribution bit (written offer for source or distributed on the web, etc.). Possibly throw in the quine-like functionality as an optional way of satisfying that requirement. If the term used (public use, say) is defined a smidge too broadly that shouldn't be too terribly much of a problem. I may not like having to provide a link to the apache source when I put up a web page, but especially if I can satisfy that by pointing to the original location if I haven't changed it, I don't think it's a terrible burden. Nonetheless, defining this term is probably the hard part. I'm guessing that that's at least in part what you're trying to avoid by leaving it up to the original author to include the quine-like functionality. This scheme has the (profound, imho) advantage that it does not restrict the functionality (or text/source) of the derivative work. Otherwise you get into the game of trying to predict and account for later development and technology. If there's one thing that's obvious looking at the history of good intentions expressed in licenses, it's that predicting the future is a losing game no matter how you play it. IANAL, so I'm happy to be educated if this isn't workable for some reason. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: PHPNuke license
On Fri, Mar 07, 2003 at 02:08:26AM +0100, Henning Makholm wrote: Scripsit Don Armstrong [EMAIL PROTECTED] You're ignoring 2 itself: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:[4] Which is ambiguous in itself. It can either mean You may modify provided blah, AND you may copy provided blah. or You may [modify and then copy] provided blah. Such are the wonders of natural language. I'd like to go on record as requesting that the FSF clarify this in future versions of the GNU GPL, such that only distribution of modifications are limited by the license, not modification in and of itself. Imposing constraints on simple modification[1] is of questionable utility given the difficulty of enforcement, to say nothing of potential clashes with the principles of Fair Use, and the U.S. Constitution's guarantee of privacy rights[2]. Mr. Turner, can you pass this along to the appropriate people? [1] that is, modification that is not combined with some other activity germane to copyright [2] It's right there in Amendment IX; it's not my fault if some people are too stupid or too conservative[3] to notice it. [3] sorry for the redundancy in this statement -- G. Branden Robinson|The basic test of freedom is Debian GNU/Linux |perhaps less in what we are free to [EMAIL PROTECTED] |do than in what we are free not to http://people.debian.org/~branden/ |do. -- Eric Hoffer pgpe65lHk5oJZ.pgp Description: PGP signature
Re: The Affero license
Scripsit Florian Weimer [EMAIL PROTECTED] If the licenses closed the ASP loophole in a way that forced me to publish *all* these changes (and AFAIK that's one of the things which people are considering), then I could not use this software because preparing the changes for distribution is often impossible (due to time constraints and local configuration intertwined with the code). That's an excellent argument. And even if you said to the hell with it and offered download of your modified code with warts and all, a zealous upstream author might be (legally, not morally) justified in considering your intertwined local configuration, which may well prevent the software from running at all in another environment, to be an attempt to circumvent the sharing requirement, and sue you for infringement nevertheless. Forced publication of in-house development considerably increases the cost of running software. Furthermore, I believe that it's of no one's business what's going on on my computers, even if I use these computers to offer some service. Amen. -- Henning MakholmDe kan rejse hid og did i verden nok så flot Og er helt fortrolig med alverdens militær
Re: transformations of source code
Scripsit Anthony Towns aj@azure.humbug.org.au The basic idea being that even if something's widely available and freely copiable, people aren't going to make massive numbers of copies available at cost, Isn't that basic idea contradicted by (to pick a completely random example) Debian and its network of mirror servers? -- Henning Makholm Jeg har tydeligt gjort opmærksom på, at man ved at følge den vej kun bliver gennemsnitligt ca. 48 år gammel, og at man sætter sin sociale situation ganske overstyr og, så vidt jeg kan overskue, dør i dybeste ulykkelighed og elendighed.
Re: the FSF's definition of Free Software and its value for Debian
On Fri, Mar 07, 2003 at 10:34:23AM -0500, Branden Robinson wrote: On Fri, Mar 07, 2003 at 11:47:52PM +1000, Anthony Towns wrote: So, considering the comments made and the FSF's lack of response [0], it's probably time for us to do a brief and simple GNU FDL Considered Harmful write up [1], As part of this, I think we should write a boilerplate rider that people who want to use the GNU FDL can apply, which will void those sections of the license we regard as non-free. This is much like existing OpenSSL linking exception riders that people put on GNU GPL, but I'd propose that we add a twist; derivative works must retain the terms in the rider. This would ensure GNU FDL-licensed works would not be able to be re-propritarized from our perspective. You'd want to be careful about ending up with YA documentation license that's mutually incompatible with everything else out there. Or at least, very upfront about it, so people can avoid it. and a review of our documentation to see what needs to be forked from an earlier version or moved into non-free. Yes, that's going to be the painful bit, and the one that gets our hapless volunteer flamed to hell and back. So, how's X 4.3 coming along, anyway? ;) Can someone other than me take care of this? I'm willing to start a thread on here this weekend. Good-o. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpU98vbDOBVb.pgp Description: PGP signature
Re: OSD DFSG - different purposes
On Thu, 2003-03-06 at 17:34, Thomas Bushnell, BSG wrote: The difference is that a guideline, as we use the term, is an *internal* tool. We do not pretend that the guideline exhausts the meaning of free, but merely that it is a guideline. A definition, as the OSD is used, is a promise if you satisfy this, we will stamp your license 'free'. I don't want to quibble over semantics, but I don't think the meanings are as you suggest. The difference in meaning between guideline and definition would seem to be one of accuracy or rigorousness. For Debian's purposes I would say that our guideline is used much more like a definition. I can't see many conditions where we would waive *any* of the guideline's premises. It's tests, and our demand of compliance, is rigid and unforgiving. Now, the question of internal or external application is a different matter. Naturally, Debian doesn't want to have anyone mucking about in our processes. We have developed our own flame-rich methods for building agreement and we don't need outside authorities tampering with them. However, at a fundamental level, the tests we apply and the values we hold are intended to be the values of the community whose software we publish. We may not be the absolute picture of that community's values but our size, our internationality and our hands-on relationships with the upstream maintainers make us, in my opinion, the most definitive organization of that type in existence. People recognize this and look to us for guidance... just as OSI looked to us for guidance when they needed a definition for Free Software, erm I mean, Open Source. :) I don't think we can hide our heads under the covers. We are not an island. Debian's role in the world grows with each new user and each new developer we add to our ranks. We have to acknowledge and build agreement with other significant organizations so that our views and values are represented in their world as well as ours. When those organizations have views that make sense in our world (and some of OSI's ideas do make sense) we should seek to integrate them. In those cases where an organization's values conflict with ours and threaten our well-being we should be prepared to fight them in an organized way. -- _ Ean Schuessler [EMAIL PROTECTED] Brainfood, Inc. http://www.brainfood.com
Re: GPLv3 2(d) (was Re: PHPNuke license)
Scripsit Jeremy Hankins [EMAIL PROTECTED] received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and [...] It definitely does seem to me that if this can be done via a public performance restriction that would be much better. A public-performance restriction will still be non-free in my eyes, but it will not be quite as bad as a modification restriction. Assuming that one can meaningfully compare badness beyond the non-free label, that is. -- Henning Makholm Al lykken er i ét ord: Overvægtig!
Re: transformations of source code
Branden Robinson [EMAIL PROTECTED] writes: On Thu, Mar 06, 2003 at 11:23:47AM -0500, Jeremy Hankins wrote: This doesn't address proprietary or otherwise difficult but not impossible to reverse formats. I considered that but I'm not sure how much of a threat it really is. Perhaps so, but in that case you should probably remove the bit about availability of encryption keys as well. After all, the line between them is fairly fuzzy (think of css reading software for an example). Obfuscated but lossless transformations needn't be any easier to get clear than encryption. Perhaps you could expand the idea of a key to include anything necessary to reverse the process, and say that if the recipient can't reasonably be expected to have the key (or whatever word you want to use) it must be provided. This, I fear, would soon result in anybody who just wanted to distribute pre-compiled binaries into providing an entire Linux distribution. After all, if they have to distribute tar and gzip beside the source tarball, why not a toolchain as well? How about a text editor for actually making modifications to the preferred form? Presumably one could reasonably be expected to have (or have access to) a computer and OS, as well as tar gzip. But yes, it's a fuzzy line. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: the FSF's definition of Free Software and its value for Debian
On Sat, Mar 08, 2003 at 02:55:48AM +1000, Anthony Towns wrote: You'd want to be careful about ending up with YA documentation license that's mutually incompatible with everything else out there. Or at least, very upfront about it, so people can avoid it. I've been making bellicose statements about a DFCL (Debian Free Content License) for several months now. Things just keep coming in above it in the priority queue. YA documentation license, one that is a copyleft, may be the only option open to us. I'd be most interested if someone can suggest another course. and a review of our documentation to see what needs to be forked from an earlier version or moved into non-free. Yes, that's going to be the painful bit, and the one that gets our hapless volunteer flamed to hell and back. So, how's X 4.3 coming along, anyway? ;) :-P Just for that you get fed something out my boilerplates directory. [The following is a form letter.] Hello, You recently sent a message to me or to the debian-x mailing list, inquiring as to when Debian packages of XFree86 4.3.0 (which was released on 27 February) would be ready. Please do not send messages, whether privately, to a mailing list, or to any other forum, asking when Debian packages will be ready. Such messages serve only to nag me, and in many cases cause me to take time replying to redundant questions that I could spend working on the packages instead. Nagging me anyway might be enjoyable to you, or it might reflect your personal anxiety for the latest and greatest version of XFree86, but its effect on me is to take some of the fun and interest out of working on XFree86, and make it seem more like a chore. If you reflect on the fact that I have been maintaining XFree86 packages for Debian for the past five years in large part because I find it fun and interesting, you may not want to indulge in self-defeating actions that rob me of my motivation to continue doing so. Debian packages of XFree86 4.3.0 will be available as soon as I can reasonably have them prepared. Updates on my progress will be available at the following Web site: URL:http://people.debian.org/~branden/xsf/xsf.html XFree86 is a complicated collection of software, containing everything from a large application that contains its own ELF object loader (the XFree86 X server itself); to approximately a dozen shared libraries; over a dozen more libraries available in static form (which implement non-standardized X protocol extensions); several dozen other application programs (some of which are utilities, and some of which are X clients), including xterm (probably the most widely-used terminal emulator for Unix in history); a large of amount of localization data used by the X library (Xlib) and the XKEYBOARD protocol extension (XKB); and a bevy of large pieces of documentation that describe the X protocol, library implementations, and various protocol extensions. Furthermore, a very significant number of other packages in the Debian system ultimately depend on the XFree86 packages, either at build-time, run-time, or both; errors in XFree86 packaging, then, can be highly disruptive to the rest of the system, and it is unwise to release such packages, even into the Debian unstable distribution, before they've been fairly extensively tested -- many Debian package autobuilders and developers, for instance, run Debian unstable constantly, and sudden breakage of XFree86 can severely hamper them. Preparation and packaging of a new upstream release of XFree86 is not in any way analogous to that of most packages in Debian; it is a significant piece of infrastructure that must be handled with care and attention to detail. I do my best to handle it accordingly. Therefore, please be patient while I attempt to give the process of packaging XFree86 for Debian the diligence it requires. Thanks for using the Debian system! -- G. Branden Robinson| There's nothing an agnostic can't Debian GNU/Linux | do if he doesn't know whether he [EMAIL PROTECTED] | believes in it or not. http://people.debian.org/~branden/ | -- Graham Chapman pgpyEfDYE0mdo.pgp Description: PGP signature
Re: transformations of source code
On Thu, Mar 06, 2003 at 11:23:47AM -0500, Jeremy Hankins wrote: This doesn't address proprietary or otherwise difficult but not impossible to reverse formats. I considered that but I'm not sure how much of a threat it really is. There's no way to keep the sourced locked into an obfuscated format under my proposal; the first person to crack it open is free to redistribute it in obfuscated form. This is directly analogous, I think, to the reason the GNU GPL doesn't have a clause forbidding selling a work so licensed for $1 million. Unfortunately, in the age of the DMCA that isn't quite enough. Since the GPL has few restrictions on functional modification, it's not much of an issue there. A document license has a broader problem: the first person to crack it open would be violating the DMCA to do so. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: the FSF's definition of Free Software and its value for Debian
Branden Robinson [EMAIL PROTECTED] wrote: On Fri, Mar 07, 2003 at 11:47:52PM +1000, Anthony Towns wrote: * How the GFDL could be fixed It's my intention that the Debian rider language would pretty much encapsulate this goal. Perhaps I'm being a spoilsport, but I feel that the GFDL is just fatally flawed. It tries to enumerate transparent and opaque formats, when transparency and opaqueness are really context dependent. It has all of the crap with Cover texts, preserving network locations, Invariant sections, etc. I feel that effort would be better spent on making a good license, rather than fixing up the broken one. Otherwise Debian is just legitimizing the GFDL. Regards, Walter Landry [EMAIL PROTECTED]
Re: The Affero license
On Fri, 2003-03-07 at 00:56, Anthony Towns wrote: Specifying a protocol in a license is a horribly bad thing; HTTP isn't useful everywhere, and requiring you to rewrite the program entirely when the protocol becomes obsolete is missing the point of free software pretty thoroughly. We know the protocol thing is broken. We hope an intend to fix it. Wording suggestions are accepted. -- -Dave Turner Stalk Me: 617 441 0668 On matters of style, swim with the current, on matters of principle, stand like a rock. -Thomas Jefferson
Should the ASP loophole be fixed? (Re: The Affero license)
Rob Lanphier [EMAIL PROTECTED] writes: So, does this group think the ASP loophole is worth closing, and if so, what is the right way to close it? If not, why not? On Fri, 7 Mar 2003, Florian Weimer wrote: In my daily work, I adapt a lot of free software and use it in an ASP-like environment. If the licenses closed the ASP loophole in a way that forced me to publish *all* these changes (and AFAIK that's one of the things which people are considering), then I could not use this software Forced publication of in-house development considerably increases the cost of running software. Furthermore, I believe that it's of no one's business what's going on on my computers, even if I use these computers to offer some service. I wholeheartedly agree with both of these points. Of course, that's part of the goal of these licenses - to prevent the program from being used in a closed way. As recently as a year ago, I was firmly of the belief that the asp loophole (though I called it the server loophole IIRC) was a pretty large hole in the virality of the GPL. I still believe it is, but I'm no longer sure it needs to or can be fixed without compromising the utility of a lot (perhaps most) software. This is enough for me to consider non-free a license that attempts to do so. There are two competing parts to a viral copyright license. 1) freedom for the recipient of the software. This is the actual utility of free software - it can be modified to fit the needs of the recipient. Without this ability, there would be no reason to prefer free software over identical proprietary software. 2) restrictions on that freedom. This is fundamentally the duty to allow n-stage recipients the same freedoms as the first one enjoys, but other restrictions have been added by various licences, with varying degrees of success: a) the duty to allow n-stage recipients the same freedoms. b) the duty to add notices to documentation/advertising. c) the duty to add notices to interactive startup. d) the duty to give #1 rights to more than just downstream recipients. e) the duty to rename files. f) the duty to be noncommercial. g) the duty not to compete with the original author (cf. bitkeeper). h) the duty not to use the sofware for insert cause here. i-zzz) others too numerous to mention. This is clearly a balancing act. There are those who cannot or will not abide #2 in order to enjoy #1, for any given software package. Those people simply don't accept the license, and are limited to the rights they intrinsicly have (which may include modification in some cases, but almost never will include distribution). Software with a stronger #2 element is clearly less free that that with a weaker #2 element. However, since the #2 element is a benefit to both the software author and to the community at large, a certain amount of it is allowed (and encouraged). Item 2d is the point of contention WRT the ASP loophole. D-l has rejected licenses (rightly so) that try to extend #1 to the original author, and to the world at large. The question is whether users (or perhaps viewers of a performance) is an acceptible extension of the 2d restriction. My opinion is that it's a reasonable thing for a software author to want to do, but it is too restrictive for me to consider free. The vast majority of rejected almost-free licenses fit into this category for me. I'd far rather live with the loophole and accept that some people will make money by running a program with unpublished changes. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: The Affero license
Florian Weimer [EMAIL PROTECTED] writes: Forced publication of in-house development considerably increases the cost of running software. This is only true when you adopt a high falutin concept of publication. Make a tar file, put it on a web site, a five minute job. Advertise a bug-reporting and comments mailing address, and then a reflector on that list which says sorry, but we don't have the time or resources to answer your email or even read it. Another five minutes.
Re: The Affero license
David Turner [EMAIL PROTECTED] writes: On Fri, 2003-03-07 at 00:56, Anthony Towns wrote: Specifying a protocol in a license is a horribly bad thing; HTTP isn't useful everywhere, and requiring you to rewrite the program entirely when the protocol becomes obsolete is missing the point of free software pretty thoroughly. We know the protocol thing is broken. We hope an intend to fix it. Wording suggestions are accepted. Once again, pipe it to /dev/null. But that seems not to be accepted.
Re: The Affero license
Henning Makholm [EMAIL PROTECTED] writes: Scripsit Anthony Towns aj@azure.humbug.org.au On Thu, Mar 06, 2003 at 04:26:08PM -0800, Thomas Bushnell, BSG wrote: And, the real killer, it fails the Chinese dissident test rather massively. How so? If the government can't get to your regular data, then there's no reason for it to be able to get to the source code you provide either. Whut? The licence explicitly says that the modified program must provide its own the source code to whoever asks for it, including the government. The program must do so even if it protects the regular data from unauthorized access (by cryptographic techniques with keys stored separate from the source code, or whatever). And, my data might be non-sensitive, but the program might well be.
Re: transformations of 'source code'
Nick Phillips said: On Thu, Mar 06, 2003 at 06:06:23PM -0500, Branden Robinson wrote: If it's lossy, it can't be transformation; instead it is modfication. Basically the forms can be judged according to their purpose. The source form is the preferred form for making modifications. The object form is the form suitable for use in the intended function of the work, and an encoded or translated form which retains the meaning of the original source (i.e. it is still sufficient to achieve the object of the original source) should be OK to distribute, provided that the translation or encoding is reversible. Unfortunately, intent is one of the hardest things to prove in court. Non-reversible (i.e. obfuscated or encrypted in such a way that the recipient cannot recover useful source) should not be allowed I think the key there is _useful_ source. Obfuscated forms that can not be turned back into useful source should not be allowed. Encypted forms (if the recipient doesn't have the key) don't give useful source. Changing the author's preference of 8-spaces for indenting to 1-tab still gives useful source (even if the author wasn't consistant and information about the fact that function foo() only was indented 5 spaces, is lost) I'm just slightly stuck on defining exactly why obfuscation (which does retain meaning) is not OK but (in my view at least) translation into a foreign language (which retains meaning but, whilst reversible, is not quite losslessly so) is OK. I don't think that losslessness is the right criterion, rather something connected to the meaning of the source and the achievability of the source's object. Can have useful source recovered from it, in a form that is something for modification? I can't think of the something to put there. It's not preferable, it's not easy, it's not acceptable... Any thoughts? This requirement, while totally inadequate from a legal perspective, also explains the foreign language: Speakers of the foreign language get useful source from the transformations, and a second translation can get useful source back into the original language. --Joe
Re: lzw code patent
On Thu, 2003-03-06 at 18:52, Drew Scott Daniels wrote: I'm cc'ing debian-legal for the legal part of this discussion. LZW was a patented algorithm which was included in Unix's compress and some versions of the gif file format. There may not be reason to exclude lzw and related code as the LZW patent is running out. http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00160.html I hope that this will be discussed further on debian-legal. I also am curious as to whether Unisys can collect royalties after their patent runs out. I suspect this may be illegal, or at least immoral. I also wonder about whether patent laws can be used from one country on another. Regardless, I don't think it's too important as long as we make sure Debian doesn't do anything illegal. 35 USC 286 says that patent holders can go after infringers for *six years* after the patent expires. Of course, there's no infringement possible after the patent exprires (excluding certain bizarre rules surrounding bioequivalent generic drugs). -- -Dave Turner Stalk Me: 617 441 0668 On matters of style, swim with the current, on matters of principle, stand like a rock. -Thomas Jefferson
Re: OSD DFSG - different purposes - constructive suggestion!
Barak Pearlmutter said: Here is a rough outline of which I think it could look like: Q: How do you do this? Perhaps: Q: How do you determine if a license is DFSG-Free? (There isn't much context to figure out what this is) A: the process involves human judgment. The DFSG is an attempt to articulate some of our criteria. But the DFSG is not a contract. This means that if you think you found a loophole in the DFSG then you don't really understand how this works. The DFSG is a, potentially imperfect, attempt to express freeness in software. It is not something whose letter we argue about. It is not a law. Rather, it is a set of guidelines. Q: How can I tell if some license is free? A: well, the DFSG is a good start. You might also consider a few thought experiments which we often apply. 1. the desert island scenario. Imagine someone stuck on ... impossible to fulfill ... 2. the Chinese Dissident. It has been suggested that this test be referred to as simply as the Dissident test. Consider a dissident in China who wishes to share a modified bit of software with other dissidents, but does not want to reveal his own identity as the modifier or directly reveal the modifications to the government. Any requirement for ... Q: what does no discrimination mean? Doesn't the GPL discriminate against companies making proprietary software? A: Some more examples (beyond those in the DFSG) are ... The GPL does not discriminate against companies that want to make proprietary software because they are given the same rights to GPLed software that anyone else has. They just happen to also want the right to make the software non-free. No one is given that right, so this is not discrimination. Q: What about licenses that grant different rights to different groups? Isn't that discrimination, banned by DFSG#5/6? A: For Debian's purposes, if all the different groups can exercise their DFSG rights, it's OK if there are other people who can do more. For example, if a work were licensed under the 3-clause BSD license only to elementary school teachers, but the GPL to everyone else, it would be DFSG-Free. --Joe
Re: The Affero license
On Fri, 2003-03-07 at 05:01, Anthony Towns wrote: Hrm, actually I don't think it even works. It's trivial to get a copy of the program, not modify it at all, and setup a wholly separate filtering proxy to ensure no one actually can activate the immediate transmission by HTTP of the complete source. *FSF hat on* I discovered this after I left work yesterday, and have brought it up internally. *FSF hat off* If there's no way to rewrite the license to fix this, then I would assume that (2)(d) won't end up in GPLv3. -- -Dave Turner GPL Compliance Engineer Support my work: http://svcs.affero.net/rm.php?r=novalisp=FSF
Re: Should the ASP loophole be fixed? (Re: The Affero license)
On Fri, 2003-03-07 at 14:03, Mark Rafn wrote: I'd far rather live with the loophole and accept that some people will make money by running a program with unpublished changes. Of course, the issue is not money. The idea is that users of a program ought to be able to get the source code for that program. Users these days often use a program without ever having recieved a copy of it. Nobody thought of this in 1991. But times are changing. -- -Dave Turner Stalk Me: 617 441 0668 On matters of style, swim with the current, on matters of principle, stand like a rock. -Thomas Jefferson
Re: The Affero license
On Fri, 2003-03-07 at 11:29, Henning Makholm wrote: Scripsit Florian Weimer [EMAIL PROTECTED] If the licenses closed the ASP loophole in a way that forced me to publish *all* these changes (and AFAIK that's one of the things which people are considering), then I could not use this software because preparing the changes for distribution is often impossible (due to time constraints and local configuration intertwined with the code). That's an excellent argument. And even if you said to the hell with it and offered download of your modified code with warts and all, a zealous upstream author might be (legally, not morally) justified in considering your intertwined local configuration, which may well prevent the software from running at all in another environment, to be an attempt to circumvent the sharing requirement, and sue you for infringement nevertheless. This seems to be a serious stretch of the actual wording of (2)(d). One could also argue that any CD which includes GPL'd software is a derivative work of that software. But arguing it doesn't make it true. Let's talk about what the AGPL actually says, and not about how people might misinterpret it. The way (2)(d) works is that the original author writes suitable quine-like functionality, and people who modify the software can't remove it. There's no need by people who merely run the software to package anything up -- the software will be designed to do this by itself. -- -Dave Turner Stalk Me: 617 441 0668 On matters of style, swim with the current, on matters of principle, stand like a rock. -Thomas Jefferson
Re: OSD DFSG - different purposes - constructive suggestion!
Joe Moore [EMAIL PROTECTED] writes: 2. the Chinese Dissident. It has been suggested that this test be referred to as simply as the Dissident test. But the suggestion has not been taken. The point isn't to hammer at China--though such hammering seems well warranted--but to point to a *particular* kind of government repression, and not government repression in general. The Soviet Union would do as well.
Re: OSD DFSG - different purposes - constructive suggestion!
On Fri, Mar 07, 2003 at 05:49:28PM -0500, Joe Moore wrote: 2. the Chinese Dissident. It has been suggested that this test be referred to as simply as the Dissident test. /me grumbles about wasting time with excessive PC noises, rejects this suggestion and continues to call it the same thing -- Glenn Maynard
Re: OSD DFSG - different purposes
On Fri, Mar 07, 2003 at 11:02:41AM -0600, Ean Schuessler wrote: I don't want to quibble over semantics, but I don't think the meanings are as you suggest. The difference in meaning between guideline and definition would seem to be one of accuracy or rigorousness. For Debian's purposes I would say that our guideline is used much more like a definition. I can't see many conditions where we would waive *any* of the guideline's premises. It's tests, and our demand of compliance, is rigid and unforgiving. I think the distinction is in the other direction. What do we do with a license that meets the DFSG in every detail, but is still non-free? Debian would refuse such a license. I asked Russell Nelson what OSI would do in such a case, but I never received an answer. Richard Braakman
Re: The Affero license
On Fri, 2003-03-07 at 05:01, Anthony Towns wrote: I'm not really convinced the ASP loophole is a loophole at all -- I'm not even really convinced that the GPL's attempts to cover various forms of dynamic linking aren't over-reaching. This isn't any thing specific to the GPL, but to copyright law. My take on the situation is this. Free software's about benefiting users; it's about giving them more control over the systems they use, and get more benefits, and flexibility, and functionality out of it. [snip] In the ASP case, there are two sorts of users of the software: the company, and its customers. The loophole that's trying to be closed, is the possibility of the company screwing its customers by giving them only partial control of the software they're trying to use. Exactly. To digress, I'm not really convinced that the Affero license does that very well. It seems to only be talking about the server side, but equally plausible seems to me to be taking a free client, implementing some additions on the server side, and adding some hooks to talk to it. Do you mean a Free client altered to work with a proprietary server? I don't see the problem for freedom here. Do you propose forbidding such modifications? That would be seriously risky for DFSG-compatibility. Likewise, making a proprietary client and making it absolutely impossible to get any use out of the server modifications without the client. Free Software simply has to make a Free Software replacement for the proprietary client. Anyway. Pretending that we had something that /did/ work, it still probably wouldn't be acceptable. For one thing, Debian's a binary distribution; we make source available to everyone, but we don't routinely install it on users' systems. This saves space and time to download it, and isn't something we're going to change anytime soon. So we'd have to be especially careful about packaging [Affero], For AGPL'd programs, it would be easy to change this practice. Each program must be packaged individually anyway, and the packager should be able to work something out. and that sort of care is what puts things in non-free. No, non-compliance with DFSG is what puts things in non-free. Since it's viral, it means you can't take some nifty url parsing function from your favourite webapp, and use it in, say, xchat or an IRC bot (depending on how you want to interpret interact with users), without having to give xchat some method of exporting its source code via HTTP (or maybe DCC, or similar). You could simply copy the (2)(d) code from the webapp at the same time you copy the URL parsing code. If the webapp didn't have (2)(d) code, you wouldn't be bound by (2)(d). If the license was effective, and it covered a large program, you wouldn't be able to use it on small sites since the request source would be a trivial denial of service attack -- if not on your machine or connection, potentially on your wallet for those of us who have to pay for traffic. It would be no more of a DOS than allowing someone to simply repeatedly reload the web page... There are already solutions for this. It doesn't work well in the general case, either. Taking the RPSL [0] as an example; if everything (linux, glibc, everything) were licensed under it, you'd be required to make the source code to the entire system available as soon as you give anyone else an ssh account. ... but only to the person you gave the account to (since they're the only user). It's also unstable: if you have to apply a security patch to your webserver yourself because Debian is running a day late and you're getting a bit paranoid, you suddenly find yourself in a position of having externally deployed some modifications, Be careful -- the RPSL isn't the AGPL. The AGPL simply applies only if you modify the software, and says nothing about deployment. and as well as checking the security fix worked, you'll suddenly have to find some way to make the source code publically available too. The software would already have a way to do this built in. (see above) These clauses fundamentally aim to be restrictions on use, which we've never allowed in free software The RPSL's clause, yes. The AGPL's clause, no. The plain language of the AGPL says that (2)(d) describes *modification* of the software. [snip stuff about an argument I have no interest in] In any event, releasing code as free software is best thought of as a way of commodotizing the technology, and in some cases outsourcing the RD costs -- to your competitors if you're especially lucky. It's not really about protecting you from competition by your users. That's not the argument that I understand Debian has for Free Software. As I understand Debian's position, Free Software isn't about commodotizing technology, but about allowing users the freedom to alter and share the software they use. If I'm wrong, and these aren't Debian's principles,
Re: transformations of source code
On Fri, 2003-03-07 at 13:11, Brian T. Sniffen wrote: On Thu, Mar 06, 2003 at 11:23:47AM -0500, Jeremy Hankins wrote: This doesn't address proprietary or otherwise difficult but not impossible to reverse formats. I considered that but I'm not sure how much of a threat it really is. There's no way to keep the sourced locked into an obfuscated format under my proposal; the first person to crack it open is free to redistribute it in obfuscated form. This is directly analogous, I think, to the reason the GNU GPL doesn't have a clause forbidding selling a work so licensed for $1 million. Unfortunately, in the age of the DMCA that isn't quite enough. Since the GPL has few restrictions on functional modification, it's not much of an issue there. A document license has a broader problem: the first person to crack it open would be violating the DMCA to do so. Would this text fix the problem? 6.6. Each time you distribute the Program (or any work based on the Program), you grant to the recipient and all third parties that receive copies indirectly through the recipient the authority to gain access to the work by descrambling a scrambled work, decrypting an encrypted work, or otherwise avoiding, bypassing, removing, deactivating, or impairing a technological measure effectively controlling access to a work. Unimportant explanation of some of the above: *BAD TEXT FOLLOWS* 6.6. Each time you distribute the Program (or any work based on the Program), you grant to the recipient and all third parties that receive copies indirectly through the recipient the authority to gain access to the work by circumventing any technological access control measure. The problem with the text above is that the DMCA says that circumvention is defined as doind the things I listed *without* authority from the copyright holder. -- -Dave Turner Stalk Me: 617 441 0668 On matters of style, swim with the current, on matters of principle, stand like a rock. -Thomas Jefferson
Re: PHPNuke license
On Thu, 2003-03-06 at 21:06, Richard Braakman wrote: On Thu, Mar 06, 2003 at 04:26:08PM -0800, Thomas Bushnell, BSG wrote: Here's a disastrous consequence. [...] In this context (but not directly on-topic), I'd like to tell about a little service we had running at Wapit, where I worked on Kannel[1]. It was a limited facility for web browsing via SMS. You'd send it a message like www debian.org and it would fetch http://debian.org/, strip out all the tags, and send the contents back to you, in the form of one or more SMS messages. There was a limit of 9 messages for one page, I think. Over here an SMS message can only hold 140 bytes, usually holding 160 7-bit characters. If you want more, you have to send more of them, and generally pay for each one. The typical GPL blurb would use up a whole message, costing money (probably around $0.05) and annoying the user. It seems to me that there's a lot of stuff that you would want that gateway to strip or abbreviate. You would want to cut all copyright notices. Incidentally, it's probable that that service as-is violates a lot of copyright notices, by rebroadcasting the pages without permission. -- -Dave Turner Stalk Me: 617 441 0668 On matters of style, swim with the current, on matters of principle, stand like a rock. -Thomas Jefferson
Re: Should the ASP loophole be fixed? (Re: The Affero license)
On Fri, Mar 07, 2003 at 04:33:12PM -0500, David Turner wrote: On Fri, 2003-03-07 at 14:03, Mark Rafn wrote: I'd far rather live with the loophole and accept that some people will make money by running a program with unpublished changes. Of course, the issue is not money. The idea is that users of a program ought to be able to get the source code for that program. Users these days often use a program without ever having recieved a copy of it. People that telnetted in to central servers, I think, fell into this category even then. Nobody thought of this in 1991. But times are changing.
Re: The Affero license
Florian Weimer [EMAIL PROTECTED] writes: Forced publication of in-house development considerably increases the cost of running software. On Fri, 7 Mar 2003, Thomas Bushnell, BSG wrote: This is only true when you adopt a high falutin concept of publication. Make a tar file, put it on a web site, a five minute job. Advertise a bug-reporting and comments mailing address, and then a reflector on that list which says sorry, but we don't have the time or resources to answer your email or even read it. Another five minutes. You're not serious are you? Include sanitize for undesirable comments, re-architect to avoid an insecure hack, setup, house, and buy bandwidth for http and mail servers for all these extra things because your core service doesn't support those non-features. Sure, all those things (except the last) are optional, but in reality they mean I can't use this supposedly-free software. By the way, if I'm required to provide source via http, does that mean I'm in violation when my HTTP server is down for a week because I've exceeded my bandwidth limit, (assume my affero-based-non-http server is still running because it has a different bandwidth agreement, or runs on a different medium)? -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: OSD DFSG - different purposes - constructive suggestion!
On Fri, 7 Mar 2003, Joe Moore wrote: Q: How can I tell if some license is free? Q: How do you determine if a license is DFSG-Free? An additional point to make is that a license is neither free nor non-free. Packages are judged for freeness, not licenses. Two packages with the same license could be judged differently based on extra-license comments the copyright holder has made regarding intent or interpretation, or based on how the content of the package interacts with license stipulations. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: Should the ASP loophole be fixed? (Re: The Affero license)
On Fri, 2003-03-07 at 17:28, John Goerzen wrote: On Fri, Mar 07, 2003 at 04:33:12PM -0500, David Turner wrote: On Fri, 2003-03-07 at 14:03, Mark Rafn wrote: I'd far rather live with the loophole and accept that some people will make money by running a program with unpublished changes. Of course, the issue is not money. The idea is that users of a program ought to be able to get the source code for that program. Users these days often use a program without ever having recieved a copy of it. People that telnetted in to central servers, I think, fell into this category even then. True, but they also typically had access to copy binaries (and therefore, get source code). -- -Dave Turner Stalk Me: 617 441 0668 On matters of style, swim with the current, on matters of principle, stand like a rock. -Thomas Jefferson
Re: Should the ASP loophole be fixed? (Re: The Affero license)
On Fri, Mar 07, 2003 at 04:33:12PM -0500, David Turner wrote: The idea is that users of a program ought to be able to get the source code for that program. Users these days often use a program without ever having recieved a copy of it. Nobody thought of this in 1991. But times are changing. On Fri, 7 Mar 2003, John Goerzen wrote: People that telnetted in to central servers, I think, fell into this category even then. Heck, leave telnet out of it. People have used software they don't have a copy of since forever. I'd guess vending machines might be the earliest common example. This isn't a new problem to be addressed. And the underlying debate has nothing to do with networking technologies. The questions are: 1) can software that forces a recipient to distribute it to non-recipient users still be considered free? 2) even if it can be considered free, is it worth the incredible hassle to recipients to add such a demand? My answers are no and no. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: The Affero license
On Fri, 2003-03-07 at 16:17, Brian T. Sniffen wrote: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Florian Weimer [EMAIL PROTECTED] writes: Forced publication of in-house development considerably increases the cost of running software. This is only true when you adopt a high falutin concept of publication. Make a tar file, put it on a web site, a five minute job. Advertise a bug-reporting and comments mailing address, and then a reflector on that list which says sorry, but we don't have the time or resources to answer your email or even read it. Another five minutes. That's not sufficient for a modern corporation: you have a duty to the shareholders to carefully examine all the code before publishing it, to ensure that no competitive advantage is lost or corporate resource squandered. You might have proprietary information embedded in the code (database passwords in your PHP-Nuke modifications, for example) or sensitive information in comments. It takes at least a couple of developers to read the entire source you're about to publish, together with an IP lawyer and somone versed in the operations of the company available to answer their questions. This is true any time you publish source code. Will you suggest that section 3 (requiring the publishing of source code when binaries are distributed) be stricken for this reason too? When you set up the mailing address, you're advertising it as a way to contact your company about these issues; I'm not a lawyer, but don't you have a responsibility to live up to that obligation? No. Not to mention the public relations hit from just spewing your code out there: this community is fickle, and a poorly done release is a great way to annoy it. None of this mailing list stuff has anything to do with the actual AGPL. -- -Dave Turner Stalk Me: 617 441 0668 On matters of style, swim with the current, on matters of principle, stand like a rock. -Thomas Jefferson
Re: OSD DFSG - different purposes - constructive suggestion!
On Fri, 07 Mar 2003, Mark Rafn wrote: An additional point to make is that a license is neither free nor non-free. We've examined licenses before to determine whether they live up to the DFSG in the general sense, although you are correct that such an interpretation doesn't necessarily extend to packages under those licenses with additional stipulations or clarifications. Don Armstrong -- America was far better suited to be the World's Movie Star. The world's tequila-addled pro-league bowler. The world's acerbic bi-polar stand-up comedian. Anything but a somber and tedious nation of socially responsible centurions. -- Bruce Sterling, _Distraction_ p122 http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgp3zqWpWc398.pgp Description: PGP signature
Re: Should the ASP loophole be fixed? (Re: The Affero license)
On Fri, 2003-03-07 at 17:27, David Turner wrote: On Fri, 2003-03-07 at 17:28, John Goerzen wrote: On Fri, Mar 07, 2003 at 04:33:12PM -0500, David Turner wrote: On Fri, 2003-03-07 at 14:03, Mark Rafn wrote: I'd far rather live with the loophole and accept that some people will make money by running a program with unpublished changes. Of course, the issue is not money. The idea is that users of a program ought to be able to get the source code for that program. Users these days often use a program without ever having recieved a copy of it. People that telnetted in to central servers, I think, fell into this category even then. True, but they also typically had access to copy binaries (and therefore, get source code). If I'm not mistaken, the official FSF position on this issue is that that is not distribution. From http://www.gnu.org/licenses/license-list.html regarding the LPPL: The LPPL makes the controversial claim that simply having files on a machine where a few other people could log in and access them in itself constitutes distribution. We believe courts would not uphold this claim, but it is not good for people to start making the claim. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: PHPNuke license
On Fri, 07 Mar 2003, John Goerzen wrote: What exactly am I ignoring here? Nothing here seems to require that I distribute modified copies. Perhaps I misunderstood you. What I was getting at is that 2 a-c doesn't apply to modifications you make that you do not distribute. Don Armstrong -- Dropping non-free would set us back at least, what, 300 packages? It'd take MONTHS to make up the difference, and meanwhile Debian users will be fleeing to SLACKWARE. And what about SHAREHOLDER VALUE? -- Matt Zimmerman in [EMAIL PROTECTED] http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgp17l6biRIWR.pgp Description: PGP signature
Re: The Affero license
[EMAIL PROTECTED] (Brian T. Sniffen) writes: That's not sufficient for a modern corporation: you have a duty to the shareholders to carefully examine all the code before publishing it, to ensure that no competitive advantage is lost or corporate resource squandered. You might have proprietary information embedded in the code (database passwords in your PHP-Nuke modifications, for example) or sensitive information in comments. But that's a self-imposed cost. It might be quite rational, but it's not someone else's fault that you choose to undertake that cost.
Re: The Affero license
Mark Rafn [EMAIL PROTECTED] writes: You're not serious are you? Include sanitize for undesirable comments, re-architect to avoid an insecure hack, setup, house, and buy bandwidth for http and mail servers for all these extra things because your core service doesn't support those non-features. I'm not in favor of the obligatory publishing clause. But it's still a fake objection to say I decided to impose on myself a $1M cost anytime I publish something, so it's not cheap for me to publish it. That's a self-imposed cost. Like I said this is because you adopt a high-falutin concept of 'publication'. thomas
Re: transformations of 'source code'
Joe Moore [EMAIL PROTECTED] writes: Unfortunately, intent is one of the hardest things to prove in court. Intent is not hard to prove. Indeed, for almost all crimes, criminal intent is an element of the crime, and it is regularly proved. Thomas
Re: Should the ASP loophole be fixed? (Re: The Affero license)
David Turner [EMAIL PROTECTED] writes: On Fri, 2003-03-07 at 14:03, Mark Rafn wrote: I'd far rather live with the loophole and accept that some people will make money by running a program with unpublished changes. Of course, the issue is not money. The idea is that users of a program ought to be able to get the source code for that program. Users these days often use a program without ever having recieved a copy of it. Nobody thought of this in 1991. But times are changing. By your usage: Right now I'm a user of the code on the router between me and you. I also am a user of the code my bank uses to track my balance. I'm a user of the code that the US Congress uses to track legislation for my congressman. I'm a user of the code that controls the lights in the Mummenschantz production I'm seeing tonight. I think this is a crazy usage. Nor was the GPL ever about giving the *users* the source code! Under the GPL I can run a system, and I am under no obligation to make the source code available to the users as long as I am not *distributing* the code to them, which in general, I am not. Indeed, *right now*, I am running such a system, and since I have not downloaded most of the source packages, I am not providing my users the source. And this is just fine, and as it should be, because the GPL says that if you *get a copy* of the program, then you have the right to the source, not that if you *use* a program, you somehow acquire the right to the source. Thomas
Re: the FSF's definition of Free Software and its value for Debian
On Fri, Mar 07, 2003 at 10:39:53AM -0800, Walter Landry wrote: Perhaps I'm being a spoilsport, but I feel that the GFDL is just fatally flawed. It tries to enumerate transparent and opaque formats, when transparency and opaqueness are really context dependent. It has all of the crap with Cover texts, preserving network locations, Invariant sections, etc. I feel that effort would be better spent on making a good license, rather than fixing up the broken one. Otherwise Debian is just legitimizing the GFDL. It may be a necessary step, though, if we want to retain *any* GNU manuals in Debian main, even the ones that have no Cover Texts or Invariant Sections. -- G. Branden Robinson| Debian GNU/Linux | Extra territorium jus dicenti [EMAIL PROTECTED] | impune non paretur. http://people.debian.org/~branden/ | pgpnoJZJvzRMM.pgp Description: PGP signature
