Initial Developer's Public License

[Lawrence E. Rosen]

> Here are two examples that I think would not be allowed
> under OSL which are allowed under IDPL.
> 
> A commercial database repair tool that uses the on disk 
> structure definitions, compression/decompression routines and 
> other parts of the Firebird database code.  The repair tool 
> combines that code with proprietary code to discover and 
> repairs corruption.  Developers of such a tool would publish 
> the interfaces between the Firebird code and their own code, 
> but would not be compelled to release their product under an 
> open source license.
> 
> A package for automatically compressing the stored format
> of the database.  The actual compression code could remain 
> proprietary.  The developer could sell "Firebird in half the 
> space".  However the interfaces to the compression code would 
> be published under the IDPL, allowing others to create 
> plug-replaceable compression packages.

Ann,

As I understand copyright law, the OSL and IDPL have the same effect. 

I don't see the plug-in applications you described as creating "derivative
works", except for the modifications you have to make to the Firebird code
itself to plug-in those modules to those API interfaces. The changes to
Firebird code would have to be distributed under the OSL, but only those
changes. Licensees could implement other plug-in software to discover and
repair corruption or to do compression -- and plug them in the same way. It
makes no difference whether the plug-ins are open source or proprietary.

This depends, of course, on my analysis of whether the combinations you
described are "derivative works." I suggested that they aren't, based on
your brief descriptions. (Please don't draw specific legal conclusions from
my preliminary read of your software architecture; I disclaim anything you
might interpret as "advice"!) I gather your product is designed to work with
independently-created and independently-owned plug-ins. If so, how does your
simply linking to those plug-ins (or from those plug-ins to you) cause them
to be brought under the terms of the OSL? A licensor under the OSL has no
right to do that. No open source license can prohibit any licensee from
creating proprietary combinations of independently-created proprietary and
open source software that merely work together through APIs. Such
combinations are not "derivative works" of software.

Does anyone on this list disagree with that conclusion? If so, what factors
about derivative works analysis in the software context am I forgetting that
are relevant to Ann's brief examples?

/Larry Rosen

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