Submitted for Approval: OSL 3.0 and AFL 3.0

[Lawrence Rosen]

Gordon Kindlmann wrote:
> For my prospective users, however, can you give some more 
> clarification of how OSL 3.0 applies (or does not apply) to 
> an executables formed by linking with my library, ideally by 
> comparison to the other licenses?  When you say above that 
> "This license operates likes the LGPL", you are not saying 
> that something like LGPL Section 6 kick in, correct?  

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.

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. 

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. 

OSL 3.0 section 1(a) authorizes the copying of your library into a
collective work without imposing reciprocity obligations on your licensees
for their own independent creations. 

OSL 3.0 section 1(b), on the other hand, deals with situations in which your
licensees need "to translate, adapt, alter, transform, modify, or arrange"
your library, thereby creating Derivative Works. Reciprocity applies ("kicks
in," to use your phrase) if your licensees distribute their Derivative Works
of your library (see OSL 3.0 § 1(c)).

OSL 3.0 accomplishes what the LGPL accomplishes, but by distinguishing
between collective and derivative works instead of describing technological
specifics. 

OSL 3.0, of course, can be used for other software besides libraries. It
operates generally the way the MPL, CDDL and similar licenses work, although
those licenses usually speak of "Modifications" to "a file" rather than the
six verbs used in OSL 3.0 section 1(b) as applied to an "Original Work." To
get the same effect as with those licenses, license each "file" as an
"Original Work" under OSL 3.0.

Sometimes OSL 3.0 can even be an alternative to the GPL. For example, many
people believe you can *link* a device driver to GPL-licensed Linux without
having to disclose its source code. If that is the interpretation a licensor
seeks, OSL 3.0 makes it less ambiguous.

/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: Gordon Kindlmann [mailto:gk at bwh.harvard.edu] 
> Sent: Sunday, September 11, 2005 12:49 PM
> To: license-discuss at opensource.org
> Subject: Re: Submitted for Approval: OSL 3.0 and AFL 3.0
> 
> hello,
> 
> I have a question about OSL 3.0 which pertains to its 
> application to software libraries, not about its conformance 
> to the OSD.  Hopefully this list has room for such queries.
> 
> On Sep 11, 2005, at 12:16 AM, Lawrence Rosen wrote:
> > ...
> > Section 1: Grant of Copyright License
> > - Expressly authorizes copies of the Original Work in collective 
> > works.
> > - Expressly defines Derivative Works consistently with 
> copyright law.
> >   NOTE: Only the listed activities ("translate, adapt, alter,
> >         transform, modify, or arrange") create derivative works.
> >         "Linking" does not create a derivative work.
> >         This license operates like the LGPL, MPL, CDDL,
> >         and many other reciprocal licenses (but with greater
> >         clarity and precision regarding derivative works);
> >         it doesn't operate like the current GPL version 2.
> 
> Suppose I'm shopping around for a license to apply to my 
> software, which is an old-fashioned C-language library (its 
> only usable after being linked into some larger executable).  
> I want a reciprocal license that applies to distributions of 
> modifications of the library, but not to executables that 
> link with the library.
> 
> The LGPL is popular, I believe, because it strives to make 
> that distinction in language programmers can understand (in 
> its Sections 5 and 6).  However, the terms of Section 6 of 
> the LGPL, which require facilitating linking with a modified 
> version of the library, are rather onerous when the 
> executable was statically linked.  The OSI- approved 
> wxWindows license (http://www.opensource.org/licenses/
> wxwindows.php) is one way to put an exception notice on top 
> of LGPL to do away with the behavior of LGPL Section 6, 
> though it also permits binary forms of modifications of the 
> library to escape the reciprocity of LGPL.  The FLTK 
> (http://www.fltk.org/COPYING.php) and FOX 
> (http://www.fox-toolkit.org/license.html) licenses include 
> more limited exceptions to the behavior of LGPL Section 6.
> 
> I have read your "Open Source Licensing" book, including 
> Chapters 6 ("Reciprocity and the GPL") and 12 ("Open Source 
> Litigation"), and I believe the statement made there that 
> linking (in the compiler sense of the word) does not create a 
> derivative work, but rather a collective work, which has 
> implications for the reach of reciprocal licenses.  Based on 
> that understanding, I believe OSL 3.0 to be a fitting license 
> for distributing my library.
> 
> For my prospective users, however, can you give some more 
> clarification of how OSL 3.0 applies (or does not apply) to 
> an executables formed by linking with my library, ideally by 
> comparison to the other licenses?  When you say above that 
> "This license operates likes the LGPL", you are not saying 
> that something like LGPL Section 6 kick in, correct?  Is it 
> more like the wxWindows license?  
> FLTK?
> 
> Thanks in advance for your time and for your continued work 
> in the field, Gordon Kindlmann