第7回 AGPLの勧め | WASP株式会社
このブログは会社の広報のためのものですから、あまり政治的なことやセンシティブなことを書くつもりはありませんが(いつもの出だし)、ここ最近のAI関係の人達のライセンスに対する考え方はいかがなものかと思うことが増えて来ました。 そのことの是非をここで言うつもりはありません。言いたいことは山ほどあるのですが、弊社の業務的にはどうでもいいことです。ただ、その中にあった「商用利用禁止のオープンソース」という話から派生して、表題のような話を書いてみようかと思います。 弊社のオープンソース戦略(？) 特定の顧客がついた仕事の成果物は別として、社内用に作ったもの、あるいは自社サービス用に作ったものは、原則オープンソースライセンスで公開することにしています。 今のところ弊社名義のGitHubのピン止め公開リポジトリは3つしかないので、そんなにドヤれるものでもないですけどね。GitHubに置くのに必要なコード
AGPLが適する場所、適さない場所 | フューチャー技術ブログ
前回翻訳したAGPLを理解する: もっとも誤解されたライセンスでは、実体以上に強いライセンスであると思われているケースについての紹介がありました。 もちろん、使い方次第ではアプリケーションコードの開示が必要になってしまうケースもあるかと思います。前回のエントリーはわかりやすい切り口で書いてくれていますが、いくつか、やはりプロダクトコード側へ制約が出るケースが考えられるので、その点についてまとめてみます。 AGPLの特徴を2行でまとめると以下の通りかと思います ネットワーク越しに利用することも配布とみなし、AGPLで書かれたアプリケーションのソースにアクセスする権利が伝わる ネットワーク越しの利用することはリンクではないため、ネットワークで通信するアプリケーションのライセンスをAGPLにする必要はない 配布とリンクがごっちゃにされるのが、よくされる誤解の原因かと思います。もしネットワークアク
AGPLを理解する: もっとも誤解されたライセンス | フューチャー技術ブログ
このエントリーはSayanさんによるUnderstanding the AGPL: The Most Misunderstood Licenseの日本語訳になります。 オープンソースの出現は、ソフトウェア産業全体を一変させました。しかし、オープンソースのコードを使って誰が何をできるかを管理することは課題でしたし、今も解決していません。オープンソースライセンスはそこに救いの手を差し伸べました。しかし、常に次のことを忘れないでください：石のない土地はなく、骨のない肉はありません。OSI（オープンソースイニシアチブ: オープンソースを促進することを目的とする組織）が承認したライセンスは80以上あり、その数はさらに増加しています。それぞれのライセンスには利点と欠点があるため、オープンソースの開発者は自分のプロジェクトにあったライセンスを選ぶのは簡単ではありません。Affero General Pu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
