RE: namespace protection compatible with the OSD?
From: phil hunt [SMTP:[EMAIL PROTECTED]] I hope this is not the case. I wouldn't like Microsoft to have the ability to suppress WINE because it uses the Windows API. [DJW:] They are attempting to achieve something similar for MS Office products. The MSDN Library licence forbids the use of the file format documentation for Word, etc., for what I interpret to be: - software that does not run on Windows; - software that attempts to compete with MS Office. -- --- DISCLAIMER - Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of BTS.
Re: namespace protection compatible with the OSD?
On Wed, 18 Apr 2001, Brian Behlendorf wrote: On Wed, 18 Apr 2001, phil hunt wrote: I'm not familiar with Perl, so I'll attempt to translate this into C for clarification. OK. I create a library in C. The interface is defined in mylibrary.h. For someone to use my library, they must: #include "mylibrary.h" The license for mylibrary contains a clause "if you create a derivative work, you must rename mylibrary.h to something like yourlibrary.h". Is this this the gist of what you are saying wrt Perl? Not exactly. 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". IMO it could be hard to define what is or isn't the same behaviour. Example (1): You write a library to access data from a disk file, like in a DBM-style database. This includes the call (in your header file): DataHandle getData(FileHandle fh, Key k); I now re-implement your library so that the getData() function exists as before, but tries to cache in RAM rather than reading the field on disk every time. Furthermore, I decide to include a getData_lowLevel() function that does the same as your original getData() function, and which my getData() function uses. Example (2): (This example makes more sense in a language that allows variables to have any datatype, such as Python or Smalltalk (or C++)). You write a library that performs math functions such as exp(), log(), sin(), cos(), tan(), et, taking floating-point arguments. I write a library with a superset of your library's functions, and in which all the functions can take complex-number arguments too. This behaves differently to your library, because in your library, using complex number arguments produces a return value signalling an error (or an error exception, or suchlike). It seems to me that the spirit of the Open Source Definition allows me to do that, and allows users of your original library to be able to use my library as a plug-in replacement to your library, if they wish to do so. A plugin replacement might well imply things like having the same filename(s), depending on the language in question. 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. 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. But the requiremnt of changing filenames could prohibit forking, to some extent. 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; 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. -- * Phil Hunt * "An unforseen issue has arisen with your computer. Don't worry your silly little head about what has gone wrong; here's a pretty animation of a paperclip to look at instead." -- Windows2007 error message
RE: namespace protection compatible with the OSD?
On Tue, 17 Apr 2001, Brian Behlendorf wrote: There are IP lawyers I know who will argue up and down that software implemented to a specification is a derivative work of that spec, so that spec's copyright terms need to be obeyed (which is why I said both the spec and the code were under my "call it something else if you're not compatible" license) when creating derivative works. And this IP lawyer will argue up and down that copyright law protects expression and not the underlying ideas. Implementing a specification without copying code is creating neither a copy nor a derivative work of that specification. I can understand the desire of some companies to prevent forking by claiming ownership of their published specifications. But having a desire doesn't mean you have a right to satisfy your desire by imposing your will on unwilling participants. Claiming a monopoly right under copyright where that claim is not allowed is copyright misuse, subjecting the claimant to a lawsuit for, at the least, injunctive relief. I appreciate your informing me that this issue has fomented lots of discussion in the past in the open source community. "Stallman's rebuff to Alladin [sic] Software" notwithstanding, the final decision may have to come from a court of law. I, for one, would almost welcome such litigation, because I believe the open source community needs to take a stand against companies that pay lip service to open source principles while preventing open source development with closed specifications and standards. This is hypocrisy. As the open source community has long since proven repeatedly, particularly with its contributions to Internet-related software, the enforcement of appropriate standards can be encouraged and achieved without recourse to licenses that prevent effective open source development. As for a "call it something else" provision of a license, that relates to trademark law and, as I said in a previous email to license-discuss, is outside the scope of any specification. You said that it's much more efficient to say "you can't use my code if you misuse my name" than "you can't use my name because I own the trademark." That misstates the legal significance of the trademark. I was trying to point out that you CAN'T ALLOW someone to use your name -- e.g., ALL uses, even friendly ones, are misuses -- because it is YOUR trademark and not theirs. If you allow a third party who creates a derivative work to market that derivative work under your trademark, without exercising control over the quality of his derivative works, you will lose your trademark. It is okay for a third party to say his derivative work is "compatible with" Apache, or "equivalent in functionality to" Apache, or "meets the specifications of" Apache, or even that it is "better than" Apache, but it is NOT okay for him to market his derivative work "as" Apache. Apache should not allow anyone else to adopt its trademark for their software! (The word "should" in that last sentence is as close as I'm going to come to giving unsolicited legal advice to Apache.) /Larry Rosen 650-216-1597 [EMAIL PROTECTED] www.rosenlaw.com www.opensource.org
RE: namespace protection compatible with the OSD?
From: Lawrence E. Rosen [SMTP:[EMAIL PROTECTED]] hypocrisy. As the open source community has long since proven repeatedly, particularly with its contributions to Internet-related software, the enforcement of appropriate standards can be encouraged and achieved without recourse to licenses that prevent effective open source development. [DJW:] However, my impression is that that only holds whilst the implementation is in the open source arena. Closed source developers tend to be the ones that create the greatest travesties of open standards, so it is possibly not surprising that the same people are wary of creating open standards - they may be judging other people by their own standards. -- --- DISCLAIMER - Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of BTS.
RE: namespace protection compatible with the OSD?
"Lawrence E. Rosen" [EMAIL PROTECTED] I was trying to point out that you CAN'T ALLOW someone to use your name -- e.g., ALL uses, even friendly ones, are misuses -- because it is YOUR trademark and not theirs. If you allow a third party who creates a derivative work to market that derivative work under your trademark, without exercising control over the quality of his derivative works, you will lose your trademark. It is okay for a third party to say his derivative work is "compatible with" Apache, or "equivalent in functionality to" Apache, or "meets the specifications of" Apache, or even that it is "better than" Apache, but it is NOT okay for him to market his derivative work "as" Apache. Apache should not allow anyone else to adopt its trademark for their software! (The word "should" in that last sentence is as close as I'm going to come to giving unsolicited legal advice to Apache.) "OSI Certified" is a certification mark, a kind of trademark. Yet open source software authors can claim their software to be "OSI Certified", not just "equivalent to OSI Certified". This doesn't constitute abandonment of the trademark -- does it? --
Re: namespace protection compatible with the OSD?
On Thu, 19 Apr 2001, Eric Jacobs wrote: Brian Behlendorf [EMAIL PROTECTED] 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
Re: namespace protection compatible with the OSD?
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
Re: namespace protection compatible with the OSD?
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 [EMAIL PROTECTED] 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;
RE: namespace protection compatible with the OSD?
On Thu, 19 Apr 2001, Lawrence E. Rosen wrote: And this IP lawyer will argue up and down that copyright law protects expression and not the underlying ideas. Implementing a specification without copying code is creating neither a copy nor a derivative work of that specification. Would you agree that if I took one of Shakespeare's plays and reworked it into a screenplay, or novel, that my work would be a derivative work? Throw in translating to Chinese for good measure. Throw in adding some extra scenes and characters to really flesh out my work, or to adapt it to a new culture. I think the idea of implementing an API is the same thing. And I think this is a much closer analogy than using the tax advice given by a tax book. Certainly, if I wrote a novel that happened to coincidentally share plot lines with a Shakespeare play, that's not something to worry about - only patents and trademarks are so broad as to cover unintended parallels. I think the issue is sufficiently grey that it's worth considering it a threat to open source development, and I'd like to find an ironclad argument against it, or fix the OSD/DFSG. I appreciate your informing me that this issue has fomented lots of discussion in the past in the open source community. "Stallman's rebuff to Alladin [sic] Software" notwithstanding, the final decision may have to come from a court of law. I, for one, would almost welcome such litigation, because I believe the open source community needs to take a stand against companies that pay lip service to open source principles while preventing open source development with closed specifications and standards. This is hypocrisy. As the open source community has long since proven repeatedly, particularly with its contributions to Internet-related software, the enforcement of appropriate standards can be encouraged and achieved without recourse to licenses that prevent effective open source development. So far we have a couple data points - Apache, sendmail, bind - to suggest that open source drives compatibility. We have data points to the contrary as well - glibc, html authoring tools, linux package formats. We have lots of data points to suggest that the world outside of the circle we know doesn't give a hoot about compatibility, they just "want to get the job done" even if the long-term impacts are significant, because those long-term impacts don't affect the developers in that situation. I'm suggesting that taking an ostrich approach to those issues isn't good for the open source community - either we find a way to accomodate these issues within the open source milieu, or we figure out a way to mitigate the need for them. You said that it's much more efficient to say "you can't use my code if you misuse my name" than "you can't use my name because I own the trademark." That misstates the legal significance of the trademark. I was trying to point out that you CAN'T ALLOW someone to use your name -- e.g., ALL uses, even friendly ones, are misuses -- because it is YOUR trademark and not theirs. If you allow a third party who creates a derivative work to market that derivative work under your trademark, without exercising control over the quality of his derivative works, you will lose your trademark. OK, so that suggests that the ASF had better *not* go out and get a trademark on "Apache", because we'll quickly lose it should we not become Nazis about enforcing it. This also suggests that anyone who has a trademark on a name used by an open source package, under a license that doesn't control how that name is used in a derivative work (a license like the GPL, for example), has lost the ability to enforce that trademark. That's absurd. This is precisely why trademark is a poor instrument for this purpose. It also means there's no way we could advocate, say, org.apache.soap to become an industry-wide API, outside of the ASF's control. It is okay for a third party to say his derivative work is "compatible with" Apache, or "equivalent in functionality to" Apache, or "meets the specifications of" Apache, or even that it is "better than" Apache, but it is NOT okay for him to market his derivative work "as" Apache. Apache should not allow anyone else to adopt its trademark for their software! (The word "should" in that last sentence is as close as I'm going to come to giving unsolicited legal advice to Apache.) OK, so when Debian creates an Apache deb package, and calls that package apache-1.3.19.deb, and tells people "you can install apache by doing apt-get install apache", are you saying the ASF should not allow them to do that, without granting them specific approval to do so? Note that such an arrangement is not cool with Debian, as it would violate the DFSG (and the OSD) by creating a second agreement limiting the right to redistribute, as well as being specific to Debian. I am not a lawyer, but I'm getting uncomfortably familiar with too many things
RE: namespace protection compatible with the OSD?
Hi, I can see the need for namespace protection; but it is clear that to remain in the spirit of an open-source system it would have to be done very carefully. I mean: Its reasonable (from my point of view): 1) To say that any extension to the API must use a particular form of name - e.g. myapi_extendersname_. (where extenders name could be an organisation for grouping extensions). And to define a group of names which only the original authors may extend. 2) To say that any implementation of the API should implement existing named entry points in a manner compatible with the API definition. It is unreasonable: 1) To say that no one is able to write a function with a particular name 2) That no one else is able to reimplement a function with a given name. Dave -- Have a happy GNU millennium! -- / Dr. David Alan Gilbert | Running GNU/Linux on Alpha, | Happy \ \ gro.gilbert @ treblig.org | 68K,MIPS,x86,ARM and SPARC | In Hex / \ ___|___ http://www.treblig.org |___/
Re: namespace protection compatible with the OSD?
Eric Jacobs wrote: without exercising control over the quality of his derivative works "OSI Certified" is a certification mark, a kind of trademark. Yet open source software authors can claim their software to be "OSI Certified", not just "equivalent to OSI Certified". This doesn't constitute abandonment of the trademark -- does it? Not at all. Note the phrase with marker above. -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: namespace protection compatible with the OSD?
Brian Behlendorf wrote: 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? The problem is not with "open source" but with "copyright license". The right you mention is just not one of those that a copyright holder has. If I bake a cake based on the recipe in your copyrighted book: 1) the cake is not a derivative work of the book, and 2) the cake is not a derivative work of some other cake that you baked. 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, That only worked for MS because of their overwhelming market power. Defying standards is (probably) a losing game for everyone else. 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? It doesn't matter what it is. See the cake example. -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: namespace protection compatible with the OSD?
Brian Behlendorf wrote: Would you agree that if I took one of Shakespeare's plays and reworked it into a screenplay, or novel, that my work would be a derivative work? Throw in translating to Chinese for good measure. Throw in adding some extra scenes and characters to really flesh out my work, or to adapt it to a new culture. All of those things are making a derivative work, clearly. I think the idea of implementing an API is the same thing. And I think this is a much closer analogy than using the tax advice given by a tax book. The closest analogy is building a house from a blueprint. The house isn't a derivative work of the blueprint, or architects wouldn't need to get paid for drawing them -- they could sue the contractor for infringement. I am not a lawyer, but I'm getting uncomfortably familiar with too many things usually only lawyers have to worry about. Tell it, brother! -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: namespace protection compatible with the OSD?
In the U.S. at least, building a house from a blueprint is creating a copy of an architectural work - see the definition of an architectural work in s. 101 of the U.S. Copyright Act and other limitations in s. 120. If someone builds an unauthorized exact or substantially similar copy (i.e. a building according to the architectural work), it may be infringement (assuming access to the architectural work). The owner of an architectural work has the exclusive right to prepare derivative works (which of course can be licensed). As to the customs and conventions in the industry defining actual and implied licensing and ownershipthat's the story of extensive litigation (including numerous disputes between architects, home owners and builders). From: John Cowan<[EMAIL PROTECTED]> To: Brian Behlendorf<[EMAIL PROTECTED]> CC: Lawrence E. Rosen<[EMAIL PROTECTED]> , [EMAIL PROTECTED] Subject: Re: namespace protection compatible with the OSD? Date: Thu, 19 Apr 2001 16:38:31 -0400 Brian Behlendorf wrote: Would you agree that if I took one of Shakespeare's plays and reworked it into a screenplay, or novel, that my work would be a derivative work? Throw in translating to Chinese for good measure. Throw in adding some extra scenes and characters to really flesh out my work, or to adapt it to a new culture. All of those things are making a derivative work, clearly. I think the idea of implementing an API is the same thing. And I think this is a much closer analogy than using the tax advice given by a tax book. The closest analogy is building a house from a blueprint. The house isn't a derivative work of the blueprint, or architects wouldn't need to get paid for drawing them -- they could sue the contractor for infringement. I am not a lawyer, but I'm getting uncomfortably familiar with too many things usually only lawyers have to worry about. Tell it, brother! -- There is / one art || John Cowan <[EMAIL PROTECTED]> no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: namespace protection compatible with the OSD?
OK, so we have two new analogies to implementing an API, that of "baking a cake from a recipe" and "that of building a house from blueprints". I still think the line between that and "write a novel based on a Shakespeare play" is not defined. What is the relevant case history, especially in the field of software? If we can find a precedent for or against, we have an answer w/r/t the likely way a judge would rule. And, if it's true that a copyright on an API can't restrict the rights to implement it, then my life becomes a lot easier. =) Brian
RE: namespace protection compatible with the OSD?
"OSI Certified" is a certification mark, a kind of trademark. Yet open source software authors can claim their software to be "OSI Certified", not just "equivalent to OSI Certified". This doesn't constitute abandonment of the trademark -- does it? "OSI Certified" is a certification mark, a special kind of trademark that can ONLY be applied to third party software. In fact, if OSI itself made software it could NOT apply the certification mark to its own software. The same general rules of trademark apply: OSI is responsible for ensuring that third-party users of the OSI Certified certification mark meet certain quality standards -- in this case, the requirement to distribute the software under an OSI-approved license. /Larry Rosen
Re: namespace protection compatible with the OSD?
Chloe Hoffman wrote: In the U.S. at least, building a house from a blueprint is creating a copy of an architectural work Oops, put my foot in it. No dog biscuit! - see the definition of an "architectural work" in s. 101 of the U.S. Copyright Act and other limitations in s. 120. Well, at least it's a hack specific to architectural works.
Re: namespace protection compatible with the OSD?
On Thu, 19 Apr 2001, Brian Behlendorf wrote: OK, so we have two new analogies to implementing an API, that of "baking a cake from a recipe" and "that of building a house from blueprints". I still think the line between that and "write a novel based on a Shakespeare play" is not defined. Unfortunatly none of these analogies are correct; they all give a false sense of apparent correctness which leads people to apply the wrong sort of laws to them. In terms of an API it is important to separate out the definition of the API from its implementation and to realise that neither can be made from the other directly without work and thought. A skilled craftsman can, using his skill, knowledge and experience without being inventive, build a house purely from the plans. This is not necessarily true of an API implementation; i.e. a skilled, but uninventive programmer or system designer can NOT implement all APIs just from their interface definition. Some APIs can be implemented purely from definition without inventiveness, but there is almost always the opportunity for an inventive implementer to entirely meet the API definition but produce a different implementation from another implementer with possible benefits such as speed, size etc. Again, using an analogy which is probably a bad one I'd consider a car wheel. The API is the definition of what shape the axel/wheel/break disc etc have to be for them to fit together. A wheel maker may make a wheel that 'implements the API' by ensuring that certain parts of it happen to fit the car. Similarly a car maker can use the API by making a car with that shape fittings. In an ideal world there is no requirement on either the car maker or the wheel maker to use any particular technology in their products - they can use wacky structural designs for better safety etc - without altering the fact that they meet the API. Given this API you can't design a car (hence its not like the house blueprint analogy) and by looking at the wheel you can't design a car. Now a car manufacturer might team up with a wheel manufacturer and decide to change the interface between car and wheel - there are at least two reasons he might want to do this: 1) To generate an unfair monopoly so that no one else can sell cheaper spare parts for the car. 2) Becuase they have some improvement which provides some tangable benefit to the consumer. This may involve some inventiveness e.g. some clever mechanical arrangment between the two. Taking case 1) it would seem that a third part wheel manufacturer could buy a car and take one of the wheels off and look at the way it fixes to the car and make another wheel that fits in the same place. It would be important that he only made something that fitted in the same way and did not copy the actual wheel design. Obviously the car manufacturer can claim this is not an autharised part and may not meet various of its specs. Indeed it is the 3rd part wheel makers skill and inventiveness and trustworthy ness that people can use to guage whether it is a safe and good wheel and whether it has tangible benefits. What is the law in this type of case? Now what about number (2) - if they really do do something clever then perhaps there is something patentable in there - but it would still be monopalistic. The real danger is people making small changes as in (1) which convey some notional but misleading benefit and then claiming it is actually (2). Dave -- Have a happy GNU millennium! -- / Dr. David Alan Gilbert | Running GNU/Linux on Alpha, | Happy \ \ gro.gilbert @ treblig.org | 68K,MIPS,x86,ARM and SPARC | In Hex / \ ___|___ http://www.treblig.org |___/
RE: namespace protection compatible with the OSD?
I am sorry about joining the discussion late. This sounds interesting. Brian, do you mind clarifying your question without rehashing what has been discussed? I do not want to bore those who have followed the thread, but what do you mean by "implement" and what is the concern you are raising? Rod -Original Message- From: Brian Behlendorf [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 19, 2001 5:34 PM To: John Cowan Cc: [EMAIL PROTECTED] Subject: Re: namespace protection compatible with the OSD? OK, so we have two new analogies to implementing an API, that of "baking a cake from a recipe" and "that of building a house from blueprints". I still think the line between that and "write a novel based on a Shakespeare play" is not defined. What is the relevant case history, especially in the field of software? If we can find a precedent for or against, we have an answer w/r/t the likely way a judge would rule. And, if it's true that a copyright on an API can't restrict the rights to implement it, then my life becomes a lot easier. =) Brian
