OSL 2.0 and linking of libraries

[Rod Dixon, J.D., LL.M.]

This issue on linking seems to come to life every full moon.

More seriously, I am unable to come up with a routine scenario in which static linking to a library would create a derivative work -- albeit, doing so COULD violate the terms of a license.  The distinction is that what constitutes a derivative work is a legal question ultimately resolved by a court interpreting the Copyright Act: this is so regardless of whether the underlying license at issue is the GPL or one issued by the Creative Commons.  As I see it, in the normal course of coding a call to a library, the author of the static link has not produce sufficient  original expression to yield an independently copyrightable derivative work, despite the possibility that the works linked are independently  copyrightable.  What is really at issue in the linking hypo is a concern regarding license terms in my opinion.  A license may seek to control certain uses of a work and, in doing so, inartfully refer to derivative work. This amounts to a redefinition of that term, which is highly inadvisable sense the definition is driven by the statute and the intent of the license and perhaps the licensor is driven by the license terms.  If there is caselaw going the other way, please post it so we can discuss it, otherwise, I think the earlier comments on this rejecting static linking as a real concern on  the derivative work question should be considered responsive to many of the recently posted questions.

Rod


-----Original Message-----
From:  pitrp at wg78.de (Peter Prohaska)
Date:  4/2/04 1:38 am
To:  license-discuss at opensource.org
Cc:  license-discuss at opensource.org
Subj:  Re: OSL 2.0 and linking of libraries

On Thu, Apr 01, 2004 at 08:32:41PM +0100, Robert Osfield wrote:
> It'd be nice to have an official OSL version specifically which allows for 
> programs to link against libraries without license propagation, as LGPL is to 
> GPL.  This could then be used off the shelf without need for customization.  
> It would certainly save on time when adopting the license, and also education 
> of users who'll need to get to grips with the implications of yet another OS 
> license.

As stated bevore, i would try to avoid raising the number of licenses
in general. There has to be a better way.
Nevertheless, i also would like to have an off the shelf track to
follow.

In the end, the problem boils down to clarification and not to
seperate licenses.  

Perhaps one could just
1) include a clarification statement in the license
2) make it clear that it is only in effect as long as the license is not
   accompanied by a clarification notice by the cpr holder.

On 1) This way, it doesn't matter what derived work is anymore because
we just define it. That should reduce the FAQ size.

On 2) Because there are different opinions concerning this point, it is
good to make it clear that the license respects this fact. So whenever i
want to link against a library, i know what the default is and i'll see
if a clarification notice is shipped. That shouldn't take too long and
is acceptable for me.

A problem is though, that any file can include a different license note
and i can never be sure that i havn't missed something.
Does anyone know how a situation is handled if a file COPYRIGHT is
shipped and it tells me that the included license applies to all files
distributed together with it and then there is a file in a subdirectory
that includes a different copyright notice at its top?

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