namespace protection compatible with the OSD?

[phil hunt]

On Wed, 18 Apr 2001, Brian Behlendorf wrote:
> On Wed, 18 Apr 2001, phil hunt wrote:
> > I'm not familiar with Perl, so I'll attempt to translate this into C
> > for clarification.
> 
> OK.
> 
> > I create a library in C. The interface is defined in mylibrary.h.
> > For someone to use my library, they must:
> >
> >    #include "mylibrary.h"
> >
> > The license for mylibrary contains a clause "if you create a derivative
> > work, you must rename mylibrary.h to something like yourlibrary.h".
> >
> > Is this this the gist of what you are saying wrt Perl?
> 
> Not exactly.  I'm saying two things: if you create a derivative work from
> my code, then the license says if you change the behavior of the functions
> or macros, etc., defined in my .h, that you must call it something else.
> However, if you keep the same interface (keep the .h consistant, but
> change the .c, though it's more accurate to say "API" and
> "implementation") then you may continue to call it "mylibrary.h".

IMO it could be hard to define what is or isn't the same behaviour.

Example (1):

You write a library to access data from a disk file, like in
a DBM-style database. This includes the call (in your header file):

   DataHandle getData(FileHandle fh, Key k);

I now re-implement your library so that the getData() function exists as
before, but tries to cache in RAM rather than reading the field on disk
every time. 

Furthermore, I decide to include a getData_lowLevel() function that
does the same as your original getData() function, and which my getData()
function uses.

Example (2):

(This example makes more sense in a language that allows variables
to have any datatype, such as Python or Smalltalk (or C++)). You write a
library that performs math functions such as exp(), log(), sin(),
cos(), tan(), et, taking floating-point arguments. 

I write a library with a superset of your library's functions,
and in which all the functions can take complex-number arguments too.
This behaves differently to your library, because in your library,
using complex number arguments produces a return value signalling an
error (or an error exception, or suchlike).


It seems to me that the spirit of the Open Source Definition allows
me to do that, and allows users of your original library to be able to
use my library as a plug-in replacement to your library, if they wish
to do so. A plugin replacement might well imply things like having the
same filename(s), depending on the language in question.

> Secondarily, I'm saying even if you didn't implement my code, but followed
> the published document that describes the spec (which I also put under
> this license), you'd have to follow the same rules.

Clearly this has nothing to do with Open Source as such, and IMO
is morally dubious to say the least.
 
> > I'm not sure what "incompatible" means here? What if my new improved
> > version was intended as a replacement, but which added new features
> > in a way that necessitated a degree of incompatibility?
> 
> If you make a change that introduces any degree of incompatibility, even
> if it's "fixing a bug", then it would have to be renamed.  Hopefully I'm
> reasonable enough to change my API should I be notified of bugs in it, but
> if I'm not, fork.

But the requiremnt of changing filenames could prohibit forking, to 
some extent.

> > I don't know. In some cases I could see (if I have understood you
> > correctly), the restriction could be a way of preventing a fork of the
> > code. IMO, the ability to fork is a necessary part of an open source
> > license.
> 
> It doesn't limit the right to fork at all, but it does somewhat carve out
> an API namespace;

So it limits the right to fork something that's plug-in compatible with
the original? Users would have to make an extra effort to use the forked
version.

-- 
***** Phil Hunt ***** 
"An unforseen issue has arisen with your computer. Don't worry your silly 
little head about what has gone wrong; here's a pretty animation of a 
paperclip to look at instead."
         -- Windows2007 error message