|
Kalman posted:People in the development world aren't loving lawyers and their opinion on legal outcomes should be trusted about as much as my opinion on whether your lovely code is going to cause the compiler to throw a type mismatch warning (or maybe less since at least I went to school for electrical engineering and wrote code for a living at one point.) Okay, full stop, right here. Lawyers are also not programmers. Or scientists. Or doctors. Their rulings have no bearing on the actual reality of something outside of its use in a courtroom setting and its legal implications. Patent Trolls ring a bell? Those guys do real damage, why should I pretend that the people who actually know and use the APIs know less than the lawyers trying to understand and interpret those same APIs in a court room with a barebones understanding of how they work? CommieGIR fucked around with this message at 01:09 on May 11, 2016 |
#
?
May 11, 2016 01:06
|
|
|
|
| # ? Jun 6, 2024 22:48 |
|
|
CommieGIR posted:Okay, full stop, right here. Patent attorneys are required to have a degree in a natural science or engineering at least.
|
|
#
?
May 11, 2016 01:08
|
|
|
CommieGIR posted:Okay, full stop, right here. You have no idea about IP law. 
|
|
#
?
May 11, 2016 01:09
|
|
|
ayn rand hand job posted:You have no idea about IP law. http://www.ipwatchdog.com/2015/04/24/when-it-comes-to-patents-john-oliver-takes-the-easy-way-out/id=57119/ https://www.gnu.org/patent-examp/patent-examples.html http://www.fosspatents.com/2012/04/pragmatic-approach-to-copyrightability.html Its not cut and dry, but Google has a strong argument http://apievangelist.com/2015/01/25/doing-the-research-in-preparation-for-my-patent-on-a-patent-api/ http://techrights.org/2009/02/04/the-api-trap-part-1/ CommieGIR fucked around with this message at 01:19 on May 11, 2016 |
|
#
?
May 11, 2016 01:10
|
|
|
You're citing to a number of source from the IP law equivalent of Infowars.
Discendo Vox fucked around with this message at 01:58 on May 11, 2016 |
|
|
#
?
May 11, 2016 01:23
|
|
|
Kalman posted:I'll leave off with a direct quote from the initial ruling: In case you're unaware, the reason that's pretty hilarious/useless in the case of Java (and other popular languages), and the reason it freaks some people out is that you really can't write portable code that does anything interesting or useful without using the standard library and you have to refer to the part of it you want to use according to how it's structured. Java's 'hello world' looks like this: Java code:Munkeymon fucked around with this message at 01:49 on May 11, 2016 |
|
#
?
May 11, 2016 01:43
|
|
|
CommieGIR posted:Okay, full stop, right here. Do you think that Google, Apple, oracle, Samsung, etc would pay literally billions of dollars to lawyers and expert witnesses that don't understand how a api works ? The EFF has taken a side and is advocating for it. I don't blame or fault them, but I wouldn't write off the involved parties, or even the judges. Everyone has spent a lot of time trying to figure this out.
|
|
#
?
May 11, 2016 04:36
|
|
|
EwokEntourage posted:Do you think that Google, Apple, oracle, Samsung, etc would pay literally billions of dollars to lawyers and expert witnesses that don't understand how a api works ? I think he thinks the tech companies' lawyers and expert witnesses understand perfectly well how an API works but are being paid literally billions of dollars to willfully misunderstand how it works, while the judges are genuinely ignorant and taking the tech companies' expert witnesses at face value. (Not saying that's necessarily what's happening in this case.)
|
|
#
?
May 11, 2016 04:53
|
|
|
It doesn't help that software is a giant square peg that the courts are trying the drive through about a dozen different round holes. It probably is unique enough to warrant not grouping it in with either patent or copyright but instead giving it an entire new Title under the United States Code. But politicians know a dumpster fire when they see one and nobody is going to be dumb enough to start that fight if we can keep things going ad-hoc through court rulings.
|
|
#
?
May 11, 2016 04:54
|
|
|
Silver2195 posted:I think he thinks the tech companies' lawyers and expert witnesses understand perfectly well how an API works but are being paid literally billions of dollars to willfully misunderstand how it works, while the judges are genuinely ignorant and taking the tech companies' expert witnesses at face value. (Not saying that's necessarily what's happening in this case.) Yea I'm sure they're stretching the truth to the limit, but they def know more than barebones of it. And I think the judges that end up making these rulings, like the federal circuit which does most the patent decisions (I think?), understands it better than people think.
|
|
#
?
May 11, 2016 05:31
|
|
|
Shifty Pony posted:It doesn't help that software is a giant square peg that the courts are trying the drive through about a dozen different round holes. It probably is unique enough to warrant not grouping it in with either patent or copyright but instead giving it an entire new Title under the United States Code. But politicians know a dumpster fire when they see one and nobody is going to be dumb enough to start that fight if we can keep things going ad-hoc through court rulings. That's mostly why I want someone to make a credible claim on C's standard library API: I can't think of anything else that'd get the money, and therefore the Congress, behind an even barely sensible reform movement because this area is both incredibly wonky and beneficial to the big, established players who own so much IP.
|
|
#
?
May 11, 2016 06:15
|
|
|
CommieGIR posted:The EFF isn't an uninformed group. They have valid reason to be concerned, and I know plenty of people in the devlopment world who are very concerned about this. These are people who regularly write and use APIs. I'm going to trust their interpretation over the courts or legals interpretation, and I'll trust the EFF I just wanted to point out, everyone uses APIs, but very few people write them. I am hugely biased here, but I think writing a clear, easy to use, and powerful API specification is usually significantly more difficult than implementing it. If you want an example from the Java world, look at Jodatime. For people who have to spend significant time having to deal with calendar math it was a revelation, and there is a reason the API has been ported to several other platforms. One of those is .NET (Nodatime) -- because whoever designed the .NET time APIs made some serious fundamental mistakes which make it almost unusable for serious Calendar applications. The fact DateTime.Kind was private before .NET 2.0 still blows my mind. I think the huge majority of people who have had to spend significant time designing APIs would find it a bit ridiculous to say their work didn't deserve copyright protection. Even insulting.
|
|
#
?
May 11, 2016 06:29
|
|
|
It's an interface, though. That's like saying that companies should be able to copyright the number of splines on a shaft or the diameter of a pipe. It's difficult to engineer a pump, but that doesn't mean that a company should be able to copyright the pulley size used to drive it. APIs shouldn't be protected at all, and the methods that are used to implement them should be under (reformed) patents. If someone wants to describe what a new system for software that would address it better would look like, that could be something to talk about, but allowing APIs to be copyrighted is defeating the whole point of an API.
|
|
#
?
May 11, 2016 07:04
|
|
|
My understanding of the Java case is that Oracle is saying that it's entirely OK to use the Java API to compile code into Java byte code and execute it on a Java virtual machine. That's not what Google did. They built a system where they're using (verbatim copies of) the Java API to compile code into ART byte code and execute it on the Android Run Time. Now, should that be legal? I don't know. But I think even if the SCOTUS decides it isn't, it doesn't automatically mean that someone could dredge up a copyright on ANSI C and sue every software company in the world. This is a special case where Google is leveraging something that someone else owns in order to build their own system. I think a good illustration of this is the Jodatime / Nodatime packages that Chuu brought up. The Jodatime folks thought up a really nice API for how to manage dates, and they also developed an implementation of that API in Java. The Nodatime folks copied the API wholesale, made minor modifications to make it work in .NET, and then built a completely different implementation. If Jodatime had been released under a license more restrictive than the Apache license, I think there'd be a legitimate case that Nodatime had infringed on their copyright in doing this. That being said, Oracle is really just being a money-grubbing rear end in a top hat here.
|
|
#
?
May 11, 2016 09:34
|
|
|
Skrewtape posted:My understanding of the Java case is that Oracle is saying that it's entirely OK to use the Java API to compile code into Java byte code and execute it on a Java virtual machine. That's not what Google did. They built a system where they're using (verbatim copies of) the Java API to compile code into ART byte code and execute it on the Android Run Time. Now, should that be legal? I don't know. But I think even if the SCOTUS decides it isn't, it doesn't automatically mean that someone could dredge up a copyright on ANSI C and sue every software company in the world. This is a special case where Google is leveraging something that someone else owns in order to build their own system. iirc, openjdk is gpl, but with an additional proviso that derivative works have to be a fully compliant JVM. android's VM is not a compliant JVM as it is missing a decent amount of the API, and implements alternatives for those. if you want to create a non-compliant VM you have to pay for a special license from oracle (and back when android was created, sun). Munkeymon posted:In case you're unaware, the reason that's pretty hilarious/useless in the case of Java (and other popular languages), and the reason it freaks some people out is that you really can't write portable code that does anything interesting or useful without using the standard library and you have to refer to the part of it you want to use according to how it's structured. Java's 'hello world' looks like this: that's not really a strong argument since the only reason google is in trouble is that they specifically only copied enough to allow java libraries to be compatible with their platform, but to disallow applications developed from their platform from being portable to standard JVMs
|
|
#
?
May 11, 2016 10:15
|
|
|
Sinestro posted:It's an interface, though. That's like saying that companies should be able to copyright the number of splines on a shaft or the diameter of a pipe. It's difficult to engineer a pump, but that doesn't mean that a company should be able to copyright the pulley size used to drive it. APIs shouldn't be protected at all, and the methods that are used to implement them should be under (reformed) patents. If someone wants to describe what a new system for software that would address it better would look like, that could be something to talk about, but allowing APIs to be copyrighted is defeating the whole point of an API. not really. apis can exist but be for internal use only. there's very obvious reasons to restrict who can and cannot use an api. also, you seem to be confusing copyrighting an API ( a collection of methods and classes for interacting with the JVM in this case) and copyrighting a method header (public String toString() {} is not copyrightable, java.lang is)
|
|
#
?
May 11, 2016 10:25
|
|
|
Munkeymon posted:In case you're unaware, the reason that's pretty hilarious/useless in the case of Java (and other popular languages), and the reason it freaks some people out is that you really can't write portable code that does anything interesting or useful without using the standard library and you have to refer to the part of it you want to use according to how it's structured. I'm aware. But it's completely irrelevant to the Oracle case because you can use the standard library and refer to the part of it you want to use without this ruling affecting you in the slightest. The only thing you can't do is write your own version of the standard library without doing so in a clean room RE situation.
|
|
#
?
May 11, 2016 13:26
|
|
|
Condiv posted:iirc, openjdk is gpl, but with an additional proviso that derivative works have to be a fully compliant JVM. android's VM is not a compliant JVM as it is missing a decent amount of the API, and implements alternatives for those. if you want to create a non-compliant VM you have to pay for a special license from oracle (and back when android was created, sun). If Google had properly cleanroomed they would be in the clear.
|
|
#
?
May 11, 2016 13:28
|
|
|
Condiv posted:iirc, openjdk is gpl, but with an additional proviso that derivative works have to be a fully compliant JVM. android's VM is not a compliant JVM as it is missing a decent amount of the API, and implements alternatives for those. if you want to create a non-compliant VM you have to pay for a special license from oracle (and back when android was created, sun). But, keep in mind that when you compile something to Android, you compile it with javac first (dx is a cross-compiler that works on .class files - it does not compile .java files on its own). So anything you compile to Android you can compile to Java itself, by design. Of course, that's assuming that the classpath is the same, and with Android there is some stuff missing as you mention. It would be weird if that was the sticking point, though, since if it were I guess you could just include the full library but have all the stuff you don't want throw a RuntimeException when used. So that doesn't sound right.
|
|
#
?
May 11, 2016 13:44
|
|
|
Munkeymon posted:In case you're unaware, the reason that's pretty hilarious/useless in the case of Java (and other popular languages), and the reason it freaks some people out is that you really can't write portable code that does anything interesting or useful without using the standard library and you have to refer to the part of it you want to use according to how it's structured. Java's 'hello world' looks like this: If there is only one way to do something that would be thinly copyrighted, it's then not copyrightable because there's no expression involved. Same with basic methods of organizing, you can't copyright alphabetizing the phone book.
|
|
#
?
May 11, 2016 13:55
|
|
|
evilweasel posted:If there is only one way to do something that would be thinly copyrighted, it's then not copyrightable because there's no expression involved. Same with basic methods of organizing, you can't copyright alphabetizing the phone book. That's what leaves a bad taste in my mouth because there's literally no way to make a library that functions the same without copying the overall structure. Someone who wants to write a piece of software that behaves the same as the Java Virtual Machine in that it will run a program written in Java and produce the same results must follow the same naming convention and overall structure that Sun originally did. That includes using names that are also trademarks, like Sun and Java. It shouldn't be possible for someone to take something that wouldn't qualify for patent protection and design it in a way that they get equivalent protection through clever use of copyright or trademark. This is especially true when copyrights don't require any sort of application process and last far longer.
|
|
#
?
May 11, 2016 14:42
|
|
|
Condiv posted:that's not really a strong argument since the only reason google is in trouble is that they specifically only copied enough to allow java libraries to be compatible with their platform, but to disallow applications developed from their platform from being portable to standard JVMs I thought it was because they didn't clean room it correctly. Wasn't it also unclear whether you actually needed a license at all to copy any part of an API before this case?
|
|
#
?
May 11, 2016 15:19
|
|
|
evilweasel posted:If there is only one way to do something that would be thinly copyrighted, it's then not copyrightable because there's no expression involved. Same with basic methods of organizing, you can't copyright alphabetizing the phone book. There's only one way to implement it that's compatible with Java. There are basically an infinite number of ways to structure an API, some better than others. System.out.println(String) could just as easily be called System.Console.WriteLine(String). The fact that there's even a dedicated method to write a line of text out to a local console (instead of, say, having to call another method to get some local console object, that you then put into a generic write-out-to-object function) is part of the API. So's the fact that System.out is separate from trigonometric functions, date methods, and windowed graphics, because there's nothing inherently against the language spec to write System.out.inverseCosine(byte) or a global getYear() method that returns a two-digit year string even though those are terrible ideas. A modern API goes way beyond alphabetical-order organization. Most everybody who works in the software industry would agree that coming up with a good, usable API that tends to encourage good code is a difficult creative challenge. Incidentally, this is also why all the talk about cleanroom implementations is kind of pointless. The point of a cleanroom implementation is that you give a team who's never seen the product you're cloning a set of carefully defined inputs and outputs, then let them come up with the functionality themselves. You can prove they didn't copy the functional parts, even if they look similar, because they were written independently. With an API, that spec you send into the cleanroom is what has to come back out, basically word-for-word. If you ask the team to just generally structure an API for a Java-like system, there's no way that they will make all the same design decisions and incidental choices that the original Java spec did, so it won't be compatible. If Oracle gets everything they want out of this case, a lot of textbook cleanroom implementations will effectively be violating copyright law. Now, despite all that difficult creative work that goes into designing an API, it's still fundamentally closer to a method of operation than anything else. Laying out a chemical plant control room or an airliner cockpit is difficult creative work that requires a lot of careful organization and domain-specific knowledge as well, but those aren't copyrightable. What Oracle is doing here is a pretty blatant cash grab, which goes against both the law and standard industry practices. The fact that API design is difficult and creative work doesn't mean that it's eligible for specific IP protection, especially under our laws that do a terrible job of accounting for inherently interconnected copyrighted works and patentable inventions in the first place.
|
|
#
?
May 11, 2016 15:30
|
|
|
Javid posted:Can we get a Latin legal concept that means "old rear end judges who can barely work a web browser shouldn't be setting legal precedent regarding computer programming"? Redde Caesari quae sunt Caesari
|
|
#
?
May 11, 2016 15:35
|
|
|
Space Gopher posted:There's only one way to implement it that's compatible with Java. This, basically. Oracle knows that Google can't really re-do the entire API without basically making it Java incompatible, so they are arguing Google owns them cash BECAUSE it works with Java. I suspect even if Google had clean room'ed the entire API from scratch, Oracle would still have them in court. I'll say it again: Oracle is the new SCO.
|
|
#
?
May 11, 2016 15:37
|
|
|
But google could and did rewrite significant portions. If they had just rewrote everything, they'd be in the clear.
|
|
#
?
May 11, 2016 15:57
|
|
|
Space Gopher posted:Incidentally, this is also why all the talk about cleanroom implementations is kind of pointless. The point of a cleanroom implementation is that you give a team who's never seen the product you're cloning a set of carefully defined inputs and outputs, then let them come up with the functionality themselves. You can prove they didn't copy the functional parts, even if they look similar, because they were written independently. With an API, that spec you send into the cleanroom is what has to come back out, basically word-for-word. If you ask the team to just generally structure an API for a Java-like system, there's no way that they will make all the same design decisions and incidental choices that the original Java spec did, so it won't be compatible. If Oracle gets everything they want out of this case, a lot of textbook cleanroom implementations will effectively be violating copyright law. The API is part of the input to the clean room. It should have been "given the Java standard library API docs* and a working knowledge of the language rules, make a standard library" but they actually looked at (copied?) some source files, which was a stupid shortcut that broke the seal on the clean room. *which necessarily describe the structure and organization of the library, because you have to know that to use them because that's how the language was designed
|
|
#
?
May 11, 2016 16:31
|
|
|
Mr. Nice! posted:But google could and did rewrite significant portions. If they had just rewrote everything, they'd be in the clear. Not according to the Federal Circuit's decision. Oracle v Google posted:[We] conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages at issue are entitled to copyright protection. The handful of lines in the rangeCheck implementation that were probably copied wholesale are a completely different issue. Under the Federal Circuit decision, the structure, sequence, and organization of the Java APIs alone, without any other code, are copyrightable. It doesn't matter whether you came up with a perfect outsourced-to-Mars cleanroom implementation of the API or just copy-pasted your way to victory: either way, if Oracle doesn't like what you're doing, under this decision you're infringing the API copyright.
|
|
#
?
May 11, 2016 16:33
|
|
|
Space Gopher posted:Not according to the Federal Circuit's decision. No. You're missing a key distinction between patents and copyright. With patents, it doesn't matter if you invented it independently, the first person to do it gets patent protection and you get poo poo. In contrast, if you independently create a work you own the copyright on it, even if that work duplicates someone else's copyrighted work as long as you independently created it without using their work. If you come up with the exact same thing they did, with a clean-room implementation, you're in the clear because you can prove independent creation. That's why the clean room workaround exists: because the people creating your version had no access to the other version, they could not have copied and must have independently created it, ergo no copyright violation.
|
|
#
?
May 11, 2016 16:41
|
|
|
Evilweasel is right. You misunderstand how copyright law works.
|
|
#
?
May 11, 2016 16:43
|
|
|
Munkeymon posted:I thought it was because they didn't clean room it correctly. Wasn't it also unclear whether you actually needed a license at all to copy any part of an API before this case? clean room would've protected them, but iirc they would've been able to get copyleft protection through the gpl if they had followed the rules of sun's (now oracles) special version of the gpl which requires you make a compliant jvm. google didn't want to make a compliant jvm so they probably won't even be able to successfully argue that they should have a interoperability fair-use exception Condiv fucked around with this message at 16:55 on May 11, 2016 |
|
#
?
May 11, 2016 16:52
|
|
|
This really isn't a catastrophic ruling and google is only hosed by their own deliberate action. They had alternatives that would have ended up at the same result but legally. They specifically chose not to pursue the legal options.
|
|
#
?
May 11, 2016 16:54
|
|
|
Kilroy posted:Android's VM is not a compliant JVM because it doesn't run the .class you get out of javac at all, rather using a different instruction set and .dex files. i think android could be considered compliant if you could convert between .dex and .class files and if applications compiled solely against the standard library worked on android (ie: no runtime exceptions because an application tried to use Swing).
|
|
#
?
May 11, 2016 17:01
|
|
|
Google was faced with trivially difficult options that would have been 100% legal but more expensive/time consuming or what amounts to IP theft to save a buck and hope they win in court. They chose the latter.
|
|
#
?
May 11, 2016 17:08
|
|
|
Space Gopher posted:The handful of lines in the rangeCheck implementation that were probably copied wholesale are a completely different issue. It was written by the same guy for Sun and later Google, IIRC, so it's going to look like a copy+paste unless one company uses a fairly different style guide and enforces it.
|
|
#
?
May 11, 2016 17:17
|
|
|
To be clear, while you can get around the api copyright issue and google is dumb to have failed to do it properly, the fact that you can get around API copyrights with this clean room nonsense and that everyone engages in this pointless dance is a strong indication that the underlying principles of the law are stupid in this case and need to be fixed. There's no good reason we should have people engaging in this pointless exercise, and the flat principle Google was going for - apis can't be copyrighted - seems to be the obvious solution.
|
|
#
?
May 11, 2016 17:22
|
|
|
evilweasel posted:No. You're missing a key distinction between patents and copyright. With patents, it doesn't matter if you invented it independently, the first person to do it gets patent protection and you get poo poo. But, in the case of actually creating and structuring an API, a true cleanroom API definition that just so happens to match the existing Java API closely enough to be compatible is so vanishingly unlikely no sane person would believe that you actually created it independently. Cleanroom implementations work because it's possible to implement the same standards as black boxes in lots of different ways - you don't have to be character-for-character identical. With an API, on the other hand, changing anything from the canonical definition will break it. There are a handful of lines that define what System.out.println is, and if you change it to System.console.println or System.out.printLine, anything that expects to use the standard API call will break. The same goes for every other function in the API. The cleanroom team, who by definition can't know what it is supposed to look like, would need not only to reinvent the functionality but the way it is named and structured, including all the little design decisions that crop up along the way. Coming up with an independently invented API out of a cleanroom that just so happens to match the Java spec perfectly is as unbelievable as if you had asked me to write a teen vampire romance novel and I handed you a word-for-word copy of Twilight. Cleanroom implementation only works for things that can be independently implemented. Oracle is claiming that the specs handed into the cleanroom, which define that implementation, are their copyrighted intellectual property. The Federal Circuit agrees. Space Gopher fucked around with this message at 17:28 on May 11, 2016 |
|
#
?
May 11, 2016 17:25
|
|
|
Space Gopher posted:But, in the case of actually creating and structuring an API, a true cleanroom implementation that just so happens to match the existing Java API closely enough to be compatible is so vanishingly unlikely no sane person would believe that you actually created it independently. Cleanroom implementations work because it's possible to implement the same standards as black boxes in lots of different ways - you don't have to be character-for-character identical. Your argument is contradictory. Either it must match virtually exactly in order to work - in which case it is not at all "vanishingly unlikely", the clean room procedure can only create an identical copy and you simply prove that, or it doesn't, and the clean room implementation most likely will differ. If there's only one way to do something, then of course your independent implementation will get to that one way. It's not like you will then go into court and say that monkeys hitting keys randomly got the answer: you'll go in and have someone explain precisely what you're saying above. There are parts of the API that can only be implemented in one way to work, and so those have been implemented in the only possible way and that's why it matches, and you testify that you kept the clean room procedures followed.
|
|
#
?
May 11, 2016 17:30
|
|
|
evilweasel posted:Your argument is contradictory. Either it must match virtually exactly in order to work - in which case it is not at all "vanishingly unlikely", the clean room procedure can only create an identical copy and you simply prove that, or it doesn't, and the clean room implementation most likely will differ. not really. yes the api must match exactly to work (where work is defined as "be interoperable with code compiled against the oracle java standard library api"), and yes it's vanishingly unlikely that the api could be recreated without looking at oracle's api or testing against oracle's software. if google didn't care about interoperability at all they could've done a clean room version of the API and wouldn't have had an issue. google's implementation of the api is not 100% compatible (by choice), but they copied what they did because they needed to to be some level of interoperable. i think that because they chose intentionally to not make android fully interoperable they will not win their fair-use defense.
|
|
#
?
May 11, 2016 17:39
|
|
|
|
| # ? Jun 6, 2024 22:48 |
|
|
An awful lot of confusion of an API and implementation thereof going on here...
|
|
#
?
May 11, 2016 17:47
|
|
