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

Re: APSL 2.0



Mark Rafn <dagon@dagon.net> writes:
> On Thu, 7 Aug 2003, Jeremy Hankins wrote:

>> Well, the APSL specifically says that the service must be "through
>> electronic communication" to qualify:
>
> Ok, though this is an arbitrary distinction, and I'd argue that something 
> that restricts e-mail communication is no more free than something that 
> restricts snail-mail communication.

Email isn't entirely electronic unless it's also automatic.  If you
type in the message and send it, there's a decidedly non-electronic
(well, non-digital) element: you.

> Anyway, rephrase my question to "why would delivery over e-mail confer 
> fewer rights to a user than delivery over http or RMI (or RMI over HTTP)?"

If it's via an automatic responder with no human intervention?  No
reason at all.

>> Though that was as much my mistake as yours, for choosing my example
>> carelessly.  How about a web server, instead?  Do you think that
>> using a web server to make your content available to others qualifies
>> as providing a service?
>
> Very much so.  
>
>> Do you think Apple thinks so?
>
> I'd be shocked if they didn't, though I can't speak for them.

Well, who knows, you may be right.  But I very much doubt that's
really the case they're after, even if they would think it's caught by
the license.  A point worth clarifying.

>> In the list you referenced, the service goes electronic when Joe
>> receives the document via email, munges it, and sends it back. 
>
> How about if he delivers it by hand, and recieves it via e-mail?

Nope.

>> It's only when Joe sets up a procmail recipe that
>> automatically munges, and then sends back the results, that the
>> APSL is triggered. IMHO, at any rate.
>
> Interesting opinion, but it seems to me it's one based on what you'd
> like to happen, rather than what the license actually says.

It's also based on what I think Apple is most concerned about.  But
yes, the license is certainly not clear on this point.

>> I'm not convinced we can clearly get non-free out of the DFSG on
>> this one.  I don't buy the discrimination against fields of
>> endeavor, and unlike the affero GPL this isn't a restriction on
>> modification.
>
> It's a restriction on use (per definition 1.4 section b).  DFSG has
> no explicit item that use of the software must not be restricted,
> but any use restriction completely breaks users' trust of the
> freeness of Debian.

This seems like a very difficult argument to know when to make.  Do
you apply it to any new license, suggesting that any license not
already in Debian will break users' trust of Debian's freeness?

>> It's a restriction, yes.  And not one I particularly like, if the
>> truth be known.  But the analogy between this restriction and the
>> source-redistribution restriction of the GPL is simply too strong for
>> me to ignore it.
>
> Completely different.  GPL is about distribution, and specifically says 
> that no use of the software is restricted.  APSL limits use.

So?  This is a serious question: why does that matter?

Note that there are two types of restrictions (either for
modifications or for use): restrictions *on* the modification or use,
and hurdles that must be jumped iff the work is modified/used.

The GPL places both kinds of restrictions on modification, but only
the latter is being placed on use by the APSL.

>> If you assume that the definition of "Externally
>> Deploy" (or more specifically, "provide a service") is going to be
>> reasonable I have trouble seeing where you can say it's not DFSG free.
>
> I haven't thought of any definition of "externally deploy" that is 
> reasonable.  I suspect none exists.  

Ok.  Say that it must be electronic and automatic (i.e., no human step
in the process).  Perhaps you could further say that it's exempted if
all it does is provide a well-known protocol.  So a web server would
be excepted, but not RPC access to proprietary functions.

-- 
Jeremy Hankins <nowan@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03



Reply to: