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
That line of thinking is a wonderful and useful thought experiment | 388 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
"Sequence" doesn't matter!
Authored by: Anonymous on Sunday, May 06 2012 @ 10:05 AM EDT
A good point. The "sequence" of some methods in a class, or classes
in a package, doesn't matter at all. It has no creativity in it, and should not
be copyrightable. If you re-arrange the order and show both orders to a
programmer, of course he will say the API is the same. The computer doesn't
care about that order, and neither does the programmer. Each method or class is
a constituent part of the complete API, but there is no meaningful
"ordering" of those parts.

That leaves just "structure" and "organization", a pair of
words which, together, describe the particular arrangement of methods in
classes, and classes in packages, and packages in other packages. But some of
that stuff is entirely functional, and could only be done in one particular way.
And for the rest of it, it was a matter of "style" or "good API
design" in the Java standard library. But for Apache Harmony or any other
implementor besides the first, they have to make 100% of the same choices that
the first implementor made. There is one and only one "structure" and
"organization" which is compatible with Sun's.

So "SSO" would normally be thought of as some nebulous combination of
three aspects of the work. But with programming language APIs, two of them are
100% dictated by functional or compatibility requirements, and the third doesn't
really exist at all (or to the extent that it does, it is 100% dictated by
functional requirements).

Maybe we need new legislation affirming that SSO copyright does not apply to
computer programs, and that copying structural choices where interoperability
dictates the choice, is not infringement.

[ Reply to This | Parent | # ]

That line of thinking is a wonderful and useful thought experiment
Authored by: Gringo_ on Sunday, May 06 2012 @ 10:11 AM EDT

That line of thinking could be worked and elaborated as an illustrative device at the appeal stage or in a motion - the point being to drive home the irrelevancy of the 'O' in "SSO" (order), and 'S' (sequence). All that would remain to discuss would be the "Structure". Suddenly we have something very nebulous indeed.

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