Initial Developer's Public License

[Rod Dixon]

Larry - For what it is worth, I think your analysis is exactly correct.
-Rod

On Wed, 11 Feb 2004, Lawrence E. Rosen wrote:

> > 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
>
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3