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