いいえ、しかし「機能的ソースコードライセンス」はオープンソースライセンスの境界をさらに曖昧にします。
ソフトウェアがパンチカードやテープにロードされていた時代、すべてのプログラムは「フリーソフトウェア」であり「オープンソース」でした。その後、プロプライエタリ・ソフトウェアが登場し、すべてが変わりました。これに対し、プログラマーたちは反旗を翻し、フリー・ソフトウェアとオープン・ソース・ソフトウェアの最初の正式な定義を作成しました。
今日では、オープンソースでないコードは稀な例外にさえなっています。しかし、オープンソースを開発モデルではなく、ビジネスモデルと勘違いしている企業が、プロプライエタリなアプローチと「オープンソース」コードを組み合わせようとするのを止めることはできません。最新の事例としては、Sentry社が発表した"
の伝統に則りFSL オープンソースの重要性を評価する一方で、その中核となるコンセプトを嘲笑し、そのアプローチを「努力なき自由」と表現しているようです。
ああ。
実は、Sentry は開発者向けのアプリケーションコード監視サービスで、Django の少量のコード開発から生まれました。現在でも、その大部分はオープンソースで開発されています。Sentry がオープンソースなしには成り立たないことは一目瞭然です。
同じことが、""やその他のセミ・オープンソース・ライセンスを使用している他のすべての企業にも当てはまります。これらはすべてオープンソース企業から生まれたもので、その後、利益を最大化するために、コードを固定化するために、無料で入手したコードを再ライセンスするのです。
ティエリー・カレズ取締役会副会長が私に語ったように、「オープンソースのリポジトリを主軸としてソフトウェアを構築し、何百ものオープンソースパッケージを依存先として使用している場合、ライセンスを求める必要がない企業もあります。彼らは、オープンソースの原則に公にコミットすることで評判を築いてきました。しかし、より大きな価値を追求しようとするあまり、そもそも成功をもたらしたモデルを近視眼的に放棄してしまったのです」。その通りです。
たとえば、Sentry、MariaDB、Redis 、 HashiCorp 、かつてのオープンソース企業の中には、権利侵害の.NET Frameworkを採用したという事実を信用できるものもあります。これらの契約は、貢献者が自分のコードをオープンソースプロジェクトで使用するために設定する条件を定義する法的文書です。Apache Software FoundationのCLAやLinuxのCLAのように、プロジェクトの法的権利を保護するためだけに使用されるCLAもある一方で。MongoDBのContributor Agreementのように、コードとその著作権を所有するために使用されるものもあります。このようなCLAがあれば、彼らが好きなようにコードを使用し、再ライセンスすることは簡単です。
SourceHutの創設者兼CEOであるDrew Devault氏は、Elasticsearchがオープンソースから "Source-ready "へと移行することについて、次のような見解を示しました。「Elasticsearchは1,573人の貢献者によって所有されており、彼らは自身の著作権を保持し、Elastic社に彼らの作品を配布するための条件付きライセンスを付与しています。Elasticsearchは1,573人のコントリビューターによって所有されており、コントリビューターは著作権を保持し、Elasticに無条件で著作物を配布するライセンスを付与しています。Elasticsearchがオープンソースでなくなると決めたとき、彼らはこの脆弱性を利用しました！."
今日、Sentry社のケースは、企業のケースと同じで、一変したと見られています。公平を期すために、Sentryは長い間Source Available Licencesを使用してきました。同社がFSLを作成し採用する前は、2018年からBSLを使用しています。もしまだSentryにコードを寄付し続けている人がいるのであれば、彼らは自分が何をしているのか知っているはずです。
BSLには2つの大きな欠点があります。第一に、4年間というソフトウェア業界では信じられないほど長い非競争期間があらかじめ決められています。これは、オープンソースへの最終的な移行が象徴的な動きに過ぎないという感覚を生みかねません。ほとんど100年でもいいくらいです。Sentry社では、この期間を3年に短縮することが選択されましたが、3年でも長すぎるということが認識されました。"
ライセンスの最後に、コードはApache 2.0またはMITライセンスを使用します。しかし実際には、これは最初に聞こえるほど寛大ではありません。FSLによれば、あなたはそのコードをどのような目的にも使うことができます。競合的使用とは、ソフトウェアそのものであれ、ソフトウェアに基づいて提供される他の製品またはサービスであれ、競合する製品またはサービスがソフトウェアのリリース日に提供されていたか、または提供されている限り、製品またはサービスと競合する商用製品またはサービスを開発または提供するためにソフトウェアを使用することを意味します。"
別の言い方をすれば、コードを見ることはできても、それを使ってビジネスを行うことはできないということです。もっと詳しく知りたい方は、FSL版のApacheライセンスとMITライセンスをチェックしてみてください。個人的には、どちらもオープンソースライセンスとは考えていません。
さらにWhitacre氏は、「より深刻な欠陥は、BSLには変更日、変更ライセンス、追加使用許諾など、パラメータが多すぎることです。最大の問題は追加使用許可で、これは空白を埋める巨大な問題であり、すべてのBSLが本質的に異なるライセンスであることを意味します"。
それには反論できません。すべての会社のBSLは異なります。それはまた、顧客がBSLを使用する会社と契約するとき、法的にどのような権利や利益が確保されているのかを正確に知ることが難しいことを意味します。
もしかしたら、このアプローチはうまくいくかもしれません。しかし、私はCarrez氏の言うことに同意します。「開発者が技術を選択する際の自主性を奪うような、また別の変種のライセンスをリリースすることは、何も新しいことではありません。これはオープンソースではありません。オープンソースを装ったプロプライエタリなポータルにすぎません。"
を経由して
