On 14-10-19 01:57 AM, lkcl . wrote:
On Sun, Oct 19, 2014 at 9:48 AM, thufir <[email protected]> wrote:
On 14-10-19 01:26 AM, lkcl . wrote:
On Sat, Oct 18, 2014 at 5:52 AM, thufir <[email protected]> wrote:
On 14-10-17 08:52 AM, lkcl . wrote:
the reverse-engineering was at several different levels:
I think your missing a key point, which is that you reverse-engineered,
which is exactly exempt:
you are correct in that the reverse-engineering *itself* is irrelevant.
however if it is an *API* that has been reverse-engineered and that
API is considered to be *copyright material*.
please ignore the fact that the material derived has been
reverse-engineered in samba, wine and many other software libre
applications.
there is no link to reverse-engineering.
it is the fact that the APIs which *have* been implemented [by a
means and method that ****HAPPENS***** to be reverse-engineering] are,
through this dangerous precedent that will be used in case-law to make
****ALL***** APIs copyrighted material, that is the most dangerous
concern.
is that clear where your confusion lies?
is that clear enough now exactly what the issue is?
l.
You've muddied the waters beyond all...something...at least for me. So I
quoted everything.
Ok, make this concrete. We're talking OpenJDK. Let's ignore the GPL for
the moment, and just consider copyright. So, OpenJDK can be reverse
engineered, resulting in ReverseEngineeredJDK, which can be completely
proprietary. You're concerned that the SSO of ReverseEngineeredJDK can be
copyrighted?
i'm not in the slightest bit interested in Structure, Sequence and
Organisation. the only thing i care about is that APIs remain
uncopyrightable.
Well, neither the appeals court nor the trial judge wrote anything about
API's themselves being copyrightable, that I'm aware of. So that
specific question isn't addressed, at least not directly, by any
decision I know of. Neither do I see a practical way, even if API's
were copyrightable, to put a copyright "on" an API.
Why are you concerned about that?
please do not make assumptions about what i am concerned about: if
you would like to know my concerns please ask.
Well, you wrote "...that is the most dangerous concern," which I read to
be your concern. Yes, I was asking what your concerns were, or rather,
why. I made no assumptions, I was replying to your words about the most
dangerous concern. There's no assumption that it's your concern, that's
the implication of what's written. Anyhow.
> Finally, while not stated by anyone, I think it's widely assumed that a
trivial API, or SSO if you prefer,
no i do not. and any confusion or attempt to call SSO "APIs" is
flat-out wrong. APIs are *NOT* the same as a program's structure,
sequence or organisation. please stop doing it.
Fair enough; there was at least one person unfamiliar with the SSO
terminology from the appeals court. While it doesn't seem a far-off
comparison, at least in the context of this specific appeals court
decision, fair enough.
can't be "protected" by copyright. The
fuzzy part is where to draw that line between an API that's not creative to
one that is. Which, I guess, is where the lawyers come in ;)
exactly. and once one court case defines it as being for example
"37" APIs, then case law will permit *ALL* APIs comprising a number of
function calls at 37 or above to be copyrighted.
once that happens then the nightmare scenario that i outlined in the
first post becomes a reality.
ok _enough_ hawat, i have to get on with other matters.
l.
That's not how it works, that 37 would now be some magic number. In
fact, the appeals court directly addressed this topic, writing:
"Given the court’s findings that the SSO is original and creative, and
that the declaring code could have been written and organized in any
number of ways and still have achieved the same functions..."
page 45
meaning that, at trial, it would be required to establish that the SSO
is original and creative.
Well, anyhow, I wanted to know what the FSF thought of this decision,
specifically, beyond the statements on the website. There seems a
disconnect between what the appeals court actually wrote and the
response from the FSF. Most of the what I've read in the press repeats
this idea that suddenly API's are copyrighted, or that it's somehow not
possible to use Wine, or along these lines, which isn't at all how I
read the decision by the appeals court.
I wouldn't expect everyone to read this decision, but I was curious
about it and thought this would be a good place to discuss the appeals
court decision; hence the subject title. I'd like the FSF to reconsider
its position on the ramifications of this lawsuit, I think that the FSF
has it backwards.
Unfortunately, this discussion went nowhere. Reverse engineering was
brought up, then dropped. Why it was even raised is unclear to me;
apparently, it was a red herring.
-Thufir
