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
> R&D 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, then we first need to figure out what Debian's
principles are. But nobody argued when Brandon proposed that the FSF's
Four Freedoms be the "constitution" of license interpretation, and the
four freedoms arne't about "outsourcing R&D costs."
--
-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
Reply to: