namespace protection compatible with the OSD?

[Brian Behlendorf]

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".
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.

> 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.

> 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; the example of MS using something like this to prevent
Win32 reimplementation is probably a good example, where they'd put a
license like this on their Win32 spec.  I'd be surprised if they don't
already have some sort of anti-reimplementation or
anti-reverse-engineering clauses in their click-through or shrink-wrap
licenses, though.

	Brian