Effect of the MySQL FLOSS License Exception?

[Chuck Swiger]

On Jun 18, 2004, at 3:02 PM, jcowan at reutershealth.com wrote:
> Lawrence Rosen scripsit:
>> The real question I'm posing is: By doing this (these) compilations 
>> of a
>> source tarball that contains proprietary module X and open source 
>> module Y,
>> does the source or compiled version of X become a derivative work of 
>> Y?
>
> Which "compiled version of X"?  X.o is clearly not a derivative of Y.c.
> However, is XY, the executable block of bits resulting from statically
> linking X.o and Y.o, a derivative of Y.c?  That's the crux.  If yes,
> then at least part of the FSF's reading of the GPL is correct; if no,
> then your reading is correct.

Is XY a derivative of Y.o?  Yes. [1]
Is Y.o a derivative a Y.c?  Yes.
Is XY therefore a derivative of Y.c?  Yes.
Does that mean that Y.c derives from X.c, or vice versa?  No.  [2]

However, I suspect this example is too simple to capture the possible 
relationships which may pertain to linking a shared executable that 
combines functionality of the two in a meaningful way.  Consider the 
following:

Program X, which consists of X1.c, X2.c, ..., and X.h, which is a 
shared header which defines the interfaces/APIs used by the various 
source modules to interact with each other.

Program Y, which consists of Y1.c, Y2.c, ..., and Y.h, same thing.  
Neither X nor Y derives from each other; they are seperate and can 
stand alone.  They may have different licenses, one proprietary and one 
Open Source, etc, to correspond with Larry's example quoted above.  If 
you have Y and someone doesn't give you X, you still have Y.

Someone decides to use X and Y together in a new program, Z.  They 
write a Z.c which includes X.h and Y.h, and then links Z.o with X1.o, 
X2.o, Y1.o, Y2.o, etc to produce an executable Z.

Z derives from both X and Y: it depends on both and cannot stand alone.
If you take X away, while you may still have Y, you no longer have Z. 
[3]

I suppose one could repeat the same analysis, only instead of creating 
a new program, consider what happens if someone changes X1.c to refer 
to Y.h, or vice versa, in order to combine X and Y.  In that case, X1.c 
now does derive from Y, and the modified version of X1.c can no longer 
stand alone without Y, which may impact X as a whole if the changed 
version of X1.c is accepted into the X project and redistributed. [4]

-- 
-Chuck

[1]: I'm using the word "derive" in the same sense that the compiler 
toolchain manages depencencies between sources, compiled object files, 
and executables.  Compiler toolchains attempt to be completely 
deterministic so that the results of compiling and linking programs are 
well-defined for all cases.

It's not clear that the use of the word means the same thing to a 
lawyer, and the notions of "well-defined" or "deterministic" also seem 
less applicable to the field of law, or quite probably any other field 
involving people, for that matter.  :-)

[2]: Call this "mere aggregation".
[3]: Call this "creation of a derivative work".
[4]: I suspect this is the interesting case....

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