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. > 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 available royalty-free ad-hoc protocol, free implementation in-house software, internal protocol based on free s/w internally developed software proprietary server patented, royalties proprietary 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  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 one thing (some C code) to require modification of another (a changelog). Use and distribution just aren't a good match. The newsforge article comments: `` Take the example of a company whose main business is to provide a Web-based service. Its source code (which these days is usually written in some kind of scripting language) is never intended to be distributed in a binary form. Thus, if the company were to release their software under the GPL, as it currently stands, a competing company would be able to quickly and easily create a modified version of the first company's work, set it up on a public Web server, and start profiting without having to release changes. Thus, the original authoring company is discouraged from making its software free (as in speech), because it would put it at a competitive disadvantage.'' I don't understand why a free software advocate would be using this sort of logic; it's too easily translated to a defense of the use of proprietary software in general. ``Take the example of a company whose business is heavily dependent on a particular program. If the company were to release this software under the GPL, as it currently stands, a competing company would be able to quickly and easily create a modified version of the first company's work, set it up, and start profiting without having to release changes. Thus, the original authoring company is discouraged from making its software free (as in speech), because it would put it at a competitive disadvantage.'' That sort of argument should apply to ISPs and programs like sendmail and bind and spamassassin ; or database consultants and postgresql and mysql; or any number of other such things. It's a valid argument, but there are already countervailing forces that make it not that relevant. There's a vibrant php community out there, for example, that doesn't seem to have been decimated by the possibility of cool enhancements that never get contributed back. 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 R&D costs -- to your competitors if you're especially lucky. It's not really about protecting you from competition by your users. Anyway, I hope that provides some food for thought. Cheers, aj  http://www.opensource.org/licenses/real.php  A concrete example: receiving measurably less spam seems like a competitive feature in today's climate. Contributing your changes to spamassassin's rules removes a competitive advantage you could have if you kept your changes private, and used it only for your own customers. -- Anthony Towns <email@example.com> <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!''
Description: PGP signature