[Approval Request] BSD-Lite license

[Paul Guyot]

>Umm, not exactly.  Let's factor out the GPL for a moment and just
>look at a proprietary program some of whose modules are BSD.

You're right, it's a different problem.

>This is perfectly all right with the BSD license, since as I said it is not
>a copyleft.
>
>Suppose that A creates an original work a, and then B (who holds
>a proper license from A to do so, namely the BSD), creates a derivative
>work b.  Then B is the copyright owner of b, and may license it however
>she pleases, provided she has no contrary obligations imposed by A as
>a condition of his license.

This is not the key point of your argumentation, but B isn't the sole 
copyright owner of b. She's just *one* copyright owner. Except this 
little detail, I agree with your statement.

>It is B's license, and only B's license, that controls what
>can be done with b in a copyright sense.

Perfectly. That's why B's license has to respect A's license. This is 
the very problem of copyleft (and of GPL here).

>A's license may require
>B to provide a copy of itself along with b, but that does not
>make A's license effective over b, because A is not the copyright owner of b.

This is where your argumentation fails, IMHO. A is the copyright 
owner of a part of b in the US copyright law and Berne convention 
ways to see things.

>Consider in particular the command-line FTP client provided with
>Windows.  This is a proprietary binary program, and it is covered
>exclusively by the Windows EULA.  The fact that part of its
>source code is covered by the BSD license is neither here nor there;

If this software is b in your example and it is derived from some 
work "a" released under BSD (by derived, I means what copyright 
implies. For a binary, linking with typically implies derivation), 
then things are not that simple.
b's documentation/material (as defined in BSD clause #2) shall 
include the BSD (if it doesn't, my guess is that Microsoft is doing 
exactly the same mistake as the authors of open source software 
containing both GPL and BSD-licensed code).
Therefore, the EULA for b is in fact the EULA plus the BSD.

If b is only distributed in binary form and 
redistributions/decompilation are forbidden by the EULA, it's because 
the BSD says that redistribution in source or binary form is possible 
provided that this and that. Windoze EULA can add restrictions to 
this without any problem. And you're not given the source code 
anyway, which the BSD doesn't require.

Just like you can link BSD-licensed code with Apache-licensed code 
and license the whole thing under Apache license.

Problem comes when the additional restrictions of B negate the 
restrictions of the BSD, not when they are just additional 
restrictions.

>downstream licensees are strictly forbidden to pick out
>the compiled code that corresponds to the BSD source, since
>the EULA forbids decompilation.

Well, (a) decompilation will never lead to source code.
(b) saying that source code cannot be distributed doesn't negate 
restrictions of the BSD, it negates what the BSD lets you do, and 
therefore it's totally valid.

In other words, A creates some work a and puts some conditions on 
creating modified versions of it. B takes a and creates a derivative 
work b on A's conditions. Since A holds some copyright on b, B cannot 
license b without A's conditions. But B can add more conditions 
without any problem since B holds some copyright on b. Neither A or 
B's copyrights will be violated that way. And if what you wanted is 
A's work only, you can obtain a license from A.

>Now in the case where B does provide the source code to downstream
>parties, as would be required if there are GPLed components in b,
>then C (a third party), who wishes to make derivative works, must
>apply A's license when deriving from the parts of the source
>written by A, since that *is* just the work a.  But this does
>not mean that b as a whole is subject to A's license, though
>there may be restrictions placed on the reuse of it by A's
>license by reason of A's license restricting derivative works
>in some way.

If A has no copyright on b, then B has no copyright on c I could 
create from his work. So I can't see how the GPL (or whatever) would 
protect B's work, I could license it in any way provided that I make 
a little addition/change.
The contract B has with me is there because B holds some copyright on 
b. This is the very root of copyleft.

>Because the old-BSD license says "Derivative works must do thus-and-so"

Let me quote the advertising clause, you'll see that it doesn't talk 
about derivation:

>3. All advertising materials mentioning features or use of this software
>    must display the following acknowledgement:
>      This product includes software developed by the University of
>      California, Berkeley and its contributors.

I think that this is much weaker than clauses #1 & #2, because it 
says: features of this software, not features of this software or any 
software derived from it.
Let's say that you write some software using Xerces (which is under 
Apache and has this very clause). If you don't mention that it's 
doing XML parsing/generating (it might be used only internally), you 
don't need to quote the advertising acknowledgement.
But you need to include the whole license in the source 
code/documentation because of clauses #1 & #2. I still can't see if 
the GPL is incompatible with that why it would be compatible with 
clauses #1-#3 (AFAIK, the GPL doesn't include #3's restriction as 
well). Just like I don't understand how the GPL would be compatible 
with the new Zope license.

Paul
-- 
Home page: http://www.kallisys.com/
Newton-powered WebServer: http://newt.dyndns.org:8080/
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3