namespace protection compatible with the OSD?

[Brian Behlendorf]

On Thu, 19 Apr 2001, Eric Jacobs wrote:
> 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"?

"API"/"interface" is the set of commands/procedures/methods/macros/
whatever that I expose to people using my software, either at a user level
or a programmatic level.  The intended effect is that someone else who
writes code that exposes the same API can be a drop-in replacement for my
code.  "Implementation" is the code I wrote behind that API which actually
does the work, and can vary even if the API stays the same.

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

On what basis do you claim I can't do this with an open source copyright
license?  What OSD section does it violate?  That's what I want to
determine.  Think of me as playing devil's advocate on this, because one
side (perhaps the stronger side) of me does want to see this to *not* be
possible, and it might be yet another hole in the OSD - best to patch it
up now than wait for someone to abuse it.  However I want to find an
ironclad argument against it, and I haven't, other than "that would be a
bad thing - e.g., Win32 and Wine".

> All changes potentially introduce incompatibility, even bug-fixes, because
> old code can rely on the buggy behavior.

I would define in/compatibility as that defined by the spec, not the code.
If I expose through the API a routine that (the spec says) returns a float
that's the square root of a float, and it returns in rare circumstances an
incorrect value, fixing that bug is not changing the API as defined by the
spec.  I agree there are more subtle examples that would cause debates to
be had, and if escalated it would ultimately mean a judge being asked to
determine if a change broke compatibility, probably not a good thing.  =)

> Is your intent to prevent people from adding new features and calling it
> the same?

Primarily it's to prevent someone from intentionally removing/breaking
functionality but trying to claim they implement the same API, then adding
new functionality, trying to move people to that new API because it's the
only one that appears to "work".  For example, think Microsoft and Visual
J++ for example, where MS claimed to implement the java.* classes and be
compatible, yet they were broken in subtle ways (intentionally), and the
docs recommended developers use the com.microsoft classes instead.
Trademark in that situation was a weak instrument to try and use to
enforce conformance, for reasons you can read about in the history of the
MS/Sun Java case.  Developers who didn't particularly care about
compatibility and used VJ++ because it came free from MS weren't incented
to mandate compatibility from MS, so market pressure wasn't there.
Outside of the open source community, the drive to standards isn't nearly
as strong as we'd all like to think.

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

That's precisely what I'm saying.  What's the copyright on the
documentation for the Win32 API as provided by MS?

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

Notice that what repels you about my proposal would still be possible in
that case, e.g., MS suing Wine developers for trademark violation.  At
least with the proposed copyright, your right to implement compatible
implementations would still survive.

	Brian