discuss: Thread: licence problems


[<<] [<] Page 6 of 6 [>] [>>]
Subject: Re: [discuss] licence problems
From: David Lawyer ####@####.####
Date: 3 Oct 2008 18:50:07 +0100
Message-Id: <20081003172528.GA2370@davespc>

On Thu, Sep 25, 2008 at 02:58:10PM -0700, Rick Moen wrote:
> Quoting Jean-Daniel Dodin ####@####.####
> 
> > well, we can't discuss if you repeatedly challenge the other intelligence.
> 
> I am certainly not impugning anyone's intelligence:  All of this stuff
> is non-obvious, and nobody's born with understanding of it.  ;->
> 
> 
> > we may have problems to understand each others, but this licencing
> > problem is not that easy, that's why I keep discussing.
> > 
> > the problem is that GPL ask derivative works to have the very same
> > licence.
> 
> I'm not sure I see the relevance, but:  No, that is not the case.
But GPL does require the derivative work to have the same license.
But see what I say later on.
> 
> Here is another illustrative example.  Again, I find that people get
> very confused when they speak in vague generalities, so I use specific
> examples to clarify.  Let's say back in the late 1990s I coded an SSL
> library similar to OpenSSL, but I put it under the new-BSD licence.
> 
> Let's say that it's now 1999 and you're in a position similar to that of
> my friend Marc Merlin back at VA Linux Systems:  You're seeking to add
> TLS crypto capabilities to the Exim MTA.  You borrow new-BSD-licensed 
> code snippets from my SSL library codebase, and extend Exim's
> SMTP-session modules to use my code.  You now issue the resulting
> derivative work, which includes some of Phil Hazel's GPLed Exim code
> plus some of my new-BSD code, in a tarball.  The tarball therefore
> includes Phil's copyright statement, plus mine.  The various .h files
> indicate more-or-less who wrote what.
> 
> You've created and distributed a derivative work, something that
> requires permission from affected copyright owners.  Have you violated
> anyone's copyrights?  No.  My new-BSD licence statement on my SSL
> codebase permits what you've done.  Phil's GPLv2 licence statement on
> Exim has not been violated, either, because my new-BSD-licensed code
> that you've borrowed doesn't impose "additional conditions" above and
> beyond those of GPLv2 on the derivative work.
> 
> Is the tarball under "the very same licence"?  No, it's not.

Here's what I think and I may be wrong:
Well, it should be under the same GPL license, but has parts that are
sort of dual licensed under both GPL and BSD.  So it's sort of under
the same GPL license except that one may reuse the BSD licensed
modifications under the BSD license.  Also, for such reuse I think
one may be required to note the BSD licensed parts.  Alternatively,
the BSD parts may be lifted from the code and used under the BSD
license in ways that violate GPL.  In doing this, one could claim
that the code was obtained from a BSD archive that says nothing about
it being under GPL.  Since it's the same code, who knows where it came
from.  One might think of the GPLed code as also an archive of some
BSD code.  Even though the BSD parts were actually obtained from GPLed
code it's still pure BSD if you choose to take it under the BSD
license.  On the other hand, if you take this code for reuse under the
GPL license then it must be used in conformance with both GPL and BSD.
This works since BSD is so permissive that it doesn't conflict with GPL.

So something licensed under GPL may also be subject to other
permissions and requirements (or other licenses) so long as they don't
conflict with GPL.  GPLv3 has some rules as to how this works and
tries to define what constitutes a conflict, etc. but in looking it over
rapidly it doesn't seem too clear to me.

> My new-BSD-licensed code fragments are still new-BSD-licensed, and
> anyone who can pick them out of the derivative work has every legal
> right to use them elsewhere under new-BSD.  The code from Phil
> Hazel's upstream standard Exim codebase remains GPLv2-licensed.

But the  BSD parts are also GPL-licensed since the whole code is under
GPL.  By GPL I mean GPLv2 and by BSD I mean new-BSD.

> 
> > This have sense. This is the main interest of GPL!
> > 
> > so what will be the licence of the derivative work?
> 
> _Which_ derivative work are you asking about?
> 
> If you're asking about a derivative work that includes, say,
> GPLv2-licensed code and new-BSD-licensed code, then those remain
> available under their respective licences, to the extent they can be
> distinguished.

Except that the whole work may be used under GPL, with a side
requirement of dual licensing the BSD parts as BSD and/or GPL (as
explained previously).

[snip of discussion of what license the glue code was under.  The glue
code is what interfaced the BSD code to the GPL code]
> 
> > If you have dual licencing, you allow people to choose what ever he
> > want for the derivative work, you don't ask him to keep the dual
> > licencing, so this licence style don't stay in the derivative work
> 
> Again, you are incorrect.  The recipient does not own the copyright
> title, and therefore cannot change what terms he passes on to others.

If the the recipient takes the code under one license he is allowed to
do what that license permits.  Where is the requirement that the
resulting modification must be dual licensed?

> Dual-licensing merely allows the recipient to choose which of two
> alternative sets of conditions he/she satisfies, in order to enjoy the
> (otherwise-reserved) rights of redistribution and creation of derivative
> works.
> 
> > usually an author choose a licence to allow freedom, but only limited
> > freedom dual licencing give more freedom than any of the two.
> 
> That is correct but I'm not sure what your point is.  Again, for
> purposes of clarity, I am going to use an example:
> 
> Concerning the WordPerfect for Linux FAQ, if you download a copy and
> wish to do something requiring permission from the copyright holder
> (redistribution or creation of derivative works), you are required to
> satisfy the conditions of _either_ GPLv2 _or_ CC BY-SA 2.0 or later.   
> 
> Any copy of my work, or any derivative of my work, must pass along my
> conditions of use unmodified:  the portion of the passed-along document
> written by me must continue to be available to recipients under the 
> conditions of _either_ GPLv2 _or_ CC BY-SA 2.0 or later.

In this case I guess the above paragraph is not in violation of either
license so that it's binding on derivative works.  But if this
paragraph was omitted, it seems to me that the recipient wouldn't need
to dual-license the resulting work.
 [snip]
			David Lawyer
Subject: Re: [discuss] licence problems
From: David Lawyer ####@####.####
Date: 3 Oct 2008 19:48:07 +0100
Message-Id: <20081003184539.GA2550@davespc>

On Thu, Sep 25, 2008 at 02:58:10PM -0700, Rick Moen wrote:
> Quoting Jean-Daniel Dodin ####@####.####
> 
> > well, we can't discuss if you repeatedly challenge the other intelligence.
> 
> I am certainly not impugning anyone's intelligence:  All of this stuff
> is non-obvious, and nobody's born with understanding of it.  ;->
> 
> 
> > we may have problems to understand each others, but this licencing
> > problem is not that easy, that's why I keep discussing.
> > 
> > the problem is that GPL ask derivative works to have the very same
> > licence.
> 
> I'm not sure I see the relevance, but:  No, that is not the case.
But GPL does require the derivative work to have the same license.
But see what I say later on.
> 
> Here is another illustrative example.  Again, I find that people get
> very confused when they speak in vague generalities, so I use specific
> examples to clarify.  Let's say back in the late 1990s I coded an SSL
> library similar to OpenSSL, but I put it under the new-BSD licence.
> 
> Let's say that it's now 1999 and you're in a position similar to that of
> my friend Marc Merlin back at VA Linux Systems:  You're seeking to add
> TLS crypto capabilities to the Exim MTA.  You borrow new-BSD-licensed 
> code snippets from my SSL library codebase, and extend Exim's
> SMTP-session modules to use my code.  You now issue the resulting
> derivative work, which includes some of Phil Hazel's GPLed Exim code
> plus some of my new-BSD code, in a tarball.  The tarball therefore
> includes Phil's copyright statement, plus mine.  The various .h files
> indicate more-or-less who wrote what.
> 
> You've created and distributed a derivative work, something that
> requires permission from affected copyright owners.  Have you violated
> anyone's copyrights?  No.  My new-BSD licence statement on my SSL
> codebase permits what you've done.  Phil's GPLv2 licence statement on
> Exim has not been violated, either, because my new-BSD-licensed code
> that you've borrowed doesn't impose "additional conditions" above and
> beyond those of GPLv2 on the derivative work.
> 
> Is the tarball under "the very same licence"?  No, it's not.

Here's what I think and I may be wrong:
Well, it should be under the same GPL license, but has parts that are
sort of dual licensed under both GPL and BSD.  So it's sort of under
the same GPL license except that one may reuse the BSD licensed
modifications under the BSD license.  Also, for such reuse I think
one may be required to note the BSD licensed parts.  Alternatively,
the BSD parts may be lifted from the code and used under the BSD
license in ways that violate GPL.  In doing this, one could claim
that the code was obtained from a BSD archive that says nothing about
it being under GPL.  Since it's the same code, who knows where it came
from.  One might think of the GPLed code as also an archive of some
BSD code.  Even though the BSD parts were actually obtained from GPLed
code it's still pure BSD if you choose to take it under the BSD
license.  On the other hand, if you take this code for reuse under the
GPL license then it must be used in conformance with both GPL and BSD.
This works since BSD is so permissive that it doesn't conflict with GPL.

So something licensed under GPL may also be subject to other
permissions and requirements (or other licenses) so long as they don't
conflict with GPL.  GPLv3 has some rules as to how this works and
tries to define what constitutes a conflict, etc. but in looking it over
rapidly it doesn't seem too clear to me.

> My new-BSD-licensed code fragments are still new-BSD-licensed, and
> anyone who can pick them out of the derivative work has every legal
> right to use them elsewhere under new-BSD.  The code from Phil
> Hazel's upstream standard Exim codebase remains GPLv2-licensed.

But the  BSD parts are also GPL-licensed since the whole code is under
GPL.  By GPL I mean GPLv2 and by BSD I mean new-BSD.

> 
> > This have sense. This is the main interest of GPL!
> > 
> > so what will be the licence of the derivative work?
> 
> _Which_ derivative work are you asking about?
> 
> If you're asking about a derivative work that includes, say,
> GPLv2-licensed code and new-BSD-licensed code, then those remain
> available under their respective licences, to the extent they can be
> distinguished.

Except that the whole work may be used under GPL, with a side
requirement of dual licensing the BSD parts as BSD and/or GPL (as
explained previously).

[snip of discussion of what license the glue code was under.  The glue
code is what interfaced the BSD code to the GPL code]
> 
> > If you have dual licencing, you allow people to choose what ever he
> > want for the derivative work, you don't ask him to keep the dual
> > licencing, so this licence style don't stay in the derivative work
> 
> Again, you are incorrect.  The recipient does not own the copyright
> title, and therefore cannot change what terms he passes on to others.

If the the recipient takes the code under one license he is allowed to
do what that license permits.  Where is the requirement that the
resulting modification must be dual licensed?

> Dual-licensing merely allows the recipient to choose which of two
> alternative sets of conditions he/she satisfies, in order to enjoy the
> (otherwise-reserved) rights of redistribution and creation of derivative
> works.
> 
> > usually an author choose a licence to allow freedom, but only limited
> > freedom dual licencing give more freedom than any of the two.
> 
> That is correct but I'm not sure what your point is.  Again, for
> purposes of clarity, I am going to use an example:
> 
> Concerning the WordPerfect for Linux FAQ, if you download a copy and
> wish to do something requiring permission from the copyright holder
> (redistribution or creation of derivative works), you are required to
> satisfy the conditions of _either_ GPLv2 _or_ CC BY-SA 2.0 or later.   
> 
> Any copy of my work, or any derivative of my work, must pass along my
> conditions of use unmodified:  the portion of the passed-along document
> written by me must continue to be available to recipients under the 
> conditions of _either_ GPLv2 _or_ CC BY-SA 2.0 or later.

In this case I guess the above paragraph is not in violation of either
license so that it's binding on derivative works.  But if this
paragraph was omitted, it seems to me that the recipient wouldn't need
to dual-license the resulting work.
 [snip]
			David Lawyer
Subject: Re: [discuss] licence problems
From: Rick Moen ####@####.####
Date: 3 Oct 2008 22:10:27 +0100
Message-Id: <20081003211023.GD1041@linuxmafia.com>

Quoting David Lawyer ####@####.####
> On Thu, Sep 25, 2008 at 02:58:10PM -0700, Rick Moen wrote:
> > Quoting Jean-Daniel Dodin ####@####.####
> > 
> > > well, we can't discuss if you repeatedly challenge the other intelligence.
> > 
> > I am certainly not impugning anyone's intelligence:  All of this stuff
> > is non-obvious, and nobody's born with understanding of it.  ;->
> > 
> > 
> > > we may have problems to understand each others, but this licencing
> > > problem is not that easy, that's why I keep discussing.
> > > 
> > > the problem is that GPL ask derivative works to have the very same
> > > licence.
> > 
> > I'm not sure I see the relevance, but:  No, that is not the case.
> But GPL does require the derivative work to have the same license.
> But see what I say later on.

No, you're making the same mistake that some of the BSD fundamentalists
are making, in their passionate cries for addition of new, anti-copyleft
defensive licensing terms and legal strategies to the codebases
maintained by BSD people.  GPL _cannot_ make that requirement of people
who create derivative works, and it does not do so.

Now, yes, I _am_ (minutely, exhaustively, ad nauseam) familiar with the
wording of GPLv2 clause 2b:  

    You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.

In the real world, that means that the derivative work must be usable
under terms no more restrictive on the user than GPL ones.  You can
incorporate a new-BSD module into a GPLv2 work without licence conflict
and without acquiring the new-BSD module author's assent to relicensing
his property under copyleft terms _because_ new-BSD user obligations are
a proper subset of GPLv2 ones, and new-BSD user rights are a proper
superset of GPLv2 ones.

The downstream user automatically satisfies new-BSD obligations if and
when he/she satisfies GPLv2 ones.  It is absolutely unnecessary to 
wrestle out of the new-BSD copyright holder a new grant of permission
under GPLv2 -- which is what your view would dictate.

If your view were correct, then every new-BSD-licensed codebase author
in the world, whose code was ever borrowed for a GPLv2 work, would have
reason to be enraged at the copyleft world over the "involuntary GPL
relicensing" of his/her work that was done without his/her permission.
No, that is _not_ what happens.  The GPL author is _not_ relicensing
the BSD guy's code.  The incorporation is possible because recipients 
can satisfy the derivative's obligations by meeting GPLv2 terms, as
those automatically satisfy the obligations enumerated in new-BSD.

If your view were correct, I could be sued for copyright violation in
the following hypothetical:

Alice creates work foo under GPLv2, and finds it convenient to incorporate
Bob's new-BSD-licensed library bar.  Later, I come along, find the copy
of bar that's packaged with foo convenient, and borrow _that_ "bar"
instance for a proprietary work of my own.  Alice hears that I've done
so, and writes to me:  "Rick, did you use the instance of 'bar' that was
bundled into my work 'foo'?"  I reply "Yes, thank you for calling my
attention to that library.  It was very useful."  She writes back,
alleging that my proprietary work is subject to GPLv2 obligations,
because I borrowed GPLv2 code.  I counter that, no, I borrowed new-BSD
code.  She sues me for copyright violation.  

If you're correct, then she prevails.  But that's madness:  It's Bob's
code, and he never specified GPLv2 terms for his property.

No, Alice cannot recover from me for refusing to comply with GPLv2
terms, because I didn't borrow GPLv2 code.  Bob cannot recover from 
Alice for "involuntary relicensing" of his code to GPLv2, because
she simply did not do that.

Yes, I know that the wording of GPL[23] seems to suggest a requirement
that is, in fact, neither pragmatically nor legally possible.  That is
not the interpretation of that clause that actually applies in the real
world.  I'm sorry if I come across as impatient, but I've gotten
_really_ tired of arguing the matter over and over.

The view referenced above is, I _think_, the most common mistake in all
of open source licensing -- and it doesn't matter how often I debunk it,
there's always some new person to come along and promote it.

[<<] [<] Page 6 of 6 [>] [>>]


  ©The Linux Documentation Project, 2014. Listserver maintained by dr Serge Victor on ibiblio.org servers. See current spam statz.