namespace protection compatible with the OSD?
eaj at ricochet.net
Thu Apr 19 05:31:45 UTC 2001
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,
> 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
What you're proposing sounds like it could be accomplished using
trademark, and avoiding that whole sticky copyright-of-API's issue
> 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.
More information about the License-discuss