[distcc] Re: Finding peers: zeroconf/rendezvous?

[Martin Pool]

On 25 Feb 2003, Bret Mogilefsky <mogul at gelatinous.com> wrote:

> "I audited this license while Apple was working on the draft. It's a good
> license. The only way in which it is GPL-incompatible is that it requires
> that you disclose some source code when the GPL would not. GPL only
> requires source code disclosure with distribution, APSL requires it if you
> use the code for your business [note: business but not individual use
> -mogul], even if you do not distribute it."

Yes, I agree that this is the "only" problem.  Being the only problem
does not imply that it is a minor problem.  (That's what the FSF page
says too, if you read the second paragraph carefully.)

Suppose person A wants to combine GPL'd and APSL'd code and distribute
that work, and that person B downstream wants to modify and
redistribute the work.  The GPL says that A *must not* impose
additional conditions on B.  The APSL says B *must* publish their
source.  Therefore they are incompatible; A cannot distribute this
work.  I think A would be allowed to write this but not distribute it,
but that's not very useful.

The GPL says that distributors may not remove particular rights of
their users, whereas the APSL wants to remove those rights.

The GPL says in clause 6 that 

      6. Each time you redistribute the Program (or any work based on the
      Program), the recipient automatically receives a license from the
      original licensor to copy, distribute or modify the Program subject to
      these terms and conditions.  You may not impose any further
      restrictions on the recipients' exercise of the rights granted herein.
      You are not responsible for enforcing compliance by third parties to
      this License.

> This seems to jibe with the FSF page you pointed to... The FSF's
> "disrespect for privacy" objection remains, but in this case You're not
> trying to keep changes private, because You're distributing them with
> distcc.  I think this is an instance where the two licenses overlap,
> though of course the usual IANAL disclaimers apply.

Note that most of the FSF page is about APSL 1.0, not 1.2.  However,
at the top they say there is still a problem with 1.2.

> I guess the question is, what happens when a business then takes distcc
> and makes modifications to the zeroconf portions of it for their private
> use, not realizing that that code is under the more restrictive APSL
> (restrictive in that you're required to make your changes known) and not
> the GPL?  In this case, distcc isn't violating the license, but that
> business would be. 

Do you mean violating the APSL Rendezvous licence?

> This may be reason enough not add zeroconf in the first place.  Then
> again it might be a reason TO do it, but make it available as a
> "contrib"-type patch to make the licensing requirements explicit.
> In that case it would still benefit anyone who's actually interested
> in helping distcc evolve (read: make their changes public), whether
> they're a business or individual.

Unfortunately even though the intentions are good, it is still
incompatible.  Distributing the patched code would (I think) violate
the distcc licence.

Hopefully an updated APSL 1.3 will resolve these problems, or somebody
will write a Rendezvous implementation under a free licence.  In the
meantime using a separate program to do mDNS avoids the issue.

-- 
Martin