Dispelling BSD License Misconceptions (fwd)

[Brian Behlendorf]

This may be off-topic in so far as license-discuss is concerned, but since
the quality of our analysis is important, I'd like to understand why
reasonable minds may differ to such a degree that the following might be
true.  Especially since IANAL and I'd like to think this was something a
lay person could navigate...

In particular, I think his claim in his paper, section 3.3:

   It is likely that the reasonable person would read the license and think
   that the licensor intended that the warranty disclaimer was to run with
   the redistribution without qualification.

and then the immediate leap in 3.4 to:

   On this analysis, the warranty disclaimer travels with the distribution
   and the distributor has no ability to qualify it.

is where the author goes astray, and with it the rest of the argument.
The need to "retain" the original license in any redistribution does not
imply that any redistribution must be under that original license.  It is
included to communicate to the recipient that some subset of the code,
perhaps even all of it, was originally under that older license.  It
doesn't preclude the possibility that there is a newer license, perhaps
even to cover newer modifications or newer code.  Nor would a newer
license prevent a recipient from exercising their rights around the older
code under the older license.

That suggests that no, the warranty disclaimer doesn't automatically apply
to the redistributor.  Most redistributors who care about this issue have
probably separately disclaimed their liability for any third-party
software they are redistributing, and separately for any of their own
code. Another angle to this is that a redistributor could establish a
code-insurance business, whereby they sell policies that assume liability
for someone else's code, because they've vetted the risk against the price
they think people will pay for such a guarantee.

At the same time, I have sympathy for:

   What the court is looking to determine is what the reasonable person
   (ie an idealized and dispassionate citizen who is called on to assess
   the scope of the license) would make of the words.

Would a reasonable person who found the BSD license in a bundle
of code assume that the notice applied to the whole thing?  Is that what
the original Berkeley Software Distribution copyright holders intended by
the word "retain"?

He continues the mistake of confusing sublicensing with relicensing, it
seems, by saying in 3.5:

   Moreover, if anyone could license the code under different terms, then
   any person redistributing the unmodified code could remove the warranty
   disclaimer and other terms, removing the protections expressly included
   by the copyright holder.

It seems to me that even if the license were modified, the protections
would continue to exist for the copyright holder - if a redistributor
removed the disclaimer and a recipient decided they needed relief, they'd
seek that from the redistributor, and both the recipient and the
redistributor would be unable to seek that from the copyright holder due
to the original disclaimer from holder to redistributor.

I feel the author takes a further unsubstantiated leap when he says in
4.3:

   However, the original licensor has mandated specific wording to be
   included which purports to apply to the code as a whole (ie as
   modified).

I don't read BSD that way, and I don't believe most others do either.
Someone reading it for the very first time, without being introduced with
a description of what the BSD license is supposed to mean, though, might
be forgiven for thinking this.

Is this a case, though, where 14 years of reading a particular body of
text and being told what it's supposed to mean can cloud one's sense of
what it actually says?

  Brian

---------- Forwarded message ----------
Link: http://slashdot.org/article.pl?sid=07/01/15/1757235
Posted by: ScuttleMonkey, on 2007-01-15 19:03:00

    [1]AlanS2002 writes "Groklaw is hosting an article by Brendan Scott
    which looks at the [2]misconceptions surrounding the BSD license. From
    the article: 'We observe that there exists a broad misconception that
    the BSD permits the licensing of BSD code and modifications of BSD
    code under closed source licenses. In this paper we put forward an
    argument to the effect that the terms of the BSD require BSD code and
    modifications to BSD code to be licensed under the terms of the BSD
    license. We look at some possible consequences and observe that this
    licensing requirement could have serious impacts on the unwary.'"

References

    1. http://alansplayground.spaces.live.com/
    2. http://www.groklaw.net/article.php?story=20070114093427179

[Chuck Swiger]

On Jan 16, 2007, at 4:53 PM, Brian Behlendorf wrote:

> In particular, I think his claim in his paper, section 3.3:
>
>   It is likely that the reasonable person would read the license  
> and think
>   that the licensor intended that the warranty disclaimer was to  
> run with
>   the redistribution without qualification.
>
> and then the immediate leap in 3.4 to:
>
>   On this analysis, the warranty disclaimer travels with the  
> distribution
>   and the distributor has no ability to qualify it.
>
> is where the author goes astray, and with it the rest of the  
> argument. The need to "retain" the original license in any  
> redistribution does not imply that any redistribution must be under  
> that original license.

True.  But neither does the BSD license grant people the right to  
relicense code under the terms of some other license or to modify the  
terms of the license as it appears in the README or source code files.

> It is included to communicate to the recipient that some subset of  
> the code, perhaps even all of it, was originally under that older  
> license.  It doesn't preclude the possibility that there is a newer  
> license, perhaps even to cover newer modifications or newer code.  
> Nor would a newer license prevent a recipient from exercising their  
> rights around the older code under the older license.

If they produce a modified version or they combine BSD-licensed code  
with additional software they've written, the portions they wrote or  
changed can be licensed under whatever terms that author wishes  
(assuming for the sake of discussion that the changes are not so  
trivial that they would not merit copyright protection), but the  
original unmodified sources are still under the terms of the BSD  
license.

On the other hand, if someone modifies or adds code to a BSD-licensed  
program, and their changes are also put under the BSD license (which  
is the normal case, as the BSD projects will generally not  
incorporate changes made under other licensing terms), that person is  
a "contributor", and the terms of the license including the  
DISCLAIMER would apply to that person as well as to the original  
authors.

> That suggests that no, the warranty disclaimer doesn't  
> automatically apply to the redistributor.  Most redistributors who  
> care about this issue have probably separately disclaimed their  
> liability for any third-party software they are redistributing, and  
> separately for any of their own code. Another angle to this is that  
> a redistributor could establish a code-insurance business, whereby  
> they sell policies that assume liability for someone else's code,  
> because they've vetted the risk against the price they think people  
> will pay for such a guarantee.

Sure.  If you want to build your own version of a BSD-licensed  
program (creating a binary version which is a derivative work of the  
original sources), and offer a warranty yourself for your particular  
version of the program, you are free to do so-- but you'd need to  
preserve the original DISCLAIMER in order to indicate that the  
original authors have no liability with regard to your modified/
derivative version that you've decided to provide support in exchange  
for a fee.

> At the same time, I have sympathy for:
>
>   What the court is looking to determine is what the reasonable person
>   (ie an idealized and dispassionate citizen who is called on to  
> assess
>   the scope of the license) would make of the words.
>
> Would a reasonable person who found the BSD license in a bundle of  
> code assume that the notice applied to the whole thing?  Is that  
> what the original Berkeley Software Distribution copyright holders  
> intended by the word "retain"?

Part of licensing software includes clearly identifying the software  
(or portions of the software) to which the license applies.

This perhaps isn't especially clear in the article on Groklaw as it  
is discussing a generic BSD license template, but in real-world  
usage, the software for which the BSD license terms applies is  
clearly identified in the README, COPYRIGHT file, source code files,  
or all of the above.

For example, the COPYRIGHT file on a FreeBSD system starts with:

> # $FreeBSD: src/COPYRIGHT,v 1.5.2.2 2006/02/16 14:49:38 kensmith Exp $
> #       @(#)COPYRIGHT   8.2 (Berkeley) 3/21/94
>
> The compilation of software known as FreeBSD is distributed under the
> following terms:
>
> Copyright (C) 1992-2006 The FreeBSD Project. All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
> [ ...snipping the rest of the BSD license terms for brevity... ]

...and this is generally true in NetBSD, OpenBSD, Apple's OSX/Darwin,  
and elsewhere.  For example, if you check the header files under /usr/
include, you'll find that the name of the header file is included in  
the same comment block as the BSD license terms.

> He continues the mistake of confusing sublicensing with  
> relicensing, it seems, by saying in 3.5:
>
>   Moreover, if anyone could license the code under different terms,  
> then
>   any person redistributing the unmodified code could remove the  
> warranty
>   disclaimer and other terms, removing the protections expressly  
> included
>   by the copyright holder.
>
> It seems to me that even if the license were modified, the  
> protections would continue to exist for the copyright holder - if a  
> redistributor removed the disclaimer and a recipient decided they  
> needed relief, they'd seek that from the redistributor, and both  
> the recipient and the redistributor would be unable to seek that  
> from the copyright holder due to the original disclaimer from  
> holder to redistributor.

I would agree with this, although it seems to be a moot point as  
nothing in the BSD license gives anyone [aside from the original  
author(s) or copyright holder(s)] the right to change the actual  
terms of that license with regard to the original version of software  
which they'd written.

> I feel the author takes a further unsubstantiated leap when he says  
> in 4.3:
>
>   However, the original licensor has mandated specific wording to be
>   included which purports to apply to the code as a whole (ie as
>   modified).
>
> I don't read BSD that way, and I don't believe most others do  
> either. Someone reading it for the very first time, without being  
> introduced with a description of what the BSD license is supposed  
> to mean, though, might be forgiven for thinking this.

There are some people who feel that software licenses somehow  
automatically apply their terms to any and all other software used in  
conjunction with the original software in question (ie, as part of a  
compilation, or via dynamic linking, or via pipelines, RPC, or other  
form of network communication).  A canonical example is when people  
claim that you can't dynamically link libreadline.so with software  
under another license unless the other software is also under the GPL.

[ My canonical response to such claims is to have them re-read the  
section of the GPL between clause 2c & 3. ]

--
-Chuck

[Lawrence Rosen]

Brian Behlendorf wrote:
> The need to "retain" the original license in any redistribution does not
> imply that any redistribution must be under that original license.  It is
> included to communicate to the recipient that some subset of the code,
> perhaps even all of it, was originally under that older license.  It
> doesn't preclude the possibility that there is a newer license, perhaps
> even to cover newer modifications or newer code.  Nor would a newer
> license prevent a recipient from exercising their rights around the older
> code under the older license.

Brian, I think you are absolutely right!

> Is this a case, though, where 14 years of reading a particular body of
> text and being told what it's supposed to mean can cloud one's sense of
> what it actually says?

Your 14 years have served you well! That article may, for all I know, apply
to Australian law (although I doubt it), but it certainly doesn't apply to
U.S. copyright law.

/Larry

> -----Original Message-----
> From: Brian Behlendorf [mailto:brian@...]
> Sent: Tuesday, January 16, 2007 4:53 PM
> To: license-discuss@...
> Subject: Dispelling BSD License Misconceptions (fwd)
>
>
> This may be off-topic in so far as license-discuss is concerned, but since
> the quality of our analysis is important, I'd like to understand why
> reasonable minds may differ to such a degree that the following might be
> true.  Especially since IANAL and I'd like to think this was something a
> lay person could navigate...
>
> In particular, I think his claim in his paper, section 3.3:
>
>    It is likely that the reasonable person would read the license and
> think
>    that the licensor intended that the warranty disclaimer was to run with
>    the redistribution without qualification.
>
> and then the immediate leap in 3.4 to:
>
>    On this analysis, the warranty disclaimer travels with the distribution
>    and the distributor has no ability to qualify it.
>
> is where the author goes astray, and with it the rest of the argument.
> The need to "retain" the original license in any redistribution does not
> imply that any redistribution must be under that original license.  It is
> included to communicate to the recipient that some subset of the code,
> perhaps even all of it, was originally under that older license.  It
> doesn't preclude the possibility that there is a newer license, perhaps
> even to cover newer modifications or newer code.  Nor would a newer
> license prevent a recipient from exercising their rights around the older
> code under the older license.
>
> That suggests that no, the warranty disclaimer doesn't automatically apply
> to the redistributor.  Most redistributors who care about this issue have
> probably separately disclaimed their liability for any third-party
> software they are redistributing, and separately for any of their own
> code. Another angle to this is that a redistributor could establish a
> code-insurance business, whereby they sell policies that assume liability
> for someone else's code, because they've vetted the risk against the price
> they think people will pay for such a guarantee.
>
> At the same time, I have sympathy for:
>
>    What the court is looking to determine is what the reasonable person
>    (ie an idealized and dispassionate citizen who is called on to assess
>    the scope of the license) would make of the words.
>
> Would a reasonable person who found the BSD license in a bundle
> of code assume that the notice applied to the whole thing?  Is that what
> the original Berkeley Software Distribution copyright holders intended by
> the word "retain"?
>
> He continues the mistake of confusing sublicensing with relicensing, it
> seems, by saying in 3.5:
>
>    Moreover, if anyone could license the code under different terms, then
>    any person redistributing the unmodified code could remove the warranty
>    disclaimer and other terms, removing the protections expressly included
>    by the copyright holder.
>
> It seems to me that even if the license were modified, the protections
> would continue to exist for the copyright holder - if a redistributor
> removed the disclaimer and a recipient decided they needed relief, they'd
> seek that from the redistributor, and both the recipient and the
> redistributor would be unable to seek that from the copyright holder due
> to the original disclaimer from holder to redistributor.
>
> I feel the author takes a further unsubstantiated leap when he says in
> 4.3:
>
>    However, the original licensor has mandated specific wording to be
>    included which purports to apply to the code as a whole (ie as
>    modified).
>
> I don't read BSD that way, and I don't believe most others do either.
> Someone reading it for the very first time, without being introduced with
> a description of what the BSD license is supposed to mean, though, might
> be forgiven for thinking this.
>
> Is this a case, though, where 14 years of reading a particular body of
> text and being told what it's supposed to mean can cloud one's sense of
> what it actually says?
>
>   Brian
>
> ---------- Forwarded message ----------
> Link: http://slashdot.org/article.pl?sid=07/01/15/1757235
> Posted by: ScuttleMonkey, on 2007-01-15 19:03:00
>
>     [1]AlanS2002 writes "Groklaw is hosting an article by Brendan Scott
>     which looks at the [2]misconceptions surrounding the BSD license. From
>     the article: 'We observe that there exists a broad misconception that
>     the BSD permits the licensing of BSD code and modifications of BSD
>     code under closed source licenses. In this paper we put forward an
>     argument to the effect that the terms of the BSD require BSD code and
>     modifications to BSD code to be licensed under the terms of the BSD
>     license. We look at some possible consequences and observe that this
>     licensing requirement could have serious impacts on the unwary.'"
>
> References
>
>     1. http://alansplayground.spaces.live.com/
>     2. http://www.groklaw.net/article.php?story=20070114093427179

[Matthew Flaschen]

Chuck Swiger wrote:
> If they produce a modified version or they combine BSD-licensed code
> with additional software they've written, the portions they wrote or
> changed can be licensed under whatever terms that author wishes
> (assuming for the sake of discussion that the changes are not so trivial
> that they would not merit copyright protection), but the original
> unmodified sources are still under the terms of the BSD license.

Moreover, the portions of their code that were licensed under BSD are
still under BSD (though this usually doesn't mean much).

> There are some people who feel that software licenses somehow
> automatically apply their terms to any and all other software used in
> conjunction with the original software in question (ie, as part of a
> compilation, or via dynamic linking, or via pipelines, RPC, or other
> form of network communication).  

There are many quite distinct conjunctive relationships, which you've
lumped together.  Some forms of conjunction (such as static linking)
clearly create a derivative work, because the original code is present
in the executable.  In most other cases, it is controversial.

> A canonical example is when people
> claim that you can't dynamically link libreadline.so with software under
> another license unless the other software is also under the GPL.
> [ My canonical response to such claims is to have them re-read the
> section of the GPL between clause 2c & 3. ]

You make this sound like the end of discussion.  In fact, this is
probably one of the most complex parts of the GPL.  I urge you to reread
the sentence stating:

"But when you distribute the same sections as part of a whole which is a
work based on the Program, the distribution of the whole must be on the
terms of this License, whose permissions for other licensees extend to
the entire whole, and thus to each and every part regardless of who
wrote it."

The FSF offers guidelines
(http://www.gnu.org/licenses/gpl-faq.html#MereAggregation) about this.
It ultimately comes down to is simply whether the new program is a
derivative work of the GPL-licensed code.  As the FSF says, "This is a
legal question, which ultimately judges will decide."

As far as Readline specifically, A USAGE file says:

"I think Allbery's suggestion is a good one.  So please add this text
in a suitable place.  Please don't put it in the GPL itself; that
should be the same as the GPL everywhere else.  Putting it in the
README and/or the documentation would be a good idea.


======================================================================
Our position on the use of Readline through a shared-library linking
mechanism is that there is no legal difference between shared-library
linking and static linking--either kind of linking combines various
modules into a single larger work.  The conditions for using Readline
in a larger work are stated in section 3 of the GNU GPL."

Obviously, this is interpretation.  Similarly, the FSF uses Readline as
an example of a library they leverage to convince people to release
their programs under the GPL
(http://www.gnu.org/licenses/why-not-lgpl.html).

You're welcome to have a different opinion, but don't try to make it
seem indisputable or uncontroversial by spouting off sections of the GPL

Matthew Flaschen

[Rick Moen]

Quoting Chuck Swiger (chuck@...):

> There are some people who feel that software licenses somehow  
> automatically apply their terms to any and all other software used in  
> conjunction with the original software in question (ie, as part of a  
> compilation, or via dynamic linking, or via pipelines, RPC, or other  
> form of network communication).  A canonical example is when people  
> claim that you can't dynamically link libreadline.so with software  
> under another license unless the other software is also under the GPL.
>
> [ My canonical response to such claims is to have them re-read the  
> section of the GPL between clause 2c & 3. ]

As Matthew points out, GPLv2's text (ditto any number of FSF FAQs)
utterly _lacks_ power to define what is and is not a derivative work,
that term of art's meaning being decided entirely by caselaw and judges.
You'd be much smarter to refer people to the text of the CAI v.  Altai
decision (in USA jurisdictions), rather than to GPL clause-anything.

The former's accessible via http://linuxmafia.com/kb/Licensing_and_Law/ ,
as it happens.  ;->

--
Cheers,      "Transported to a surreal landscape, a young girl kills the first
Rick Moen     woman she meets, and then teams up with three complete strangers
rick@...       to kill again."  -- Rick Polito's That TV Guy column,
              describing the movie _The Wizard of Oz_

[John Cowan]

Brian Behlendorf scripsit:

> Would a reasonable person who found the BSD license in a bundle
> of code assume that the notice applied to the whole thing?  Is that what
> the original Berkeley Software Distribution copyright holders intended
> by the word "retain"?

Well, it would depend on the context.  If it appeared in a top-level
file labeled "LICENSE" or "COPYING", then yes, I would think so.

I wanted to point out the case of Python, which since the 2.1.1 release
has been lugging around four license texts in its LICENSE file
<http://svn.python.org/view/python/trunk/LICENSE?rev=53286&view=markup>.
A close reading shows that only the topmost of these, the Python Software
Foundation License Version 2, is actually effective, and the others
are carried around at the tail simply because their own text, as applied
to earlier versions of Python, says that they must be.

Still, this is less than obvious, and I can see someone believing that
the conjunction of all four licenses is in effect, and in particular
that the various choice-of-law provisions (California, U.S., and Virginia)
are all somehow applicable.

--
What asininity could I have uttered     John Cowan <cowan@...>
that they applaud me thus?              http://www.ccil.org/~cowan
        --Phocion, Greek orator

[Chuck Swiger]

On Jan 16, 2007, at 7:08 PM, Matthew Flaschen wrote:

> Chuck Swiger wrote:
>> If they produce a modified version or they combine BSD-licensed code
>> with additional software they've written, the portions they wrote or
>> changed can be licensed under whatever terms that author wishes
>> (assuming for the sake of discussion that the changes are not so  
>> trivial
>> that they would not merit copyright protection), but the original
>> unmodified sources are still under the terms of the BSD license.
>
> Moreover, the portions of their code that were licensed under BSD are
> still under BSD...

I agree up to here...

> ...(though this usually doesn't mean much).

...but I am not quite sure what you meant by this.  One would hope  
that having source code available under an OSI-approved open source  
license would have some meaning at least for the people on the OSI  
mailing lists.

>> There are some people who feel that software licenses somehow
>> automatically apply their terms to any and all other software used in
>> conjunction with the original software in question (ie, as part of a
>> compilation, or via dynamic linking, or via pipelines, RPC, or other
>> form of network communication).
>
> There are many quite distinct conjunctive relationships, which you've
> lumped together.  Some forms of conjunction (such as static linking)
> clearly create a derivative work, because the original code is present
> in the executable.  In most other cases, it is controversial.

I would agree that static linking forms a derivative work for exactly  
the reason you've mentioned; however, if you'll notice, I did not  
mention static linking in the list above.  This omission was quite  
deliberate.

However, that is slightly aside from the central point, which is that  
a license applies to the software under that license and to  
derivative works but *not* to other software which is completely  
independent and exists under other license terms.

>> A canonical example is when people
>> claim that you can't dynamically link libreadline.so with software  
>> under
>> another license unless the other software is also under the GPL.
>> [ My canonical response to such claims is to have them re-read the
>> section of the GPL between clause 2c & 3. ]
>
> You make this sound like the end of discussion.

Actually, it is another discussion (and one we've already had  
before); and is also somewhat aside from Brian's original discussion  
about this Groklaw article on the BSD license.

> In fact, this is probably one of the most complex parts of the  
> GPL.  I urge you to reread the sentence stating:
>
> "But when you distribute the same sections as part of a whole which  
> is a
> work based on the Program, the distribution of the whole must be on  
> the
> terms of this License, whose permissions for other licensees extend to
> the entire whole, and thus to each and every part regardless of who
> wrote it."

Of course.  And if one of the other parts is under license terms  
which are not GPL-miscible, then the derived work cannot be  
redistributed at all.

As far as I can tell, *none* of the OSI-approved licenses grant  
redistributors or people modifying the code the right to change the  
original license terms.  Nothing in the GPL gives one the right to  
change the license on other software, just as nothing in any other  
license gives one the right to change the license of GPLed code.  The  
author or copyright holder is free to relicense software, and might  
grant others permission to change the license or use the source code  
in a circumstance otherwise not permitted by the original license  
terms, but the right to do so must be explicitly granted.

And this is exactly what the GPL says in the portion of the paragraph  
just before what you've quoted above:

"These requirements apply to the modified work as a whole. If  
identifiable sections of that work are not derived from the Program,  
and can be reasonably considered independent and separate works in  
themselves, then this License, and its terms, do not apply to those  
sections when you distribute them as separate works."

[ ...followed by the section "But when..." Matthew quoted above... ]

"Thus, it is not the intent of this section to claim rights or  
contest your rights to work written entirely by you; rather, the  
intent is to exercise the right to control the distribution of  
derivative or collective works based on the Program."

"In addition, mere aggregation of another work not based on the  
Program with the Program (or with a work based on the Program) on a  
volume of a storage or distribution medium does not bring the other  
work under the scope of this License."

> As far as Readline specifically, A USAGE file says:
>
> "I think Allbery's suggestion is a good one.  So please add this text
> in a suitable place.  Please don't put it in the GPL itself; that
> should be the same as the GPL everywhere else.  Putting it in the
> README and/or the documentation would be a good idea.
>
> ======================================================================
> Our position on the use of Readline through a shared-library linking
> mechanism is that there is no legal difference between shared-library
> linking and static linking--either kind of linking combines various
> modules into a single larger work.  The conditions for using Readline
> in a larger work are stated in section 3 of the GNU GPL."
>
> Obviously, this is interpretation.

Yes, and that interpretation seems to contradict both the actual  
language and the intent of GPL clause 2 quoted above.

Specifically, it's entirely possible to write software which can be  
distributed without including any GPL'ed code, which will dynamically  
link libreadline.so (if available), or run without it, if  
libreadline.so is not available.  Both Perl and Python do this, for  
example.  Perl is dual-licensed under the GPL, but Python is not--  
nor does it need to be.

> Similarly, the FSF uses Readline as an example of a library they  
> leverage to convince people to release their programs under the GPL  
> (http://www.gnu.org/licenses/why-not-lgpl.html).

Of course they do.  It's not surprising that the article you've  
referenced was written back in 1999 but makes no mention of the  
existence of a BSD-licensed readline library (written by Jaromir  
Dolecek for NetBSD in 1997), nor the libedit library written by  
Christos Zoulas for 4.4BSD back in 1992.  The earliest version of GNU  
readline that I can find (originally written by Brian Fox) dates to  
1994.

I've even seen people claim that the only reason why proprietary  
software running on Linux can avoid being "forcibly relicensed under  
the GPL" is because GNU libc is under the LGPL.  They seem to forget  
that the original standard C library was written by Kernighan and  
Richie back around 1971, some twenty years before Roland McGrath  
started writing GNU libc circa 1992.

Just because a program calls printf() does not mean that it becomes a  
derivative work of GNU libc when dynamically linked on a Linux  
platform, any more than that same exact same program source code  
becomes a derivative work of the original C library on a BSD  
platform, of Microsoft's Visual-C++ DLLs when dynamically linked on  
Windows, and so forth for every platform that supports an ANSI-C  
library.

> You're welcome to have a different opinion, but don't try to make it
> seem indisputable or uncontroversial by spouting off sections of  
> the GPL

Honi soit qui mal y pense.  I'd prefer to avoid debating opinions--  
mine included-- in favor of facts (ie, things which are testable,  
repeatable, refutable, and so forth).

--
-Chuck

[Matthew Flaschen]

Chuck Swiger wrote:

>> Moreover, the portions of their code that were licensed under BSD are
>> still under BSD...
>
> I agree up to here...
>
>> ...(though this usually doesn't mean much).
>
> ...but I am not quite sure what you meant by this.  One would hope that
> having source code available under an OSI-approved open source license
> would have some meaning at least for the people on the OSI mailing lists.

Of course this means a lot to me (I would strongly prefer that the
license also be FSF-approved).

What I meant here is that if BSD code is modified substantially with
proprietary changes, the BSD code usually can't be extracted from the
proprietary version.  Thus, the BSD license doesn't have any practical
meaning for users of the blend (why I don't like the BSD license and
avoid proprietary software derived from BSD code).

Thus, for example, much of OS X is under a BSD license, but difficult to
extract out the BSD code and use it separately.  There's also usually no
reason, since it's available untainted straight from the source.

Matthew Flaschen

>
>>> There are some people who feel that software licenses somehow
>>> automatically apply their terms to any and all other software used in
>>> conjunction with the original software in question (ie, as part of a
>>> compilation, or via dynamic linking, or via pipelines, RPC, or other
>>> form of network communication).
>>
>> There are many quite distinct conjunctive relationships, which you've
>> lumped together.  Some forms of conjunction (such as static linking)
>> clearly create a derivative work, because the original code is present
>> in the executable.  In most other cases, it is controversial.
>
> I would agree that static linking forms a derivative work for exactly
> the reason you've mentioned; however, if you'll notice, I did not
> mention static linking in the list above.  This omission was quite
> deliberate.

I misread "as part of a compilation" as the vague and totally different
"when compiled together".  Excuse me for this foolish mistake.
>
> However, that is slightly aside from the central point, which is that a
> license applies to the software under that license and to derivative
> works but *not* to other software which is completely independent and
> exists under other license terms.

My understanding (I admittedly did not originally interpret the license
this way) is that BSD doesn't apply for even derivative works, only for
the original code.

>> "But when you distribute the same sections as part of a whole which is a
>> work based on the Program, the distribution of the whole must be on the
>> terms of this License, whose permissions for other licensees extend to
>> the entire whole, and thus to each and every part regardless of who
>> wrote it."
>
> Of course.  And if one of the other parts is under license terms which
> are not GPL-miscible, then the derived work cannot be redistributed at all.
>
> As far as I can tell, *none* of the OSI-approved licenses grant
> redistributors or people modifying the code the right to change the
> original license terms.

This is not a question of whether you can change the terms of existing
code.  It is a question of the terms for derivative works, or the
question of copyleft.  Critically, the BSD and GPL give different
answers to this answer.  The BSD license allows derivative works to have
any license (as long as the BSD is preserved for the original code).
The GPL mandates that derivative works are licensed under the GPL in
their entirety.

>
> "These requirements apply to the modified work as a whole. If
> identifiable sections of that work are not derived from the Program, and
> can be reasonably considered independent and separate works in
> themselves, then this License, and its terms, do not apply to those
> sections when you distribute them as separate works."
>
> [ ...followed by the section "But when..." Matthew quoted above... ]
>
> "Thus, it is not the intent of this section to claim rights or contest
> your rights to work written entirely by you; rather, the intent is to
> exercise the right to control the distribution of derivative or
> collective works based on the Program."
>
> "In addition, mere aggregation of another work not based on the Program
> with the Program (or with a work based on the Program) on a volume of a
> storage or distribution medium does not bring the other work under the
> scope of this License."
> And this is exactly what the GPL says in the portion of the paragraph
> just before what you've quoted above:

Yep, these two parts carefully counter each other.  Again, copyright law
will be a final arbiter.

>> As far as Readline specifically, A USAGE file says:
>>
>> "I think Allbery's suggestion is a good one.  So please add this text
>> in a suitable place.  Please don't put it in the GPL itself; that
>> should be the same as the GPL everywhere else.  Putting it in the
>> README and/or the documentation would be a good idea.
>>
>> ======================================================================
>> Our position on the use of Readline through a shared-library linking
>> mechanism is that there is no legal difference between shared-library
>> linking and static linking--either kind of linking combines various
>> modules into a single larger work.  The conditions for using Readline
>> in a larger work are stated in section 3 of the GNU GPL."
>>
>> Obviously, this is interpretation.
>
> Yes, and that interpretation seems to contradict both the actual
> language and the intent of GPL clause 2 quoted above.

Seems to you.  It depends on whether shared library linking creates a
derivative work.  This is a matter of opinion and interpretation thus far.

> Specifically, it's entirely possible to write software which can be
> distributed without including any GPL'ed code

Derivative works don't have to include literal content from the
original.  If I translate a poem, I may not include any words from the
original, but it is still a derivate work.

, which will dynamically
> link libreadline.so (if available), or run without it, if libreadline.so
> is not available.  Both Perl and Python do this, for example.  Perl is
> dual-licensed under the GPL, but Python is not-- nor does it need to be.

Again, this still may create a derivative work, since program (or the
part that can use readline) is written to so tightly depend on readline.

> I've even seen people claim that the only reason why proprietary
> software running on Linux can avoid being "forcibly relicensed under the
> GPL" is because GNU libc is under the LGPL.

No one can force anyone to license something under the GPL. They can
only sue them for copyright infringement if they distribute a derivative
work under different terms.  It is my understanding as well that this is
the case for libc, but this is again opinion.

  They seem to forget that
> the original standard C library was written by Kernighan and Richie back
> around 1971, some twenty years before Roland McGrath started writing GNU
> libc circa 1992.

And similarly to the LGPL, this library does not substantially restrict
the license of derivative works.

>
> Just because a program calls printf() does not mean that it becomes a
> derivative work of GNU libc when dynamically linked on a Linux platform,
> any more than that same exact same program source code becomes a
> derivative work of the original C library on a BSD platform, of
> Microsoft's Visual-C++ DLLs when dynamically linked on Windows, and so
> forth for every platform that supports an ANSI-C library.

I think Microsoft's EULA for these DLLs would offer a very different
interpretation of copyright law.  I think all of these licenses allow
derivative works, and this has blinded you to the fact that they could
restrict them.

>> You're welcome to have a different opinion, but don't try to make it
>> seem indisputable or uncontroversial by spouting off sections of the GPL
>
> Honi soit qui mal y pense.

Translation?

  I'd prefer to avoid debating opinions-- mine
> included-- in favor of facts (ie, things which are testable, repeatable,
> refutable, and so forth).

The problem is you keep confusing the two.

Matt Flaschen

[Chuck Swiger]

On Jan 17, 2007, at 11:32 AM, Matthew Flaschen wrote:
>> One would hope that
>> having source code available under an OSI-approved open source  
>> license
>> would have some meaning at least for the people on the OSI mailing  
>> lists.
>
> Of course this means a lot to me (I would strongly prefer that the
> license also be FSF-approved).

You ought to be aware that the "new" BSD license appears in the FSF-
approved list of "GPL-compatible Free Software Licenses":

   http://www.fsf.org/licensing/licenses/index_html

...?

> What I meant here is that if BSD code is modified substantially with
> proprietary changes, the BSD code usually can't be extracted from the
> proprietary version.

This is true and represents the intended goal of the original author
(s): people are welcome to use BSD-licensed code in proprietary  
software and only release binaries rather than being obligated to  
release their modified version of the source code as well.

> Thus, the BSD license doesn't have any practical
> meaning for users of the blend (why I don't like the BSD license and
> avoid proprietary software derived from BSD code).

The BSD license (or the MIT/X11 license, or the Zlib & PNG licenses)  
have a very practical meaning for people who want to use some  
existing software when writing proprietary software.  You're welcome  
to decide for yourself that you don't want to use proprietary  
software, Matthew, but you seem curiously unwilling to acknowledge  
that people using BSD-licensed software to write proprietary software  
are also users of BSD software.

> Thus, for example, much of OS X is under a BSD license, but  
> difficult to
> extract out the BSD code and use it separately.  There's also  
> usually no
> reason, since it's available untainted straight from the source.

It's not hard to get the BSD-licensed portions of OS X from Apple:

   http://www.apple.com/opensource/

...and I know that a number of changes and improvements Apple have  
made their way back into the BSDs, to the Apache projects, to the  
ISC's software (BIND, DHCP, etc), and elsewhere.

>> I would agree that static linking forms a derivative work for exactly
>> the reason you've mentioned; however, if you'll notice, I did not
>> mention static linking in the list above.  This omission was quite
>> deliberate.
>
> I misread "as part of a compilation" as the vague and totally  
> different
> "when compiled together".  Excuse me for this foolish mistake.

I see-- very well.

>> However, that is slightly aside from the central point, which is  
>> that a
>> license applies to the software under that license and to derivative
>> works but *not* to other software which is completely independent and
>> exists under other license terms.
>
> My understanding (I admittedly did not originally interpret the  
> license
> this way) is that BSD doesn't apply for even derivative works, only  
> for
> the original code.

I would not agree with that position at all.

The BSD license is a simple, permissive license which allows you to  
add your own software or make changes, and license the derivative  
work formed thereby under *both* the BSD license and your proprietary  
license-- so long as you adhere to the terms of the BSD license by  
preserving the statements and original disclaimer in source or binary  
forms.

>>> "But when you distribute the same sections as part of a whole  
>>> which is a
>>> work based on the Program, the distribution of the whole must be  
>>> on the
>>> terms of this License, whose permissions for other licensees  
>>> extend to
>>> the entire whole, and thus to each and every part regardless of who
>>> wrote it."
>>
>> Of course.  And if one of the other parts is under license terms  
>> which
>> are not GPL-miscible, then the derived work cannot be  
>> redistributed at all.
>>
>> As far as I can tell, *none* of the OSI-approved licenses grant
>> redistributors or people modifying the code the right to change the
>> original license terms.
>
> This is not a question of whether you can change the terms of existing
> code.  It is a question of the terms for derivative works, or the
> question of copyleft.  Critically, the BSD and GPL give different
> answers to this answer.  The BSD license allows derivative works to  
> have
> any license (as long as the BSD is preserved for the original code).

That's right.

> The GPL mandates that derivative works are licensed under the GPL in
> their entirety.

No, not quite.  With regard to derivative works of GPL'ed software,  
"distribution of the whole must be on the terms of this License"; if  
you don't (re)distribute the combination then the other parts do not  
need to be licensed under the GPL or even under a GPL-miscible license.

If you do wish to redistribute the combination, then you must follow  
the terms of both licenses, which in practice means that you can only  
do so if the other parts are licensed under a GPL-miscible license.  
However, the other parts need not be under the GPL.

[ ... ]

>>> Our position on the use of Readline through a shared-library linking
>>> mechanism is that there is no legal difference between shared-
>>> library
>>> linking and static linking--either kind of linking combines various
>>> modules into a single larger work.  The conditions for using  
>>> Readline
>>> in a larger work are stated in section 3 of the GNU GPL."
>>>
>>> Obviously, this is interpretation.
>>
>> Yes, and that interpretation seems to contradict both the actual
>> language and the intent of GPL clause 2 quoted above.
>
> Seems to you.  It depends on whether shared library linking creates a
> derivative work.  This is a matter of opinion and interpretation  
> thus far.

I am not aware of any court decision which has indicated that dynamic  
linking produces a derivative work.

>> Specifically, it's entirely possible to write software which can be
>> distributed without including any GPL'ed code
>
> Derivative works don't have to include literal content from the
> original.  If I translate a poem, I may not include any words from the
> original, but it is still a derivate work.

Sure.  Likewise-- compiling program source code into a binary may not  
include any literal content from the original sources (although it  
usually does), but the binary that results from compiling source code  
is commonly held to be a derivative work.

>> which will dynamically link libreadline.so (if available), or run  
>> without it,
>> if libreadline.so is not available.  Both Perl and Python do this,  
>> for example.
>> Perl is dual-licensed under the GPL, but Python is not-- nor does  
>> it need to be.
>
> Again, this still may create a derivative work, since program (or the
> part that can use readline) is written to so tightly depend on  
> readline.

Please re-read what I said, especially the part "or run without it".

The Python interpreter runs just fine without readline; however, if  
you like, you can type "import readline", and Python will attempt to  
dynamically load readline if available, which is handy for doing  
interactive debugging.

>> Just because a program calls printf() does not mean that it becomes a
>> derivative work of GNU libc when dynamically linked on a Linux  
>> platform,
>> any more than that same exact same program source code becomes a
>> derivative work of the original C library on a BSD platform, of
>> Microsoft's Visual-C++ DLLs when dynamically linked on Windows,  
>> and so
>> forth for every platform that supports an ANSI-C library.
>
> I think Microsoft's EULA for these DLLs would offer a very different
> interpretation of copyright law.  I think all of these licenses allow
> derivative works, and this has blinded you to the fact that they could
> restrict them.

If your position is correct, would you care to explain how Cygwin  
redistributes GPL-licensed software compiled for Windows without  
running afoul of the GPL-immiscibility of the Microsoft EULAs?

Is every program that runs under Windows a derivative of Microsoft's  
software?  If the same exact program source code also runs on MacOS  
X, or Linux, or FreeBSD, does this same program somehow become a  
derivative work of MacOS X, Linux, FreeBSD, etc-- all at the same  
time?  Such a position seems absurd....

>>> You're welcome to have a different opinion, but don't try to make it
>>> seem indisputable or uncontroversial by spouting off sections of  
>>> the GPL
>>
>> Honi soit qui mal y pense.
>
> Translation?

French for "shame upon him who thinks evil of it".
It's meant in the sense of Matthew 7:1-5...

>> I'd prefer to avoid debating opinions-- mine included-- in favor  
>> of facts (ie, things which are testable, repeatable,
>> refutable, and so forth).
>
> The problem is you keep confusing the two.

Probably not; I don't believe that my opinions are important either  
to other people or even to myself.

I find the prospect of trying to persuade or manipulate other people  
into believing something just because I might hold a particular  
position to be disturbing and repugnant.  Because I am human, I know  
that I am fallible and imperfect, and I perceive things in a fashion  
that is intrinsically biased from genetic and cultural influences  
that cannot be completely removed.  Because I acknowledge these  
things, and start from the position that I'm at least as likely to be  
wrong as the people I might be talking with, I compensate for these  
limitations and biases as best as I can.

Observation suggests that many people find their own opinions to be  
so overwhelmingly important that they simply refuse to acknowledge  
facts which contradict these opinions; observation also suggests that  
many people are also completely unwilling to acknowledge that they  
might make mistakes or be wrong.

However, it has not been my observation that people who refuse to  
acknowledge their intrinsic biases or admit the possibility of error  
are more likely to be factually correct.

--
-Chuck

[Matthew Flaschen]

Chuck Swiger wrote:
>> Of course this means a lot to me (I would strongly prefer that the
>> license also be FSF-approved).
>
> You ought to be aware that the "new" BSD license appears in the
> FSF-approved list of "GPL-compatible Free Software Licenses":
>
>   http://www.fsf.org/licensing/licenses/index_html
>
> ...?

I do know that.  I certainly didn't mean to imply BSD wasn't a free license.

>> What I meant here is that if BSD code is modified substantially with
>> proprietary changes, the BSD code usually can't be extracted from the
>> proprietary version.
>
> This is true and represents the intended goal of the original author(s):
> people are welcome to use BSD-licensed code in proprietary software and
> only release binaries rather than being obligated to release their
> modified version of the source code as well.

I do know this.  It is a goal I disagree with, but I see their perspective.

>> Thus, the BSD license doesn't have any practical
>> meaning for users of the blend (why I don't like the BSD license and
>> avoid proprietary software derived from BSD code).
>
> The BSD license (or the MIT/X11 license, or the Zlib & PNG licenses)
> have a very practical meaning for people who want to use some existing
> software when writing proprietary software.

I am aware of the practical benefits BSD provides to initial redistributors.

  You're welcome to decide
> for yourself that you don't want to use proprietary software, Matthew,
> but you seem curiously unwilling to acknowledge that people using
> BSD-licensed software to write proprietary software are also users of
> BSD software.

They are users (sometimes in the sense of both end users and
redistributors).  However, my point was end users of proprietary
BSD-based software generally have no way to extract the free BSD code.
Thus, they can no longer redistribute the BSD code in that version.

>> Thus, for example, much of OS X is under a BSD license, but difficult to
>> extract out the BSD code and use it separately.  There's also usually no
>> reason, since it's available untainted straight from the source.
>
> It's not hard to get the BSD-licensed portions of OS X from Apple:
>
>   http://www.apple.com/opensource/
>
> ...and I know that a number of changes and improvements Apple have made
> their way back into the BSDs, to the Apache projects, to the ISC's
> software (BIND, DHCP, etc), and elsewhere.

Okay, that was probably unfair, and a bad example.  I don't think Apple
has separately released all the BSD code they're using (but I may be
wrong).  However, Microsoft for instance has been less cooperative
still.  Early versions of Microsoft used the BSD stack extensively (they
may still, though I'm not sure).  Even though that code is under the BSD
license, it is impossible (I think) to extract and redistribute the BSD
code MS uses.  Thus, the BSD license for the TCP stack doesn't affect
endusers of Windows NT; they can't become redistributors (of WinNT's TCP
code).
>> I misread "as part of a compilation" as the vague and totally different
>> "when compiled together".  Excuse me for this foolish mistake.
>
> I see-- very well.

My apology sounds sarcastic now.  It wasn't meant to be.

>>> However, that is slightly aside from the central point, which is that a
>>> license applies to the software under that license and to derivative
>>> works but *not* to other software which is completely independent and
>>> exists under other license terms.
>>
>> My understanding (I admittedly did not originally interpret the license
>> this way) is that BSD doesn't apply for even derivative works, only for
>> the original code.
>
> I would not agree with that position at all.

This is certainly an important issue, and I would appreciate hearing
from others or being pointed to some resources to clarify.  When I first
read BSD, I interpreted it your way, but have since been steered to the
view I gave above.  I should clarify that I don't think it applies to
*new code* in the derivative work.

> The BSD license is a simple, permissive license which allows you to add
> your own software or make changes, and license the derivative work
> formed thereby under *both* the BSD license and your proprietary
> license--

So this means that for instance the WinNT TCP stack is all under BSD (or
at least the parts derived from BSD code)?  How is this different from
the GPL, which also allows new code (in a distributed derivative work)
to be dual licensed under the GPL and a proprietary license?  Is the
only difference source availability?

>> This is not a question of whether you can change the terms of existing
>> code.  It is a question of the terms for derivative works, or the
>> question of copyleft.  Critically, the BSD and GPL give different
>> answers to this answer.  The BSD license allows derivative works to have
>> any license (as long as the BSD is preserved for the original code).
>
> That's right.

But we disagree on whether new code in derivative works must also be
under BSD.  I think it need not.

>> The GPL mandates that derivative works are licensed under the GPL in
>> their entirety.
>
> No, not quite.  With regard to derivative works of GPL'ed software,
> "distribution of the whole must be on the terms of this License"; if you
> don't (re)distribute the combination then the other parts do not need to
> be licensed under the GPL or even under a GPL-miscible license.

Yes, I meant if a derivative work were redistributed.

> If you do wish to redistribute the combination, then you must follow the
> terms of both licenses, which in practice means that you can only do so
> if the other parts are licensed under a GPL-miscible license.  However,
> the other parts need not be under the GPL.

Agreed, many licenses (BSD-included) are GPL-miscible (GPL-compatible).

>> Seems to you.  It depends on whether shared library linking creates a
>> derivative work.  This is a matter of opinion and interpretation thus
>> far.
>
> I am not aware of any court decision which has indicated that dynamic
> linking produces a derivative work.

I'm not well versed in case law; you're probably right.  However, I
don't think there has been a decision the other way either.  In any
case, many (including some experts) do assert this.

>>> which will dynamically link libreadline.so (if available), or run
>>> without it,
>>> if libreadline.so is not available.  Both Perl and Python do this,
>>> for example.
>>> Perl is dual-licensed under the GPL, but Python is not-- nor does it
>>> need to be.
>>
>> Again, this still may create a derivative work, since program (or the
>> part that can use readline) is written to so tightly depend on readline.
>
> Please re-read what I said, especially the part "or run without it".

That's why I said "the part that can use readline)".  This code may be a
derivative work of readline, which would mean the whole program was.

>
> The Python interpreter runs just fine without readline; however, if you
> like, you can type "import readline", and Python will attempt to
> dynamically load readline if available, which is handy for doing
> interactive debugging.
>
>>> Just because a program calls printf() does not mean that it becomes a
>>> derivative work of GNU libc when dynamically linked on a Linux platform,
>>> any more than that same exact same program source code becomes a
>>> derivative work of the original C library on a BSD platform, of
>>> Microsoft's Visual-C++ DLLs when dynamically linked on Windows, and so
>>> forth for every platform that supports an ANSI-C library.
>>
>> I think Microsoft's EULA for these DLLs would offer a very different
>> interpretation of copyright law.  I think all of these licenses allow
>> derivative works, and this has blinded you to the fact that they could
>> restrict them.
>
> If your position is correct, would you care to explain how Cygwin
> redistributes GPL-licensed software compiled for Windows without running
> afoul of the GPL-immiscibility of the Microsoft EULAs?

I think the EULAs allow derivatives to be distributed under any terms,
as long as the DLLs themselves are not distributed.  In turn, I think
the GPL permits this through the operating system exception:

"the source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which the
executable runs, unless that component itself accompanies the executable."

>> Is every program that runs under Windows a derivative of Microsoft's
> software?  If the same exact program source code also runs on MacOS X,
> or Linux, or FreeBSD, does this same program somehow become a derivative
> work of MacOS X, Linux, FreeBSD, etc-- all at the same time?  Such a
> position seems absurd....

If the library is so simple that the API is shared among all these
systems, it would probably not result in a derivative work.  Of course,
this is a gray area, and we again must await legal decisions.

>>>> You're welcome to have a different opinion, but don't try to make it
>>>> seem indisputable or uncontroversial by spouting off sections of the
>>>> GPL
>>>
>>> Honi soit qui mal y pense.
>>
>> Translation?
>
> French for "shame upon him who thinks evil of it".
> It's meant in the sense of Matthew 7:1-5...

I'm sorry.  I've been rather rigid and impatient through this whole
discussion.

> Because I am human, I know that I am
> fallible and imperfect, and I perceive things in a fashion that is
> intrinsically biased from genetic and cultural influences that cannot be
> completely removed.  Because I acknowledge these things, and start from
> the position that I'm at least as likely to be wrong as the people I
> might be talking with, I compensate for these limitations and biases as
> best as I can.

That's certainly a goal I can agree with.

>
> Observation suggests that many people find their own opinions to be so
> overwhelmingly important that they simply refuse to acknowledge facts
> which contradict these opinions; observation also suggests that many
> people are also completely unwilling to acknowledge that they might make
> mistakes or be wrong.

I agree.  Hopefully, I am not being so blind.

Matthew Flaschen

[Chuck Swiger]

On Jan 17, 2007, at 3:45 PM, Matthew Flaschen wrote:

>> You're welcome to decide
>> for yourself that you don't want to use proprietary software,  
>> Matthew,
>> but you seem curiously unwilling to acknowledge that people using
>> BSD-licensed software to write proprietary software are also users of
>> BSD software.
>
> They are users (sometimes in the sense of both end users and
> redistributors).  However, my point was end users of proprietary
> BSD-based software generally have no way to extract the free BSD code.
> Thus, they can no longer redistribute the BSD code in that version.

It's certainly common for people to statically link in BSD code into  
a proprietary program in a fashion that makes it difficult to extract  
or update.

On the other hand, it's not uncommon for even highly proprietary  
software (I'm thinking about things like Windows-based games, which  
tend to be copy-protected & come with obnoxious forms of DRM like  
Starforce, SecuROM, SafeDisc, etc) to have a zlib.dll or similar,  
where you actually can swap that out for a newer version of the ZLib  
compression software you build yourself.

>>> Thus, for example, much of OS X is under a BSD license, but  
>>> difficult to
>>> extract out the BSD code and use it separately.  There's also  
>>> usually no
>>> reason, since it's available untainted straight from the source.
>>
>> It's not hard to get the BSD-licensed portions of OS X from Apple:
>>
>>   http://www.apple.com/opensource/
>>
>> ...and I know that a number of changes and improvements Apple have  
>> made
>> their way back into the BSDs, to the Apache projects, to the ISC's
>> software (BIND, DHCP, etc), and elsewhere.
>
> Okay, that was probably unfair, and a bad example.  I don't think  
> Apple
> has separately released all the BSD code they're using (but I may be
> wrong).

Perhaps you might ask Ernie Prabhakar; I cannot answer that question  
myself.

> However, Microsoft for instance has been less cooperative
> still.  Early versions of Microsoft used the BSD stack extensively  
> (they
> may still, though I'm not sure).  Even though that code is under  
> the BSD
> license, it is impossible (I think) to extract and redistribute the  
> BSD
> code MS uses.  Thus, the BSD license for the TCP stack doesn't affect
> endusers of Windows NT; they can't become redistributors (of  
> WinNT's TCP
> code).

Microsoft's licensing actually lists a number of BSD contributors who  
have worked on the TCP/IP stack and firewall capabilities, and this  
is still true of XP/2003/Vista, so it's reasonable to assume that  
there's still a fair amount of BSD-derived code lurking in their  
network stack.

It would be difficult to extract that code, agreed, although it is  
quite possible to replace the CLI binaries for things like ping, ftp,  
telnet, and so forth with alternatives.  That's part of what Cygwin  
does.

>>> I misread "as part of a compilation" as the vague and totally  
>>> different
>>> "when compiled together".  Excuse me for this foolish mistake.
>>
>> I see-- very well.
>
> My apology sounds sarcastic now.  It wasn't meant to be.

A legitimate confusion about what someone meant happens sometimes  
even with the best of intent on both sides; no problem.

>>> My understanding (I admittedly did not originally interpret the  
>>> license
>>> this way) is that BSD doesn't apply for even derivative works,  
>>> only for
>>> the original code.
>>
>> I would not agree with that position at all.
>
> This is certainly an important issue, and I would appreciate hearing
> from others or being pointed to some resources to clarify.  When I  
> first
> read BSD, I interpreted it your way, but have since been steered to  
> the
> view I gave above.  I should clarify that I don't think it applies to
> *new code* in the derivative work.

Ah, that's a critical distinction.  I would now agree with your  
statement with regard to *new code* added to BSD-licensed software;  
that does not need to be under the BSDL.

>> The BSD license is a simple, permissive license which allows you  
>> to add
>> your own software or make changes, and license the derivative work
>> formed thereby under *both* the BSD license and your proprietary
>> license--
>
> So this means that for instance the WinNT TCP stack is all under  
> BSD (or
> at least the parts derived from BSD code)?

The unmodified portions of the Windows NT TCP stack which came from  
BSD were and are under the BSD license.  The combination of that  
original software and Microsoft's changes are distributed under  
Microsoft's proprietary EULA, but that EULA still lists the terms of  
the original BSD license, including some attribution requirements in  
the case of the "old" form of the BSDL.

Search most of the way down for "Acknowledgements" in:

    http://support.microsoft.com/kb/306819

> How is this different from the GPL, which also allows new code (in  
> a distributed derivative work)
> to be dual licensed under the GPL and a proprietary license?  Is the
> only difference source availability?

That's an interesting question.  The main differences I see are that  
the GPL requires source code availability and places requirements  
upon the distribution & licensing of all subsequent derivative works.

>>> This is not a question of whether you can change the terms of  
>>> existing
>>> code.  It is a question of the terms for derivative works, or the
>>> question of copyleft.  Critically, the BSD and GPL give different
>>> answers to this answer.  The BSD license allows derivative works  
>>> to have
>>> any license (as long as the BSD is preserved for the original code).
>>
>> That's right.
>
> But we disagree on whether new code in derivative works must also be
> under BSD.  I think it need not.

We're actually in agreement here; see above.  :-)

[ ... ]

>>> Seems to you.  It depends on whether shared library linking  
>>> creates a
>>> derivative work.  This is a matter of opinion and interpretation  
>>> thus
>>> far.
>>
>> I am not aware of any court decision which has indicated that dynamic
>> linking produces a derivative work.
>
> I'm not well versed in case law; you're probably right.  However, I
> don't think there has been a decision the other way either.  In any
> case, many (including some experts) do assert this.

I wonder if you might name these experts and point to their reasoning  
for closer evaluation?

For what it's worth, I've served as an expert witness in a software  
copyright infringement case [1] and have performed the "abstraction-
filtration-comparison" testing to identify copyrightable program code  
required by the Computer Associates v. Altai decision.  This doesn't  
make me even slightly qualified to hold or provide legal opinions,  
BTW, but the Honorable Richard Conway Casey, U.S.D.J. was willing to  
accept my opinions with regard to computer software in his court.  
YMMV.  :-)

>>>> which will dynamically link libreadline.so (if available), or run
>>>> without it, if libreadline.so is not available.  Both Perl and  
>>>> Python do this,
>>>> for example.  Perl is dual-licensed under the GPL, but Python is  
>>>> not-- nor does it
>>>> need to be.
>>>
>>> Again, this still may create a derivative work, since program (or  
>>> the
>>> part that can use readline) is written to so tightly depend on  
>>> readline.
>>
>> Please re-read what I said, especially the part "or run without it".
>
> That's why I said "the part that can use readline)".  This code may  
> be a
> derivative work of readline, which would mean the whole program was.

Well, that's simply not how the analysis for copyright infringement  
works.

The filtration test requires one to analyze the program modules via a  
flowchart, and decide whether each distinct module or section "shows  
only an idea" (if yes, the material is not copyrightable, but might  
be patentable), or is an expression of an idea.  If the latter, the  
analysis requires consideration of whether the expression is (a)  
dictated by efficiency, (b) dictated by external factors  
(specifically interfaces, APIs), or (c) whether the expression is  
taken from the public domain.  Unless the answer to (a)-(c) are all  
no, and it does not represent a "protected combination", and it  
constitutes "enough copying to be a wrongful taking", it is  
considered "lawful copying" and not "copyright infringement".

Notice (b) & (c) in particular; publicly published APIs generally  
cannot qualify or be used as grounds for software copyright  
infringement...  [2]  ( IANAL, TINLA. )

>> If your position is correct, would you care to explain how Cygwin
>> redistributes GPL-licensed software compiled for Windows without  
>> running
>> afoul of the GPL-immiscibility of the Microsoft EULAs?
>
> I think the EULAs allow derivatives to be distributed under any terms,
> as long as the DLLs themselves are not distributed.

Absolutely not; this isn't a matter where you have to guess, go to:

   http://www.microsoft.com/about/legal/useterms/default.aspx

...and choose your favorite version of Visual Studio.  One version of  
the EULA states:

"2.4 Redistributable Code-Visual C++: Microsoft Foundation Classes  
(MFC), Active Template Libraries (ATL), and C runtimes (CRTs). If  
this EULA accompanies Visual C++, then in addition to the rights  
granted in Section 1, Microsoft grants you a license to use and  
modify the source code version of those portions of the Software that  
are identified as MFC, ATL, or CRTs (collectively, the "VC  
Redistributables"), for the sole purposes of designing, developing,  
and testing your software product(s). Provided you comply with  
Section 3.1..."

...and section 3.1(b) says:

"3.1 [ ... ]
(b) If you use the Redistributables, then in addition to your  
compliance with the applicable distribution requirements described  
for the Redistributables, the following also applies. Your license  
rights to the Redistributables are conditioned upon your not (i)  
creating derivative works of the Redistributables in any manner that  
would cause the Redistributables in whole or in part to become  
subject to any of the terms of an Excluded License; or (ii)  
distributing the Redistributables (or derivative works thereof) in  
any manner that would cause the Redistributables to become subject to  
any of the terms of an Excluded License. An "Excluded License" is any  
license that requires as a condition of use, modification and/or  
distribution of software subject to the Excluded License, that such  
software or other software combined and/or distributed with such  
software be (x) disclosed or distributed in source code form; (y)  
licensed for the purpose of making derivative works; or (z)  
redistributable at no charge."

You can't mix this EULA with the GPL under any circumstances,  
including the exception mentioned in GPL #3.

>> Is every program that runs under Windows a derivative of Microsoft's
>> software?  If the same exact program source code also runs on  
>> MacOS X,
>> or Linux, or FreeBSD, does this same program somehow become a  
>> derivative
>> work of MacOS X, Linux, FreeBSD, etc-- all at the same time?  Such a
>> position seems absurd....
>
> If the library is so simple that the API is shared among all these
> systems, it would probably not result in a derivative work.  Of  
> course,
> this is a gray area, and we again must await legal decisions.

It doesn't have to be a library, simple or otherwise: any program  
written against only the ANSI-C/POSIX 1003.x APIs is portable to a  
very wide of systems.  Such programs are not derivative works of any  
specific operating system.

--
-Chuck

[1]: UNITED STATES DISTRICT COURT/SOUTHERN DISTRICT OF NEW YORK/Civil  
Action No.: 02 CV 354x (RCC)

[2]: The exact text of the decision reads:

"Professor Nimmer points out that "in many instances it is virtually  
impossible to write a program to perform particular functions in a  
specific computing environment without employing standard  
techniques." 3 Nimmer s 13.03[F][3], at 13-65. This is a result of  
the fact that a programmer's freedom of design choice is often  
circumscribed by extrinsic considerations such as (1) the mechanical  
specifications of the computer on which a particular program is  
intended to run; (2) compatibility requirements of other programs  
with which a program is designed to operate in conjunction; (3)  
computer manufacturers' design standards; (4) demands of the industry  
being serviced; and (5) widely accepted programming practices within  
the computer industry. Id. at 13-66-71."

[Matthew Flaschen]

Chuck Swiger wrote:

> It's certainly common for people to statically link in BSD code into a
> proprietary program in a fashion that makes it difficult to extract or
> update.
>
> On the other hand, it's not uncommon for even highly proprietary
> software (I'm thinking about things like Windows-based games, which tend
> to be copy-protected & come with obnoxious forms of DRM like Starforce,
> SecuROM, SafeDisc, etc) to have a zlib.dll or similar, where you
> actually can swap that out for a newer version of the ZLib compression
> software you build yourself.

Yes, but the latter are the exception rather than the rule.  I also
don't think it is the intention of most proprietary software developers
to allow such flexibility; rather convenience dictates.

> It would be difficult to extract that code, agreed, although it is quite
> possible to replace the CLI binaries for things like ping, ftp, telnet,
> and so forth with alternatives.  That's part of what Cygwin does.

Yes, I use Cygwin, but that's quite separate from the question of
Windows' TCP stack.

>>>> My understanding (I admittedly did not originally interpret the license
>>>> this way) is that BSD doesn't apply for even derivative works, only for
>>>> the original code.
>>>
>>> I would not agree with that position at all.
>>
>> This is certainly an important issue, and I would appreciate hearing
>> from others or being pointed to some resources to clarify.  When I first
>> read BSD, I interpreted it your way, but have since been steered to the
>> view I gave above.  I should clarify that I don't think it applies to
>> *new code* in the derivative work.
>
> Ah, that's a critical distinction.  I would now agree with your
> statement with regard to *new code* added to BSD-licensed software; that
> does not need to be under the BSDL.

Yes, glad we cleared that up.  I think it certainly still applies to the
original BSD code in the derivative work.

> The unmodified portions of the Windows NT TCP stack which came from BSD
> were and are under the BSD license.  The combination of that original
> software and Microsoft's changes are distributed under Microsoft's
> proprietary EULA, but that EULA still lists the terms of the original
> BSD license, including some attribution requirements in the case of the
> "old" form of the BSDL.
>
> Search most of the way down for "Acknowledgements" in:
>
>    http://support.microsoft.com/kb/306819

That was an interesting page.  I've never seen such a long list of
BSD-like licenses for Microsoft software.  I especially like the
introductory comment (not required by the license) like "Because
Microsoft has included the Hewlett-Packard Company software in this
product, Microsoft is required to include the following text that
accompanied such software:"  They're almost apologizing for including an
open source license for part of their product.

>> How is this different from the GPL, which also allows new code (in a
>> distributed derivative work)
>> to be dual licensed under the GPL and a proprietary license?  Is the
>> only difference source availability?
>
> That's an interesting question.  The main differences I see are that the
> GPL requires source code availability and places requirements upon the
> distribution & licensing of all subsequent derivative works.

Yes.  The GPL does require new code in a distributed derivative work be
licensed under the GPL.  That's the critical distinction (along with
mandatory source availability).  My question was based on my
misunderstanding of your interpretation of BSD.

>> But we disagree on whether new code in derivative works must also be
>> under BSD.  I think it need not.
>
> We're actually in agreement here; see above.  :-)

Right.

>
> [ ... ]
>>>> Seems to you.  It depends on whether shared library linking creates a
>>>> derivative work.  This is a matter of opinion and interpretation thus
>>>> far.
>>>
>>> I am not aware of any court decision which has indicated that dynamic
>>> linking produces a derivative work.
>>
>> I'm not well versed in case law; you're probably right.  However, I
>> don't think there has been a decision the other way either.  In any
>> case, many (including some experts) do assert this.
>
> I wonder if you might name these experts and point to their reasoning
> for closer evaluation?

Well, Eben Moglen comes to mind.  He said
(http://interviews.slashdot.org/interviews/03/02/20/1544245.shtml?tid=117&tid=123):

"The language or programming paradigm in use doesn't determine the rules
of compliance, nor does whether the GPL'd code has been modified. The
situation is no different than the one where your code depends on static
or dynamic linking of a GPL'd library, say GNU readline. Your code, in
order to operate, must be combined with the GPL'd code, forming a new
combined work, which under GPL section 2(b) must be distributed under
the terms of the GPL and only the GPL."

in response to a question about using GPLed JARs.  It's clear he
believes dynamic linking of GPL software (e.g. readline) creates a
derivative work that must be licensed under the GPL if distributed.

>>> Please re-read what I said, especially the part "or run without it".
>>
>> That's why I said "the part that can use readline)".  This code may be a
>> derivative work of readline, which would mean the whole program was.
>
> Well, that's simply not how the analysis for copyright infringement works.
>
> The filtration test requires one to analyze the program modules via a
> flowchart, and decide whether each distinct module or section "shows
> only an idea" (if yes, the material is not copyrightable, but might be
> patentable), or is an expression of an idea.  If the latter, the
> analysis requires consideration of whether the expression is (a)
> dictated by efficiency, (b) dictated by external factors (specifically
> interfaces, APIs), or (c) whether the expression is taken from the
> public domain.  Unless the answer to (a)-(c) are all no, and it does not
> represent a "protected combination", and it constitutes "enough copying
> to be a wrongful taking", it is considered "lawful copying" and not
> "copyright infringement".
>
> Notice (b) & (c) in particular; publicly published APIs generally cannot
> qualify or be used as grounds for software copyright infringement...
> [2]  ( IANAL, TINLA. )

That's quite interesting.  Depending on the interpretation of b. if
source file A is coded using library B, then they are statically linked
together, source file A might not be a derivative work of B if B is
considered an external factor.  The binary probably still would be, though.

>>> If your position is correct, would you care to explain how Cygwin
>>> redistributes GPL-licensed software compiled for Windows without running
>>> afoul of the GPL-immiscibility of the Microsoft EULAs?
>>
>> I think the EULAs allow derivatives to be distributed under any terms,
>> as long as the DLLs themselves are not distributed.
>
> Absolutely not; this isn't a matter where you have to guess, go to:
>
>   http://www.microsoft.com/about/legal/useterms/default.aspx
>
> ...and choose your favorite version of Visual Studio.  One version of
> the EULA states:
>
> "2.4 Redistributable Code-Visual C++: Microsoft Foundation Classes
> (MFC), Active Template Libraries (ATL), and C runtimes (CRTs). If this
> EULA accompanies Visual C++, then in addition to the rights granted in
> Section 1, Microsoft grants you a license to use and modify the source
> code version of those portions of the Software that are identified as
> MFC, ATL, or CRTs (collectively, the "VC Redistributables"), for the
> sole purposes of designing, developing, and testing your software
> product(s). Provided you comply with Section 3.1..."
>
> ...and section 3.1(b) says:
>
> "3.1 [ ... ]
> (b) If you use the Redistributables, then in addition to your compliance
> with the applicable distribution requirements described for the
> Redistributables, the following also applies. Your license rights to the
> Redistributables are conditioned upon your not (i) creating derivative
> works of the Redistributables in any manner that would cause the
> Redistributables in whole or in part to become subject to any of the
> terms of an Excluded License; or (ii) distributing the Redistributables
> (or derivative works thereof) in any manner that would cause the
> Redistributables to become subject to any of the terms of an Excluded
> License. An "Excluded License" is any license that requires as a
> condition of use, modification and/or distribution of software subject
> to the Excluded License, that such software or other software combined
> and/or distributed with such software be (x) disclosed or distributed in
> source code form; (y) licensed for the purpose of making derivative
> works; or (z) redistributable at no charge."
>
> You can't mix this EULA with the GPL under any circumstances, including
> the exception mentioned in GPL #3.

Why not?  I think this exception ensures the DLLs wouldn't fall under
the GPL; thus neither i or ii should be violated.

Matthew Flaschen

[Chuck Swiger]

On Jan 17, 2007, at 7:02 PM, Matthew Flaschen wrote:

>>>> I am not aware of any court decision which has indicated that  
>>>> dynamic
>>>> linking produces a derivative work.
>>>
>>> I'm not well versed in case law; you're probably right.  However, I
>>> don't think there has been a decision the other way either.  In any
>>> case, many (including some experts) do assert this.
>>
>> I wonder if you might name these experts and point to their reasoning
>> for closer evaluation?
>
> Well, Eben Moglen comes to mind.  He said
> (http://interviews.slashdot.org/interviews/03/02/20/1544245.shtml?
> tid=117&tid=123):
>
> "The language or programming paradigm in use doesn't determine the  
> rules
> of compliance, nor does whether the GPL'd code has been modified. The
> situation is no different than the one where your code depends on  
> static
> or dynamic linking of a GPL'd library, say GNU readline. Your code, in
> order to operate, must be combined with the GPL'd code, forming a new
> combined work, which under GPL section 2(b) must be distributed under
> the terms of the GPL and only the GPL."
>
> in response to a question about using GPLed JARs.  It's clear he
> believes dynamic linking of GPL software (e.g. readline) creates a
> derivative work that must be licensed under the GPL if distributed.

Notice the key phrases "...where your code depends on static or  
dynamic linking of a GPL'ed library..." & "...in order to operate".  
If your program cannot operate without the GPL'ed library, I would  
agree with Eben's position that whether the program uses static or  
dynamic linking doesn't matter; the program is a derivative work of  
the GPL'ed library.

However, I'd be curious to hear his opinion with regard to the  
situation where the program does not depend on the GPL'ed library to  
run, but might optionally use it via dynamic linking.  I did a quick  
search on this mailing lists' archives with regard to that question;  
in doing so, I noticed the following:

   http://www.linuxdevices.com/files/misc/asay-paper.pdf

...where he's quoted as saying (with regard to whether a situation  
would create a derivative work, ppg 15-16):

"A module written to be plugged into an API defined specifically to  
support dynamic loading?
Moglen:  No."

[ CC:ing Eben so he might clarify his position, if he wishes to do  
so.... ]

--
-Chuck

[Chuck Swiger]

On Jan 17, 2007, at 7:02 PM, Matthew Flaschen wrote:
[ ...earlier portions of the thread reformatted to avoid deeply-
nested quotes... ]

CS> Just because a program calls printf() does not mean that it  
becomes a
CS> derivative work of GNU libc when dynamically linked on a Linux  
platform,
CS> any more than that same exact same program source code becomes a
CS> derivative work of the original C library on a BSD platform, of
CS> Microsoft's Visual-C++ DLLs when dynamically linked on Windows,  
and so
CS> forth for every platform that supports an ANSI-C library.

MF> I think Microsoft's EULA for these DLLs would offer a very different
MF> interpretation of copyright law.  I think all of these licenses  
allow
MF> derivative works, and this has blinded you to the fact that they  
could
MF> restrict them.

CS> If your position is correct, would you care to explain how Cygwin
CS> redistributes GPL-licensed software compiled for Windows without  
running
CS> afoul of the GPL-immiscibility of the Microsoft EULAs?

MF> I think the EULAs allow derivatives to be distributed under any  
terms,
MF> as long as the DLLs themselves are not distributed.

>> Absolutely not; this isn't a matter where you have to guess, go to:
>>
>>   http://www.microsoft.com/about/legal/useterms/default.aspx
>>
>> ...and choose your favorite version of Visual Studio.  One version of
>> the EULA states:
[ ...Microsoft EULA snipped for brevity... ]
>> You can't mix this EULA with the GPL under any circumstances,  
>> including
>> the exception mentioned in GPL #3.
>
> Why not?  I think this exception ensures the DLLs wouldn't fall under
> the GPL; thus neither i or ii should be violated.

Microsoft EULA's not only impose many additional constraints which  
are not GPL-miscible, the M$ EULA explicitly forbid one to create a  
derivative work of "Redistributable Code - Visual C++: Microsoft  
Foundation Classes (MFC), Active Template Libraries (ATL), and C  
runtimes (CRTs)" in conjunction with an "Excluded License", which the  
GPL obviously is.

Your position is (or was) that a program which dynamically links  
against the standard C library constitutes a derivative work of the  
standard C library; if your position is correct, then Cygwin  
constitutes a derivative work of both the Windows DLLs which it loads  
and Cygwin's GPL'ed source code.  However, Cygwin could not be  
redistributed unless it complied with both the terms of the GPL  
(which most of Cygwin is under, see: [1]) and the appropriate  
Microsoft EULA for the platform; which would not be possible since  
the two licenses are not miscible.

It's conceivable that the portions of Cygwin which invoke Win32 APIs  
are not under the GPL, but exist as a "shim" to connect the Microsoft  
specific code with Cygwin's GPL'ed internals.  However, notice that  
this approach is precisely the same that nVidia's proprietary drivers  
do in order to produce a Linux kernel module.

Why is it OK for Cygwin to use a shim to dynamically link against  
Windows DLLs and redistribute the result, but not OK for nVidia to do  
the same when linking against the Linux kernel?

--
-Chuck

[1]: http://cygwin.com/license.html

[Matthew Flaschen]

Chuck Swiger wrote:

>> Well, Eben Moglen comes to mind.  He said
>> (http://interviews.slashdot.org/interviews/03/02/20/1544245.shtml?tid=117&tid=123):
>>
>>
>> "The language or programming paradigm in use doesn't determine the rules
>> of compliance, nor does whether the GPL'd code has been modified. The
>> situation is no different than the one where your code depends on static
>> or dynamic linking of a GPL'd library, say GNU readline. Your code, in
>> order to operate, must be combined with the GPL'd code, forming a new
>> combined work, which under GPL section 2(b) must be distributed under
>> the terms of the GPL and only the GPL."
>>
>> in response to a question about using GPLed JARs.  It's clear he
>> believes dynamic linking of GPL software (e.g. readline) creates a
>> derivative work that must be licensed under the GPL if distributed.
>
> Notice the key phrases "...where your code depends on static or dynamic
> linking of a GPL'ed library..." & "...in order to operate".

Sticking to the example of readline and Python, part of the code is
still specifically written to depend on readline.  I think under Eben's
argument, this part would then be a derivative work.  Thus, that part at
least should be licensed under the GPL.

> However, I'd be curious to hear his opinion with regard to the situation
> where the program does not depend on the GPL'ed library to run, but
> might optionally use it via dynamic linking.  I did a quick search on
> this mailing lists' archives with regard to that question; in doing so,
> I noticed the following:
>
>   http://www.linuxdevices.com/files/misc/asay-paper.pdf
>
> ...where he's quoted as saying (with regard to whether a situation would
> create a derivative work, ppg 15-16):
>
> "A module written to be plugged into an API defined specifically to
> support dynamic loading?
> Moglen:  No."

This isn't quite the same thing.  Readline wasn't written to an existing
Python plugin API.  Part of Python was written to interact specifically
with readline.

>
> [ CC:ing Eben so he might clarify his position, if he wishes to do so.... ]

I'd certainly be glad to hear his views on this issue.  Chuck first
noted that it was possible to write code (such as Perl or Python) that
would only use readline if available in
http://crynwr.com/cgi-bin/ezmlm-cgi?3:msp:12224:eekjfkiiplhjdkoabfid .

Also, Chuck, please don't CC list members to list mail, unless they ask
you to.

Matthew Flaschen

[Matthew Flaschen]

Chuck Swiger wrote:

>>> Absolutely not; this isn't a matter where you have to guess, go to:
>>>
>>>   http://www.microsoft.com/about/legal/useterms/default.aspx
>>>
>>> ...and choose your favorite version of Visual Studio.  One version of
>>> the EULA states:
> [ ...Microsoft EULA snipped for brevity... ]
>>> You can't mix this EULA with the GPL under any circumstances, including
>>> the exception mentioned in GPL #3.
>>
>> Why not?  I think this exception ensures the DLLs wouldn't fall under
>> the GPL; thus neither i or ii should be violated.
>
> Microsoft EULA's not only impose many additional constraints which are
> not GPL-miscible, the M$ EULA explicitly forbid one to create a
> derivative work of "Redistributable Code - Visual C++: Microsoft
> Foundation Classes (MFC), Active Template Libraries (ATL), and C
> runtimes (CRTs)" in conjunction with an "Excluded License", which the
> GPL obviously is.

I'm fairly certain the GPL would allow the DLLs to be excluded from
Corresponding Source due to the system library exception.  However, I
now see you're right that that doesn't address the problem of the GPLed
binary being a derivative work.  I don't know the answer to this
question.  It's quite possible that Microsoft isn't fully enforcing
their EULA here.

> Your position is (or was) that a program which dynamically links against
> the standard C library constitutes a derivative work of the standard C
> library; if your position is correct, then Cygwin constitutes a
> derivative work of both the Windows DLLs which it loads and Cygwin's
> GPL'ed source code.  However, Cygwin could not be redistributed unless
> it complied with both the terms of the GPL (which most of Cygwin is
> under, see: [1]) and the appropriate Microsoft EULA for the platform;
> which would not be possible since the two licenses are not miscible.
>
> It's conceivable that the portions of Cygwin which invoke Win32 APIs are
> not under the GPL, but exist as a "shim" to connect the Microsoft
> specific code with Cygwin's GPL'ed internals.

All of Cygwin is under free/open source licenses, and the cygwin library
(which I think makes the WinAPI calls) is under the GPL (with additional
permissions to link against software with other OSI-approved licenses).

  However, notice that this
> approach is precisely the same that nVidia's proprietary drivers do in
> order to produce a Linux kernel module.
>
> Why is it OK for Cygwin to use a shim to dynamically link against
> Windows DLLs and redistribute the result, but not OK for nVidia to do
> the same when linking against the Linux kernel?

I don't recall saying anything about whether nVidia's actions were okay...

Matt

[Ben Tilly]

On 1/18/07, Matthew Flaschen <matthew.flaschen@...> wrote:
> Chuck Swiger wrote:
>
> Sticking to the example of readline and Python, part of the code is
> still specifically written to depend on readline.  I think under Eben's
> argument, this part would then be a derivative work.  Thus, that part at
> least should be licensed under the GPL.

I can't speak to Python, but I can to Perl.  The situation is nowhere
near as simple as you describe.

There is a module, Term::ReadLine, that is distributed with the Perl
core.  This module is a stub, it allows people to interface to one of
(currently) three implementations of readline.  The first will load a
module (available on CPAN) that provides a Perl interface to the GNU
application.  The second is a pure Perl implementation that is
available on CPAN.  The last is a fallback built into the module.
When Perl runs, this module is NOT loaded.  It is only loaded when
someone imports it.

Here is my opinion as a non-lawyer who can't give legal advice.  It is
obvious to me that no part of Perl outside of Term::ReadLine depends
on or is derivative from the GNU implementation of readline.  I
strongly doubt that Term::ReadLine can be said to be derivative of
readline.  I suspect that the author of Term::ReadLine::Gnu may be
overstepping when he licenses his module  under a dual Artistic/GPL
license.  (See the README file at
http://search.cpan.org/~hayashi/Term-ReadLine-Gnu-1.16/ for details.)
The authors of projects that use readline through his interface are on
more solid ground, but there is an outside chance (particularly if
they make heavy use of readline special variables etc) that they might
be argued to have to be GPLed.

[...]
> This isn't quite the same thing.  Readline wasn't written to an existing
> Python plugin API.  Part of Python was written to interact specifically
> with readline.

I suspect that Python did what Perl does.  (Possibly with less
pieces.)  In which case Python is written with a general plugin API,
and someone wrote a Python plugin around readline.  I suspect that
what is actually distributed with Python is a stub like the Perl one
so the situation is completely parallel, but the Python stub may be
more filled in than the Perl one is.

> > [ CC:ing Eben so he might clarify his position, if he wishes to do so.... ]
>
> I'd certainly be glad to hear his views on this issue.  Chuck first
> noted that it was possible to write code (such as Perl or Python) that
> would only use readline if available in
> http://crynwr.com/cgi-bin/ezmlm-cgi?3:msp:12224:eekjfkiiplhjdkoabfid .
>
> Also, Chuck, please don't CC list members to list mail, unless they ask
> you to.

Um, that's going to happen by default for most people.  The emails
arrive from the sender and CCed to the list, so "reply all" is going
to reply to both sender and list.

I manually edited things to not double send to you this time.  But I
won't guarantee to remember in the future.

Cheers,
Ben

[Chuck Swiger]

On Jan 18, 2007, at 3:39 PM, Matthew Flaschen wrote:

>> Notice the key phrases "...where your code depends on static or  
>> dynamic
>> linking of a GPL'ed library..." & "...in order to operate".
>
> Sticking to the example of readline and Python, part of the code is
> still specifically written to depend on readline.  I think under  
> Eben's
> argument, this part would then be a derivative work.  Thus, that  
> part at
> least should be licensed under the GPL.

Well, Python's Modules/readline.c isn't under the GPL.  Python's  
README states:

> This Python distribution contains no GNU General Public Licensed
> (GPLed) code so it may be used in proprietary projects just like prior
> Python distributions.  There are interfaces to some GNU code but these
> are entirely optional.

...and the LICENSE states:

> (1) GPL-compatible doesn't mean that we're distributing Python under
>     the GPL.  All Python licenses, unlike the GPL, let you distribute
>     a modified version without making your changes open source.  The
>     GPL-compatible licenses make it possible to combine Python with
>     other software that is released under the GPL; the others don't.
>
> (2) According to Richard Stallman, 1.6.1 is not GPL-compatible,
>     because its license has a choice of law clause.  According to
>     CNRI, however, Stallman's lawyer has told CNRI's lawyer that 1.6.1
>     is "not incompatible" with the GPL.

Feel free to report Python to gpl-violations.org, if you like.

[ ... ]

>>   http://www.linuxdevices.com/files/misc/asay-paper.pdf
>>
>> ...where he's quoted as saying (with regard to whether a situation  
>> would
>> create a derivative work, ppg 15-16):
>>
>> "A module written to be plugged into an API defined specifically to
>> support dynamic loading?
>> Moglen:  No."
>
> This isn't quite the same thing.  Readline wasn't written to an  
> existing
> Python plugin API.  Part of Python was written to interact  
> specifically
> with readline.

Python is designed with a plugin API which can dynamically load  
optional modules if present.  It's entirely possible to add readline  
support to a version of Python compiled without it; for examples see:

http://face.centosprime.com/macosxw/?p=171
http://cheeseshop.python.org/pypi/readline/2.4.2

> Also, Chuck, please don't CC list members to list mail, unless they  
> ask you to.

Sigh.  Different mailing lists have different conventions with regard  
to that;
I will be happy to refrain from CC:ing you in the future, or at least  
try not to do so....

--
-Chuck

[Matthew Flaschen]

Ben Tilly wrote:

> On 1/18/07, Matthew Flaschen <matthew.flaschen@...> wrote:
>> Chuck Swiger wrote:
>>
>> Sticking to the example of readline and Python, part of the code is
>> still specifically written to depend on readline.  I think under Eben's
>> argument, this part would then be a derivative work.  Thus, that part at
>> least should be licensed under the GPL.
>
> I can't speak to Python, but I can to Perl.  The situation is nowhere
> near as simple as you describe.

To clarify, I wrote that text, not Chuck.

> There is a module, Term::ReadLine, that is distributed with the Perl
> core.  This module is a stub, it allows people to interface to one of
> (currently) three implementations of readline.  The first will load a
> module (available on CPAN) that provides a Perl interface to the GNU
> application.

IANAL, but I think this is most likely to be a derivative work of readline.

> Here is my opinion as a non-lawyer who can't give legal advice.  It is
> obvious to me that no part of Perl outside of Term::ReadLine depends
> on or is derivative from the GNU implementation of readline.  I
> strongly doubt that Term::ReadLine can be said to be derivative of
> readline.  I suspect that the author of Term::ReadLine::Gnu may be
> overstepping when he licenses his module  under a dual Artistic/GPL
> license.  (See the README file at
> http://search.cpan.org/~hayashi/Term-ReadLine-Gnu-1.16/ for details.)

I don't follow.  If you say his code is not derivative of anything,
shouldn't he be able to choose whatever license he wants?

>> This isn't quite the same thing.  Readline wasn't written to an existing
>> Python plugin API.  Part of Python was written to interact specifically
>> with readline.
>
> I suspect that Python did what Perl does.  (Possibly with less
> pieces.)  In which case Python is written with a general plugin API,
> and someone wrote a Python plugin around readline.  I suspect that
> what is actually distributed with Python is a stub like the Perl one
> so the situation is completely parallel, but the Python stub may be
> more filled in than the Perl one is.

I think this hypothetical plugin/stub is most likely to be a derivative
work.

>> Also, Chuck, please don't CC list members to list mail, unless they ask
>> you to.
>
> Um, that's going to happen by default for most people.  The emails
> arrive from the sender and CCed to the list, so "reply all" is going
> to reply to both sender and list.

It happens by default for me too.  Some people take the trouble to fix
it, and some don't.

> I manually edited things to not double send to you this time.  But I
> won't guarantee to remember in the future.

Understood.

Matt Flaschen

[Matthew Flaschen]

Chuck Swiger wrote:

> On Jan 18, 2007, at 3:39 PM, Matthew Flaschen wrote:
>>> Notice the key phrases "...where your code depends on static or dynamic
>>> linking of a GPL'ed library..." & "...in order to operate".
>>
>> Sticking to the example of readline and Python, part of the code is
>> still specifically written to depend on readline.  I think under Eben's
>> argument, this part would then be a derivative work.  Thus, that part at
>> least should be licensed under the GPL.
>
> Well, Python's Modules/readline.c isn't under the GPL.  Python's README
> states:

I've been talking "should" not "is".

> Feel free to report Python to gpl-violations.org, if you like.

Not interested (I'm actually on that mailing list).  If the FSF wants to
enforce more strictly, they certainly can.

>>> "A module written to be plugged into an API defined specifically to
>>> support dynamic loading?
>>> Moglen:  No."
>>
>> This isn't quite the same thing.  Readline wasn't written to an existing
>> Python plugin API.  Part of Python was written to interact specifically
>> with readline.
>
> Python is designed with a plugin API which can dynamically load optional
> modules if present.  It's entirely possible to add readline support to a
> version of Python compiled without it; for examples see:

Again, it would be this plugin that is derivative of readline.

>
> http://face.centosprime.com/macosxw/?p=171
> http://cheeseshop.python.org/pypi/readline/2.4.2
>
>> Also, Chuck, please don't CC list members to list mail, unless they
>> ask you to.
>
> Sigh.  Different mailing lists have different conventions with regard to
> that;
> I will be happy to refrain from CC:ing you in the future, or at least
> try not to do so....

Thank you.  I don't think anyone on this list generally *prefers* being
CCed.

Matthew Flaschen