Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jury in Oracle v. Google finds in Google's favour

twitter.com

Post reply on HN
Print view View original

371–380 of 409 posts

Re: Jury in Oracle v. Google finds in Google's favour

#371

Post by snambi »

Zigurd wrote: post #369
brianwawok wrote: post #194

Earlier quoted context omitted.

Like when windows extended Java then started adding incompatibile methods to the windows Java extension that would be on all windows computers? Or maybe when office used a hidden format to store files so no one could share files without buying a license? They were not great times at all...

> Like when windows extended Java then started adding incompatibile methods Visual J++ was a very usable Java. Had Sun failed to sue it out of existence, the world would have had a Java with a good UI stack developers actually used, an IDE that was not unusably slow and buggy, AND almost all packages built for Sun's Java would drop right in without problems. Visual J++ would have created the same effect on the use of…

Btw, Java has a great UI stack, it is part of Android.

Re: Jury in Oracle v. Google finds in Google's favour

#372

Post by dang »

ChrisLomont wrote: post #241

This is 100% inaccurate That story leaves out significant details, and his description of the reason is wrong. He leaves out significant prior sources and reasons, to the point your statement "It was not created to help artists or whoever" is simply wrong. Wikipedia provides a far better history with extensive sources [1]. Note for example the section "Early Developments" where they list precursors to anything in you…

We detached this subthread from https://news.ycombinator.com/item?id=11782568 and marked it off-topic.

Re: Jury in Oracle v. Google finds in Google's favour

#373

Post by Zigurd »

snambi wrote: post #371
Zigurd wrote: post #369

Earlier quoted context omitted.

> Like when windows extended Java then started adding incompatibile methods Visual J++ was a very usable Java. Had Sun failed to sue it out of existence, the world would have had a Java with a good UI stack developers actually used, an IDE that was not unusably slow and buggy, AND almost all packages built for Sun's Java would drop right in without problems. Visual J++ would have created the same effect on the use of…

Btw, Java has a great UI stack, it is part of Android.

I'm sorry if I missed the humor. But yeah, interactive Java is Android Java. It might have been WFC. It surely was never going to be AWT or Swing.

Re: Jury in Oracle v. Google finds in Google's favour

#374

Post by dragonwriter »

icebraining wrote: post #250
dragonwriter wrote: post #167

Earlier quoted context omitted.

> The GPL does not depend on copyrightable APIs True in terms of the GPL as such , but the FSFs interpretation that the GPL applies to works that link, even dynamically, to a GPL covered work, which it holds to be derivative works, depends absolutely on the API presented by a library being a copyright-protected element (it also probably can't stand even then without an extremely narrow interpretation of "fair use".)

Why? A license is just a contract, no? Can't the clauses be arbitrary? I mean, could you have a clause in a license that said "to distribute this work, you need to wear purple shoes on Mondays"? If so, why wouldn't you just be able to say "to distribute this work, you need to distribute works that link to it under the same license", as as arbitrary condition?

> Why? A license is just a contract, no? Can't the clauses be arbitrary?

You don't need to abide by a copyright license if you aren't doing anything for which permission of the copyright holder is required in the law -- a copyright license is only needed to do things which would otherwise be prohibitd as within the exclusive purview of the copyright owner.

As the GPL isn't a sale contract that you must agree to as a precondition for receiving a copy of the software, when you receive a copy of GPL-covered software you can do anything you want with it as long as that isn't legally within the exclusive prerogative of the copyright owner (or contrary to the law for some other reason), and the GPL itself is irrelevant. The assertion by the FSF that particular uses of GPL-licensed software are constrained by the license is, therefore, necessarily an assertion that those uses are within the scope of the exclusive rights provided by copyright law.

Re: Jury in Oracle v. Google finds in Google's favour

#375

Post by ChrisLomont »

tripzilch wrote: post #368
ChrisLomont wrote: post #361

Earlier quoted context omitted.

>You can also check the references from the article i cited. The references are correct. They leave out significant parts of the story, as I stated. You started with "Copyright law was created as a way to support a nascent publishing industry by granting it a monopoly. It was not created to help artists or whoever.". This is demonstrably false as shown above many times. >I think any intelligent person realizes wikipe…

Spinning " more evidence" into " better evidence" is just as stupid of a bias, IMHO. The only way is to consider evidence based in its own merits. But of course it's easier to count links and judge the size of names.

>The only way is to consider evidence based in its own merits

Bingo, which is what I did. Note the post you reply to has a paragraph starting "Any intelligent person will look at the two sources, note differences..".

I posted the comparison between sources in reply to DannyBee claiming one was niche, when both decent. One simply subsumes the other.

Re: Jury in Oracle v. Google finds in Google's favour

#376

Post by belorn »

dragonwriter wrote: post #167
farcical_tinpot wrote: post #119

Earlier quoted context omitted.

This is irrelevant. There was a ridiculous notion going around a while back that if Oracle lost then the GPL would become unenforceable. The GPL does not depend on copyrightable APIs, and says nothing about what Oracle is trying to argue. Linking to a library and merely using an API are two different things. The GPL depends on the former and says the latter is neither here nor there.

> The GPL does not depend on copyrightable APIs True in terms of the GPL as such , but the FSFs interpretation that the GPL applies to works that link, even dynamically, to a GPL covered work, which it holds to be derivative works, depends absolutely on the API presented by a library being a copyright-protected element (it also probably can't stand even then without an extremely narrow interpretation of "fair use".)

That is a very surface based interpretation of FSF stance on the subject. What I have heard from members of FSF board members is that the dynamic linking aspect of GPL is a simplified rule that a non-lawyer can use to identify when a derivative work is created.

The primary argument is the simple question: is there two disconnected works or a single work with separate parts, parts that exist either for technical reason or for plain arbitrary reasons. Software that is dynamically linked can't be run without the dynamic library, is dependent on the library, and generally has no purpose if you try to use it without the library. If a judge/jury member will view the complete work as the software+library, then the method of linking the two together is irrelevant.

The "first" case of this was a patch to GCC. The patch would not have much purpose without GCC. A common sense approach would be that the working Objective-C compile had two parts, the patch provided by apple and the compile provided by the GNU project. RMS initial thought like most programmers that since patches seems like separate parts than it was separate and disconnected works. However, it was unclear so he asked a lawyer and thought that a judge would not view it like that. From there the dynamic linking guideline came to be and that is where current thinking has stayed. Nothing about API is needed for this, and GPL would still work tomorrow if someone created a third method to link software together as a single work.

A interesting future case would be a program that is dynamically linked to a library that exist under several different licenses. Such software would have a strong argument to be disconnected from their library, but they would still be incomplete and a judge would likely put a lot of weight on the developers intention rather than any technical aspects.

Re: Jury in Oracle v. Google finds in Google's favour

#377

Post by monocasa »

jra_samba wrote: post #242
nl wrote: post #192

Earlier quoted context omitted.

Samba is API compatible with Windows file server. Unless you are arguing that network protocol compatibility is a different thing? It seems to me that there is a lot of overlap, since Samba relies on re implementing the same behavior as a Windows file server.

Samba uses NO Windows APIs. Please learn the difference between an API and a network protocol, else you end up looking foolish. https://www.samba.org/ftp/tridge/misc/french_cafe.txt

It's not nearly as cut and dry as you're making it. Wiki of all places defines 'API' to be broad enough to include network wire protocols and endpoints. This trial was over "sequence, structure, and organization" rather than literal copying.

And of course Samba isn't built of WIN32 APIs, that's not what we're talking about.

Re: Jury in Oracle v. Google finds in Google's favour

#378

Post by ChrisLomont »

dang wrote: post #372
ChrisLomont wrote: post #241

This is 100% inaccurate That story leaves out significant details, and his description of the reason is wrong. He leaves out significant prior sources and reasons, to the point your statement "It was not created to help artists or whoever" is simply wrong. Wikipedia provides a far better history with extensive sources [1]. Note for example the section "Early Developments" where they list precursors to anything in you…

We detached this subthread from https://news.ycombinator.com/item?id=11782568 and marked it off-topic.

It was a reply to DannyBee's post claiming copyright "was not created to help artists or whoever". It starts with "This is 100% inaccurate" which is why I began this the same way.

I note others have since reposted the same links in reply to DannyBee for the same reason.

How it is off topic since it directly addresses that claim?

Did it get detached from the parent, removing context?

Re: Jury in Oracle v. Google finds in Google's favour

#379

Post by PeterisP »

tripzilch wrote: post #363
deciplex wrote: post #263

Earlier quoted context omitted.

Was the hold Office format hidden? It was delightfully obtuse and even obfuscated IMO, no doubt about that, but not impenetrable, and you can find the docs describing the file format on Microsoft's site now . Could you not get them 10-15 years ago?

The prevailing idea seemed to be that if you wanted conversion of Word documents, let's say to screenshots, to match properly in all cases, the only way was a dedicated (or virtual) machine running Windows+Word and some VBS to automate the conversion. I don't know if this is still the best way. LibreOffice has came a long way for sure, but still doesn't reproduce Word's layout perfectly (which is still the expectatio…

Some differences in rendering or printing would be acceptable - what is not acceptable, however, is unintended corruption of existing documents.

E.g. if I open a word document in libreoffice (to do e.g. review and commenting), save it without any changes to the layout, then I'd expect the original author to have the same document layout as before... and that is not so. The same applies to LibreOffice Calc - opening and saving the document produces changes.

Can't you just have a unit test that verifies that reading and immediately writing a document should keep it completely unchanged, except possibly for metadata?

Re: Jury in Oracle v. Google finds in Google's favour

#380

Post by PeterisP »

curt15 wrote: post #230
rayiner wrote: post #198

Earlier quoted context omitted.

Copyright doesn't care about the software's behavior, just the text and structure of the code. Samba implemented CIFS without looking at or copying any Microsoft code.

Reverse engineering is not a defense against infringement if the subject of reverse engineering is copyright-protected.

It kind of depends - in some jurisdictions, for example, interoperability requirements is a sufficient defense against copyright infringement, i.e., if you've built your product so that interoperating with it requires [re]using copyrighted parts, then it's okay to do so (up to the extent required for interoperability) even if you explicitly forbid it.

Sane laws such as that automatically prevent issues such as this Java API dispute and also things such as the attempts to block interoperability for coffee machine "pods" by requiring a copyrighted magic string and using DMCA to prevent others from using it.

Post reply on HN