namespace protection compatible with the OSD?

[Eric Jacobs]

Brian Behlendorf <brian at collab.net>

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

I'm having trouble with the interface/implementation distinction here.
Is "behavior" the same thing as "interface"?

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

This cannot be accomplished with an open source copyright license. This
sounds like a job for trademarks.

Perhaps a better way to think about this whole issue is something like
this: "Permission is hereby granted to use the trademark 'mylibrary'
in connection with a computer program, provided the following conditions
are met: 1. The program include a file named 'mylibrary.h' which is
syntactically equivalent to the file 'mylibrary.h' of the reference
implementation available from <somewhere>"... (be more specific about
the meaning of "syntactically", mention standards, etc.)

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

All changes potentially introduce incompatibility, even bug-fixes, because
old code can rely on the buggy behavior. Is your intent to prevent people
from adding new features and calling it the same?

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

This doesn't seem to be at all the same thing. Nobody has to execute
a license of Microsoft's in order to implement the same API's as Windows,
unless doing so involved creating a derivative work of some copyrighted
material.

What you're proposing sounds like it could be accomplished using
trademark, and avoiding that whole sticky copyright-of-API's issue
altogether.

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

They can have all kinds of clauses; that doesn't mean anything if nobody
executes the licenses. You can get people to execute the license by
granting them a right that they would not otherwise have: an exclusive
right under copyright, or the right to use a trademark. Because your
objectives seem to be aligned with the intentions of trademark law
(preventing consumer confusion from dilution of the name), it seems
that trademark would be a better fit.
--