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
+1 That's exactly what I think | 286 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
API's Not Like SSO's of Music (Stave, 4/4 time, treble clef, etc)!
Authored by: Anonymous on Wednesday, May 09 2012 @ 01:11 PM EDT
API's are NOT the creative part of Application Development
like the Notes are in writing music. The Structure, Sequence
and Organization of Music is dictated by the Stave (lines),
Timing Marks (4/4), Clef (pitch). They are the Functional part
of writing music. Not the Creative part that Oracle has
attempted to mislead the World into believing.

The Notes are the language (like words) to CREATE the Musical
Composition (Application). By using the language in concert
with the SSO calls to form what's really the creative part of
Music! ....but like the API SSO's of the language of written
Musical Notations, you can't write the Musical Creation
(Application) without them!!!

[ Reply to This | Parent | # ]

+1 That's exactly what I think
Authored by: Anonymous on Wednesday, May 09 2012 @ 02:32 PM EDT
As a developer who has designed and implemented APIs. Most
of the cleverness is in the implementation, but a bad API is
worse than useless.

Good design takes time, creativity and
effort, but the result is functional. It must be;
accessibility and reuse of the implementation is
the whole point of an API.

That. Is. What. The. Words. In. 'API'. Mean. Application.
Programming. Interface.

I honestly don't know how anyone who knows anything about
software development could not see this. Maybe it needs
words of one syllable.

I conclude it's wilful blindness on the part of Oracle.

[ Reply to This | Parent | # ]

Poetry
Authored by: cricketjeff on Wednesday, May 09 2012 @ 02:47 PM EDT
I like to pretend that I'm a poet, the API, applied to poetry, would equate to a
form.
Form gives (well some forms give more or less than this but typically) line
lengths, in terms of syllables, the meter (where stresses fall and their number)
and a rhyme scheme. All sorts of people create new forms, some of them are even
good, but the idea that they are copyrightable is simply laughable. If someone
uses "your" form it's a matter of celebration!

---
There is nothing in life that doesn't look better after a good cup of tea.

[ Reply to This | Parent | # ]

most of which is functionally dictated.
Authored by: Anonymous on Wednesday, May 09 2012 @ 04:29 PM EDT
java language standards for example define case to be used for
verbs(classes)/nouns(methods) and so forth including accessors set/get
is<boolean>, so cut that for a start.

deciding to use x,y instead of y,x is not any more creative than deciding to use
a 3:4 beat for your waltz, sure you could do it anyway you liked, but you'd be
forcing everyone who wanted to use your API into a different conceptual
framework, so it would be extremely stupid to do so and would mean that people
probably decide to try and find,even write themselves wrapper functions at
least, an equivalent API that didn't use such barking ideas. No matter your
genius of creativity, it's very hard to dance a waltz to a marching beat.

Just because lots of people use it, doesn't mean it's either popular or creative
(look at the Windows API)

Further the name of the function that you wish to document and abstract to the
API is a human readable reference to the expected output/action of the function
being called.

It is thus a requirement that the name used be descriptive of what the user of
your abstraction can expect to happen, In addition it needs to be as concise as
possible to avoid excessive verbiage in resulting source code


Your creative choices in "designing" an API are about as equally
constrained as a Casio Home Organ with all the keys, switches buttons, controls
and display removed with the exception of the few marked "auto rhythm"
"chord accomp", "auto melody", "tempo" and
"on/off"

Sure, you could make some noise that might easily fool people that you are
"creating" music, but in fact all you are actually doing is expressing
the significantly greater and protected creative work that is built in to the
system itself (i.e the API implementation and it's accompanying Documentation)


I suspect you're probably the same bridge resident who thinks HelloWorld has
validity as a benchmarking tool beyond 'yup it's doing something'.


[ Reply to This | Parent | # ]

a great API
Authored by: BJ on Wednesday, May 09 2012 @ 05:34 PM EDT
Please give me an example of a 'great API' that I cannot use without a license.

bjd

[ Reply to This | Parent | # ]

API's, creativity and music
Authored by: Anonymous on Thursday, May 10 2012 @ 02:58 AM EDT
I'm a language designer (well PhD student in Programming Languages, so
language designer in training, but close enough), and I want to say
"Language Design is Creative"
You know what
"Algorithm Development is Creative" too. Also, my brother is a
mathematician
and it is clear that
"Mathematics is Creative"
Yet, none of these things should be copyrightable, and neither should APIs.
Math (and all of CS is math) is not simply discovered, it is invented.
Scientific
theories (what we colloquially refer to as "facts") are invented. The
mere fact
that something is creative or invented doesn't change the fact that it is not
the
kind of thing that can be owned. No one can own a mathematical theorem, an
algorithm, a formal language, or an API.
The specifics of copyright do not apply. All of these things are abstract
ideas.
They are functional. They are not tied to any medium of expression.
The specifics of patents do not apply. They are not methods of manufacture.
They are incorporeal, and not tied to any particular (physical) machine. They
may involve transformations, but the things they transform are themselves
abstract and incorporeal.

We do not need patents or copyrights to "protect" our ideas. Math and
the
sciences have never had these "protections". The progress of our
creative endeavor is the central aim of humanity: to explore, to better
ourselves, to
create. Market incentives can only create friction that anathema to science
and mathematics. Ours is a regime of sharing. Our approach to inquiry has
brought enormous wealth to the world. It continues to be extremely
productive. Law should not interfere in our endeavor.

[ Reply to This | Parent | # ]

API's, creativity and music
Authored by: Anonymous on Thursday, May 10 2012 @ 04:21 AM EDT
Sure, creating an API requires a lot of work and skills and creativity and
ingenuity. I could readily imagine cases where inventive elements of them could
be patentable as long as software can be patented. And writing descriptions for
it may be a copyrightable piece of creative expression.

But copyright on the API itself is ridiculous, and there would be unusually high
thresholds for patentable elements, and they would rather certainly only concern
very limited parts. For example, consider a signal processing framework: its
mechanisms for tying components together might be innovative and hard to
separate from the APIs, meaning that you could not reimplement the code behind
the APIs reasonably without reverting to the same manner of combining stuff.

Then reimplementing the APIs would be pretty hard without violating the
underlying patents, but that does not mean that the APIs themselves are
patentable.

Underlying the APIs may be calling/sequencing methods that could more
realistically be subject ot patents. However, those would be features of the
language rather than the APIs themselves.

So in short: the patent case has a bit more chance of not being a lame duck.
But it will be very hard to tie a significant amount of damage to it since, if
at all, a minuscule ratio of APIs will be connected with patents.

[ 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 )