RE: Combining GPL and non-GPL code

[Chris Travers]

Hi all;

IANAL, of course.  But this topic seems to me to be a huge mess.  My own
advice would be, "don't do it unless you talk to a lawyer first." The
rest of this discussion is about my thoughts why certain apparently
questionable practices might in fact be permitted under the license.

Consider two obvious examples:  ndiswrapper and the closed source Linux
drivers from nVidia.  I have not heard a clear argument that either one
of these, as generally distributed separately from the Linux kernel, is
a GPL violation.  In fact I think that neither one is.

In the case of ndiswrapper, you have a program which is clearly
derivative of the Linux kernel which is licensed under terms compatible
with the GPL.  This program, however, allows the kernel to dynamically
link to a set of closed-source Windows drivers which otherwise would not
work.  Before people say "linking is not permitted," I would  point out:

1)  the closed source drivers are *clearly* not derivatives of the Linux
kernel since they were written and tested for the NT kernel.

2)  The closed source drivers, when downloaded from the hardware vendors
site can hardly be considered to be part of the same "work as a whole"
as the Linux kernel.

Since the closed source drivers are neither derivative nor part of the
Linux kernel's copyrighted work as a whole, it is hard to see how they
are covered under the GPL v2.

As for the nVidia drivers, you have a similar case.  The driver software
was written for an environment other than Linux, there is a LGPL'd
wrapper, and the driver is distributed as a separate work.  Derivative
portions are licensed in terms compatible with the GPL.  I would point
out that the FSF would be entirely within their means to help Linux
kernel developers go after nVidia for this, but they have not done so to
my knowledge, perhaps because nVidia has a very defensible position?

I suspect that the question of whether a GPL-incompatible portion of an
application falls within the scope of the GPL would depend on whether it
is really part of the covered work (not clearly defined in any version
of the license) and whether it is derivative (also not clearly defined
in the license).  If these are clearly not the cse, I would think that a
developer would be safe but I would still recommend asking lawyers for
additional inormation.

The big question that remains is this:  If nVidia is within their rights
to offer a means to mix their closed-source drivers with the GPL'd Linux
kernel, does that necessarily mean that distributors are free to
distribute those drivers with the Linux kernel?  Or would this make them
part of the covered work, thus opening up distributors who do offer both
to copyright infringement lawsuits even where the original developer was
not guilty of such infringement?

As to the contrived GPL/BSD questions:
 >Do you honestly think you would win this argument that you can strip
off the GPL just

>because a BSD version exists somewhere?

No I don't actually.  If you could show that you did have a copy of the
BSD application somewhere but had not, say, even looked at it, it would
be a harder case to make.  But I would question who is the bigger fool
in such a hypothetical lawsuit:  you or the defendant.  In both cases,
it seems to me that this is effectively a non-issue provided that both
programs are publically available (one could argue that by making the
original BSD code publically available, if this in fact was done, you
had granted the public as a whole permission to use it as such).  At any
rate such a lawsuit would probably cost both parties a lot of time and
money and solve very little if the BSD code was publically available.

"Final Judgement:  The Defendant is hereby ordered to download the BSD
version..."

However, if the BSD code was not your own, one might question your
copyright ownership of the code fragments in question and that would be
another issue.

Key lesson-- probably a good idea to ask a lawyer.

One more point from a while back:

"From a pragmatic point of view, although GPL requires you to mark source

code changes, in the real world this doesn't always happen.  The user
who has received a copy of a derivative should see the original
BSD copyrights intact in the sources, but he/she is probably ill-advised
to assume the original code is also intact."

My reading of the GPL does not require a GPL project maintainer to change files from
BSD-licensed to GPL-licensed.  If the file has a BSD copyright/License notice, I would
argue that it is BSD-licensed *regardless of* its place in a larger GPL project.

Similarly nothing in the GPL prevents an author from releasing half of the code under
other licenses provided that these licenses are compatible with the GPL.

Hence it probably doesn't matter if the original code is intact if the original license
and copyright notice is.  By including that copyright notice  (even for a stated part
of the file), I would argue that the author has *granted you* all relevant rights under
the BSD license.

"If the code does contain any modifications, if those modifications are made to a
GPL'd derivative they are automatically GPL."

No.  If those modifications are derivative of code covered under the GPL to which the
author does not have rights to grant additional licenses, then they must be released
under the same license.  This may be simple or complex to evaluate depending on the
structure of the project.

Consider:
I create a project consisting of 100 BSD libraries and 1 GPL'd library.  I choose to
release the main logic of the program under the GPL in order to comply with the GPL'd
library's license.  In the process of the code, I make
changes to 3 of the BSD libraries in order to solve interop issues between them.  These
changes do *not* involve any intimate knowledge of the data structures of the GPL'd
code.  Are the final BSD files as distributed as a part of a larger GPL'd work required
by the GPL to now be under the GPL just because I made changes which had *nothing* to
do with the GPL'd portions of the application?  If I keep the BSD license intact in the
files, and someone does use them in proprietary software, can I sue them for failing to
apply a license *I* never applied to the code?

Granted this is a huge mess and can of worms.  Back to:  If you want to do this, hire a
lawyer for advice, ask a *lot* of questions, and then pay him a *large* retainer :-)

Best Wishes,
Chris Travers

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Wilson, Andrew-2]

 
Chris Travers wrote:

> "From a pragmatic point of view, although GPL requires you to mark
source

> code changes, in the real world this doesn't always happen.  The user
> who has received a copy of a derivative should see the original
> BSD copyrights intact in the sources, but he/she is probably
ill-advised
> to assume the original code is also intact."
>
> My reading of the GPL does not require a GPL project maintainer to
change files from
> BSD-licensed to GPL-licensed.  If the file has a BSD copyright/License
notice, I would
> argue that it is BSD-licensed *regardless of* its place in a larger
GPL project.
>
> Similarly nothing in the GPL prevents an author from releasing half of
the code under
> other licenses provided that these licenses are compatible with the
GPL.
>
> Hence it probably doesn't matter if the original code is intact if the
original license
> and copyright notice is.  By including that copyright notice  (even
for a stated part
> of the file), I would argue that the author has *granted you* all
relevant rights under
> the BSD license.
>
> "If the code does contain any modifications, if those modifications
are made to a
> GPL'd derivative they are automatically GPL."
>
> No.  If those modifications are derivative of code covered under the
GPL to which the
> author does not have rights to grant additional licenses, then they
must be released
> under the same license.  

Several points.

1. You are quoting me without attribution, which I thank you not to do.

2. John Cowan and I, along with several other contributors, walked our
way
   through the question of which license applies to a program where GPL
and
   BSD code have been intermingled at the source level within a module
   (not at the multiple file or archive level).  After looking at some
length at
   the issue from a variety of different points of view, I think it is
   fair to say that John and I and the other contributors agreed
   the answer is "GPL."
   
   If you have a refutation of this carefully developed consensus answer
   based on a fact-based argument, please post it.  If you do not have a
   reasoned counter-argument, please refrain from posting.  "My reading
of GPL"
   absent any citations to support your opinion is not a fact-based
argument.

3. The concept that the BSD copyright allows relicensing is one of the
more difficult
   points of open source licensing to get one's mind around.

Andy Wilson
Intel open source technology center

[Chuck Swiger]

Hi, Andy & all--

On Aug 17, 2007, at 2:42 PM, Wilson, Andrew wrote:

> 2. John Cowan and I, along with several other contributors, walked  
> our way
>    through the question of which license applies to a program where  
> GPL and
>    BSD code have been intermingled at the source level within a module
>    (not at the multiple file or archive level).  After looking at  
> some length at
>    the issue from a variety of different points of view, I think it is
>    fair to say that John and I and the other contributors agreed
>    the answer is "GPL."

While I agree that we have discussed this topic before, I believe you  
might be oversimplifying the end consensus (to whatever extent this  
is ever reached :) just a bit.  My answer to the above would be "both  
BSDL and GPL".  Since all of the requirements from the BSD license  
are a subset of the requirements of the GPL, your answer is also right.

However, the portion of the code which started off as BSDL code  
remains available under the terms of that license alone, and any  
derived work which uses a significant portion of the BSDL code must  
retain the BSD license text, original copyright notices, the mention  
in the documentation or other materials if a binary form of  
redistribution occurs, etc.

> 3. The concept that the BSD copyright allows relicensing is one of the
> more difficult points of open source licensing to get one's mind  
> around.

The BSD license does not mention relicensing anywhere, only:  
"Redistribution and use in source and binary forms, with or without  
modification, are permitted provided...."

It is commonly understood that this permits people to modify BSD  
licensed code and place the resulting derivative work under the terms  
of another license so long as the other license preserves the  
original copyright notice and BSD license text.  I would term this  
"sublicensing".

--
-Chuck

[Wilson, Andrew-2]

 
Chuck Swiger wrote:

>> 3. The concept that the BSD copyright allows relicensing is one of
the
>> more difficult points of open source licensing to get one's mind  
>> around.
>
> The BSD license does not mention relicensing anywhere, only:  
> "Redistribution and use in source and binary forms, with or without  
> modification, are permitted provided...."
>
> It is commonly understood that this permits people to modify BSD  
> licensed code and place the resulting derivative work under the terms

> of another license so long as the other license preserves the  
> original copyright notice and BSD license text.  I would term this  
> "sublicensing".

BSD doesn't mention "sublicensing" either, does it?
However -- and it does sound as if we are really in agreement on
this point, call it what you will; call it sublicensing, relicensing,
or overlaying a compatible license on top of BSD -- the license
(singular) which applies to the derivative work where GPL source has
been
combined with BSD source is GPL.  If GPL is clear on little else, it
is clear that GPL must apply to all derivatives *as a whole* (GPLv2
sec. 2 para (b)).

I said this is a difficult concept to get your mind around.  ;-)

Andy Wilson
Intel open source technology center

[Scott Paxton]

I am not sure how I got on this e-mail list but could you please take me
off.

Thanks

-----Original Message-----
From: Wilson, Andrew [mailto:andrew.wilson@...]
Sent: Friday, August 17, 2007 3:24 PM
To: Chuck Swiger
Cc: License Discuss
Subject: RE: Combining GPL and non-GPL code



Chuck Swiger wrote:

>> 3. The concept that the BSD copyright allows relicensing is one of
the
>> more difficult points of open source licensing to get one's mind
>> around.
>
> The BSD license does not mention relicensing anywhere, only:
> "Redistribution and use in source and binary forms, with or without
> modification, are permitted provided...."
>
> It is commonly understood that this permits people to modify BSD
> licensed code and place the resulting derivative work under the terms

> of another license so long as the other license preserves the
> original copyright notice and BSD license text.  I would term this
> "sublicensing".

BSD doesn't mention "sublicensing" either, does it?
However -- and it does sound as if we are really in agreement on
this point, call it what you will; call it sublicensing, relicensing,
or overlaying a compatible license on top of BSD -- the license
(singular) which applies to the derivative work where GPL source has
been
combined with BSD source is GPL.  If GPL is clear on little else, it
is clear that GPL must apply to all derivatives *as a whole* (GPLv2
sec. 2 para (b)).

I said this is a difficult concept to get your mind around.  ;-)

Andy Wilson
Intel open source technology center

[Chris Travers]

First I appologize to Andrew Wilson for not attributing his comments
when quoting them.

Chuck Swiger wrote:

>
> The BSD license does not mention relicensing anywhere, only:
> "Redistribution and use in source and binary forms, with or without
> modification, are permitted provided...."
>
> It is commonly understood that this permits people to modify BSD
> licensed code and place the resulting derivative work under the terms
> of another license so long as the other license preserves the original
> copyright notice and BSD license text.  I would term this "sublicensing".
>

I don't think the following points apply in any way safely.  IANAL though.

1) Unmodified BSD code available to the general public but distributed
by the same individual in a different program under the GPL cannot be
reverted to the BSD license.  If it is available to the general public
under the BSDL, I would argue that any member of the general public has
permission to use it under that license, wherever they got the code.  
This case is stronger where the content is relicensed by a third party
under the GPL because they may not have a strong claim to the copyrights
of the code in question when divorced from the rest of their application.

2)  That code in a GPL application which is still bears BSDL licenses in
the files cannot be reverted to BSDL just because it came from a GPL
app.  I don't read the GPL as requiring that an author relicense BSDL
code under the GPL as a condition for including it.  If in doubt, one
may look for other ways to incorporate code incompatible with the GPL
alongside code derived from GPL code (IANAL, but I would think the
proprietary code would need to be nonderivative and the work you
distribute would need to be arguably separate from the GPL'd work, thus
limiting derivate portions to something that could exist under the LGPL).

Best WIshes,
Chris Travers

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Wilson, Andrew-2]

 

Chris Travers wrote:

> First I appologize to Andrew Wilson for not attributing his comments
> when quoting them.

Accepted!

> I don't read the GPL as requiring that an author relicense BSDL
> code under the GPL as a condition for including it.

Please re-read GPLv2 sec. 2 para (b) on the license which
must apply to a derivative work of GPL code, if that derivative
is to be distributed.

Note this is not a "Schrodinger's cat" scenario (speaking
of concepts that are hard to get your mind around).  If I have
included a copy of BSD source in GPL source and have relicensed (or, per
Chuck, sublicensed) it under GPL as a derivative work, then
nothing at all has happened to change the state of other
copies of the original BSD work.  They are still BSD.  There has been
no paradoxical "action at a distance" to their license, and anyone who
can
find a copy of the original code may use it under BSD.

Once you get your mind around the necessity to relicense
(or sublicense) GPL derivatives as GPL, it makes other
questions more decidable.  For example, the NDIS driver wrapper
scenario you raised: you may combine that binary NDIS driver
with GPL code as long as you do not distribute the combination.
To distribute it, sec-2-para-b says you must relicense the whole
as GPL.  Since you do not have rights to relicense the binary,
there is a conflict of licenses and you cannot distribute
the combination.

IANAL, TINLA, your mileage may vary, apply directly to the forehead, &
etc.

Andy Wilson
Intel open source technology center

[Rick Moen]

Quoting Andrew Wilson (andrew.wilson@...):

[...]

> Once you get your mind around the necessity to relicense
> (or sublicense) GPL derivatives as GPL,...

FWIW, I deny the premise, as detailed below.

> ...it makes other questions more decidable.  For example, the NDIS
> driver wrapper scenario you raised: you may combine that binary NDIS
> driver with GPL code as long as you do not distribute the combination.
> To distribute it, sec-2-para-b says you must relicense the whole as
> GPL.  Since you do not have rights to relicense the binary, there is a
> conflict of licenses and you cannot distribute the combination.

GPLv2 section 2b does indeed use the phrase "must cause any work [...]
to be licensed as a whole [...] under the terms of this License."
_However_, for purposes of avoiding copyright infringement, it suffices
for the extra, third-party code to be available with new-BSD or MIT /
X11 rights, of which GPLv2 rights are a proper subset, with the effect
of compliance to the likely satisfaction of any judge.  I agree with
John Cowan:  If someone hands me a CD with tarballs of the Exim MTA
source code (which is GPLv2 with a licensing exception for
old-BSD-licensed libraries) configured to use external library code for
SSL/TLS-wrapped SMTP, accompanied by OpenSSL source code (which is a
combination of Eric A. Young's old-BSD code and subsequent new-BSD
additions), then, if I extract the OpenSSL tarball and redistribute it,
_that_ code remains BSD-licensed, as specified and required by its
owners and licensors.

Many innocent electrons have been needlessly murdered, over the years,
by some of our BSD brethren up in arms over the bugabear of GPL
codebases' alleged "relicensing" of their work to GPLv2, against their
wishes:  This may be a fine point of law, but I personally think it's
abundantly clear that this is, actually, a phoney issue, because
copyright owners alone are entitled to decree licence terms for their
creations.  Period.

[Chris Travers-5]

GPLv2 section 2b does indeed use the phrase "must cause any work [...]
to be licensed as a whole [...] under the terms of this License."

I agree with your statement and reasoning.  Work as a whole does not necessarily mean "every line of code" but rather "the compilation" in the same sense as "anthology" but IANAL.

I.e. nothing prevents me from licensing *part* of that work under a license compatible with the GPL as long as the "work as a whole" is licensed with appropriate permissions.  This becomes a larger question if the BSD depends on GPL code rather than the other way around (and that might be a more difficult case because one could argue derivation).

Absent from the concerns of derivation, nothing in the GPL requires that code not derived from other GPL code that the author does not hold appropriate copyrights to might be licensed under terms more permissive than the GPL.  For example, if the code is all my own, nothing says I can't license every file based on different compatible licneses provided that they do not prevent the *work as a whole* from carrying the rights and restrictions of the GPL.

To put it another way, I can compile a large amount of public domain literature, and reserve all rights to the anthology, but someone can still take my work and copy out the public domain components, combine them with other ones, re-arrange them, and copyright that anthology as non-derivative of my own.

There may be cases where the path of licensing has an effect (I license a copy of a program to you under a BSD license, change my mind, and release to the public under the GPL).  Limited distribution might matter.

_However_, for purposes of avoiding copyright infringement, it suffices
for the extra, third-party code to be available with new-BSD or MIT /
X11 rights, of which GPLv2 rights are a proper subset, with the effect
of compliance to the likely satisfaction of any judge.  I agree with
John Cowan:  If someone hands me a CD with tarballs of the Exim MTA
source code (which is GPLv2 with a licensing exception for
old-BSD-licensed libraries) configured to use external library code for
SSL/TLS-wrapped SMTP, accompanied by OpenSSL source code (which is a
combination of Eric A. Young's old-BSD code and subsequent new-BSD
additions), then, if I extract the OpenSSL tarball and redistribute it,
_that_ code remains BSD-licensed, as specified and required by its
owners and licensors.

Agreed.  THe license isn't "that" contageous.  Arguing that any user of GPL tools forfits BSD rights to the dependencies is silly :-).

Many innocent electrons have been needlessly murdered, over the years,
by some of our BSD brethren up in arms over the bugabear of GPL
codebases' alleged "relicensing" of their work to GPLv2, against their
wishes:  This may be a fine point of law, but I personally think it's
abundantly clear that this is, actually, a phoney issue, because
copyright owners alone are entitled to decree licence terms for their
creations.  Period.

It is a moot point.  The BSD code is publically available.  Therefore they have granted such a license to the public at large.  Restricting code copied into another application does not mean you can't go back to the original.  And if the file as a whole is still licensed under the BSD license, I would argue that this would be sufficient even if other files in the application are now GPL, absent concerns about derivation ( i.e. one would probably want to look over the code to make sure that the GPL code depended on the BSD code and not the other way around).

The BSD vs GPL argument is furthermore *stupid* and *counterproductive.* All software lives or dies based on community.  GPL and BSD both have advantages and not in many areas including collaborative development of systems to compete with established competition (I think it is a toss-up as for utility), but in the end community, and not licenses are what are important for the success of a project.

Best WIshes,
Chris Travers

[John Cowan]

Rick Moen scripsit:

> > Once you get your mind around the necessity to relicense
> > (or sublicense) GPL derivatives as GPL,...
>
> FWIW, I deny the premise, as detailed below.

Well, some people call it sublicensing or relicensing, but what we
are talking about here is just the incorporation of BSD-licensed text
(possibly just part of it) into a GPLed work, in such a way that the
original BSD text is no longer really visible as such.  This is *not*
the normal case of a tarball containing separate GPL and BSD files,
such as you explain below:

> then, if I extract the OpenSSL tarball and redistribute it,
> _that_ code remains BSD-licensed, as specified and required by its
> owners and licensors.

So it does.  This, however, is about something like copying some functions
from a BSDed coriginal into your GPL code, possibly modifying them in
the process, in such a way that it isn't obvious how to reconstruct
the original.

> I personally think it's abundantly clear that this is, actually, a
> phoney issue, because copyright owners alone are entitled to decree
> licence terms for their creations.  Period.

Quite so.  But the copyright on a derivative work (as opposed to a mere
collective work) belongs to the deriver, provided the derivation was
lawfully made, which means obeying any licensing requirements attached
to the original.  So this is not "relicensing" or "sublicensing", it's
applying the license permissions to make a derivative work.

--
John Cowan                              cowan@...
            http://www.ccil.org/~cowan
Humpty Dump Dublin squeaks through his norse
                Humpty Dump Dublin hath a horrible vorse
But for all his kinks English / And his irismanx brogues
                Humpty Dump Dublin's grandada of all rogues.  --Cousin James

[Chris Travers-5]

On 8/17/07, John Cowan <cowan@...> wrote:

So it does.  This, however, is about something like copying some functions
from a BSDed coriginal into your GPL code, possibly modifying them in
the process, in such a way that it isn't obvious how to reconstruct
the original.

This is a problem not because the original code is not under the BSD license but because the changes are under the GPL and this is permitted uner the BSDL.

> I personally think it's abundantly clear that this is, actually, a
> phoney issue, because copyright owners alone are entitled to decree
> licence terms for their creations.  Period.

Quite so.  But the copyright on a derivative work (as opposed to a mere
collective work) belongs to the deriver, provided the derivation was
lawfully made, which means obeying any licensing requirements attached
to the original.  So this is not "relicensing" or "sublicensing", it's
applying the license permissions to make a derivative work.

While I agree with your conclusions in a limited way, I think your statement is overly broad, but IANAL.  Copyright applies to original expression (at least in the US) only.  Therefore the copyright on a collective work may be limited to the collection itself (the expression in terms of selection, ordering, and organization of the work-- since a telephone directory has no expressive elements in a basic white-pages list, there isn't much that is copyrighted outside of advertising) and not the internal pieces (which could be differently licensed, public domain, etc. provided that the person who prepared the collective work has appropriate rights to do so).

I similar case occurs in relation to a derivative work.  The deriver only owns copyrights to the original elements, not to every aspect of the work as a whole.  The key problem here is that the original elements may not be clearly separated from those that are not, and so permission may be a problem.

The basic issue here is that you *don't* own the copyright to the original BSD code unless you also wrote it or have had it assigned to you.  But you do own the copyright to a) your changes to that code and b) the collective work as a whole.  While b) may not be much of a problem, a) could be if you cannot separate out the changes (but see below).

Another potential problem is that standards of derivation and what is protectable may vary from one jurisdiction to another.  Simply using the #include directives in a header file may not be enough under a Gates-type test (used by the 9th Circuit, iirc) because the practical, interop elements may not be protectable, but may be covered under other jurisdictions.  If there is conflict among these within the US, one can imagine it getting far worse as other nations' notions of copyright are added to the mix.  Hence it may not be clear what is protectable under "work as a whole" and "derivative work" terms until you get into court :-(.

Best Wishes,
Chris Travers

[Rick Moen]

Quoting John Cowan (cowan@...):

> Quite so.  But the copyright on a derivative work (as opposed to a mere
> collective work) belongs to the deriver, provided the derivation was
> lawfully made, which means obeying any licensing requirements attached
> to the original.  So this is not "relicensing" or "sublicensing", it's
> applying the license permissions to make a derivative work.

Sure, I'll go along with that.  The work entailed in creating the
derivative (the set of incremental changes), to the extent it gives rise
to copyright title, is required to be available under GPL terms in order
to qualify for creation and distribution of that derivative, rights
otherwise reserved.

If anyone wants access to the BSD-licensed code in your hypothetical
under its owner's terms, that access does remain available -- anywhere
such separate code can be found.

Note:  It might be argued that the changes required to Exim to hack in
OpenSSL calls raise derivative work questions, as opposed to merely
creating a collection.  When my friend Marc Merlin wrote the bridge code
patches in around 2000, arguably they used significant copyrightable
elements of OpenSSL, as GNU TLS wasn't yet available.  (At that time,
Phil Hazel had Exim under pure GPLv2:  Marc released the patched Exim
tarball, I pointed out the licensing problem, Marc swore a blue streak,
and an e-mail to Phil resulted in him amiably issuing the needed licence
exception.)

[David Woolley (E.L)]

Chris Travers wrote:

> in terms of selection, ordering, and organization of the work-- since a
> telephone directory has no expressive elements in a basic white-pages
> list, there isn't much that is copyrighted outside of advertising) and

This might be the case for US law.  It appears to be the intent of UK
law that it is not the case of UK law, as there is copyright in
databases, which I believe is intended to cover exactly that case.

IANAL
--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[John Cowan]

Rick Moen scripsit:

> If anyone wants access to the BSD-licensed code in your hypothetical
> under its owner's terms, that access does remain available -- anywhere
> such separate code can be found.

Exactly so.  The BSD and similar licenses, as I've said before, don't
actually grant access to source code; they presuppose it.  "Here is what
you can do with the source code you now have."

--
Samuel Johnson on playing the violin:           John Cowan
"Difficult do you call it, Sir?                 cowan@...
 I wish it were impossible."                    http://www.ccil.org/~cowan

[Chris Travers]

David Woolley wrote:

> Chris Travers wrote:
>
>> in terms of selection, ordering, and organization of the work-- since
>> a telephone directory has no expressive elements in a basic
>> white-pages list, there isn't much that is copyrighted outside of
>> advertising) and
>
> This might be the case for US law.  It appears to be the intent of UK
> law that it is not the case of UK law, as there is copyright in
> databases, which I believe is intended to cover exactly that case.

IANAL, but for the record, I did include disclaimers about this being

specific to US law.

I would also suggest that copyright over databases might not cover data
in the databases.  I.e. if I publish *your* phone number only, the phone
company might not be able to allege a copyright infringemnet associated
with the mere publication of a fact.

This does get back to the BSD-in-GPL question because, assuming
different authorship and no assgnement of rights, the GPL work's author
does *not* have rights to restrict code originally licensed by someone
*else* under the BSD license.

Best WIshes,
Chris Travers
>
> IANAL


[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Arnoud Engelfriet-2]

David Woolley wrote:
> Chris Travers wrote:
> >in terms of selection, ordering, and organization of the work-- since a
> >telephone directory has no expressive elements in a basic white-pages
> >list, there isn't much that is copyrighted outside of advertising) and
>
> This might be the case for US law.  It appears to be the intent of UK
> law that it is not the case of UK law, as there is copyright in
> databases, which I believe is intended to cover exactly that case.

According to EU Directive 96/9/EC on the protection of databases,
databases which, by reason of the selection or arrangement of their
contents, constitute the author's own intellectual creation shall be
protected as such by copyright.

Independently from copyright this Directive also creates a _sui
generis_ right for databases that guards against extraction and/or
re-utilization of the whole or of a substantial part, evaluated
qualitatively and/or quantitatively, of the contents of that
database.

You get this right if creation of the database involves a substantial
investment in either the obtaining, verification or presentation of
the contents of the database. In the US they'd call this "sweat of
the brow".

Arnoud

--
Arnoud Engelfriet, Dutch & European patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
              Arnoud blogt nu ook: http://blog.iusmentis.com/

[John Cowan]

David Woolley scripsit:

> This might be the case for US law.  It appears to be the intent of UK
> law that it is not the case of UK law, as there is copyright in
> databases, which I believe is intended to cover exactly that case.

U.K. law uses a "sweat of the brow" standard, whereby things like the
white pages *are* copyright; the U.S., by its Constitution, uses an
"originality" standard, which sets a higher barrier.

> IANAL

/me too.

--
When I'm stuck in something boring              John Cowan
where reading would be impossible or            (who loves Asimov too)
rude, I often set up math problems for          cowan@...
myself and solve them as a way to pass          http://www.ccil.org/~cowan
the time.      --John Jenkins

[Chris Travers]

Rick Moen wrote:

> Quoting John Cowan (cowan@...):
>
>  
>> Quite so.  But the copyright on a derivative work (as opposed to a mere
>> collective work) belongs to the deriver, provided the derivation was
>> lawfully made, which means obeying any licensing requirements attached
>> to the original.  So this is not "relicensing" or "sublicensing", it's
>> applying the license permissions to make a derivative work.
>>    
>
> Sure, I'll go along with that.  The work entailed in creating the
> derivative (the set of incremental changes), to the extent it gives rise
> to copyright title, is required to be available under GPL terms in order
> to qualify for creation and distribution of that derivative, rights
> otherwise reserved.
>  

Agreed this far.
> If anyone wants access to the BSD-licensed code in your hypothetical
> under its owner's terms, that access does remain available -- anywhere
> such separate code can be found.
>  

There is an exception that is worth noting.  IANAL though.

If the GPL work author *is also* the author of the code or has had
copyright asigned to him/her, it may be possible to release the code in
terms other than the BSD terms.  But then the issue here is not
derivation or work as a whole but outright ownership of the relevant
copyrights.  So while path *may* matter, it only matters where a person
has the legal right to further restrict distribution of the relevant
source.  The BSD license does not automatically grant this.
> Note:  It might be argued that the changes required to Exim to hack in
> OpenSSL calls raise derivative work questions, as opposed to merely
> creating a collection.
I don't now.  I think it would depend on the nature of the changes.  Are
the changes derivative of the Exim code?  Or are they separate?  If they
are derivative, then who owns the copyrights to the sections of code in
Exim and the changes in OpenSSL?  If they are both owned by the same
person, I wouldn't see a problem.  This is likely to depend on an
analysis of the actual nature of the changes and the interaction of the
related sections of code.

Now you see the problem with this sort of discussion.
>   When my friend Marc Merlin wrote the bridge code
> patches in around 2000, arguably they used significant copyrightable
> elements of OpenSSL, as GNU TLS wasn't yet available.  (At that time,
> Phil Hazel had Exim under pure GPLv2:  Marc released the patched Exim
> tarball, I pointed out the licensing problem, Marc swore a blue streak,
> and an e-mail to Phil resulted in him amiably issuing the needed licence
> exception.)
Cool.  Glad it worked out. :-)

Best Wishes,
Chris Travers


[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Rick Moen]

Quoting Chris Travers (chris@...):

[Exim:]

> I don't now.  I think it would depend on the nature of the changes.  

I believe that's exactly what I just said, genius.

> Are  the changes derivative of the Exim code?  [...]

Feel free to judge for yourself.  I merely pointed out that it's a
relevant question of fact, and always would be in such situations,
as a correction to John Cowan's assertion that the two codebases
remained separate.  You've added nothing.