Nvidia CUDA 的 EULA 禁止跑在模擬層上面

Hacker News 上看到「Nvidia bans using translation layers for CUDA software to run on other chips (tomshardware.com)」這個討論串,原報導「Nvidia bans using translation layers for CUDA software — previously the prohibition was only listed in the online EULA, now included in installed files」。

文章最上面更新的這段把重點講完了,在 11.6 之後的版本就有加入這段文字了:

[Edit 3/4/24 11:30am PT: Clarified article to reflect that this clause is available on the online listing of Nvidia's EULA, but has not been in the EULA text file included in the downloaded software. The warning text was added to 11.6 and newer versions of the installed CUDA documentation.]

主要是這條:

You may not reverse engineer, decompile or disassemble any portion of the output generated using SDK elements for the purpose of translating such output artifacts to target a non-NVIDIA platform.

從「CUDA Toolkit Archive」這邊可以看到 11.6.0 是 2022 年一月的事情:

CUDA Toolkit 11.6.0 (January 2022), Versioned Online Documentation

看起來跟 ZLUDA 有關 (參考「IntelAMD GPU 直接跑 CUDA 程式的 ZLUDA」)。

時間軸看起來有對起來,2021 年的時候被 Intel 找去聊,2022 年的時候改跟 AMD 簽約,然後 AMD 後來也放掉:

In 2021 I was contacted by Intel about the development of ZLUDA. I was an Intel employee at the time. While we were building a case for ZLUDA internally, I was asked for a far-reaching discretion: not to advertise the fact that Intel was evaluating ZLUDA and definitely not to make any commits to the public ZLUDA repo. After some deliberation, Intel decided that there is no business case for running CUDA applications on Intel GPUs.

Shortly thereafter I got in contact with AMD and in early 2022 I have left Intel and signed a ZLUDA development contract with AMD. Once again I was asked for a far-reaching discretion: not to advertise the fact that AMD is evaluating ZLUDA and definitely not to make any commits to the public ZLUDA repo. After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs.

Rocky Linux 提出兩個方法取得 RHEL 的 source code

在「AlmaLinux 與 Rocky Linux 看起來都暫時無解」這邊提到了檯面上目前沒有好方法穩定取得 source code 後,Rocky Linux 提出了兩個方法,在不需要同意 RHEL 的條款下取得 RHEL 的 source code:「Keeping Open Source Open」。

中間還有一些小插曲可以提一下,在社群不少抗議聲後,IBM & Red Hat 的 VP 出來直接說他們認為 RHEL rebuild 沒有任何價值,而且是故意讓 rebuilder 更難實作 RHEL rebuild:「Red Hat’s commitment to open source: A response to the git.centos.org changes」。

Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make.

回到 Rocky Linux 的文章,他們提出來的兩個方法都是基於 GPL 的重要性質:如果你可以合法拿到 binary,那麼散佈者就有義務要提供 source code。

第一個方法是透過 RHEL 目前公開提供的 container image:

One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.

另外一種方式是透過雲端服務的 cloud instance 跑 RHEL:

Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.

這兩個方法都不需要同意 RHEL 目前在網站上的 TOS 與 EULA,而且短時間內應該不好防堵:前者要關掉的話,應該有一堆既有 RHEL 客戶在用會直接抱怨,真的要硬幹的話得給這些客戶時間從 public repository 轉移到要認證的 repository 上;而後者要堵的話,除非 IBM & Red Hat 決定直接不做雲端生意?

看起來 Rocky Linux 與 AlmaLinux 用這套方法可以撐一陣子,直到 IBM & Red Hat 想出新方法來搞?

AlmaLinux 與 Rocky Linux 看起來都暫時無解

昨天提到的「IBM 決定停止公開發布 RHEL 的 source code」有了另外一邊的說明了:

如同 AlmaLinux 所說的,重新散佈程式碼是受限的:

Unfortunately the way we understand it today, Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.

所以目前 AlmaLinux 的意思是沒有什麼好解法,而 Rocky Linux 的公告文章只有幹話,沒有實質內容。

但我猜既有的客戶裡面有不受這個條款影響的族群,像是直接跟 IBM 談授權合約的公司,有可能會有排除單方面修改授權的條款,這個應該會是目前 RHEL 8/9 的破口,但後續再釋出的版本應該會被 IBM 的法務給補上?

EULA 不能禁止使用者 decompile 修 bug

Hacker News Daily 上翻到的,歐洲法院認為 EULA 不能禁止使用者 decompile 修 bug:「EU court rules no EULA can forbid decompilation, if you want to fix a bug (europa.eu)」,官方的英文版文件在這邊可以翻到,不過原始判決是法文:

* Language of the case: French.

這是 Top System SA 與比利時政府打的訴訟,法院認為修 bug 而需要 decompile 這件事情是合法的,即使考慮到 Article 6 的規範:

In the light of the foregoing considerations, the answer to the first question referred is that Article 5(1) of Directive 91/250 must be interpreted as meaning that the lawful purchaser of a computer program is entitled to decompile all or part of that program in order to correct errors affecting its operation, including where the correction consists in disabling a function that is affecting the proper operation of the application of which that program forms a part.

In the light of the foregoing considerations, the answer to the second question referred is that Article 5(1) of Directive 91/250 must be interpreted as meaning that the lawful purchaser of a computer program who wishes to decompile that program in order to correct errors affecting the operation thereof is not required to satisfy the requirements laid down in Article 6 of that directive. However, that purchaser is entitled to carry out such a decompilation only to the extent necessary to effect that correction and in compliance, where appropriate, with the conditions laid down in the contract with the holder of the copyright in that program.

案子看起來應該還有得打?看起來好像不是最終判決...

REQUEST for a preliminary ruling under Article 267 TFEU from the Cour d’appel de Bruxelles (Court of Appeal, Brussels, Belgium), made by decision of 20 December 2019, received at the Court on 14 January 2020[.]

但不管怎樣,算是有些東西出來了... 然後 Hacker News 上面的討論就看到一些很歡樂的例子:

This becomes incredibly interesting in terms of e.g. Denuvo. This anti-piracy middleware has been shown to make games unplayable, and this EU law seems to support removing it.

哭啊怎麼提到該死的 Denuvo XDDD

原來 Oracle 與 Microsoft 裡的條款是這樣來的...

看到「That time Larry Ellison allegedly tried to have a professor fired for benchmarking Oracle」這篇文章的講古,想起很久前就有聽過 Microsoft 有這樣的條款 (禁止未經原廠同意公開 benchmark 結果),原來是 Oracle 在三十幾年前創出來的?而且這種條款還有專有名詞「DeWitt Clauses」,出自當初被搞的教授 David DeWitt...

Microsoft 的條款是這樣:

You may not disclose the results of any benchmark test … without Microsoft’s prior written approval

Oracle 的則是:

You may not disclose results of any Program benchmark tests without Oracle’s prior consent

IBM 的反而在 license 裡面直接允許:

Licensee may disclose the results of any benchmark test of the Program or its subcomponents to any third party provided that Licensee (A) publicly discloses the complete methodology used in the benchmark test (for example, hardware and software setup, installation procedure and configuration files), (B) performs Licensee’s benchmark testing running the Program in its Specified Operating Environment using the latest applicable updates, patches and fixes available for the Program from IBM or third parties that provide IBM products (“Third Parties”), and © follows any and all performance tuning and “best practices” guidance available in the Program’s documentation and on IBM’s support web sites for the Program…

OS X El Capitan (10.11) 軟體授權文件的白話翻譯

有人把 OS X El Capitan 的軟體授權文件翻譯成白話的 22 條英文說明:「OS X El Capitan License: in Plain English」,也就是這份文件:

其實有不少有趣 (?) 的設計...

Ptt 新版使用者條款的問題...

剛剛登入發現需要同意新版條款 (2.0),但有條文有問題啊...

1-2 的部份:

任何資料一經您上載、傳送、輸入或提供至本站時,除私人信件外,視為您已同意本站為非營利之無償使用、修改、重製、公開播送、散布、發行、公開發表該等資料,並得將前述權利在保留原作者資訊前提下,轉授權為非營利之使用(轉授權部分本站將列舉轉授權之網站並公告於本站 Announce 板,非本站或本站轉授權之網站未經同意使用您之資料,仍為侵權)。您並應保證本站使用、修改、重製、公開播送、散布、發行、公開發表、轉授權該等資料,不致侵害任何第三人之權利,否則應對本站負損害賠償責任(包括但不限於訴訟費用及律師費用等)。

以下資料在本次條文修正時表示站方可以將以下資料公開散佈:

  • 個人訊息 (水球紀錄)
  • 個人資料 (因為是你在註冊時輸入進去的)

後者由於受到「個人資料保護法」的法律保護,這項條文在碰觸這塊時會有很多可以防禦的方法。但前者明顯是漏洞...

然後我以為官方站名中的「BBS」這個詞彙應該大寫?不知道會不會出 2.0.1...