On Fri, Aug 20, 2004 at 08:52:47AM -0400, Brian Thomas Sniffen wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > On Thu, Aug 19, 2004 at 09:38:24PM +1000, Matthew Palmer wrote: > >> On Thu, Aug 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: > >> > On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: > >> > > On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: > >> > > > > I don't see how this makes it non-free. You are distributing > >> > > > > under the > >> > > > > same license you received the software under, so DFSG 3 is > >> > > > > satisfied, > >> > > > >> > > But you're not. The license permissions you received don't permit > >> > > using > >> > > the code under a completely difference license; for example, you can't > >> > > link the code with GPL work, since the licenses are incompatible. > >> > > However, > >> > > you have to distribute your modifications under terms that *do* allow > >> > > the > >> > > original programmer to do so. The license terms you're forced to > >> > > release > >> > > modifications under are different from the ones you received. > >> > > >> > But if upstreqm incorporqtes your changes, thus creating a modification > >> > of > >> > your QPLed work, you have the same right as he has, don't you ? > >> > >> I really wish you'd stop pushing this barrel, because I have to keep > >> swatting it down. > > > > Well, it would be an interpetation that if followed would make people think > > two times before licencing stuff under the QPL. > > > >> The initial developer does not have to abide by the terms of the QPL with > >> regard to your changes, because he received an all-permissive licence to > >> them. > > > > It says : > > > > b. When modifications to the Software are released under this > > license, a non-exclusive royalty-free right is granted to the > > initial developer of the Software to distribute your > > modification in future versions of the Software provided such > > versions remain available under these terms in addition to any > > other license(s) of the initial developer. > > > > So, i don't see here an "all-permisive" licence. Just that they have the > > right > > to use the patch as part of future versions of the Software, provided it is > > under the QPL and some other licence. Nowhere do i see there that the > > initial > > developer has the right to ignore the QPL licence which covers the patch, > > and > > thus he is evidently bound by it. He still has the right to relicence it and > > distribute it though, agreed, but that doesn't mean he has the right to not > > respect the > > licence of the modificator, does it ? > > Thanks for going into detail about why you believed this. Now I think > I see where the misunderstanding is. The initial developer does get > to ignore any other license granted by the modifier, and here's why: > if I offer you some code under the GPL or the BSD license, then you > can pick. You don't have to distribute the source of your > modifications, because you can accept the BSD license and ignore the > GPL entirely. Because it's a license and not a bilateral (i.e., > common law) contract, it can't actually restrict him -- all it can do > is grant him permissions. If he doesn't like the conditions on those > permissions, he can ignore the whole bundle. > > So yes, the initial author doesn't have to respect a license of the > modifier unless he wants to make further modifications to the patch.
Well, you are equally unrestricted as long as you don't modify the original upstream code, are you not ? So this is indeed the same kind of permissions that apply to upstream when taking your patch than you when taking the original code. > Which, incidentally, is an issue. If some user sends you a patch for > O'Caml, you can't apply it, because then you'll be distributing > software under the QPL, and trigger QPL 3b, which means you have to > grant the initial author permission to relicense... but you aren't the > copyright holder for the patch, and so can't grant that permission. No, i don't believe this to be a problem. It is a separate patch, so whoever want to modify it, he can take your patch, the original upstream, build its own modified stuff based on both, and then release its own patch and binary distrib based on both your and his work in addition to the original work. Still, the fact that you are speaking of patches here is cosmetic. The reality is that all three persons involved here produce code, and that once it is integrated together, all three pieces of code are mutually derivatives of the two others, and thus the rights granted under the QPL flow in all ways. Friendly, Sven Luther