What's the difference between this and Wine/Proton? I guess Microsoft EULA has similar conditions, if they were enforceable wouldn't Microsoft do the same and send a C&D to Wine devs?
This isn't NV saying "you can't make ZLUDA," it's NV saying "you can't run our libraries like cuDNN, cuBLAS, cuBN on non-NV hardware."
While this kind of restriction still isn't legally cut and dry, it does come with tons of precedent, from IBM banning the use of their mainframe OSes in emulation to Apple only licensing OSX for use on Apple hardware.
> from IBM banning the use of their mainframe OSes in emulation
I don’t think they would have tried that in the 1970s, when there was an antitrust suit against them for disallowing running their software on plug compatible (https://en.wikipedia.org/wiki/Plug_compatible) mainframes.
That (I think) made IBM offer reasonable licensing terms for their software (https://en.wikipedia.org/wiki/Amdahl_Corporation#Company_ori...: “Amdahl owed some of its success to antitrust settlements between IBM and the U.S. Department of Justice, which ensured that Amdahl's customers could license IBM's mainframe software under reasonable terms.”)
That case eventually got dropped in 1982, so it didn’t lead to any jurisprudence as to if/when such restrictions are permitted.
(Aside: for a case that ran for over a decade and produced over 30 million pages (https://www.historyofinformation.com/detail.php?id=923), I find it strange this case doesn’t seem to have made it to Wikipedia yet, and how little there’s elsewhere. Nice example of how bad the public digital record is)
I think this is a more nuanced point that just running "CUDA software" which is what's been commonly discussed. Nvidia is licensing their shared libraries in such a way that you can only run then on their hardware.
It's notable however, that both of the examples you give are for Operating Systems, rather than a library which is part of a larger work. Do you know of an example of a single application or library being hardware locked? the only instance I can think of off the top of my head are the old Dos versions of Autocad which had a physical dongle. But even that was DRM and not just an EULA restriction.
Actually, that might be an interesting direction for them to go. Include some key in Nvidia hardware which the library validates. Then they'd get DMCA protection for their DRM.
Hardware-dongle DRM was the default licensing model in the 90s for any kind of enterprise-type software.
Pretty much all audio and video production and editing software for many years, and even today. C compilers, for many years, as well. PhysX for awhile. Native Instruments stuff. Saleae logic analyzer software.
Another message in this thread reminded me, too, of the Google Play frameworks on Android, which are also a very good analogy - Google ship these libraries licensed for use only on approved phones.
> old Dos versions of Autocad which had a physical dongle.
Those didn't go away in the industry, though AutoCAD moved away from them. Resolume (professional VJ software) and Avid (professional video editing software) still have hardware dongles. Arguably so does Davinci, theirs are just much bigger ;). progeCAD (AutoCAD compatible CAD program) also has USB protection dongles available as a license option.
It's actually NVIDIA saying you can't reverse engineer anything you build using CUDA SDK in order to run it on another platform. If someone else built it with the SDK and you have never downloaded the SDK yourself then you would not be bound by this agreement. I don't think you could get the cublas etc libraries without agreeing to the EULA so it includes what you are saying, but also includes apps or libraries you build yourself using the SDK.
"You may not reverse engineer, decompile or disassemble any portion of the output generated using SDK elements fo the purpose of translating such output artifacts to target a non-NVIDIA platform."
> from IBM banning the use of their mainframe OSes in emulation
It doesn't change your point (which is that it appears de facto legally established that IBM can do this), but IBM doesn't completely ban the use of their mainframe OSes in emulation. They are totally okay with people running them in their own emulators (zPDT and ZDT); the thing they won't authorise is people running them on the open source Hercules emulator, since their own emulators cost $$$$, and Hercules is free, and it appears they view the $0 of Hercules as a threat to the $$$$ of their mainframe ecosystem.
In the past they've even authorised third party commercial emulators, such as FLEX-ES. At some point they stopped allowing FLEX-ES for new customers, although I believe some customers who bought licenses when it was allowed are still licensed to use it. But, it isn't impossible they might authorise a third party commercial emulator again – make it expensive, non-open source, and make it only run on IBM hardware (such as POWER Systems), and there's a chance IBM might go along with it.
> On November 13, 2009, the court granted Apple's motion for summary judgement and found Apple's copyrights were violated as well as the Digital Millennium Copyright Act (DMCA) when Psystar installed Apple's operating system on non-Apple computers.
Besides the copyright violation, it is very important to note that the court also considered that circumventing the hardware checks were a violation of the DMCA and illegal in and of itself.
Apple doesn't do anything about the hackintosh ""community"" because they simply don't care about a bunch of random nerds in their basement running macOS but the moment a corporation starts using it to replace their macs you can bet they're going to be sued to oblivion. Not that it would ever happen, hackintosh are going to prove a complete dead end once Apple drops support for x86.
We live in a post-DMCA world. This isn't the era that allowed Bleem to win against Sony, and this is the era that saw the switch emulator developers shit their pants and promise millions to Nintendo in a settlement because they were very unconfident in the possibility of winning in a trial. NVIDIA, for better or worse, has a strong legal standing to clamp down on people who think it would be funny to run their libraries on non-NVIDIA hardware. Do it in your basement if you will, but don't try to push this in a data center.
EULA permits the companies to have grounds to take someone to court. Their choice to prosecute. It's a reserved right more so than one that they use 100%.
In this case translating CUDA can allow AMD to chip away at NVidia's market share.
Nvidia cares about the people reverse-engineering CUDA, who don't have anything to reverse-engineer unless they actually download the SDK. Of course, when you download the SDK it has an associated license.
It's also possible to do a clean-room reverse where one group tests the hardware and software and writes specifications and another group who has never seen the hardware or docs then does the implementation. This has been legally tested and protected going back to at least the early 1980s.
It is possible, but a) it is expensive as hell to get enough engineers whom you can prove in court have no exposure to the original software (most SWE's would get some exposure just naturally in college nowadays, leave alone at any sort of job) and b) CUDA is constantly changing and updating and so you need to have this expensive clean-room process going constantly or else you will fall behind.
The most famous case of clean-room reverse engineering is for the original BIOS chips back in the early 1980's, where the chips themselves couldn't change- they were hardware! It's going to be orders of magnitude more difficult to do that for software packages that change regularly.
I disagree on Cuda changing constantly. The hardware is stable once sold and new devices are usually backwards compatible by at least a version or two. The API is also locked down for already deployed versions, can't go pulling the rug from paying customers. However, new versions of both hardware and Cuda do introduce new things that'll need addressed. I don't think it's much of a moving target though.
