Sentry 的 License 不是 Open Source License...

前一篇「Sentry 的替代品:GlitchTip」我自己提到:

Sentry 本身已經是 open source software 了

結果在 HN 上面馬上就看到討論:「Sentry: From the Beginning (」,其中 id=38097463 這邊提到:

The article doesn't appear to mention that Sentry abandoned open source.

LICENSE 這個檔案的記錄 History for LICENSE 裡慢慢翻,可以翻到 Apache License, Version 2.0 是在 2589cbef43659151e70fd3d20eb8b34d7f1f574f (2019/06/11) 這邊加進去的,而變成 BSL 是在 e2b7c743af70e192588d843512412e653eddab17 (2019/11/07) 這邊發生的,另外也有對應的 blog 文章:「Re-Licensing Sentry」。

原來 OSI 有寫過 LLaMA 的 license 不是 open source license 的宣告

MetaLLaMA 宣稱是「The next generation of our open source large language model」,而 OSI 很早就有發文駁斥:「Meta’s LLaMa 2 license is not Open Source」。

在 OSI 的網站上可以看到「The Open Source Definition」,其中這條:

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

open source 不能限制使用,而 LLaMA 的授權限制了商業使用:

2. Additional Commercial Terms. If, on the Llama 2 version release date, the monthly active users of the products or services made available by or for Licensee, or Licensee’s affiliates, is greater than 700 million monthly active users in the preceding calendar month, you must request a license from Meta, which Meta may grant to you in its sole discretion, and you are not authorized to exercise any of the rights under this Agreement unless or until Meta otherwise expressly grants you such rights.

前幾天翻車的 CKIP-Llama-2-7b 目前都已經下架了,但可以在 Archive Today 的「CKIP Llama 2 7b Chat - a Hugging Face Space by ckiplab」看到存檔頁面,以及在 Internet Archive 上的「GitHub - ckiplab/CKIP-Llama-2-7b: CKIP Traditional Chinese Llama-2」看到 GitHub 當時的頁面。

當時看到 CKIP-Llama-2-7b 宣稱用 Apache License, Version 2.0 放出來,我就「蛤?」了出來...


OpenSSL 1.1.1 EoL

看到 OpenSSL 官方的公告,1.1.1 版 EoL:「OpenSSL 1.1.1 End of Life」(btw,我不知道他們為什麼網址上會放兩個 /blog/...)。

OpenSSL 1.x 與 3.x 最大的差異就是他的 license 了,1.x 版是 dual license,但這兩個 license 都與 GPL 不相容:

OpenSSL was dual-licensed under the OpenSSL License and the SSLeay License, which means that the terms of either licenses can be used. The OpenSSL License is Apache License 1.0 and SSLeay License bears some similarity to a 4-clause BSD License.

As the OpenSSL License was Apache License 1.0, but not Apache License 2.0, it requires the phrase "this product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit" to appear in advertising material and any redistributions (Sections 3 and 6 of the OpenSSL License). Due to this restriction, the OpenSSL License and the Apache License 1.0 are incompatible with the GNU GPL.

後續 3.x 的版本則改成 Apache License 2.0 了:

OpenSSL announced in August 2015 that it would require most contributors to sign a Contributor License Agreement (CLA), and that OpenSSL would eventually be relicensed under the terms of Apache License 2.0.

不過 Apache License 2.0 與 GPLv2 還是不相容 (但相容於 GPLv3),這個更換只是換成一個比較常見的 license:

The Free Software Foundation considers all versions of the Apache License to be incompatible with the previous GPL versions 1 and 2.

話說 Ubuntu 20.04 內的 OpenSSL 是 1.1.1f,看起來光是標準的 LTS (到 2025/04) 期間都得自己維護了?其他作業系統應該也會有類似的問題...

不是 open source license 的 Falcon 180B 釋出

看到「Spread Your Wings: Falcon 180B is here」這個,Falcon 180B 釋出,號稱跟 LLaMA 2 站在同一個平台上,但目前看到的授權不是 open source license,大概就是留個記錄下來,實際上應該就不會去碰...

關於 license 的討論在 Hacker News 上有不少,可以參考:「Falcon 180B (」。

OpenTF 開張

前陣子有提到因為 HashiCorp 沒有正面回應 (如預期的) 授權的爭議,所以決定將最後一個 open source 版本的 Terraform 給 fork 出來:「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」。

剛剛在 Hacker News 上看到「OpenTF repository is now public (」這個,OpenTF 正式開張了。

瞄了一下 issues,初期還有蠻多雜事得處理的,但跨出第一步了,可以看看社群的能量到底有沒有超過 HashiCorp 自家的能量...

OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來

先前在「HashiCorp 將放棄 Open Source License,改採用 BSL 1.1」這邊提到的,HashiCorp 決定將所有產品線從現有的 open source license 換成非開源的 BSL 1.1 後,OpenTF 先丟出了「呼籲」希望 HashiCorp 可以撤回這個決定:「The OpenTF Manifesto」。

想當然的,HashiCorp 沒有回應,所以 OpenTF 宣佈了要把 Terraform 的最後一個 open source 版本 fork 出來:「OpenTF Announces Fork of Terraform」。

有幾個比較重要的資訊,第一個是申請 Linux Foundation 資格,希望成為 CNCF 的一環:

We completed all documents required for OpenTF to become part of the Linux Foundation with the end goal of having OpenTF as part of Cloud Native Computing Foundation.

另外一個是首頁上的 Co-signed 的部分,翻了一下有三家公司 (Spacelift、env0、Scalr) 有提出支援五年五位的 Full time engineer 的經費 (Cover the cost of 5 FTEs for at least 5 years),另外一家公司 (Sailorcloud) 則是提出支援兩年一位的經費 (Cover the cost of 1 FTE for at least 2 years)。


llama.cpp 官方支援 Falcon

先前有提過採用 Apache License 2.0Falcon 40B,少數能跟 LLaMA (第一代) 打對台的版本,而且是真正的 open source license:「Falcon 40B 超越 LLaMA 65B 成為目前 Open LLM 的領頭」,當時有提到 llama.cpp 還沒有支援。

過了一陣子,社群自己先 fork 了一版,想辦法支援 Falcon 40B:「cmp-nct/ggllm.cpp」,但這也導致沒有跟到很多 llama.cpp 的新功能 (尤其是各種透過硬體加速的支援)。

剛剛刷了一下,發現前幾天 llama.cpp 官方支援 Falcon 的 model 了:「llm : add Falcon support」。


日本 LINE 推出的 LLM (以日語材料訓練)

看到「36億パラメータの日本語言語モデルを公開しました」這篇,日本的 LINE 丟出 Apache License 2.0 的 LLM,拿起來跑看看還蠻有趣的:

他的特點是用日語資料訓練出來的 LLM:


我拿 1.7B 跑,小修改一下故意給英文的 prompt 後,可以看到輸出頗有趣的,畢竟是從日文資料訓練出來的:

{'generated_text': 'An apple a day keeps the doctor away.\n「一日リンゴ1個」は apple days で'}
{'generated_text': 'An apple a day keeps the doctor away thinking happier. The biggest happ'}
{'generated_text': 'An apple a day keeps the doctor away from here.」と英語で訳しましょう。「I have a dream'}
{'generated_text': 'An apple a day keeps the doctor away(sometimes usually thinks far a'}
{'generated_text': 'An apple a day keeps the doctor away. 日はまたのぼり、 医者は去って行った。 They'}
{'generated_text': 'An apple a day keeps the doctor away thought about being in the center of the'}
{'generated_text': 'An apple a day keeps the doctor away from all the time.\n16. I feel like'}
{'generated_text': 'An apple a day keeps the doctor away and draws and eats around one table'}
{'generated_text': 'An apple a day keeps the doctor away from your mother\nAnd another male you are'}
{'generated_text': "An apple a day keeps the doctor away. What's the opinion you wrote in"}

這邊有訓練的運算量計算,1.7B 的 model 訓練換成起來會用道 4000 小時的 A100 80GB (假設你有 100 張的話,就是 40 小時):

本モデルの構築に要した時間について、例えば1.7BモデルについてはA100 80GBで換算し、約4000GPU時間を費やしています。学習時間は特に日本語の大規模言語モデルの学習では公開されていないことが多く、適切な比較はできませんが、例えば rinna 0.3Bモデルの学習はV100 32GBで約8600GPU時間を費やしているようで、費やした時間に比して効率の良い学習が行えていると考えられます。

目前是提到有計畫要放出 instruction tuning 的版本:

また、これらのモデルについて、指示文に対して適切な出力を行えるようにチューニング(Instruction tuning)したモデルを近日中に公開予定です。続報は@LINE_DEVをフォローしてお待ち下さい。

這個 LLM 先記起來,以後也許在其他場景有機會用到?

HashiCorp 將放棄 Open Source License,改採用 BSL 1.1

早上發佈的大新聞,HashiCorp 將放棄本來的 Open-source license (MPL-2.0),改用 BSL 1.1:「HashiCorp adopts Business Source License」,Hacker News 上的討論也可以參考:「HashiCorp Adopts Business Source License (」。

看了一下產品線,最成功的應該是 Terraform 這條,其他也有些人會用,但大多都有替代品。

這些軟體可以預期都會有 fork,但後續的開發能量還會有多少就不知道了...

另外前陣子有測過一次 Pulumi,但整體的體驗很差,也許再看看其他的方案?

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