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 想出新方法來搞?

IBM 決定停止公開發布 RHEL 的 source code

Hacker News 首頁上看到的新聞,IBM 決定停止公開發布 RHEL 的 source code:「Red Hat cutting back RHEL source availability」,原始的文章在「Furthering the evolution of CentOS Stream」這邊。

可以猜測這與 Rocky LinuxAlmaLinux 有關。

有購買 RHEL 的人 (取得 binary 的人) 可以在 Red Hat Customer Portal 上取得 source code,這部份應該是遵守 GPL 的關係。

但不確定後續 Rocky Linux 與 AlmaLinux 會怎麼處理,看了看 GPLv2 裡面的條文,不是很確定是否可以限制散佈 source code 的行為...

Brendan Gregg 遇到的 An Unbelievable Demo

Hacker News Daily 上看到的熱門話題,Brendan Gregg 是效能分析領域的大老,現在在 Netflix 工作,在維基百科的條目「Brendan Gregg」上也有提到他的一些知名發明,像是 Flame Graphs:

He has also created visualization types to aid performance analysis, including latency heat maps, utilization heat maps, subsecond offset heat maps, and flame graphs.

昨天他發了一篇文章在講之間他遇到的事情,原文把過程寫的很有戲劇性,值得去看一看:「An Unbelievable Demo」,而 Hacker News 上的討論也很精彩:「An Unbelievable Demo (brendangregg.com)」,還引出了 Colin Percival 也分享他的經驗。

快速講 Brendan Gregg 遇到的事情,2005 年時 Brendan Gregg 因為業務上的需要 (他當年是效能分析的顧問),幫 Sun 推出的 DTrace 寫了一包工具,叫做 DTraceToolkit,用 GPLv2 或是 CDDL 釋出。

這包工具被 Sun 的人拿去用,並且拔掉作者與授權資訊,然後還被拿去「世界巡迴」介紹這個工具,最後在雪梨的時候居然是拿來介紹給 Brendan Gregg,然後被原作者打臉。

不過他後來還是加入了 Sun... XDDD

Colin Percival 的故事則沒有牽扯到 copyright issue,不過也很有趣,這邊提到的是 bsdiff,也是個經典的工具:

Reminds me of when Apple started providing "smaller size updates" to OS X. I was curious about the details since my doctorate had touched on the topic, so I worked my contacts (I had a few in Apple engineering from the FreeBSD / OS X relationship) and after a few months I got back as answer: "We're using a tool called bsdiff, are you familiar with it?" I was indeed, since I was the author of said tool.

(Just to be clear, there was no license violation involved in this case; just a lack of awareness of the provenance of the open source software they were using.)

另外在其他的 thread 裡面,可以看到 Brendan Gregg 也有浮上來回應 (可以直接字串搜尋 brendangregg),裡面也提到了有趣的故事,像是他另外一個發明 latency heat map 在一些會場上的交流,以及自己也有遇到其他工具的作者:

Thanks. There was a time when many observability products were adding latency heat maps, and at one conference expo floor there were three companies with latency heat maps on their screen at the same time, pitching them as a flagship feature. If I walked near them they'd start trying to explain them to me, and I never figured out an appropriate response. If I said "hey, great to see you added them, I invented these back at Sun" I'd get funny looks.

I think it's a small world, and everything is software, so the chance you'll bump into someone who wrote software you are using I think is pretty high. I was once trying to get my head around Andi Kleen's pmu-tools, and I had the github repo open in my browser on my laptop I was carrying, when the guy sitting next to me on a bus says he's Andi Kleen. (Ok, it was a bus taking Linux conference attendees to an event, not a random bus, but I still found it remarkable timing -- I was studying pmu-tools at that exact time!)

拿來配啤酒的文章 XD

Firefox 引入 BigInt,Safari 也在實作...

Firefox 實作了 BigInt (進度可以在「Implementation of BigInt values for SpiderMonkey」這邊看到):「bigint shipping in firefox!」,現在可以在 68 beta 版裡使用:

I am delighted to share with folks the results of a project I have been helping out on for the last few months: implementation of "BigInt" in Firefox, which is finally shipping in Firefox 68 (beta).

另外文中也提到了其他瀏覽器的情況 (再 Can I Use 也可以看到「BigInt」目前的支援情況),用 V8 engine 的都已經支援 (包括 Chrome 與新版的 Edge),而 Safari 也在實作中:

BigInt is also shipping already in V8 and Chrome, and my colleague Caio Lima has an project in progress to implement it in JavaScriptCore / WebKit / Safari. Depending on your target audience, BigInt might be deployable already!

另外一個有趣的事情是 license,其中馬上可以想到的是 GMP,裡面牽扯到 LGPLv3GPLv2 的授權問題:

Since version 6, GMP is distributed under the dual licenses, GNU LGPL v3 and GNU GPL v2. These licenses make the library free to use, share, and improve, and allow you to pass on the result. The GNU licenses give freedoms, but also set firm restrictions on the use with non-free programs.

從說明有提到一些目標,短期可能會用 GMP 以儘快時做出合理的效能版本,長期則是希望用自己的版本:

An important design question is whether to implement the arithmetic operators as native or self-hosted intrinsics, probably using an external library such as GMP in the former case. Using an existing library has the advantage of providing good performance for less initial effort, but a self-hosted library also has advantages, such as greater flexibility in representation, better compiler integration, and simpler integration with the rest of the JS runtime (GC, etc.).

2018 年一月的討論有提到有一包 patch 是使用 GMP 的版本,這樣看起來應該是有解決 license 上的問題...

The current version of the patch uses libgmp for BigInt arithmetic, supports most features from the current proposal, and passes all up-to-date test262 tests for BigInt. Direct compiler support for BigInt has been removed; instead, compilation should fail if a possible BigInt value is encountered.

後續的描述裡面也都有提到 GMP 相關的事情,應該是沒錯...

MySQL 與 GraalVM 的結合...

Twitter 上看到 Oracle 計畫在 MySQL 內包入 GraalVM

這能不能解決 MySQL 的 stored procedure 一直以來都很殘的問題就要多花些時間看看了... 另外 GraalVM 用 GPLv2,但沒有明確的專利授權條款也是大家很在意的問題 (參考 Hacker News 上「GraalVM: Run Programs Faster Anywhere | Hacker News」這邊的討論),因為大家都很清楚,這家公司只要是沒有授權的東西就不要碰...

話說 Percona 都把 PostgreSQL 包進來吃了,來考慮多用用 PostgreSQL 好了... (把 blog 換掉?)

CUPS 從 GPLv2 變成 Apache License, Version 2.0 了

CUPS 是處理印表機的軟體,在 macOS 以及其他各種 Unix-like 環境下都會使用。

在「CUPS relicensed to Apache v2」這邊看到 relicense 的消息,正式的公告則是在「CUPS License Change Coming」這邊可以看到:

Apple is excited to announce that starting with CUPS 2.3 we will be providing CUPS under the terms of the Apache License, Version 2.0.

剛好 GPLv2Apache License, Version 2.0 之間不相容,這樣跳過去算是趣味趣味...

Software Freedom Conservancy 對 Ubuntu 認定 ZFS 相容性的反對意見

在「Ubuntu 搞定 ZFS 授權問題,將直接納入系統中使用」這邊提到了 Canonical 的律師們認為搞定 ZFS 的授權問題。

Software Freedom Conservancy 則是提出反對意見:「GPL Violations Related to Combining ZFS and Linux」。

主要是討論 GPLv2CDDLv1 的感染性相容問題。

我是覺得 Ubuntu 的說法比較合理,但這種事情沒上法院前誰都不知道... (而且第一仗的結果會特別重要)

Ubuntu 搞定 ZFS 授權問題,將直接納入系統中使用

Canonical 的人 (Ubuntu 背後的公司) 跟律師研究後決定採用 .ko 的方式 (就像 nvidia.ko 的方式) 納入 ZFS,讓 Ubuntu 的人可以更方便使用,而不是像現在要另外手動做不少步驟:「ZFS Licensing and Linux」。

依照 Canonical 的研究,CDDL (ZFS) 與 GPLv2 (Linux) 的授權方式不同,所以可以找到方法交叉避開衝突:

While the CDDL and GPLv2 are both "copyleft" licenses, they have different scope. The CDDL applies to all files under the CDDL, while the GPLv2 applies to derivative works.

The CDDL cannot apply to the Linux kernel because zfs.ko is a self-contained file system module -- the kernel itself is quite obviously not a derivative work of this new file system.

And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris. Equivalent exceptions have existed for many years, for various other stand alone, self-contained, non-GPL kernel modules.

至於這種說法是不是成立,至少在還沒上法院認證前也還不知道... 不過看起來 Canonical 是頗有自信,打算將 ZFS 弄進 Ubuntu,上面有不少好用的東西...

GNU GPLv2 的判例

OSNews 上看到 GNU GPLv2 在美國的判例:「The GNU GPL to be tested in court」。

引用的報導在「GPLv2 goes to court: More decisions from the Versata tarpit」這篇,裡面有幾個角色:

  • Ximpleware:撰寫了一套 XML parser,同時以 GPLv2 與商用版權釋出。
  • Versata:在自家產品 DCM software 使用了 Ximpleware 的 XML parser,依照後面的訴訟,看起來是沒有付錢買商用版本。而 DCM software 裡面沒有引用 GPLv2 條款,同時也當然沒有公開程式碼。
  • Ameriprise:付錢給 Versata 購買 DCM software 使用權的公司,另外取得 Versata 的授權,可以找外包商修改 Versata 的 DCM software。
  • Infosys:Ameriprise 的外包商。

起因在於 Versata 不爽 Infosys 拿他們的軟體開發同性質的軟體,結果告下去後這件事情牽扯到 GPLv2 的授權問題。

然後 Ximpleware 也跳出來告了所有人,還因為專利關係,告了 Versata 的其他客戶。

問題分成兩塊討論,一塊是 copyright,另外一塊是 patent。看了一下文章的說明,案子似乎還沒結束,但已經有些結論出來了。

在 copyright 的部份,法院要求明年二月底前必須上 patch 修正問題。也就是 GPLv2 的感染力是有效的,如果你不打算服從就要賠錢,然後把 GPLv2 程式碼拔乾淨。

而 patent 的部份有點複雜啊... Ximpleware 的控訴都不成立,不過理由沒有看懂 @_@

等有更多時間再來看其他的說明研究...