Subject: Re: Effect of the MySQL FLOSS License Exception?
From: Rick Moen <rick@linuxmafia.com>
Date: Wed, 16 Jun 2004 18:01:30 -0700

Quoting nospam+pixelglow.com@pixelglow.com (nospam+pixelglow.com@pixelglow.com):

> (BTW, apologies for not quoting the context in my messages, it has to
> do with my webmail client.)

Not a problem. 

> I think I understand this a bit better. In GPL clause 2, it says "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,"

Yes, that wording's a little misleading, isn't it?  It implies that 
the licence's terms might otherwise reach over and "apply" to such
third-party codebases, when such cannot be the case.

The owner of those codebases, and they alone, get to determine what
licence grants apply to instances of the work they choose to issue to
others.  Recipients then might elect to create derivative works, e.g.,
through linking it to someone else's GPLed codebase.  The result is
either lawfully redistributable or not, depending on whether there is
licence conflict.  (Licence conflict means that one or more of the
copyright holders' terms cannot be met.  Ergo, the act of redistributing
would commit the tort of copyright violation.)

> so I thought I already did not need to apply GPL to the separate BSD
> portions of my work, but I suppose then "as separate works" is the
> issue --

Old BSD licence included an advertising clause.
New BSD licence has no advertising clause.

The advertising clause (just and reasonable though it might be) is a
"further restriction" within the meaning of GPLv2 clause 6, as to the
derivative work created by combining GPLv2 + old-BSD-licensed code.
Per GPLv2 clause 2b, permission to create, copy, and redistribute
derivative works is conditioned on the whole thing being available under
GPL, so deriviatives using old-BSD code are in licence conflict.  (Owner
of the codebase instance under GPL can remove this obstacle if he wishes
by issuing a licence exception, e.g., "User may accept this copy of
codebase Foo under GPLv2 with the additional exception that Foo may be
linked against OpenSSL."  (OpenSSL is in part old-BSD-licensed.)

On the other hand, I can take your new-BSD-licensed codebase, combine it
with my GPL-licensed codebase, and consider the derivative work as a
whole[1] to be GPLed, since the newer BSD licence grants recipients all
the GPL rights and then some.  The same is true of other, similarly
permissive licences (e.g., MIT/X).

Section 2 goes on to clarify no claim is staked thereby on the
other-licensed work as a separate entity -- which is a good thing, since
the licence has no authority to do so.  All it can do is state the
conditions under which the derivative is free of licence conflict.

If there isn't a distinct work, and you're just polishing the existing
GPLed work, then avoiding licence conflict indeed requires that you put
the instance of your improvement code in question under GPL.

> Treatment of independent work under GPL: if combined, all must be
> under GPL if seperate, each can be under different license

As noted, in my view, "all must be under GPL" is in effect an odd,
high-concept way of saying "must not have licensing that imposes further
restrictions per clause 6 if it's a work with separate existence; must
be GPLed if it's not".

A couple of other things to note:  1. Realise that licensing is a
property that one (as copyright owner) attaches to an _instance_ of a
codebase that one elects to distribute.  Nothing prevents you from
issuing multiple instances with diverse rights grants.  2. As copyright
holder, you can always cure licensing conflicts, where you wish to do
so, by supplementing the licence property you attach to an issued code
instance with a licence exception, e.g., for linking to OpenSSL.

> Treatment of independent work under GPL + FLOSS Exception: if combined
> or seperate, each can be under different license
>
> Is that essentially correct?

Sounds right.

[1] The notion of the "derivative work as a whole" seems slightly
chimerical:  My understanding is that, legally, there are just creative
works of differing ownership that have been physically combined but have 
distinct rights grants as properties of their respective code objects.
So, to speak of the whole work having a licence is to simplify for
purposes of discussion -- except, I guess, in the aforementioned cases
of "polishing", where there is no distinct work.

There are some fine points about "collective works" vs. "joint works",
which I'd rather not get into -- mostly because I'm tired.  See
"Licensing HOWTO" on http://linuxmafia.com/kb/Licensing_and_Law for
details.

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3