namespace protection compatible with the OSD?

[Brian Behlendorf]

On Thu, 19 Apr 2001, phil hunt wrote:
> IMO it could be hard to define what is or isn't the same behaviour.

Granted that "compatible" would need to be rigorously defined by the
license, and it would be up to the original copyright holder to ascertain
if a derivative work was non-compliant; and if the author of the
derivative work felt the original holder was unfairly labelling their work
incompatible, they'd take their debate to the court of public opinion, or
ultimately, a judge, who could rule in favor of the derivative author.

Note that this is the same situation as would be faced by a trademark
holder attempting to accomplish the same goal of API consistancy via
trademark law instead of copyright law - but in the case of trademark law,
if there were any examples of people who created even slightly
incompatible derivative works, my ability to enforce that trademark would
be seriously curtailed.  That would mean that I'd have to be much more of
an asshole to anyone creating derivative works - I'd have to go after the
independent developers just as much as the big guys.  Compared to
copyright, where I can selectively enforce without losing my ability
to enforce at all.  That's a pretty regressive situation, doncha think?

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

It has everything to do with Open Source.  So far, most OS programs that
implement a published spec do so against specs with very liberal
copyrights - the IETF, the W3C, etc.  I'm worried about the more
"corporate" API's out there.  Wouldn't you be worried that MS might be
able to shut down WINE if they could claim the WINE developers got the
Win32 API docs under a copyright that said they couldn't reimplement it?
Someone already posted a link to the MSDN agreement that states that API's
you get through that service have this quality.  It's probably the main
reason we don't see big companies authoring Win32 alternatives anymore
(OS/2 was the last one, and yes I know that hidden function calls were the
bigger reason).  I would really like to find a good reason to shoot this
down on DFSG/OSD terms, and if I can't, then I'd suggest a patch to the
DFSG/OSD.   =)

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

No, if it's really "plug-in compatible", you can use the same API name.
If you change it's behavior in a way that breaks "plug-in compatible", or
however "compatible" is defined, you change the name.  In either case, the
advantages to forking are preserved - you don't have to rewrite code that
already exists.

	Brian