Hacker News Reader

Comment by starspangled | Hacker News Reader

Just the impact of making this move will have a chilling effect, regardless of the long term outome.

ARM Ltd wants to position itself as the ISA. It is highly proprietary of course, but the impression they want to give is that it is "open" and freely available, no lock-in, etc.

This really brings the reality back into focus that ARM controls it with an iron fist, and they're not above playing political games and siding against you if you annoy their favored customers. Really horrible optics for them.

View on HN

"Chilling effect" implies that we should want ARM to succeed.

IMO we need to question the premises of the current IP ecosystem. Obviously, the principles of open-source are quite the opposite to how ARM licenses IP. (Afaik, ARM also licenses ready-to-go cores, which is very different from what Q is getting.)

It's easy to see how RISC-V avoids the conflict of interest between owning the ISA and licensing specific implementations.

> "Chilling effect" implies that we should want ARM to succeed.

It really doesn't.

I agree an actual open ISA is far preferable, ARM is not much different than x86.

> RISC-V

We’d just get a bunch of proprietary cores which might not even be compatible with each other due to extensions. Companies like Qualcomm would have zero incentives to share their designs with anyone.

ARM is not perfect but it at least guarantees some minimal equal playing field.

> Afaik, ARM also licenses ready-to-go cores

Which is the core of Qualcomm’s business. All their phone chips are based on Cortex. Of course ARM has a lot of incentives to keep it that way, hence this while thing.

> We’d just get a bunch of proprietary cores which might not even be compatible with each other due to extensions.

No different than ARM. Apple has matrix extensions that others don't, for example.

The ecosystem (e.g., Linux and OSS) pressure will strongly encourage compatible subsets however. There is some concern about RISCV fragmentation hell that ARM used to suffer from, but a least in the Linux-capable CPU space (e.g., not highly embedded or tiny), a plethora of incompatible cores will probably not happen.

> Companies like Qualcomm would have zero incentives to share their designs with anyone.

ARM cores are also proprietary. All ARM cores actually, you can't get an architectural license from ARM to create an open source core. With RISCV at least you can make open cores and there are some out there.

But opening the ISA is attacking a different level of the stack than the logic and silicon.

> RISCV fragmentation hell that ARM used to suffer from

Does "fragmentation hell" refer to Age Old problem of massive incompatibility in the Linux codebase, or the more "modern" problem people refer to which is the problem of device trees and old kernel support for peripheral drivers? Because you can rest assured that this majestic process will not be changed at all for RISC-V devices. You will still be fed plenty of junkware that will require an unsupported kernels with blobs. The ISA isn't going to change the strategy of the hardware manufacturers.

Neither. It refers to proliferation of incompatible extensions that plagued ARM. Most well known one was hf incompatibility, but there were others too.

> No different than ARM

Everyone has more or less the same access to relatively competitive Cortex and Neoverse cores. As ARM’s finances show that’s not a very good business model so it’s unlikely anyone would do that with RISC-V.

You can make opensource cores, but nobody investing massive amounts of money/resources required to design high end CPUs will make them open source. The situation with ARM is of course not ideal but at least the playing field is somewhat more even.

> Companies like Qualcomm would have zero incentives to share their designs with anyone.

And yet, that's what linux did in 1991- they shared the code, lowering the cost of buying an operating system. I wouldn't say there is zero incentive, but it certainly lowers the incentive without a profitable complementary hardware implementation that can be sold for less than the proprietary isa when there is a royalty free license allows the manufacturer/fab designer "mask rights" to get a small margin within the difference of the foundry/ISA proprietary core competitor.

Hardware is not software. Almost nothing alike. Surr it might happen for low-end/old chips with low margins but nothing cutting edge or competitive on the high-end

software used to be hardware limited, and therefore efficient. Today Software relies on many more transistors per joule to compute a number of operations in high-level languages. I'd agree 22nm isn't leading edge, but foundries like Skywater could theoretically provide more options at 65nm and 90nm in coming years that are fully open source, except for the cost of the foundry technique perhaps: https://riscv.org/wp-content/uploads/2018/07/1130-19.07.18-L...

Yes, I think we might be talking about slightly different things. I don’t really see OS model working for higher-end / leading-edge chips.

In segments where chips are almost an interchangeable commodity and the R&D cost might be insignificant relative to manufacturing/foundry it would make a lot more sense.

> No different than ARM. Apple has matrix extensions that others don't, for example.

Not anymore, M4 supports ARM SME instead.

Even the base integer instructions are Turing complete in RISC-V. Only instruction extensions that could be a point of contention are Matrix operations, as T-Head and Tenstorrent already have their own. Even then, I can't find a reason how this "clash" is any different than those in the x64 or ARM space.

Even if Qualcomm makes their own RISC-V chips that are somehow incompatible with everyone else's, they can't advertise that it's RISC-V due to the branding guidelines. They should know them because they are on the board as a founding top tier member.

> they can't advertise that it's RISC-V due to the branding guidelines

Unless it’s a superset of RISC-V. They can still have proprietary extensions

I don’t understand how they can copyright just the ISA. Didn’t a recent Supreme Court case in oracle v google Java issue decide that you can copy the api if you impelement it differently? So what exactl is arm pulling? Implementation hardware specs? I suspect Qualcomm can do that on its own

I think it might actually be patents rather than copyright restrictions that are in play here.

> Dudn’t a recent Supreme Court case in oracle v google Java issue decide that you can copy the api if you impelement it differently

No, it didn’t. It ruled that the specific copying and use of that Google did with Java in Android was fair use, but did not rule anything as blanket as “you can copy an API as long as you re-implement it”.

It was a little more nuance than that. Oracle was hoping SCOTUS would rule that API Structure, sequence and organization are copyrightable - the court sidestepped that question altogether by ruling that if APIs are copyrightable[1], the case fell under fair use. So the pre-existing case law holds (broadly, it's still fine to re-implement APIs - like s3 - for compatibility since SCOTUS chose not to weigh in on it in Google v. Oracle).

1. Breyer's majority statement presupposes API's are copyrightable, without declaring it or offering any kind of test on whats acceptable.

> So the pre-existing case law holds (broadly, it's still fine to re-implement APIs - like s3 - for compatibility since SCOTUS chose not to weigh in on it in Google v. Oracle).

There is no clear preexisting national case law on API copyrightability, and it is unclear how other, more general, case law would apply to APIs categorically (or even if it would apply a categorical copyrightable-or-not rule), so, no, its not “ok”, its indeterminant.

You are right there is no single national case that clearly ruled in either way, but the status quo is that it's de facto ok. Adjacent case law made white room reverse engineering & API re-implementation "ok" de jure, which is why most storage vendors - including very large ones - are confident enough to implement the S3 protocol without securing a license from Amazon first.

Edit: none of the large companies (except Oracle) are foolish enough to pursue a rule that declares APIs as falling under copyright because they all do it. In Google v. Oracle, Microsoft files briefs support both sides after seemingly changing their mind. In lower courts, they submitted an amicus brief supporting Oracle, then when it got to SCOTUS, they filed one supporting Google, stating how disastrous it would be to the entire industry.

Qualcomm is slightly bigger than ARM so it seems like a fair fight to me. Does Qualcomm police it's IP at all?

> Qualcomm is slightly bigger than ARM so it seems like a fair fight to me.

I'm not really sure what you're responding to. It's got nothing to do with size whether or not something is fair, it's what is in the contract. None of us know exactly what's there so if it becomes disputed then a court is going to have to decide what is fair.

But that was entirely not the point of my comment though. I'm talking about how corporations looking to make chips or get into the ecosystem view ARM and its behavior with its architecture and licensing. ARM Ltd might well be in the right here by the letter of their contracts, but that canceling their customer's license (ostensibly if not actually siding with another customer who is in competition with the first) is just not a good look for positioning they are going for.

You might be right, but they do perhaps also have to establish that their contracts are going to be defended/enforced. Otherwise they have nothing.

Big middle ground before nuclear option of canceling license entirely though. It's a bad look too because Nuvia/QC has bad blood with Apple, and Apple is suspected to be a very favored client for ARM, so ARM has this problem of potentially appearing to be taking Apple's side against Qualcomm.

I'm not saying that's what happened or that ARM did not try to negotiate and QC was being unreasonable and the whole thing has nothing at all to do with Apple, or that ARM had any better options available to them. Could be they were backed into a corner and couldn't do anything else. I don't know. That doesn't mean it's not bad optics for them though.

According to Wikipedia,

Qualcomm has 50,000 employees, $51 billion assets and $35 billion revenue https://en.wikipedia.org/wiki/Qualcomm

ARM Holdings has 7000 employees, $8 billion assets and $3 billion revenue https://en.wikipedia.org/wiki/Arm_Holdings

I think "slightly bigger" is an understatement.

That's roughly the same size -- like swamp thing vs namor -- both are name brand, almost blue chip heros.

Or put another way -- as they said in gawker[1] -- if you're in a lawsuit with a billionaire you better have a billionaire on your side or you're losing.

In this case -- it's unlikely that qualcomm will have quite enough juice to just smoosh Arm, in the same way that they would be able to just smoosh a company that's 100th the size of arm (not just 1/10th), regardless of the merits of the case.

[1]https://gawker.com/how-things-work-1785604699

Does Qualcomm police it's IP at all?

Traditionally they've been known as a tech company that employs more lawyers than engineers, if that tells you anything.

I'd probably go up against IBM or Oracle before I tugged on Qualcomm's cape. Good luck to ARM, they'll need it.

Oracle v Qualcomm would be epic.

The public will likely be the loser of such a battle. :-(

Not if they end up cancelling each other's patents. :)

I am an ex Qualcomm employee. We often called ourselves a law firm with a tech problem. QC doesn't actually have more lawyers than engineers, but I'd not be surprised if the legal department got paid more than all the engineers combined.

Reply on news.ycombinator.com