Re: Is this better for tomsrtbt?
on Fri, Apr 20, 2001 at 11:33:27PM -0400, Tom Oehser ([EMAIL PROTECTED]) wrote: > > > ...well, it doesn't fold in mail well > > Good point. I'll work on that... > > > Why your own variant of the BSD license instead of a lightly adapted > > one? The issue is more one of cognitive distance than of unsuitedness > > Well, the BSD license is basically trying to say, as I read it: > > Don't sue me or pretend I endorse your stuff in your advertising. > > > My license says, or attempts to say: > > Don't cp my stuff wholesale and make out like you did the work. > > > I don't feel it is necessary to explicitly protect myself from ad men > pretending I endorse their product, and I'm happy with only a few words > that there are no guarantees. But I really didn't like it when I saw > high percentages of stuff on other distributions used without credit. > I am flattered if they use the stuff. But I expect a note saying "this > work makes liberal use of stuff from X at http://Y by [EMAIL PROTECTED]", and that > is what I want to make clear is required. Which, though included in some > licenses, is not as much the central focus for _why_ there is any license > at all, for them, as it is for me... I thought I knew the law, but it appears I'm wrong. Was all ready to say "but you've got that right by law". Maybe not. US Copyright law has very weak attribution rights -- as best I can tell only an author of "a work of visual art" has the right "to claimm authorship of a work" or "prevent the use of his or her name as author of any work" (17 USC 106A). There doesn't appear to be a general attribution protection. Section 501(a) explicitly states: Anyone who violates any of the exclusive rights of the copyright owner as provided by sections 106 through 121 or of the author as provided in section 106A(a) ...note the carve-out for authors, and that it references only 106(a), which covers only works of visual art. IANAL, so...Larry or Rod? -- Karsten M. Self <[EMAIL PROTECTED]>http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org PGP signature
Re: Is this better for tomsrtbt?
> What is it you want to protect? I'll give you an example. My bootdisk currently includes a libc5.so.5.4.13 that I have down to only 416,361 bytes. More than 2 years ago, back in October of 1998, I had it only down to 432,684 bytes. I havn't distributed that binary libc.so for about 2 years. Now, guess what libc5.so.5.4.13 file is currently in use on the MuLinux distribution? Yep, the 432,684 byte one I created about 2 years ago. Now, the author of MuLinux does *not* mention that he used a bunch (more than just this) of stuff directly out of tomsrtbt, he did *not* ever contact me about how to build it that small, and I would be curious in the abstract to know what he would do if someone asked him for the source code sufficient to rebuild it. Now, it is within 3 years of when I distributed it- so he could still ask me for the source to the libc I distributed 2 years ago- and he does mention tomsrtbt positively as another minilinux to check out- but I think it is fair that I require that users of anything I *can* require this of, give me credit. (Note: this is not meant to single out MuLinux, there are others doing the same thing). At a MINIMUM, it is only fair that a user of one of these know where the stuff came from, after all, what if I stuck a trojan in it? I really want any object file created by a compiler on my machine to be so documented. It isn't fair that users of these distributions are allowed to have the impression that their distribution author actually built it. In fact, I *do* build everything on tomsrtbt directly from source, and I *don't* crib stuff without giving fair credit to the authors and others who do the work. I want to prevent people from taking the binary objects and copying them into their own mini distributions without mentioning where they got them. I guess one question I have is, suppose I have on my web site: hello.c and a.out Where hello.c is a GPL program and a.out is an object file that I artistically chose to use "-m386 -O2 -fomit-frame-pointer -fno-strength-reduce", stripped with ELF-Tiny elf object utilities, used an older GCC to save a few bytes, and cetera. GPL prevents me from adding restrictions to 'the program'. Well, I am not restricting it- it is right there- "hello.c" is the program- and I'm glad to include the *instructions* for how to build it the smallest way- and the intent of the GPL is clearly to protect the freedom of the source. What I don't like is other people just copying the *actual binary* without giving any credit or acknoledgement that *they* don't want to bother to compile it *themselves*. As long as they mention where they got it, I'm fine with it. So, in the case above, am I required not to add the 'give credit and mention where you got it' clause to the binary object, even if I make the source code available without any such restriction? The GPL doesn't really clarify this, it is, after all, aiming at the source code, and there is probably no consideration that anyone would *care* about a particular binary compile output. Now, I can *definitely* apply this restriction to all the scripts and Luas that I wrote from scratch, *maybe* apply it to the agglomeration and the arrangement (such as using a very small gzipped root and bzip2ed /usr, is that copyrightable?) and *maybe* apply it to my versions of the documents and man pages. It is *possible* that I can apply it to binary objects where I am making the program *in source* available *without* restriction, but I dunno from reading the licenses. But I can *ABSOLUTELY* make it clear that this is my desire, want, and expectation, to the fullest extent legally available to me. That is what I'm getting at, in my license- "as far as legally possible, if you reuse ANY of this, you must give credit to the source". -Tom
Re: copyrightable APIs? (was RE: namespace protection compatiblewit
On Fri, 20 Apr 2001, Angelo Schneider wrote: > Hi! > > In Europe APIs are not "copyright able". > No idea about the US. > > However if you publich them in a book, the book of course is > copyrighted. > However you can not prevent anyone to write a software against a given > API. > Same is true for data formats. (In Europe dataformats e.g. a flat file > format for a word processor are not copyright able) This will change under the new EU copyright law, where it will be illegal to decrypt any encrypted file format (e.g. DVD) without the copyright holder's permission. -- * 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?
Rod Dixon, J.D., LL.M. scripsit: > "Java Platform Interface. In the event that Licensee creates an > additional API(s) which: (i) extends the functionality of a > Java Environment; and, (ii) is exposed to third party software > developers for the purpose of developing additional software which > invokes such additional API, Licensee must promptly publish broadly an > accurate specification for such API for free use by all developers." > > One wonders whether that provision is consistent with the First Amendment. Whyever not? A private party can compel speech from you if you agree to be so bound, surely. After all, it can compel silence easily enough, as in NDAs. > Even so, it is clear that it is consistent with Sun's view on the > copyrightability of Java APIs. The link to the entire license, which > includes provisions concerning the development kit and a rather odd > provision regarding the Windows platform: That provision arises because Sun is bound by Microsoft not to use the Windows look-and-feel off the Windows platform. If Sun cannot, you cannot either using Sun's tools. Or so Sun interprets the restrictions on it, anyway. -- John Cowan [EMAIL PROTECTED] One art/there is/no less/no more/All things/to do/with sparks/galore --Douglas Hofstadter
RE: copyrightable APIs? (was RE: namespace protection compatiblewit
On Fri, 20 Apr 2001, Lawrence E. Rosen wrote: > Even if a company were to argue successfully that its API is *both* > expressive and substantive, and thus protectible as copyrightable subject > matter, I would argue that access to the API for the purpose of preparing > independent (compatible or incompatible) software, even including making > copies, is still allowed under the fair use provisions of the copyright act. > As the court held in Sega v. Accolade, 977 F.2d 1510, 1521-1524 (9th Cir. > 1992), in analyzing the four factors justifying a fair use defense: Compelling. If not "ironclad", this does appear to be the decision I was looking to be able to cite regarding the enforceability of copyright of an API over implementations. Thanks Larry; I'm now done with this topic. =) Brian
Re: namespace protection compatible with the OSD?
On Fri, 20 Apr 2001, Tom Hull wrote: > After watching this argument roll around and around, it's tempting to just > say "no". A "no" answer could be derived from any of the following: > > 1) If the API is not copyrightable and enforceable. Conceded, it is in doubt whether the implementation is always a derivative work of an API. > 2) If the proposed copyright-based restrictions are contrary to the OSD. I've not heard anyone claim this to be the case. Which provision of the OSD would it violate? > 3) If the restrictions undermine its acceptance and usability. yep, left to historians. > > If the GPL's ethos is "access to source code is paramount", > > The key point is not just access to the source code: it is the right to > modify the source code, to create something new from that, and the right > to make those modifications available to others. No. To the author who places their work under the GPL, it's more important that an author of a derived work also place their code under the GPL (biggest practical impact: the author of the derived work has to publish their modifications) than it is to have the rights you list above. I.e., you do not have the right to modify/redistribute *unless* you also publish under the GPL. The BSD license, on the other hand, grants broader rights to modify/redistribute under the license of one's choosing, so long as you follow a few procedural requirements. > I think the right to modify an API is implicit in GPL. No question. The point I was making is that in the same way that the GPL's main philosophical objective is to advocate the availability of source code by placing requirements on derived works, another license may have as its philosophical objective the advocacy of implementations conformant to the APIs they claim to implement. Brian
RE: copyrightable APIs? (was RE: namespace protection compatiblewit
> -Original Message- > From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 20, 2001 11:24 PM > To: [EMAIL PROTECTED] > Subject: RE: copyrightable APIs? (was RE: namespace protection > Finally, one CAN use trademark law -- with all its strengths and > weaknesses -- to prevent third parties from applying your > trademark to their > goods, or to prevent third parties from applying your > certification mark to > their incompatible goods. For example, legitimate trademarks or > certification marks for "Java" or "Windows," (if they exist; I haven't > searched!) could be used to prevent people from forking Java and Windows > APIs and still calling those imprecise implementations "Java" or > "Windows." Hello Larry, Good point! Microsoft fought like hell to obtain a federally registered trademark on "Microsoft Windows." After initial failure, there persistence eventually paid off. Sun claims to have a common law trademark on various iterations of "Java," but no federal registration has been obtained. Of course, Sun used its trademark and license as a basis to file suit against Microsoft for "implementing" the Java API in an incompatible manner. Although it looks as if the terms of the settlement agreement allow Microsoft to continue to support (and, perhaps, promote) third party Java application development on the Windows platform that is incompatible with the Sun API, - - but without use of the common law java trademark - - it's unclear from the terms whether Microsoft agreed it was paying to license a copyright interest in Sun's Java API. We know Microsoft did not pay to license the trademark. > > I hope that other attorneys on this discussion list will help me evaluate > whether a court challenge to the use of the copyright law to > protect APIs is > likely to succeed [SNIP] I think this is a difficult question to answer in the abstract. Microsoft seems to have raised the argument indirectly (and quite cautiously) in its antitrust litigation. Judge Jackson did not give the argument much response, but during oral argument before the D.C. Circuit, one could have drawn an inference that the D.C. Circuit might actually be sympathetic to a clearly presented argument. Hence, I think a court challenge to the use of the copyright law to protect APIs would be a gamble. It might be better to expect that courts will apply the abstraction/filtration test or the idea/expression dichotomy in cases claiming infringement of the copyright in a set of APIs in a manner that filters out those claims or flatly rejects them. One final note: one might argue that such a use of copyright constitutes copyright misuse, if faced with a claim of infringement. I do not know whether Microsoft raised that defense in its answer to the Sun lawsuit. The downside to this argument is that copyright misuse is a judicial doctrine without a statutory basis or explicit support from the Supremes. Hence, many courts reject the defense entirely or limit it to "antitrust-like" issues. Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden www.cyberspaces.org [EMAIL PROTECTED]
Re: copyrightable APIs? (was RE: namespace protection compatiblewit
Hi all! Rod Dixon wrote: > > > > Those are very good thoughts, if I may say so. > Rod > > On Fri, 20 Apr 2001, Chloe Hoffman wrote: > > > > > I am not sure I see how 102(b) should exclude APIs from copyrightable > > subject matter as an absolute matter. Surely some aspects of an API may > > fail because of various doctrines such as merger, scenes a faire, etc. > > (viz. sqrt()) but I am not sure I see how a full set of APIs should be > > excluded per se. I find it hard to distinguish an API from a "computer > > program" - if APIs fail under 102(b) then shouldn't computer programs in An API is not THE program. A POSIX compliant kernal (or his calling interface) all suport the same API, POSIX. The standard C library and the glibc have a lot of "functions" in common. The command line options of the command "ls" or for simplicity a command like "rm" are mre or less the same in the same UNIX family. THAT is an API. Of course one can write a replacement for glibc exposing the same API. Of course one can write a kernal which has a calling interface which is identical to that of POSIX. Of course one can write a replacement for "ls" or "rm" which accept the same command line options (and serve the same purpose). An API is in my sence a LANGUAGE. Take it as an mathematical language if you like, a language can not be copyrighted. The other posts I saw regarding this thread (about Adope, Psotscript and PDF, and Sun/Microsoft JAVA) are in my opinion Trademark issues. The same is true if you go and call a kernal POSIX compliant. I don't know if POSIX is a trademark. The only thing which is in general copyrightable, is CONTENT. The only thing which is in general(exceptions exist e.g. in the US) patent able is a PROCESS in conjunction whith the artifact which is created by performing it. (Same process for different purpose is not affected, same artifact created in a different way is not affected - except that artifact is copyrighted) The only thing wich can get trademarked are (artificial) names used in public (business) affairs (where the names reffer to an artifact or an business). Well, I'm not a lawyer and I simplificated it a bit. (Also I'm from germany, a lot of stuff is different here than in the rest of the world, outside europe) However I work in copyright relevant areas for 10 years now Finaly: JAVA is a trademark, so if GNU CLASSPATH would call it self JAVA, than there would be trouble. Regards! Angelo > > general fail also because they comprise an idea, process, method, etc.? I > > see both as expressions, not the idea themselves. I think the tougher > > issue is infringement/derivative works (leave alone implied/express > > licenses, estoppels, etc.). Just some thoughts > > > > >From: Rod Dixon > > >To: Angelo Schneider > > >CC: , > > >Subject: Re: copyrightable APIs? (was RE: namespace protection > > compatible wit > > >Date: Fri, 20 Apr 2001 14:12:13 -0400 (EDT) > > > > > >This is the issue I was hinting at. I do not believe that as a general > > >matter that APIs should be copyrightable under U.S. copyright law since > > >section 102(b) of the Copyright Act should exclude APIs from copyright > > >subject matter. Having said that, I admit the issue seems unresolved > > since > > >both Microsoft and Sun Microsystems are two well known developers who > > >claim copyright interests in APIs; Microsoft for Windows, and Sun for > > >Java. > > > > > >Rod > > > > > > > > >On Fri, 20 Apr 2001, Angelo Schneider wrote: > > > > > > > Hi! > > > > > > > > In Europe APIs are not "copyright able". > > > > No idea about the US. > > > > > > > > However if you publich them in a book, the book of course is > > > > copyrighted. > > > > However you can not prevent anyone to write a software against a > > given > > > > API. > > > > Same is true for data formats. (In Europe dataformats e.g. a flat > > file > > > > format for a word processor are not copyright able) > > > > > > > > Regards, > > > > Angelo > > > > > > > > Forrest J Cavalier III wrote: > > > > > > > > > > > -- > > > > > > Von: Forrest J Cavalier III[SMTP:[EMAIL PROTECTED]] > > > > > > Gesendet: Freitag, 20. April 2001 13:50:06 > > > > > > An: [EMAIL PROTECTED] > > > > > > Cc: [EMAIL PROTECTED] > > > > > > Betreff: copyrightable APIs? (was RE: namespace protection > > compatible wit > > > > > > Diese Nachricht wurde automatisch von einer Regel weitergeleitet. > > > > > > > > > > > How can you copyright an API? Isn't it simply a > > > > > collection of facts? > > > > > > > > > > Perhaps you could copyright the formal parameter > > > > > names, and certainly the documentation in a header > > > > > file. > > > > > > > > > > But the facts of > > > > > function name, > > > > > return type(s) > > > > > parameter type(s) > > > > > are just facts. There is no creative expression involved. > > > > > > > > > > Forrest J. Cavalier III, Mib Software Voice 570-992-8824 > > > > > http://www.rocketaware.com/ has over 30,000 links to > > > >
RE: namespace protection compatible with the OSD?
> Brian Behlendorf wrote: > > > > On Thu, 19 Apr 2001, Rod Dixon, J.D., LL.M. wrote: > > > 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? > > > > I was wondering if there was a way, compatible with the Open > > Source Definition as well as acceptable to others in the community, to > > create a copyright license for an API specification that helps ensure > > compatibility of derivative works. > > After watching this argument roll around and around, it's tempting to just > say "no". A "no" answer could be derived from any of the following: > > 1) If the API is not copyrightable and enforceable. > 2) If the proposed copyright-based restrictions are contrary to the OSD. > 3) If the restrictions undermine its acceptance and usability. > > The lawyers can debate #1, and #3 can be left to historians, but it's hard > to see any way to reconcile #2, except perhaps on the trivial case of what > one calls the API. Trademarks are a legally sanctioned, generally accepted > mechanism for clarifying the namespace. But anything more general > mechanism > that threatens to prevent unauthorized derivations would > certainly restrict > freedom -- regardless of its legal status. > > > If the GPL's ethos is "access to source code is paramount", > > The key point is not just access to the source code: it is the right to > modify the source code, to create something new from that, and the right > to make those modifications available to others. I think the right to > modify an API is implicit in GPL. Well-stated. In fact, it seems to me that if it were not an implicit assumption of the open source movement, we might want to reconsider why not. On the other hand, if the prevailing practice is to make such use of the API permissible by explicitly stating so in a license (e.g., the Java API is licensed by Sun), then OSI may want to consider making the implicit assumption explicit in the OSD. Sun has an interesting provision in its license: "Java Platform Interface. In the event that Licensee creates an additional API(s) which: (i) extends the functionality of a Java Environment; and, (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, Licensee must promptly publish broadly an accurate specification for such API for free use by all developers." One wonders whether that provision is consistent with the First Amendment. Even so, it is clear that it is consistent with Sun's view on the copyrightability of Java APIs. The link to the entire license, which includes provisions concerning the development kit and a rather odd provision regarding the Windows platform: http://java.sun.com/products/jdk/1.2/LICENSE - Rod
RE: copyrightable API???
A number of things could be said about the "license" in your sig file. The first thing that stands out (aside from the copyright claim...does my message create a derivative work?) is that your license fails to give adequate notice of its terms. A hyperlink is insufficient for e-mail. ;-) Rod > -Original Message- > From: mirabilos [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 21, 2001 8:01 AM > To: [EMAIL PROTECTED] > Subject: Re: copyrightable API??? > > > If I have followed the discussion correctly, no one wants to > copyright his API, but he wants to prevent some people > from claiming some incompatible software compliant. > Example: > > What YOU think of, and IMO is not asked, is: > > - M$ publishes (not) WIN32 API > - Wine (under different name) seeks compliance > is ok > > What I think is meant: > > - I write an API, and someone using it has to include "myapi.h" > - someone extends myapi.lib to yourapi.lib, which still is >compatible with the original API and thus may be used with >including either one of "myapi.h" and "yourapi.h" > - BUT if someone doesn't keep the interface compliant, he >shouldn't claim it is, because e.g. if I replaced old Trumpet >Winsock.DLL with a different one, programmes linked to it >weren't functional any longer, so I wanted to prohibite it. > > Ok, that's just my 0.02 EUR ;-) > > > (PS: Now that's my .sig - I'd like to discuss the license in it, too) > > -mirabilos > -- > ))) LICENSE FOR ABOVE MESSAGE BODY: ((( > YOU _MUST NOT_ READ ABOVE MESSAGE BODY IF YOU DO NOT AGREE TO THESE > TERMS. BY READING ABOVE MESSAGE BODY YOU _AUTOMATICALLY_ _DO AGREE_ > TO THE FOLLOWING TERMS: > This mail/work is protected by copyright law. It _MUST NOT_ be used > otherwise than specified by the terms and conditions at: > http://members.tripod.de/mirabilos/license.mip > The mail is, if not _explicitly_ specified differently, ONLY licensed > by these terms. THIS _CANNOT_ BE OVERRIDDEN BY ANY "TERMS OF SERVICE" > OF ANY S.PROVIDER THE MAIL GOES THROUGH, EVEN _NOT_ IF I SIGNED THEM! > -- > (Sorry for the bandwidth, but some ToS force me to.) > EA F0 FF 00 F0 #$@%CARRIER LOST > >
Re: copyrightable API???
If I have followed the discussion correctly, no one wants to copyright his API, but he wants to prevent some people from claiming some incompatible software compliant. Example: What YOU think of, and IMO is not asked, is: - M$ publishes (not) WIN32 API - Wine (under different name) seeks compliance is ok What I think is meant: - I write an API, and someone using it has to include "myapi.h" - someone extends myapi.lib to yourapi.lib, which still is compatible with the original API and thus may be used with including either one of "myapi.h" and "yourapi.h" - BUT if someone doesn't keep the interface compliant, he shouldn't claim it is, because e.g. if I replaced old Trumpet Winsock.DLL with a different one, programmes linked to it weren't functional any longer, so I wanted to prohibite it. Ok, that's just my 0.02 EUR ;-) (PS: Now that's my .sig - I'd like to discuss the license in it, too) -mirabilos -- ))) LICENSE FOR ABOVE MESSAGE BODY: ((( YOU _MUST NOT_ READ ABOVE MESSAGE BODY IF YOU DO NOT AGREE TO THESE TERMS. BY READING ABOVE MESSAGE BODY YOU _AUTOMATICALLY_ _DO AGREE_ TO THE FOLLOWING TERMS: This mail/work is protected by copyright law. It _MUST NOT_ be used otherwise than specified by the terms and conditions at: http://members.tripod.de/mirabilos/license.mip The mail is, if not _explicitly_ specified differently, ONLY licensed by these terms. THIS _CANNOT_ BE OVERRIDDEN BY ANY "TERMS OF SERVICE" OF ANY S.PROVIDER THE MAIL GOES THROUGH, EVEN _NOT_ IF I SIGNED THEM! -- (Sorry for the bandwidth, but some ToS force me to.) EA F0 FF 00 F0 #$@%CARRIER LOST
