Dispelling BSD License Misconceptions (fwd)

Wed Jan 17 19:32:33 UTC 2007

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070117/ff5c7ef1/attachment.sig>