On Fri, Mar 07, 2003 at 04:56:12PM -0500, David Turner wrote:
> On Fri, 2003-03-07 at 05:01, Anthony Towns wrote:
> > 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.
Take, say, xine as an example. Nice free program. GPLed. Someone wants
to add support for Quicktime to it, but wants to get royalties for
it. The write a Quicktime to mpeg convertor, and put that up on their
website. They require you to pay a subscription to have access to that
service. They hack xine so that it can use the service automatically.
You then have a new version of xine that can play Quicktimes, but users
don't get the source to the code that plays Quicktimes.
> Do you propose forbidding such
> modifications? That would be seriously risky for DFSG-compatibility.
No, I'm just saying it's part of "closing the ASP loophole". I don't think
the ASP "loophole" is something that should be closed.
> > 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.
This isn't necessarily possible, or particularly feasible. It's not
the right argument, anyway: consider trying to convince RMS that in
the case of someone writing a C# frontend to the gcc backend, that
"Free Software simply has to make a Free Software replacement for the
proprietary frontend".
Patenting the algorithms used to decode the stream of information from the
server, or using technological measures (encryption of the datastream and
heavy obfuscation to block reverse engineering) can make development of a
free client significantly difficult.
> > 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.
No, for AGPL'd programs we would be *forced* to change this
practice. We're forced to distribute qmail in source form too, that's
why it's in non-free not main.
> > and that sort of care is what puts things in non-free.
> No, non-compliance with DFSG is what puts things in non-free.
*shrug*
The Affero license discriminates against people doing SMS messaging: it's
not possible for them to use the program due to the license conditions.
> > 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.
Having xchat run a web server is not something that's good for security.
Likewise, your random webapp is probably going to just use your existing
webserver's http code, which likely isn't going to be easily copyable
into xchat.
> > 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.
I'm not required by any software licenses to make a webpage available. The
aim of the RPSL and the AGPL are to require me to make the source code
available. Blocking these attempts could very easily block legitimate
requests for the source code, and put me in violation of either the
letter or the spirit of the license.
> > 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).
The RPSL currently requires me to make the source code publically available.
But that's not the point: the point is I have to make the source code
available. I don't even have a copy of the source code to most of my
system at present; downloading it or getting a CD and installing it would
be a nuisance and possibly expensive; making sure I actually have enough
disk space for it would be a nuisance.
> > 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.
Uh, that's a pretty facile claim. If the program already has HTTP source
distribution, you're required to either use it as is, verbatim, or to not
modify that particular piece of code out of the way. That's pretty much
saying "If you use this program, you make the source available via HTTP.".
> > 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.
*shrug* I'm not writing this as "Debian", I'm writing it as "Anthony
Towns".
We distribute free software because it's what's best for our users;
but we're a distributor, code we author is pretty much "glue" stuff that
helps make other software work a little bit better.
The considerations are different for people who're authoring free
software, and for people who're releasing proprietary code as free
software (or under free-er terms). Corporations especially are generally
not trained to think primarily of what's good for their customers, but
rather what's good for their owners -- which is merely usually what's
good for their customers.
And as far as that goes, the benefits for the owners of the company
are decreased expenses in maintaining and developing that software,
balanced by decreased proprietary rights in that software. Proprietary
rights are one commercial advantage that commoditisation will remove.
> But nobody argued when Brandon proposed that the FSF's
^
*cough*
Cheers,
aj
--
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:
pgpzrUc5aLct6.pgp
Description: PGP signature