Original link: http://blog.farmostwood.net/944.html
Write about my understanding of the US Supreme Court’s final decision on the Google vs. Oracle case today (I don’t have a legal background, this is written from an engineer’s perspective). The case has been litigated for ten years, with a target value of US$8.8 billion. After three judgment reversals, today’s final ruling is widely regarded as a far-reaching case in the technology industry.
The reason for this is very simple: Java is a language that is very popular among programmers, and it is in the hands of Oracle. When Google launched the Android system, in order to allow more programmers who write third-party apps for Android to get started as soon as possible, they directly reused a large number of Java function interfaces (APIs) in the Android APP development tool, but re-implemented the function itself . Oracle therefore sued Google for copyright infringement.
The heart of the question here is: is a language’s interface subject to copyright protection? Is its reuse infringing?
Oracle’s argument is pretty straight forward (and actually quite convincing to non-industry people): Is software copyrightable? certainly. Are interfaces an important part of software? certainly. Then the interface should obviously be copyrighted.
Google’s argument is a bit more complex, requiring a detailed dissection of the meaning of an interface—the word API itself is unfamiliar to most legal professionals and the general public. The chief author of the Supreme Court decision is the 82-year-old Judge Breyer, who has probably never written a line of code in his life. But judging from the judgment, he has a precise understanding of the function and connotation of the API.
The argument adopted by the decision was that an API is an interface that sends commands, like the gas pedal of a car (an example of which came before the First Circuit in Lotus vs. Bortland), or the QWERTY keyboard of a computer. ——These two examples are not random, because they both reflect the essence of this case: Google uses the ready-made Java interface to attract programmers to get started quickly. Should this kind of “using previous ready-made knowledge to save learning costs” be protected or punished? The gas pedal is such a similar situation. The first person to design a car already designed the gas pedal like this, and if the design itself is copyrighted, every subsequent new automaker faces a dilemma, it either inherits the design but pays a high price The copyright fee, or start from scratch but no user will buy its car, because no one wants to buy a new car and form a new set of muscle memory. The same is true for the API. The judgment pointed out that its value is largely reflected in the proficiency of the programmer community and the savings in learning costs that can result from reusing this API.
Therefore, the core of this judgment is to declare that this kind of free riding is a fair use and should not be punished. The core of which (and the most concerned by most of the comments) is such a statement:
“What we must consider is whether the protection of copyright advances the public interest and whether it promotes innovation.” (p. 31)
“Given the investment programmers have made in learning the Java API, it would be detrimental to the public interest if the interface itself was protected because it would force programmers to make extra effort to adapt to the new interface. New creations would be Locked up, and the key is in the hands of the Oracle family. This allows Oracle to make a lot of money, but these profits could have flowed into new applications that can be created by a large number of people who have mastered these interfaces. So this lock is contrary to the original intent of the copyright.” (p. 34)
As you can imagine, the impact of these discourses (particularly on the public interest) will be very far-reaching.
The above is about the verdict itself. But I have some other thoughts.
In this specific example, the judgment is with the industry’s common sense. Copying Java’s interface (which only accounts for a very small proportion of Java’s total code size) and copying Java’s specific function implementation are two different things, and they are not the same.
But what is not touched here is that designing an interface is not a trivial task for a system. In a sense, the interface of a platform is as important as the implementation behind it. The interface is a bit like the “user interface” in the programmer’s world. A good interface can decisively give a platform an advantage. In some extreme cases, the value of a platform can be mainly reflected in the interface. For example, Keras, one of the most popular platforms for machine learning, you can say that it is an API as a whole – it leaves the specific implementation to Tensorflow or Theanos in the background. (Later Keras was integrated into Tensorflow, here is the original version.)
The law depends on metaphors, and metaphors are always imprecise. If the relationship between interface and implementation is imagined as a few plugs on a huge machine shell and a wealth of actual functional components inside, Google’s approach is equivalent to copying the design of several plugs on the shell for compatibility and completely starting from scratch internally. But modern software engineering is not a simple machine, it is difficult for you to clearly separate the shell and the inside. In most cases, what you see is a layer-by-layer function encapsulation, a lot of wisdom is invested in the design of the interface, and the bottom-level implementation is probably just trivial details.
Blockchain is an extreme case. In 2016, Joel Monegro, an analyst at Union Square Investments, wrote a very famous article: fat-protocols. He pointed out that, contrary to the situation in the traditional network field where the protocol is very light and the application is heavy, in the blockchain world, the protocol is “fat” and the application is insignificant. Investing in apps is far less rewarding than investing in protocols. For example, Ethereum is a great protocol, its value far exceeds the specific application itself running on Ethereum. ——A protocol (protocol) is of course not exactly the same concept as an interface (API), but they are strongly related. Copying the entire interface of Ethereum is almost equivalent to copying Ethereum itself. How should this matter be compared to the real world?
Of course, this does not mean that today’s judgment means that you can directly copy an entire Keras or Ethereum. In Google’s case, there are many other factors to consider (the most important point is transformative use, that is to say, Google does not intend to create a Java equivalent competitor, Android and Java are two different fields thing). But the verdict draws a clear line at the boundaries of the metaphor after all. —— Judging from the reaction of the industry today, this boundary has been almost overwhelmingly supported by the industry (except Oracle).
But its long-term impact remains to be seen.
This article is transferred from: http://blog.farmostwood.net/944.html
This site is only for collection, and the copyright belongs to the original author.