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. Note that libraries linking to each other don't apply, as they're not modifying each other. 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 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". "You're only users, you don't deserve source". > > > 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". > > 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. - Matt
signature.asc
Description: Digital signature
