Submitted for Approval: OSL 3.0 and AFL 3.0

[Lawrence Rosen]

> Well true, to a point. However, let's say I produce a 
> software suite which consists of executables A, B, C. They 
> share code in common, so I put that in a (shared, dynamic) 
> library D. The reason for putting the code in a library is a 
> technical one to do with reducing memory requirement when 
> more than one of A, B, C is loaded at once. It has nothing to 
> do with code reuse. Let us presume A, B, C are executables 
> that fundamentally rely upon eachother, are deeply 
> interwoven, and share data. In this instance, there is a 
> library, but it would be hard to argue A, B, C, D are 
> anything but part of the same work. They are not a collective 
> work just because of the on-disk format. I would argue that 
> in this instance, if A, B, C, D are licensed under a 
> reciprocal license, the owner of D did intend for things to 
> link to it, but quite possibly not anything other than A, B, 
> C (and other parts of a derived work).

As the author of A, B, C and D, you can license each of them separately
under OSL 3.0, or license the collective work as one work under OSL 3.0, or
both. License each chapter of the book or license the entire book. 

In your example, perhaps, you should license the entire A+B+C+D as one work.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242  *  fax: 707-485-1243
Author of "Open Source Licensing: Software Freedom and 
   Intellectual Property Law" (Prentice Hall 2004) 
   [Available also at www.rosenlaw.com/oslbook.htm]
 
 

> -----Original Message-----
> From: Alex Bligh [mailto:alex at alex.org.uk] 
> Sent: Monday, September 12, 2005 2:53 AM
> To: lrosen at rosenlaw.com; 'Gordon Kindlmann'; 
> license-discuss at opensource.org
> Cc: Alex Bligh
> Subject: RE: Submitted for Approval: OSL 3.0 and AFL 3.0
> 
> Larry,
> 
> This whole subject comes up because people are trying to 
> square computer science formulations with legal formulations. 
> In the end, I suppose the answer is "it's a question of 
> fact", but I shall comment a little below.
> 
> > Linking to a library is essential for its use; a library serves no 
> > other purpose. The owners of such libraries must intend for their 
> > licensees to link to them (however the term "link" is defined 
> > technically), and their licenses should make that point clear.
> 
> Well true, to a point. However, let's say I produce a 
> software suite which consists of executables A, B, C. They 
> share code in common, so I put that in a (shared, dynamic) 
> library D. The reason for putting the code in a library is a 
> technical one to do with reducing memory requirement when 
> more than one of A, B, C is loaded at once. It has nothing to 
> do with code reuse. Let us presume A, B, C are executables 
> that fundamentally rely upon eachother, are deeply 
> interwoven, and share data. In this instance, there is a 
> library, but it would be hard to argue A, B, C, D are 
> anything but part of the same work. They are not a collective 
> work just because of the on-disk format. I would argue that 
> in this instance, if A, B, C, D are licensed under a 
> reciprocal license, the owner of D did intend for things to 
> link to it, but quite possibly not anything other than A, B, 
> C (and other parts of a derived work).
> 
> A library, developed as a separate work, with clear 
> interfaces to external users, is clearly a different case. 
> Even here it could be argued though that the licensor's 
> intent was to allow linking TO OTHER APPLICATIONS WITH THE 
> SAME LICENSE.
> 
> But I do not think you can always assume that a licensor 
> intends a library which is part of a work licensed under a 
> reciprocal license is always intended to be permitted (by the 
> licensor) to be linked to other works under different licenses.
> 
> > The LGPL specifies how libraries work in practice using rather 
> > complicated technical terms of computer art that have 
> proven difficult 
> > to extrapolate into modern applications.
> 
> And indeed no-one has yet conclusively demonstrated the 
> correctness of the FSF's interpretation of the GPL, which 
> prohibits linking of GPL'd libraries to non-GPL works under 
> all circumstances (apart from, obviously, where a license 
> exception is made).
> 
> I believe that if the facts support it (as per the example 
> you were thinking of), i.e. where there is a single GPL'd 
> library clearly designed to link to other things, there is a 
> good case that linking does not create a derived work.
> 
> > I prefer to view mere linking as the creation of a collective work, 
> > "in which a number of contributions, constituting separate and 
> > independent works in themselves, are assembled into a 
> collective whole." 17 USC 101.
> 
> That's as fine as far as it goes, but it is in a sense a 
> cop-out, not least because the user then has to determine 
> whether or not his application plus library is a collective 
> work or not. I think there is a case for some endogenous 
> guidance from the license itself on interpretation.
> 
> Actually, to be more precise, in the case of a library 
> executable plus application executable, there is little doubt 
> that the pair together form a collective work in the sense of 
> 17 USC 101. The pertinent questions are:
> 1. whether the application itself is also a derived work of 
> the library
>    SOURCE (for instance by inclusion of code-containing headers).
> 2. whether the obligation to provide source code for an executable
>    licensed under an open-source reciprocal license includes 
> the obligation
>    to provide library headers - these are necessary for compilation,
>    so you would have thought that it was necessary. Is it allowable
>    to provide these separately (presumably yes, so long as they are
>    in fact provided). What about where they are under a 
> different license
>    which contains additional restrictions (even if it's 
> "just" the GPL)?
>    (this is prohibited under some licenses, but not seemingly the OSL.
>    What if the headers are for a closed-source library? (i.e. that the
>    source code can be used to build the executable, but it can never
>    run without a closed-source library) - this seems possible under
>    the OSL 3.0 too, as only the headers form part of the "Source Code"
>    if one accepts that the library itself is a separate work.
> 
> Alex