6 ms·

Would copying an instruction set and ABI to make an interoperable processor and system be fair use in light of Google v. Oracle (2021) [0][1]? [0] https://www.

Would copying an instruction set and ABI to make an interoperable processor and system be fair use in light of Google v. Oracle (2021) [0][1]? [0] https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf [1] https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_.... Edit: Changed phrasing of question. Also, to be clear I think the answer is probably yes.

hn_acker 2y ago
Most likely yes. In Google v. Oracle, the Supreme Court ignored whether software APIs are copyrightable and instead performed a fair use test. Oracle's Java APIs remain under copyright, but Google's use of the APIs were fair use.
- bdowling 2y ago
  I rephrased the question. The instruction set may be copyrightable, but as in Google v. Oracle, we don't have to answer that question. Even if an instruction set is copyrightable, then under Google, it is probably fair use to copy it for interoperability purposes (e.g., making a compatible processor or emulator). For the actual binary encoding of instructions, there is even less of an argument for copyright protection because the encoding is purely functional.
  - layer8 2y ago
    It’s certainly (?) legal to implement an emulator for a given instruction set. I’m not sure how implementing a CPU in hardware would be different. What clearly is subject to copyright is the documentation describing the instruction set and its semantics.
  - deleted 2y ago
    [deleted]
LegionMammal978 2y ago
Google v. Oracle was not about interoperability: as the decision presents it, Google copied the APIs for Android specifically because they didn't want false interoperability with desktop Java. Instead, the court found that the use was transformative (bringing Java to a new, distinct platform), insubstantial (the declarations being non-central to the overall implementation), and with little market effect (Sun/Oracle having failed to make its own mobile Java viable). In contrast, reimplementing a copyrighted ISA would quite clearly be substantial and could easily have large market effects. So you'd have to lean heavily into the idea of interoperability to overwhelm the lack of these other factors, or argue that the ISA is not copyrightable per se. Also, even if an ISA isn't copyrightable, you have to watch out for patent rights the owner might have over any part of the ISA.
- wk_end 2y ago
  Just to prod at this a little bit: The vast majority of ARM licensees aren't doing anything transformative, that's for sure. But would something like the M1 - bringing ARM to the desktop when all past attempts have failed - have been considered transformative? The question of what constitutes a "large market effect" is a big one...if I make a chip to serve as a controller in my brand of hard drives, is that a large market effect? ARM loses out on a few pennies per drive or something. And I'd dispute the characterization of micro-architecture design as "insubstantial". Not accusing you of this, but this really has been the most frustrating thing about RISC-V - software engineers who don't know anything about CPU design comparing it to Linux when really it's more like POSIX or, yes, the Java class library. The insides of microcomputer CPUs haven't really resembled their interfaces very much since the early 80s - even the 68000, a consumer-grade CPU that's 45 years old (!) was designed so that the microcode engine that drove it could be used to implement an array of instruction sets. Any useful implementation of a CPU has an enormous number of internal details that aren't implied by the ISA.
  - LegionMammal978 2y ago
    > Any useful implementation of a CPU has an enormous number of internal details that aren't implied by the ISA. If anything, I'd say that it's precisely because of this independence that an ISA can be seen as a separate work from any of its existing implementations. So what I'm trying to get at, is that if an ISA is copyrightable at all, in whole or in part, then any complete re-implementation will be copying most of the ISA's own substance, regardless of differing internal details. (Where by 'ISA' I specifically mean the external interface that software can access.)
dbcurtis 2y ago
The case Amdahl brought against IBM tackles this question directly. It may have settled, though. (I was a CPU logic designer at Amdahl for a while. Some people had access to info from IBM under the terms of the settlement. They could read and make plans. Then one day they could walk down the hall and tell me about new tasks on my to-do list. )
bitwize 2y ago
You can patent an ISA. And then everyone who implements that ISA, in hardware or emulation, is infringing. Intel actually threatened lawsuits against Microsoft for implementing emulation of recent x86 instructions on ARM Windows.
- eschaton 2y ago
  You cannot patent an instruction set architecture, but you can patent mechanisms used in the implementation of the instruction set architecture. This is an extremely important distinction. Usually these patents are written such that it’s difficult or impossible to implement the covered portions of the instruction set without violating the patent, but that’s by no means guaranteed.
- kragen 2y ago
  arm thumb-2 is over 20 years old now, so any patents that cover necessary techniques to implement it are expired by now (unless they are lemelson-style submarine patents from much longer ago that issued very recently)
- neonsunset 2y ago
  Do you have a link covering that? AFAIK anything up to SSE4.2 was effectively public domain and AVX2 has recently joined that.
eschaton 2y ago
It would in light of decades of case law prior to Google v. Oracle. An instruction set itself is not protectable IP, only descriptions and implementations are. What restricts new implementations are: 1. Existing legal agreements, eg if you agree in a contract that you will treat an instruction set as protectable IP, you’d be violating the contract. (Assuming the contract is valid.) 2. Patents, if you need to violate a patent to implement an instruction set then you need to license or wait out the patent, or figure out a way to work around it. I believe both of these were at issue in Intel v. AMD, since AMD was initially a licensed second source, and Intel thought you couldn’t implement the Pentium instruction set without violating its patents.
- pjmlp 2y ago
  Which in the end is what allowed AMD to come up with AMD64 and torpedo Intanium efforts.

hn_acker 2y ago

Most likely yes. In Google v. Oracle, the Supreme Court ignored whether software APIs are copyrightable and instead performed a fair use test. Oracle's Java APIs remain under copyright, but Google's use of the APIs were fair use.

bdowling 2y ago
I rephrased the question. The instruction set may be copyrightable, but as in Google v. Oracle, we don't have to answer that question. Even if an instruction set is copyrightable, then under Google, it is probably fair use to copy it for interoperability purposes (e.g., making a compatible processor or emulator). For the actual binary encoding of instructions, there is even less of an argument for copyright protection because the encoding is purely functional.
- layer8 2y ago
  It’s certainly (?) legal to implement an emulator for a given instruction set. I’m not sure how implementing a CPU in hardware would be different. What clearly is subject to copyright is the documentation describing the instruction set and its semantics.
- deleted 2y ago
  [deleted]

LegionMammal978 2y ago

Google v. Oracle was not about interoperability: as the decision presents it, Google copied the APIs for Android specifically because they didn't want false interoperability with desktop Java. Instead, the court found that the use was transformative (bringing Java to a new, distinct platform), insubstantial (the declarations being non-central to the overall implementation), and with little market effect (Sun/Oracle having failed to make its own mobile Java viable). In contrast, reimplementing a copyrighted ISA would quite clearly be substantial and could easily have large market effects. So you'd have to lean heavily into the idea of interoperability to overwhelm the lack of these other factors, or argue that the ISA is not copyrightable per se. Also, even if an ISA isn't copyrightable, you have to watch out for patent rights the owner might have over any part of the ISA.

wk_end 2y ago
Just to prod at this a little bit: The vast majority of ARM licensees aren't doing anything transformative, that's for sure. But would something like the M1 - bringing ARM to the desktop when all past attempts have failed - have been considered transformative? The question of what constitutes a "large market effect" is a big one...if I make a chip to serve as a controller in my brand of hard drives, is that a large market effect? ARM loses out on a few pennies per drive or something. And I'd dispute the characterization of micro-architecture design as "insubstantial". Not accusing you of this, but this really has been the most frustrating thing about RISC-V - software engineers who don't know anything about CPU design comparing it to Linux when really it's more like POSIX or, yes, the Java class library. The insides of microcomputer CPUs haven't really resembled their interfaces very much since the early 80s - even the 68000, a consumer-grade CPU that's 45 years old (!) was designed so that the microcode engine that drove it could be used to implement an array of instruction sets. Any useful implementation of a CPU has an enormous number of internal details that aren't implied by the ISA.
- LegionMammal978 2y ago
  > Any useful implementation of a CPU has an enormous number of internal details that aren't implied by the ISA. If anything, I'd say that it's precisely because of this independence that an ISA can be seen as a separate work from any of its existing implementations. So what I'm trying to get at, is that if an ISA is copyrightable at all, in whole or in part, then any complete re-implementation will be copying most of the ISA's own substance, regardless of differing internal details. (Where by 'ISA' I specifically mean the external interface that software can access.)

dbcurtis 2y ago

The case Amdahl brought against IBM tackles this question directly. It may have settled, though. (I was a CPU logic designer at Amdahl for a while. Some people had access to info from IBM under the terms of the settlement. They could read and make plans. Then one day they could walk down the hall and tell me about new tasks on my to-do list. )

bitwize 2y ago

You can patent an ISA. And then everyone who implements that ISA, in hardware or emulation, is infringing. Intel actually threatened lawsuits against Microsoft for implementing emulation of recent x86 instructions on ARM Windows.

eschaton 2y ago
You cannot patent an instruction set architecture, but you can patent mechanisms used in the implementation of the instruction set architecture. This is an extremely important distinction. Usually these patents are written such that it’s difficult or impossible to implement the covered portions of the instruction set without violating the patent, but that’s by no means guaranteed.
kragen 2y ago
arm thumb-2 is over 20 years old now, so any patents that cover necessary techniques to implement it are expired by now (unless they are lemelson-style submarine patents from much longer ago that issued very recently)
neonsunset 2y ago
Do you have a link covering that? AFAIK anything up to SSE4.2 was effectively public domain and AVX2 has recently joined that.

eschaton 2y ago

It would in light of decades of case law prior to Google v. Oracle. An instruction set itself is not protectable IP, only descriptions and implementations are. What restricts new implementations are: 1. Existing legal agreements, eg if you agree in a contract that you will treat an instruction set as protectable IP, you’d be violating the contract. (Assuming the contract is valid.) 2. Patents, if you need to violate a patent to implement an instruction set then you need to license or wait out the patent, or figure out a way to work around it. I believe both of these were at issue in Intel v. AMD, since AMD was initially a licensed second source, and Intel thought you couldn’t implement the Pentium instruction set without violating its patents.

pjmlp 2y ago
Which in the end is what allowed AMD to come up with AMD64 and torpedo Intanium efforts.