decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Examples? | 396 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
API what it is and what it isn't and fair use.
Authored by: Anonymous on Wednesday, April 25 2012 @ 11:10 AM EDT
Ive watched as people try to describe an API.
We've had difficulty explaining it.

I thought, let's start again. From what we know.

Let's say I write lots of code, in several files. This code does things.
I write more code, with different functionality. I keep this body of code
separate
from the first.

Again and again, 37 times.

The CODE I write is mine. You cannot use it, its copyrighted.

This code is useless to anyone but myself, because no one knows HOW to use it.

I then write a description of what things those 37 bodies of code does. This
document is also copyrighted. Its a different copyright than I have on the
files in
the 37 other bodies of code.

Let's call those 37 bodies of code, packages.

Lets call the document that describes the functionality of those the API
specification.

The API specification is a 'contract' that fixes the functionality of the
packages.
I have said how it works, what the output is for a given input...

I know have a document that you can use to write your own programs that does
whatever it is you want, when you use MY packages.

I make my packages available for free on specific terms and conditions. You are

getting the compiled packages and API specifications. You aren't getting my
source.

You and everyone can write code knowing and relying on the 'contract'.

In time, I let you see the source for one of my packages. You see that I have
described what it does quite well, in the API specification, but I've coded it
poorly. You re-write the code, without changing the API specification for this

package.

You can do this for all of my packages. You can call yours harmony.

Your code is different than mine, with its own copyright.

The interfaces to both are the same. They need to be for interoperability.

Back in the day, I would have said that at a programmatic level, that even
though
I might have a copyright on a specific file that you used as the INTERFACE to
either of our packages, it was fair use for us both to use for
interoperability.

We could use header files describing the interfaces without using each others
implementations of those interfaces.

Requiring other users to re-write their code to use different interfaces to
access
our separately developed packages with essentially the same functionality would

be a colossal waste of time. All the advancements that have taken place over
the
years of development have come precisely because we built on a well defined set

of basic interfaces. Whole new bodies of code, (packages) have been developed
because each development group could rely on the basic packages and build on
it.

After years of such reliance, after years of promoting my specific API
specification, through books, standard bodies and years of software releases,
the
community has an expectation that those API specifications, those contracts,
will
continue.

All this seems compatible with what I know about copyrights. I own the
copyright to the source code I wrote in my packages, you own yours. The
SPECIFIC document that I wrote to describe the functionality of my packages, I
own. The INTERFACE itself, I thought in the past was not copyrightable, as it
was
an description of the copyrightable implementation of the code and required for

interoperability. Interoperability at one time was perceived as a 'good thing'
and
was allowed on grounds of fair use.





[ Reply to This | Parent | # ]

Examples?
Authored by: Anonymous on Wednesday, April 25 2012 @ 11:14 AM EDT
Does baking a cake work for you?
  • Specification - provide a specific cake given a specific type and quantity of ingredients. Here all possible things are described like the type of flours that can be used (in the USA this includes All-purpose, bread, cake, and self- rising).
  • Interface - perhaps the actual ingredients and quality of each ingredient like a cup of flour
  • Implementation - all the things that result in a cake. Check for the correct ingredients and associated quantities. Steps to combine the ingredients and actually cook the cake - probably as defined in the specification.
Notice that the API, probably the implementation aspect, may call other APIs like preheating the oven to some temperature. Also there could be multiple cake baking APIs for different cakes as in the way APIs are being described in the case (as libraries).

[ Reply to This | Parent | # ]

2. doesn't exist
Authored by: Anonymous on Wednesday, April 25 2012 @ 03:47 PM EDT
It's a figment of your imagination.

There is the document that describes what is expected to happen in association
with 'a name', this is an API Specification.

there is some source code, that may (you hope, it may not, be warned) attempt to
describe in a programming language, that which is expected to happen as
described in the document.

That source code can be compiled to an object code representation of the source
code.
(these *two* things, are sometimes referred to as an "API
Implementation", while it is sort of true, it does not distinguish and it
misstates what those two things are)

Subsequent use of the name in conjunction with other tools, to reconcile the
name with it's offset in the object code can cause the object code at the offset
to be executed on request

I don't think that uses any terms that are difficult to understand

There may be extra hidden wizardry in a bytecode (e.g.JVM) type environment, it
does not change anything, for all the magic, the name, gets translated to an
offset which is used as a pointer from which to start executing object code.

That is what an API is. Magic.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )