911–920 of 965 posts
Why would Google do this in the first place? The reason is that they did not have time to figure out what capabilities might be needed in their own solution. So copy the API from someone's other competing product and then later, put code behind those API calls. Is it theft or cheating? Kind of, I suppose. It saved them time from having to engineer the API surface.
Earlier quoted context omitted.
Why was this comment downvoted? Does GNU/Linux not largely reimplement proprietary Unix?
Yes why? Doesn't it?
A: some of those suits are still ongoing, and
B: the suits never alleged infringement based on the API alone, SCO was claiming that Linux copied functional code in multiprocessing modules (we don't know which functions because they demand secrecy, even though it's open source).
Not even SCO, trolls that they are, were insane enough to claim that the APIs themselves are copyrighted.
Earlier quoted context omitted.
I noticed that comment too early on. Breyer's opinion comes pretty close to saying "it's at best 'thin copyright'" but the fact that it's explicitly disclaimed makes me think that this is to some extent a compromise position: rather than arguing about whether SSO is copyrightable and risk a bigger split, just concede it because the fair use is sufficient here.
That's exactly why fair use exists. A teacher showing a movie in class is fair use, editing a clip for memes is fair use, making backups is fair use. APIs are copyrightable, but independent implementations are fair use, this is an outright win IMO. SSO might or might not be copyrightable in all of these cases, but we have certainty with fair use for specific cases. In deference to OP, the question was never "Are APIs…
Playing Kremlinology here, it feels like Breyer originally had an opinion that explained that APIs were not copyrightable, but sacrificed that section of the opinion to build a 6-2 majority. It's really weird that the opinions took so long to come out for how simple they end up being--why is this coming it in early April instead of early/mid February if it's written like this? My supposition is that there was a much more sharply divided court, running a 3-3-2 or 4-2-2 opinion, and by dropping the discussion of whether or not the APIs were copyrightable and instead saying "it's at best thin copyright" (i.e., it's copyrightable but good luck ever winning infringement) the opinions collapsed down into a more simple outcome. One thing's for sure: this is the case I'm most interested in finding out all the backroom discussions that went on here.
While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming. One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use: > To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on…
While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming. It is even less decisive than you're saying. The fact that the Supreme Court decided not to overturn the decision of the Court of Appeals for the Federal Circuit that APIs are copyrightable means that binding precedent on every court except the Supreme is that they are. And for fair use, one of…
Lotus couldn't make the transition to Windows, and so lost to Excel (and perhaps Quattro Pro... it's been a long time and I don't remember details). This had nothing to do with copying APIs. Of course, it probably had everything to do with Microsoft's anti-competitive advantage by having access to Windows internals and undocumented features, but that's another matter.
Earlier quoted context omitted.
That's exactly why fair use exists. A teacher showing a movie in class is fair use, editing a clip for memes is fair use, making backups is fair use. APIs are copyrightable, but independent implementations are fair use, this is an outright win IMO. SSO might or might not be copyrightable in all of these cases, but we have certainty with fair use for specific cases. In deference to OP, the question was never "Are APIs…
When SCOTUS accepted the cert petition, it granted two questions: a) are APIs copyrightable and b) if they are, is Google's use fair. Breyer's opinion explicitly lays this out, but doesn't explore API copyrightability any further than "assume it is for this discussion." Playing Kremlinology here, it feels like Breyer originally had an opinion that explained that APIs were not copyrightable, but sacrificed that sectio…
From the market effect part of the opinion, it's Oracle who should be worried if they're different enough from AWS or maybe not if learning any widely-used API means it's a loss if not copied. The WINEs of the world should be safe, Microsoft was never going to bring Win32 or DirectX to Linux.
In my cursory readings about merger doctrine, it's been around for decades, but hasn't been widely adopted by courts, and the justices by little surprise couldn't agree (3-3 or 4-2). The open source lawyers love it, but that means little. Fair use is about as good as it was ever really going to get for the foreseeable future. The industry is just going to have to settle for this or maybe pool it's copyrights like OIN does for patents.
Earlier quoted context omitted.
Yeah, but Thomas said "The majority can not square it's fundamentally flawed fair-use analysis with a finding that declaring code is copyrightable". Which is obviously false. A fair use analysis can -only- take place if the assumption is the code is copyrightable; if the majority had first decided the code was not copyrightable, fair use is immaterial. Thomas' argument, if followed, would either have led to this same…
> Thomas said "The majority can not square it's fundamentally flawed fair-use analysis with a finding that declaring code is copyrightable". Which is obviously false. A fair use analysis can -only- take place if the assumption is the code is copyrightable You are not disputing Thomas's point; you are agreeing with it. Thomas's point was exactly that, before even embarking on a fair use analysis, the Court should have…
The majority supreme court opinion basically said "even assuming it is copyrightable, this IS fair use", with the implication that if it's not copyrightable, there is no case, so the same outcome, a win for Google. They intentionally were keeping their decision as little precedent setting as possible.
Thomas' dissent said "you can't decide this based on hypotheticals! You have to decide whether it's copyrightable or not first!" - had justice Thomas felt the code was not copyrightable in the first place he could have written his own concurring opinion. In fact, he did not; his position, as made clear in his dissent, was that he felt APIs -were- copyrightable, AND that this was not fair use.
The court did not agree with him. And had the court first started with addressing whether an API was copyrightable, the outcome would have either been they are not (a more far reaching decision, but still a win for Google), or that they were, and that this was fair use (so the same outcome, but now with, again, a more far reaching decision).
You claim that Thomas is saying that "if the court decided it was copyrightable, then they would have also had to have found this was not fair use". If that is indeed what he said (not my take on it, but I'll grant it), that is false on the face of it, as that is -explicitly what the court did not do-. They accepted it was copyrightable as a hypothetical, and then focused solely on, if that is true, was this was fair use? And they found that it was. To form an argument in this way is logically consistent; Thomas may disagree with it, as is his right, but the statement that the court has made a logical error is absurd.
Earlier quoted context omitted.
It's still a long time! You try being two years later to a major market than Microsoft and still beating them. How often has that happened?
Windows Mobile - iPhone Tablet PC - iPad Internet Explorer - Google Chrome MSN Messenger - Facebook Messenger, iMessage, etc Microsoft Band - Apple Watch Zune Pass (2006) - Spotify (2009, 2011), Apple Music, etc Skype - Zoom Hotmail - Gmail
Internet Explorer wasn't the first browser on the market but by the time Chrome had come around Microsoft had let it languish and it became pretty awful. For a long time Microsoft had convincingly won the browser war.
Same with MSN messenger, it didn't keep up. And nobody has ever decisively won that chat app war anyways .
Smartwatches have been around for a very very long time. What Apple did was get smartphone integration right.
Zune Pass isn't a streaming service, its a DRM laden online music store. So more akin to iTunes than Spotify or Apple Music. And it was very late to the game.
Earlier quoted context omitted.
No, I'm asserting that those (while being extremely valuable additions to the field) have nothing to do with a newer version of Java which is what you were asking about. > the next excuse for not updating Android Java to latest versions.
So let's back to that. The only two companies that ever had issues with Java owners were Microsoft thanks to J++ and Google with its Android Java. Lots of companies have produced their own Java version, without any issue. Sad that things have gone this way and Google isn't being hardly punished for what they did to Java ecosystem with their special flavoured Java and by giving Sun's fatal blow. Thankfully they never…
While the Apache project is not a company, it definitely had issues with Sun over Apache Harmony's Java certification (I'm not confirming or denying that this was part of IBM's proxy wars with Sun).
Incidentally, Apache Harmony is what Google used to jumpstart not-officially-Java compatibility with Android.
> Sad that things have gone this way and Google isn't being hardly punished for what they did to Java ecosystem with their special flavoured Java and by giving Sun's fatal blow.
Speaking of "special flavoured Java" - what Google did with Android was an improvement over the fragmented mess that was Java ME. Good God, I remember Sun-approved, vendor-specific extension, so Samsung/Nokia/Sony-Ericsson each had its own API for the same functionality - e.g. checking for connectivity. Additionally, the API could be subtly different for each phone model from the same vendor. You either had to create different build pipelines (1 per vendor, with overlays/facades), or do an ungodly amount of reflection in your runtime logic. So much for "Write Once". Sun was never interested in licensing Java SE on mobile, I don't see how Google could have killed them when they weren't even competing on "your phone as a full-blown computer"
I loved Sun Microsystems; they were idealistic, geeky, and made very cool, albeit expensive gear. I suspect their idealism made them hop onto the open source bandwagon without due consideration for long-term sustainability. They open-sourced the OS (OpenSolaris), open sourced the application stack (Java, perhaps reluctantly), while their server hardware was being disrupted by x86; how were they going to make money? They were not long of this world - Linux, commodity x86 and open source Java Application Servers killed Sun. IBM was in a similar place at the time, and they shifted focus to consulting.
> But yeah lets not get distracted and join the Oracle hate mob.
I've been part of that mob for a long time, fuck Oracle for how they treated Gosling, how they handled the JCP, and mishandled OpenOffice (until it blew up in their face). I didn't care for MySQL, but it seems to have been ok so far.
Earlier quoted context omitted.
I've never heard of any evidence that Microsoft planted: if (NetscapeIsRunning()) corrupt_data(); in their OS API calls. If they had, I'm sure it would have come out at the anti-trust trial, and would have made it an open and shut case. Did that happen? As I recall, the anti-trust case revolved around Microsoft including IE for free with Windows, not sabotage. (Of course, every OS comes with a free browser these days…
The claim by tinus_hn is that FrontPage - Microsoft's HTML editing tool - created pages that crash Netscape. While it would arguably be Netscape's fault if Netscape actually crashes (rather than simply failing to display a malformed input) at that time in the browser wars there were plenty of energy going into creating incompatible new 'features' - such as Microsoft's own JavaScript competitor, VBScript [1], vector i…
There's zero evidence Microsoft sabotaged Netflix.
There's zero evidence Netscape crashed for any reason other than buggy Netflix code. Making a web page that crashes Netflix is a bug in Netflix. Microsoft is under zero obligation to work around Netflix bugs.
Earlier quoted context omitted.
Lotus' failure was more because they failed to port to Windows, betting instead on OS/2. Lotus was at a crossroads. DOS was obsolete, was the future OS/2 or Windows? They chose OS/2. Lotus was a big, cash rich company at the time. Their fatal error was not realizing they should have ported 1-2-3 to both OS/2 and Windows. Then they would have been secure regardless of which prevailed.
At that point(1989), the future was less clear-cut than Windows vs OS2. Windows was more a graphical shell for DOS than a real OS, and there were other graphical shells for DOS. From the top of my head: I vaguely remember GEM, I have used one from Tandy. There was something else installed on our school computers, Dynamic Environment or something . Windows before 3.0 (1990) was inferior to a lot of these DOS shells. I…