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
