[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Should the ASP loophole be fixed? (Re: The Affero license)

On Mon, 2003-03-10 at 17:33, Henning Makholm wrote:
> Scripsit David Turner <novalis@novalis.org>
> > On Sun, 2003-03-09 at 14:49, Henning Makholm wrote:
> > > True. Ever since I started reading debian-legal, one of the tests
> > > applied when we consider the freedom of a license has been, "can it be
> > > used in a business?" 
> > That depends on the type of business, doesn't it?
> No, it doesn't. We require of free software that a business must be
> allowed to modify and run it on their own hardware for whatever
> purpose they think make business sense, *including* providing a
> service to their customers for profit, and *without* jumping through
> hoops.

When you say "providing a service", you are inadvertently concealing a
significant difference between printing an invoice for a customer, and
the customer interacting with the software.

> > The question is, then, whether (2)(d) is a hoop.
> It clearly is. We have ample precedent on d-l that even things like
> "make a good-faith attempt to send an email to the upstream author"
> constitutes a hoop and will make a license nonfree if it's stated as a
> condition for distributing modified copies.  And that's a lot less
> onerous than forced distribution of the modified code itself - it is
> only real trouble in extreme situations like the desert island
> scenario, but would be non-free even if it tried really hard to
> exclude inhabitants of desert islands from the requirement, simply
> because it is a hoop.

I don't think that's true.  d-l accepts all sorts of hoops, such as:

1. requiring that modified source be distributed as patches+original
(so, no public CVS, since cvs co gives fully-merged source).  

2. requiring that license text be maintained in 
	a. code (GPL, etc) or
	b. doco (Apache, etc)

3. requiring alternate names for 
	a. executables (Perl) or 
	b. packages (Apache)

4. disallowing certain people from copying, modifying, or distributing
altogether on the basis of their past actions (IBM public license
section 7 [iirc], GPL section 4)

5. requires altering notices in each source file (LGPL section 3, and
yes, FSF knows it's a bug)

In light of the above, I understand d-l's hoop policy to be that hoops
must be not too onerous (that is, that easy hoops are not hoops), and
that they serve substantial Free Software interests (I'm not sure, now,
if I want to stick by my previous "strict scrutiny" standard, since that
clearly doesn't match the actual decisions of d-l).  They also must not
violate certain basic rights, but there's all sorts of disagreement on

For instance, some people think it's OK for primary copyright holders
(whatever that means) to demand source code access.  Some people think
users should be able to.  Some think only distributees should be able
to, and some (Theo de Raadt comes to mind) think that nobody should.  

So, I think the Desert Island test is one way to determine if a hoop is
truly a hoop.  

-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: