|
|
|
| Authored by: Anonymous on Tuesday, April 17 2012 @ 03:29 PM EDT |
Since Oracle is in charge of Sun's UNIX OS (Sun also freed
much of that too, under open forms of license), ...one can
imagine Larry wanting to change many past rules - in order to
"make" his ship sail in more friendly and proprietary seas.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, April 17 2012 @ 03:46 PM EDT |
Creating the implementation of the API may be difficult, but thinking up a name
and a list of the parameters for each of the routines is easy, just copy what
C/C++, Python, Pascal or many others used or use the english name of the
functionality.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, April 17 2012 @ 03:49 PM EDT |
Ah, yes. The old "sweat of the brow" argument. A classic. This was
used to try and support a brand new copyright for databases.
It didn't work then, should it work now?[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, April 17 2012 @ 03:50 PM EDT |
Even to the extent that difficulty might make it special, or
more specifically, "protectable", it certainly doesn't make
it copyrightable.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, April 17 2012 @ 03:54 PM EDT |
Just write software.
Writing API Specifications is harder
but mostly/strictly dictated by the functions of your software.
Organising your software may be not easy, as opposed to hard
but again is largely set by function.
Just because developers (usually) loathe writing documentation does not make
APIs hard to write.
That said, if you choose to design your APIs by community participant committee,
it could turn out to be quite hard, but then, they are not yours anyway, you are
only the custodian.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, April 17 2012 @ 04:27 PM EDT |
Well, it may be to establish the groundwork for argument that an api (or
language specification) is copyrightable, because the work is non-trivial.
For
instance, a phone book or dictionary is copyrightable because the publisher
did
a lot of work in collecting and arranging non-copyrightable facts or
words.
Let's say I wanted to write my own Scheme language. What makes it
Scheme is that it adheres, generally, to the Reports that a Scheme governing
board periodically issues. For instance in RSR^6, case-sensitivity — to great
controversy — was added for symbols and variables. It is not hard law, Scheme
writers may implement or not implement elements of the report as they wish,
but, and this is the big but, programmers who write good programs in other
environments will have inconsistent results or crashes when they run in my
environment. Leave out enough things and I will be the pariah at the
programmers' picnic. So, if I'm doing a good job, and I want to
implement the language, I will refer and check my work against the Report,
which is a tangible expression of the idea of the Scheme programming
language.
(At this point, I'll disclaim that I'm no expert in copyright laws and
while I
am sincerely trying to use terms of art correctly, I may not be.)
Sun's
first variable Collection object was called a Vector. Access to the
object at
index i was achieved via elementAt(i). Vector had problems as an
interface and
the better List object was added to the language down the road.
Still, Vector
remained in the language and has certain behaviors with regards to
locking
during object addition and removal. Anyone who says their language is
java has
to implement elementAt(i) for Vector and get(i) for List. There are many
methods in the Vector class and many methods in the List class. There are
specific keywords and syntax rules. (One of the keywords added turned out to
be one of my pet variable names. Rewrite and recompile city, but the
functionality the keyword added was much needed and requested.) There are
different behaviors and millions of lines of code relying on the classes
behaving
as Sun specified. There are thousands of classes in the Sun/Oracle
SDK.
Someone who writes a java-compatible language without reference to Sun's
published, copyrighted, documentation will fail and join me at the
aforementioned Pariah's table.
Now I should admit that Oracle vs. Google
on patents didn't really interest
me. If the patents were tossed, then fine. If
the patents were upheld, well, I
don't believe that software is patentable. Now
that copyright of apis remains as
a key point, I'm looking in and clearly
playing catch-up. It took a few years for
Gosling and team to move Oak, for
cable set-top boxes, to java. Java 1.0 was a
mess, and its api was revamped, at
Sun's expense, in order to make the
language better for the programmers. It is
still a work in progress and there's a
can of worms involving a complex story
of Sun's desire to keep some control,
Sun's desire to have java widely used,
and frenemies such as IBM who wrote
their own virtual machine and coding tools.
There's the
Apache Software Foundation and Harmony adding complexity to the
story.
There's Sun having talks with Google and then letting the issue go (but,
mentioning Google's unlicensed use of java as a tease to potential serious
buyers). There's
Crazy Larry, colorful and quotable, but otherwise
unsympathetic as one who
deserves more material wealth. So I don't know if
Oracle has a leg to stand on
when it comes down to the real law and not some
what-I-wish that I have.
Before they had java, there was the database product,
the SQL language and the
extensions they added, and programming languages for
stored procedures
within the database all of which they need to get right as
part of having
customers. As one who has tried to write reusable code with a
good interface/
api and whose customer base is me, yet come up short many
times, I think
Ellison is right when he says that that is a
hard thing to do.
[ Reply to This | Parent | # ]
|
| |
| Authored by: hAckz0r on Tuesday, April 17 2012 @ 04:37 PM EDT |
| The JCP writes the Java API's, not Oracle. ---
DRM - As a "solution", it
solves the wrong problem; As a "technology" its only 'logically' infeasible. [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, April 17 2012 @ 04:56 PM EDT |
As an expert, I can assure you that writing APIs well is a bit difficult, but
not all that difficult, and the Java APIs are not all that well written anyway.
It is absolutely a lie to say that writing APIs is the most difficult thing that
any software company does. Absolutely false. Far more money and time is spent
on coding and testing than on initial design. [ Reply to This | Parent | # ]
|
| |
| Authored by: xtifr on Tuesday, April 17 2012 @ 06:24 PM EDT |
It's hard to write a good API, because it should be
functional, rather than creative! If your API is creative, that's just
going to confuse people.
Yes, it can be hard to make something
functional. It's much harder to build a functional engine than it is to make a
bunch of "cool looking" parts and stick them together. The latter may be very
creative; the former is not (not in the copyright law sense), even though it's
harder.
If I were a Sun engineer, I would be infuriated to hear my hard
work dismissed as merely "creative", after all that time and effort I'd spent
making sure the APIs were functional (efficient, consistent, and not
actively confusing).
---
Do not meddle in the affairs of Wizards, for
it makes them soggy and hard to light. [ Reply to This | Parent | # ]
|
| |
| Authored by: calris74 on Tuesday, April 17 2012 @ 10:56 PM EDT |
Larry - Ellison says writing APis trying to
sue Google is
'arguably one of the most difficult things we do
at Oracle.
There,
fixed :)[ Reply to This | Parent | # ]
|
|
|
|
|
