Initial Developer's Public License

Rod Dixon rodd at
Thu Feb 12 13:14:46 UTC 2004

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

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
license-discuss archive is at

More information about the License-discuss mailing list