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 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 [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 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 [1]; 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
[0] http://www.opensource.org/licenses/real.php
[1] 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 <aj@humbug.org.au> <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!''
Attachment:
pgpJ148m8TEzb.pgp
Description: PGP signature