namespace protection compatible with the OSD?

[Frank LaMonica]

Brian,
Just a real world example:

SGI owns the OpenGL trademark, and it cannot be used without the
appropriate licensing from SGI.  The OpenGL API is publicly available,
and Brian Paul created an open source project which he named "Mesa3D"
because he couldn't use the OpenGL trademarked name.  Mesa3D is a fully
open source, free implementation of the OpenGL API.  The Mesa3D team,
still headed up by Brian Paul, is committed to making sure the API
remains identical to the one published by the OpenGL Architectural
Review Board (ARB), the independent organization which was created to
maintain the OpenGL API as a vendor neutral API, but that is a purely
voluntary decision on the part of that team.  Since Mesa3D in NOT OpenGL
(the official sample implementation released by SGI), and is not called
OpenGL (the trademarked name owned by SGI), Mesa3D COULD fork its API if
it chose to do so.  If it did, then it would no longer be an open source
implementation of the OpenGL API, but it could still be a valid and
useful API.  I have no idea if SGI could successfully sue Mesa3D if it
chose to do so, but the question has been avoided by Mesa3D's voluntary
commitment to follow the OpenGL API as it evolves.

Regards,
Frank

Brian Behlendorf wrote:
> 
> 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

-- 
Frank LaMonica         VA Linux Systems Inc.      frankl at valinux.com
(512) 378-3003                                    (512) 378-3004 fax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frankl.vcf
Type: text/x-vcard
Size: 326 bytes
Desc: Card for Frank LaMonica
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20010419/0d8f1a36/attachment.vcf>