[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-license
Subject:    Re: Covered Code Workarounds
From:       Mike Shaver <shaver () mozilla ! org>
Date:       1999-12-07 3:14:01
[Download RAW message or body]

Daniel Veditz wrote:
> Any license that allows combination with proprietary additions has this
> problem, but we hope the Mozilla Public License minimizes the problem to
> acceptable limits. Only a true copyleft license (which allows for NO
> proprietary extensions) would prevent this completely, but for various
> reasons (see the license FAQ) Netscape felt it could not use the GPL.

The GPL is still vulnerable to this attack, in other forms: if I use
some form of RPC, then I can have dependencies on some piece of Evil
Proprietary Code for correct behaviour.  If your argument is that
someone could provide an open-source implementation of whatever is on
the other side of that RPC, then the same logic can be applied to the
implementation of ::Baz().  In the case of CORBA and ORBs that provide
in-process servers, the programmer might never know if the call in
question crosses a process boundary, which appears to be the magical GPL
demarcation point -- if you look at how the GPL is interpreted by
non-lawyers, rather than the language of the license, anyway.

Jason, you say that:
> My whole purpose in evaluating the MPL was
> because I wanted to make sure that Modifications to my Original Code
> would be made available to the public for everyone (me, especially) to
> benefit and learn from.

The MPL provides _exactly_ that, but it does not -- by design! -- impose
licensing terms on things which are not Modifications.  Under the terms
of the license, Modification vs. New Code is determined at the
granularity of source files (rules about ``derived work'' apply, of
course).  When we were originally designing the license, we talked
(briefly) about how to prevent the scenario you describe -- which is
perhaps somewhat counter to the spirit of the license, I guess -- but
there just didn't seem to be a good solution.  You want to start by
talking about not introducing ``link-time'' dependencies on non-MPL
code, maybe, but then you get into the issue of dlopen(3) and other
space-age technologies.  (Oh, and you get to define ``link-time'' for
lawyers and judges, which is likely to be Unlimited Amounts Of Fun.)

It sounds like you want to require other files to be under the MPL as
well, which would not be without cost: we would lose LGPL/BSD+ad/etc.
compatibility, since there's not much conceptual difference between
pulling in GNU_somefunc from liblgpl.so and pulling in Foo::Baz from
nastySecretBadBad.cpp.

I hope that this makes things a little clearer, though I fear that it
will do the opposite.

Mike
(still not a lawyer)

-- 
2533698.79 2456892.24

[prev in list] [next in list] [prev in thread] [next in thread]