copyrightable APIs? (was RE: namespace protection compatible wit

[Rod Dixon]

On Fri, 20 Apr 2001, Chloe Hoffman wrote:

>
> Do you have any basis for the "better" view? Also, how does it better
> serve the purposes of copyright?
Well, I said I *THINK* the better view is... In other words, I was
expressing an opinion. The reason why I think it is the better view is
because it serves the purposes of copyright NOT to view APIs as
copyrightable subject matter, generally. (There might be some exceptions,
but i cannot think of any). I cannot answer the "how" part in an e-mail
message, but i could point you to a law review article, if you are
interested.

> What happened to protection for authors
> for limited times?
I am glad you asked the question. Authors who create copyrightable works
gain the protection, those who do not don't (not even for a limited time).
What we might disagree on is what is the constitutional purpose of
copyright. For me, the constitution clearly sets out that the purpose of
the congressional power to grant copyright interests is to *promote the
progress of science and art.* What better way to do so than to let
programmers develop works  that ARE subject to copyright protection by
ensuring free and open access to APIs (ideas), which constitute processes,
ideas and methods outside the scope of copyright?
 > Surely
non-copyrightable APIs are good for the 'open
> source' software (or are they?) but I am not sure if it is better as a
> general proposition.
I disagree. (see above)

>
> Also, I am not sure I see the basis for the implied license to copy (or
> perhaps even the more important right, to create a derivative work) in
> all cases.
Good point here. As I mentioned earlier, some developers like Sun and
Microsoft can weaken or disturb the implied license argument by explicitly
stating to the contrary. However, merely asserting a copyright interest in
an API is not sufficient.  Indeed, the implied license argument assumes
that such an assertion might be made.

As for derivative work, I am unsure how that changes the analysis.  The
assumption is that at least one exclusive right has been infringed unless
there is an implied license. If your position is that the creation of a
derivative work must be viewed as outside the scope of the implied
license, then we are in very cloudy territory. Certainly, we would not
want to say that assuming an API is copyrightable, that any call to an API
function results in a derivative work. Would we? There might be a strong
disincentive for anyone who might own the copyright in an API to make that
claim. Wouldn't you say so?

 - Rod





 > Surely it is not in the interest of most
software vendors to
> prevent copying/preparing derivative works of API (network effects and
> all that) but that does not necessarily mean those vendors rights are
> foregone. In many proprietary software cases no express rights have been
> given (contra see the license provisions in the Java APIs) nor could I
> see any such license being implied as necessary to the "use" of the
> licensed software (absent ambiguous or express language in that
> software's license).
>
> >From: Rod Dixon
> >To: Chloe Hoffman
> >CC: ,
> >Subject: Re: copyrightable APIs? (was RE: namespace protection
> compatible wit
> >Date: Fri, 20 Apr 2001 14:34:38 -0400 (EDT)
> >
> >I doubt whether we will resolve the copyrightability question. I think
> the
> >better view is that an API is not copyrightable subject matter. I also
> >think that viewing an API as such better serves the purposes of
> copyright
> >law. Even so, I agree that the more important question is if you assume
> >that an API *IS* copyrightable, what next? The answer is that
> programmers
> >have an implied license to copy. Of course, that does not mean a
> >programmer ought to be able to copy an entire API for a given
> programming
> >environment, but it does mean that most copies of an API function or
> >routine do not exceed the implied license. (BTW, not to add to any
> >confusion, but my use of the term copy is in the strict copyright sense
> >that applies to software).
> >
> >Rod
> >
> >
> >On Fri, 20 Apr 2001, Chloe Hoffman wrote:
> >
> > >
> > > In my view, an API is as much a collection of facts as your original
> > > message, as Stephen King's latest novel, etc. I think in most cases
> an
> > > API involves creative expression or at least some selection,
> arrangement
> > > or coordination of function names, parameter type(s) and return
> type(s)
> > > (of course I am not talking about the simple abstract concept of an
> API;
> > > I am talking about a set of developed APIs). Surely if an API is just
> one
> > > function then you have a de minimis problem. But let's take the Java
> API.
> > > Taking U.S. law as an example, I would think that after you take
> whatever
> > > material (functions, return types, parameter types, parameter names,
> > > etc.) that is not copyrightable (by virtue of, for example, the
> merger
> > > doctrine(the idea and expression merged into one and there is no
> other
> > > way of expressing it), the scenes a faire doctrine (only so many ways
> of
> > > expressing the idea) and being in the public domain) there would be a
> > > great deal of material left over that involved creative expression or
> at
> > > least serious selection, coordination, or arrangement. For copyright
> to
> > > attach only minimal originality is needed. I can't see the argument
> > > flying that the Java API is like a purely alphabetical white pages.
> > >
> > > I think the real question is not whether an API is copyrightable but
> how
> > > an API is infringed and what is a derivative work of an API.
> > >
> > > >From: "Forrest J Cavalier III"
> > > >Reply-To: forrest at mibsoftware.com
> > > >To:
> > > >CC: forrest at mibsoftware.com
> > > >Subject: copyrightable APIs? (was RE: namespace protection
> compatible
> > > wit
> > > >Date: Fri, 20 Apr 2001 07:50:06 -0400
> > > >
> > > >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
> > > >source, libraries, functions, applications, and documentation.
> > >
> > >_______________________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com
> > >
> > >
> > >
> >
>
> ________________________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
>