Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.

[Sven Luther <sven.luther@wanadoo.fr>]

On Thu, Aug 19, 2004 at 10:42:36PM +1000, Matthew Palmer wrote:
> On Thu, Aug 19, 2004 at 02:45:11PM +0200, Sven Luther wrote:
> > On Thu, Aug 19, 2004 at 09:56:45PM +1000, Matthew Palmer wrote:
> > > On Thu, Aug 19, 2004 at 01:56:07PM +0200, Sven Luther wrote:
> > > > Now, you may claim that the patch may be more significant than the original
> > > > code, or equaly so. But then, in this case, it would be argued which of those
> > > > correspond to a derived work of the other. My position is that each one is a
> > > 
> > > I think it'd be pretty clear which was which.  Your work was developed as a
> > > result of what was already provided under the QPL.  The work resulting from
> > 
> > It is not always that clear, imagine two works, A and B, which can integrate
> > well enough, but each one could be a patch of the other, or vice versa.
> 
> Nope, I'm having a great deal of trouble imagining two independently
> developed works each of which could be a patch to the other.

Imagine, to stay in the ocaml line of things, that someone A developed a new
bytecode JIT virtual machine, independently of anything related by the original QPLed
software. Imagine now that someone else B, developed a bytecode language, a
ocaml or java clone for example. Now consider the two scenarios :

  1) A takes the code from B, and integrates is bytecode compiler, replacing the
     loosy slow primitive virtual machine, or even plain interpreted or C
     translated version B did originally use.

  2) B is not competent in writing virtual machines, looks around the web, and
     finds the work of A. He then decide to take the virtual machine, and
     incorporate it in his own work.

In both the 1) and 2) case, the respective developer would have to create a
patch to the other software, since it is QPLed. 

> Note that libraries linking to each other don't apply, as they're not
> modifying each other.

Well, i guess the FSF would argue against this, woudln't they ?

> I really cannot think of how two works, each of which is a modification of
> the other, could ever come to be, short of time travel or some such.

The way of patching is just a clumsy way of combining or merging two different
code bases. Notice that the QPL says : 

  3. You may make modifications to the Software and distribute your
  modifications, in a form that is separate from the Software, such as
  patches. The following restrictions apply to modifications:

And speaks of modifications that are distributed in a separate form, patches
are only a common example of those. Imagine an arch/svn/bk like repository,
and each modification a changeset on top of each other for example.

> > > the combination of the original software and your patch is a derived work of
> > > both, but thankfully the initial developer isn't bound by the terms of the
> > > QPL because he got an all-permissions, so you've got bupkis.  Similarly, any
> > > modifications that the original author does to your work don't fall under
> > > the "modified versions" rule, because the initial developer didn't need to
> > > accept the QPL to modify your work.
> > 
> > So what ? It is just a patch, no interaction with the original software at
> > all, unless it is compiled that is.
> > 
> > Now, if you consider those patch as only small piece of modification from the
> > original software, like, err, the patches they are, then it is only fair to
> > notice that there is some disymetry of importance between the huge work having
> > gone in the original software, and the smallish patch you have sent upstream,
> > and thus it is no wonder that you find this same disymetry in the licence and
> > attached rights too.
> 
> "You didn't do much, so you don't deserve freedom".

Ok, i said there is a disymetry, but it is not a disymetry which limits your
freedom in anyway, if just gives more freedom to the upstream author, so ...

> "You're only users, you don't deserve source".

I sincerely defy you to find anywhere in what i wrote the place where i even
hinted at such a thing. Also QPL 3b especially says that the modification may
be made proprietary (or BSDed or GPLed or whatever), as long as the same
software is also released under the QPL. So sources are available, in at least
the same degree than the GPL makes them available.

> > > > derived work of the other, each being QPLed, and so each get the same licence
> > > > and the same benefit, in particular your right to claim upstream's code is a
> > > > derived work of your own stuff, and can thus be incorportated in your own code
> > > > base, provided upstream incorporate your work.
> > > 
> > > The QPL doesn't talk of derived works as such[1], merely modified versions
> > > of the original software.  Your modification, though it may constitute 90%
> > > of the resulting codebase, is still a modified version of a QPL'd work.  (In
> > 
> > Well, i have somehow the feeling that this would be something you could go to
> > court and argue over.
> 
> I wouldn't like to.  We generally accept that there are two ways to create a
> derived work, linking and modification.  Each is dealt with separately in
> the QPL.  I doubt you'd have an easy time convincing a judge that the
> licence authors really had no idea what they were doing, and mistook
> "modified" as "derived".

No, but in such case, i believe there are previous cases (or whatever you call
those in legalese words) where people argued over which is the original and
which is the modification. Indeed i believe the ridicoulous SCO vs IBM case is
exactly of this kind, isn't it ? 

> > > that case, you'd be nuts not to just rewrite the other 10% and freely
> > > licence it, but we'll leave that alone for now).  All modifications of a
> > > QPL'd work have to follow the guidelines in 3b.
> > 
> > But still, the copyright of your patch or modification remains with you,
> > altough upstream has the right to integrate it, and all persons further
> > patching it are thus obliged to give you the same right you give upstream,
> > so ...
> 
> The upstream author still doesn't have to abide by the same terms I had to. 
> All I can do is take modifications to my patch and do whatever I like to
> them.  Whoop-dee-doo!  I still have an asymmetric relationship with
> upstream.

And ? the same goes for upstream. He can only take the downstream patches,
isn't it ? Given the QPL, and if you didn't had this asymetric case, only
BSDish situation would be allowed. And even there, it is still asymetric, but
in the other direction.

Now, the real question in matters freedom is, what does it cost you if
upstream is able to make your modifications proprietary ? I claim it costs you
nothing.

Friendly,

Sven Luther