はてなブックマーク

QEMUプロジェクトは、AIツールによって生成されたコードによる貢献を拒否する方針を正式に取り決めた。その核心的な理由は、貢献者が提出するパッチの正当性を証明するために用いているDeveloper’s Certificate of Origin (DCO) の要件を、AI生成コードが満たせないという懸念である。この問題に対して我々は何をすべきなのだろうか？ English article: https://shujisado.org/2025/07/02/how-can-open-source-projects-accept-ai-generated-code-lessons-from-qemus-ban-policy/ なぜDCOはAI生成コードを拒むのか？ AI生成によるコードがDCOをクリアしにくい理由は二つある。一つは人間による作者性の問題である。DCOの条項は貢献が「自身によって

DeepSeekは世界に衝撃を与えているが、その要因としては、中国から米国の巨大AIベンダーを脅かす新たな勢力が現れたことに加え、AIモデルがMITライセンスというオープンソースライセンスでも頒布されている点が大きいと考えられる。しかし、DeepSeekはモデルこそMITライセンスで公開しているものの、データ処理コードや肝心のトレーニングデータに関する情報は、現時点では何も公開されておらず、詳しい情報も開示されていない。このような経緯から、「DeepSeekはオープンソースとは言えない」とする意見が各所で盛んに主張されており、「果たしてオープンソースと呼ぶために完全なトレーニングデータの公開は必須なのか」という問いへの関心も、ある程度高まっているように思われる。 昨年10月、Open Source Initiative(OSI)は「オープンソースAIの定義」(OSAID: Open Sou

Meta Platforms社のLlamaモデルならびにLlamaライセンス契約(Llama Community License Agreement)がオープンソースに全く該当しないことは既に解説した通りであるが、Llamaライセンス契約にはオープンソースであるか否かという観点において直接的に関係せず、実用に際して予期せぬライセンスの終了にも繋がりかねない幾つかの重大な問題が潜んでいると考えられる。Llamaのオープンソース性に関する論考と重複する部分も多く含まれるが、ここではそれらの問題に対する危険性について雑多に解説する。 なお、本稿はLlama派生モデルの開発やLlamaモデルを自社サービスに組み込もうと検討している企業・エンジニア・コンプライアンス担当者を主な対象としてLlamaモデル利用における潜在的リスクを整理したものであるが、具体的な利用事案への法的助言を提供するものではなく

Meta Platforms社が開発するAIモデルのシリーズである「Llama」は、高性能で費用対効果が高く、比較的寛容な条件で頒布されていると多くの人々から見做されていることからシステムへの採用や派生モデルの開発等の利用が拡大しているように見受けられる。しかし、Meta社のCEOが自ら「Llamaはオープンソースである」と喧伝することで本当にLlamaがオープンソースであると誤解する傾向もあり、またLlamaライセンス契約自体に幾つかの厄介な問題が潜んでいるにも関わらず採用が進むことで今後法的な問題が生じかねないと考えられる。そこで本稿では、先ずLlamaライセンス契約のオープンソースへの適合性から解説することとする。 なお、Llamaライセンス契約のモデル利用時における注意点に関しては別の記事とする。 AIはtypoする Llamaのオープンソースへの適合性 1. オープンソース性を否

オープンソースAI(Open Source AI)とは、オープンソースの状態にあるAIシステムのことである。これはある意味で自明なのではあるが、「オープンソースの定義」(OSD)を管理している米国の非営利団体Open Source Initiative(OSI)では、2023年からわざわざ新たに「オープンソースAIの定義」(OSAID: Open Source AI Definition)の策定を開始している。2024年の8月頃には定義のRC版が公開される見込みであるが、本稿ではこの新たな定義が何故必要になり、その定義がどのような機能するものであるかということに対し、主に佐渡が視点から時系列的に簡単に紹介していく。これによって日本国内においてOSAIDが認知され、AI開発コミュニティにおいて自由かつ透明性が確保されたシステムの必要性への理解が深まる一助となることを期待する。 注：2024年

オープンソースとは何か？ Open Source Definition(オープンソースの定義) 逐条解説書 v1.0, 2024年1月22日 佐渡 秀治 Open Source guy オープンソース(Open Source)とは、米国の公益法人であるOpen Source Initiative(OSI)が策定した「オープンソースの定義」(Open Source Definition)で書かれた条件を満たすライセンス及びそのライセンスが適用されるソフトウェアのことである。このオープンソースという用語は自由ソフトウェア(Free Software)の代替として企図され、広く一般へ自由なソフトウェアを広めるためのキャンペーンのための用語として人為的に策定されたが、その後のオープンソース・ムーブメントと呼ばれる熱狂期を経て、紆余曲折ありながらも現在では世界の様々な領域においてオープンソースは当た

オープンソースという用語は自由ソフトウェア(Free Software)という用語を置き換えるために作られたのは周知の事実である。それならば、両者の意味する所は全く同じであるはずであるが、歴史的経緯により両者には別々にその言葉の定義が存在する。それぞれの用語を代表する組織であるFree Software Foundation(FSF)とOpen Source Initiative(OSI)は各々の定義の維持に心血を注いでいるが、実際の所、この両者の違いというものは存在するのだろうか？ (本稿は「オープンソースとは何か？ Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。) 四つの基本的な自由 どんな目的に対しても、プログラムを望むままに実行する自由 (第零の自由)。 プログラムがどのように動作しているか研究し、必要に応じて改造する自由 (第

「オープンソースの定義」はDebianフリーソフトウェア・ガイドライン(DFSG)を流用したことは周知の事実であるが、何故Debianプロジェクトは一般的にはFree Softwareという用語の祖とも管理者ともみなされるFree Software Foundation(FSF)とは別に自由なソフトウェアの定義を定めたのだろうか？この疑問を解き明かすため、用語の定義から見た自由なソフトウェアの歴史についてここで述べる。 (本稿は「オープンソースとは何か？ Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。) FSFの自由ソフトウェア いわゆる自由ソフトウェア(Free Software)運動の開始は、1983年9月にRichard StallmanがUSENETニュースグループに「GNU(Gnu’s Not Unix)と呼ばれる完全なUNI

2023年8月10日、長らくオープンソース業界の優等生として一般的に扱われてきたHashiCorp社がTerraformを含む全ての製品と幾つかのライブラリの将来のリリースについて、Mozilla Public License v2.0 (MPL-2.0) からBusiness Source License v1.1 (BUSL-1.1) への移行を発表した。 このプロプライエタリ化に対してオープンソースコミュニティから強い反発の声が上がり、Terraformをフォークする動きが表面化した後、9月20日にはそのフォークがOpenTofuプロジェクトとしてLinux Foundation傘下にて運営されるほどの動きにつながった。本稿では、このメカニズムを明らかにするために、特にライセンス観点から解説していく。 (注：元々、この文書はOpenTofu発足直後に書かれたものであり、当時とは状況が

SSPL(Server Side Public License)は2018年10月にMongoDB社が発表したライセンスである。MongoDBはそれまでAGPLv3(GNU Affero General Public License)を採用してきたが、クラウドベンダーがただ乗りしていることを理由として掲げてSSPLの正当性を主張し、現在もその利用を推進している。一方、オープンソースのコミュニティにおいては、SSPLがオープンソースの定義に反するというだけでなく、ライセンスとして使用することへの忌避感も生じている。 本稿では、そのSSPLの条文とオープンソースおよびライセンスとしての適格性について論考する。 SSPL条文分析何を？誰にどうする場合？条件 (何をしなければならないか)AGPLv3とSSPLとの違いのまとめオープンソースへの適格性ライセンスとしての適格性主張通りのライセンスである

ルールを守るのが日本的 ちょっと前に，日本では みんなの考えたオープンソース とかいう議論がありました．オープンソースの定義に合致しないのにオープソースを騙るとは何事だ，なんて風潮があったのを思い出したわけです．例えば，HORBライセンスも槍玉にあがっていたのですが，あれって，いわば「軍事利用禁止」版修正BSDとでもいうような内容なのですよね． オープンソースを定義した立場のOSIの創設者の一人は「共感を覚える」と言っているようですが，日本では，定義に即しているかどうかという審判的議論に終始しがちです．それも，異端の盲信者ではなく，代表的な論客達が，です． ということだそうだ。これはOTPの「軍事利用禁止」版GPLを掲げるオープンソース・プロジェクトGPUに関しての記述である。 ここでの盲信者と論客達が誰を指しているのか分からないが、少なくとも私がよく知っている連中はそんなレベルでの話はし

LinuxWorldの基調講演という場で華々しく発表されたAndover.netの買収はオープンソースコミュニティへは大きなインパクトを与えたが、市場の反応はその逆だった。ハードウェア事業とはかけ離れた事業に大きく投資す続きを読む “ドットコムバブルの終焉とVA Linux Systemsの崩壊”

さて、ついに退職エントリだ。私は米国のオープンソース・ムーブメントを日本で再現するためのコアを作るために民間企業へやってきたはずだった。それから21年、随分と長い航海になってしまったが、結局様々な尻拭いを続けてきたという感慨ばかりが起きてくる。一つの歴史として書き残すいいタイミングなのでその苦闘を振り返っておこう。 なお、長く付き合いが続いてしまう米国側法人は下記のように名称が変化している。なるべく頭に米国と付けて日本側法人と区別しやすいように記述するが、突然名称が変わったりするので注意してほしい。多くがもはや消滅した法人のことなので、さすがに一気読みするような酔狂な人はほぼいないと思うが。 VA Research　　　　　　Andover.net ↓　　　　　　　　　↙︎ (VAによる買収) VA Linux Systems ↓　　　　　　　　↘︎ (Andoverから社名変更) VA

GoogleやMicrosoftといったビッグテックにOpen Source Program Office (OSPOという略で界隈では通じる)という部署が存在することは日本でも知られているが、現在では多くのグローバルIT企業にも同名の部署が存在する。近年では中国系の企業での設置が目立つが、日本でもサイボウズ、メルカリといった企業には存在するようだ。 名前で勘違いする方もいるかと思うが、このOSPOという部署はオープンソース開発を行っている部署のことではない。一言で言えば、オープンソースの世界と企業の内部との全ての接点に関与し、それを支援することで円滑にオープンソースの価値を享受するための部署である。時には法務やコンプライアンスの部署に見えるし、マーケティングや広報のようにも見える。また、社内の情報システム部門の一部のように見えることもある。もう少し詳細にOSPOの役割を列挙すると以下のよ

オープンソースという言葉がVA Research社のオフィスで誕生して以降、VAを取り巻くビジネス環境は激変することになった。 創業からの数年間は成長とは言っても微々たるものであり、200万ドル程度の年商、つまり当時の秋葉原の小さな雑居ビルに入居していた多くのショップブランドのPCショップよりも小さいような規模であったわけだが、オープンソースというキーワードが突然脚光を浴びてからは、四半期毎に売上が倍増していくような急成長のペースに乗った。 ヒト・モノ・カネといった個別の内容に分けて1998年から1999年にかけてVA社に何が起きていたかを記していく。 ベンチャーキャピタルからの投資 VA社のCEOのLarryはよくSun Microsystems社のビジネスとの比較を好んでしていたような記憶がある。Sunが高価なSPARCのSolarisマシンをあれだけの規模で売っているのだから、同等性