Re: ocaml, QPL and the DFSG: New ocaml licence proposal.
On Tue, Aug 03, 2004 at 09:05:56AM +0200, Sven Luther wrote:
> On Mon, Aug 02, 2004 at 11:38:58PM +0200, Francesco Poli wrote:
> > On Mon, 2 Aug 2004 09:23:11 +0200 Sven Luther wrote:
> >
> > > Now, what would be your ground for the original author not respecting
> > > the QPL of the patch ?
> >
> > I think that the initial developer does not have to comply with the QPL
> > of the patch, because he/she already has the rights he/she needs (the
> > right to integrate the patch in future versions of the Original Software
> > and the right to distribute them under any other license as long as they
> > remain available under the QPL too).
> >
> > > He is allowed to apply its proprietary licence,
> > > as long as he also adds the patch to the QPLed version, thus allowing
> > > you the same rigths under the QPL back ?
> >
> > Let's look at the QPL license under which my hypothetical patch is
> > distributed.
> > Who is the "initial developer" in this instance of the QPL license?
> > Is it me? I don't think so: I'm not the initial developer of the
> > Software, I'm just a contributor, because I created a derived work of
> > the Software.
> > Hence (if it's true that I'm *not* the initial developer, not even for
> > the QPL applied to the patch), I don't get any special right from
> > further modifiers that must comply with the QPL: the true initial
> > developer gets it!
>
> I don't think you can go this way, since the QPL insists on patches that are
> separate from the original work, then these standalone patches can as well be
> applied to some other software (well, there are other kind of separate
> distribution than just patches), and thus the upstream author has to live by
> the same rules when he integrates your patches,
Aaah, but he doesn't, because of the permission grant you have given in 3b
as a result of accepting the QPL. Regardless of any licence under which
your modification may be distributed, you have given the initial developer
an all-permissive licence.
There's a possible loophole I've just discovered in the licence which you
might want to notify upstream about if it turns out right. See the bottom
for my analysis.
> and thus create a derived work from your patches.
So Patch P is a derived work of software S, and software S' is a derived
work of P? In that case, would there be reason to presume that the author
patch P is an Initial Developer of S', and hence has all of the same rights
as the Initial Developers of S?
That would result, after several iterations of patch application, in
software S''''', which would have many Initial Developers, all of whom have
an all-permissive licence to changes to software S'''''.
Earlier you said that keeping track of which submitted changes have
permission grants or copyright assignments would be a problem. Do you
believe it would be any less onerous to keep track of who qualifies as an
"initial developer" for the purposes of determining who has preferential
rights to modifications to an arbitrary version of the software?
This becomes a larger problem when considering that a patch will likely
apply cleanly to several versions of the software. If a patch Q is
developed against version S'' but applies cleanly to S''', it would likely
be very difficult to determine whether I, as an initial developer of S'''
but not of S'', have preferential rights to Q, without a lot of detail into
the development process of Q.
Trying to track all of these changes suddenly makes getting permission
grants for contributions downright simple...
> > But I'm not allowed to, because the QPL forces me to grant additional
> > permissions to the initial developer.
>
> But by integrating the patch, he gives you the same kind of rights, so ...
So there is now an ever-widening set of people who can create proprietary
works. Cool. You've also effectively argued that the patch clause in the
QPL is totally non-effectual as soon as I get upstream to include a patch of
mine, because I have an all-permissive grant to the changes to my patch
(which you appear to indicate is the entireity of the original software,
once my change has been integrated) thus I can distribute however I like,
with whatever other patches I like.
Methinks you might not want to be pushing that argument.
As to the loophole: 3b says "When modifications to the Software *are
released under this license*, a non-exclusive royalty-free right is granted
to the initial developer" (emphasis mine). So if the changes are released
under a different licence, upstream is screwed -- especially if it's a
QPL-incompatible licence (such as the GPL). The only circumstance I can
find where a change must be released under the QPL is when binary
distribution takes place. If I only distribute my patch, upstream has no
special right to my code.
Considering that you have said that upstream really, really wants to be able
to sell my changes, I think this clause might want to be reviewed to see if
it really does what upstream wants it to do, because as it stands, unless I
distribute my changes in binary form or explicitly under the QPL, OCaml has
no right to it.
Again, a straight permission grant or copyright assignment would cause this
problem to go away, because unless I'm doing binary distribution, OCaml
needs it before it can sell my changes even with OCaml under the QPL as it
currenly is. And licence incompatibility is going to totally screw with
cherry-picking changes as it stands.
- Matt
Reply to: