ソフトウェアが「オープンソース」ではなく「利用可能なソース」であることはあなたにとって重要ですか

おそらく、OSIによって公式に承認されたオープンソースライセンスのリストをご存知でしょう。最も注目すべきは、GPL、MIT、[お気に入りのライセンスをここに挿入]だと思います。

私は最近、オープンソース（作成者がすべてのソースコードを利用可能にしました）であるが、それらの公式ライセンスの1つでは公式にオープンソースではないプロジェクトに出会いました。

• ソースをリリースしましたが、将来ソースをリリースする約束はしませんでした。

• 変更の提案は許可されていましたが、パッチを受け入れることは約束されておらず、外部からパッチを当てたバージョンの外部配布は許可されていませんでした。

• 商用プロジェクトまたは有料プロジェクトでのソフトウェアの使用は許可されていましたが、ソフトウェア自体の販売は許可されていませんでした。

私たちはそれを考えるのが好きなので、オープンソースではなく「利用可能なソース」と呼ぶことができると思います。

会社の経営陣がこのソフトウェアでビジネスをしたくない理由を私は見ることができます。彼らはそれをフォークすることも、販売することも、ソフトウェアの独自のバージョンを作成し、配布または販売することもできません。

しかし、このソフトウェアを使用しているソフトウェアエンジニアリングチームの一員として、あなたにとって重要なことでしょうか？私はまだそれで仕事を終わらせることができます、私は私が支払われているプロジェクトでそれを使用できます（しかし、私はソフトウェア自体を販売することはできません、とにかくすることのビジネスではありません）、そして私はできますコードに変更を加えて、ニーズに応じて異なる動作をするようにします（ただし、それらの変更を公開することはできません）。また、それらの変更を公式に他の人が利用できるようにしたい場合、承認はプロジェクト自体に委ねられ、それらを公式リリースに組み込むかどうか。

したがって、この「利用可能なソース」ソフトウェアに基づいてビジネスを行いたい企業はそれができないことを知っていますが、ソフトウェアエンジニアリングチームの誰かとして、それらの違いはあなたにとって重要ですか、それとも関連性が低いと思われますか？

他の人がこれについてどう思うか興味があります。

このソフトウェアが提供する機能をゼロから開発しなければならなかったプロジェクトの場合、そうしないことは間違いなく便利です。

ただし、同等のオープンソースパッケージの方が優れているかどうかは、他の要因によって異なります。

• 何らかのサービスを提供したり、別の製品の一部としてバンドルしたりするために使用されますか？
• 製品を独立して強化および保守するためのリソースがありますか？
• オープンソースバージョン（コードまたはプロジェクト管理のいずれか）よりもこのソフトウェアを使用する方が競争上の優位性はありますか？

これらの要素のいずれにもノーと答えると、OSSがより良い選択であることを示します。

ほとんどの場合、コード自体が決定要因ではありません。全体像を調べる必要があります。

SIDEBAR OSSプロジェクトは、将来のバージョンをオープンにしておくこと、または将来のバージョンがあることを法的に約束することはできません。それが、オープンライセンスを持つことが非常に有利な理由の1つです。また、OSSプロジェクトは貢献者からのパッチを受け入れる必要はありません（特に所有権や権利の譲渡なし）。

これと他の外部ライブラリの問題はメンテナンスです。

アプリケーションの寿命と、このライブラリの見かけ上の寿命はどれくらいですか？できれば最短になるようにしてください。

このライブラリのバグ修正を行うのは誰ですか？ここからわかるように、他の修正バグに頼ることはできないため、会社はこのソフトウェアを保守するために将来的にリソースを明示的に割り当てる必要があります。ソースを共有できないため、メンテナンスの負担を他の人と共有することはできません。わからないコードのとらえどころのない競合状態のバグを探し出したいですか？

これだけでも、ライブラリを使用するには高価すぎる可能性があります。

ライブラリが非常に堅牢で堅牢であり、ソースレベルでの操作が容易な場合、これは無関係かもしれませんが、私の経験では、真のオープンソースプロジェクトの仲間からの圧力は、あなたがベストを尽くす傾向があるため、単にコードを改善するだけです。

個人的には、他の人のコードを使用する理由は、あなたが自分で対処する必要がないからです。将来のメンテナーについても考えてください-ライブラリ内のコードを変更するファイアドリルを実行して、それが実行できるかどうかを確認する必要があります。ここには非常に厄介な驚きがあるかもしれません。

問題のライブラリについて議論する自由がありますか？

正直に言うと、会社の経営陣がこのような「利用可能なソース」ライブラリの使用に問題を抱えている理由はわかりません。自社製品への統合に関する限り、彼らはそれをクローズドソースライブラリとみなすことができます。

私にとって、プログラマーとして、ライブラリが「オープンソース」であるか「利用可能なソース」であるかは問題ではありません。外部ライブラリにローカルな変更を加えたくないのは、メンテナンスの負担が増えるためです。ローカルの修正にバグが見つかったときだけでなく、ライブラリの新しいリリースがリリースされたときに修正を何度も統合するときにも。

私見で、「オープンソース」が質問で説明されている「利用可能なソース」ライセンスに勝る唯一の状況は、

• 製品のライセンスには、含まれているライブラリのソースの開示も必要です。
• 私たちは、ライブラリの拡張/拡張バージョンを作成しています

これが、Free Software Foundationが「フリー」または「非フリー」という用語を使用してソフトウェアを説明する理由です。それらは価格ではなく、ソフトウェアの使用または配布に課せられる制限です。

何かのソースコードに完全にアクセスできるというまれなケースの1つに出会ったようですが、OSI定義ではソフトウェアが「オープンソース」ではありません。

どちらの用語にも、誤った名称になる可能性があります。私はemacsの最初のコピー（QICテープ）に50ドルを支払いましたが、emacsはフリーソフトウェアです。社内で使用している一部の専用アプリケーションのソースコードは持っていますが、オープンソースではありません。

（少なくとも私には）最大の危険信号を出すことは、将来のバージョンのソースコードへのアクセスを保証するものではありません。このツールを変更できることに大きく依存している場合は、注意が必要です。ベンダーと口頭で合意したとしても、常にコードがあるということです。ただし、契約書に記載されている場合を除き、その合意は成立しませんでした。

CTOとして、非フリーソフトウェアに依存しないように最善を尽くします。私は過去数回、ベンダーロックの悪い状態にありましたが、これは避けたいミスです。私たちはプロプライエタリなものを使用しますが、突然使用できなくなっても、私たちのビジネスは過度の苦労をすることはありません。

このソフトウェアとコードへのアクセスを中心に構築しているように思えますので、常にアクセスできると書かれたものを入手することをお勧めします。ベンダーを購入するとどうなりますか？

これはかなり重要です。説明した「使用可能なソース」アプローチの主な問題：

• ソースを変更する自由がない場合、技術的な運命を制御することはできません。面倒な回避策よりも、ソースを直接ハッキングすることが望ましい場合があります。
• あなたはソフトウェアが維持され続けるという保証はありませんし、あなたはあなたが本当のオープンソースで手に入れることを自分でやるというフォールバックオプションを持っていません。
• カスタムライセンスのように聞こえるので、GPLまたはBSDライセンスのような有名で実績のあるものを使用する場合に比べて、おそらく大きな法的リスクがあります。
• それが本当のオープンソースでなければ、多くのオープンソースプロジェクトにとって大きな利点である同じレベルの有用なコミュニティを得ることができません。

私の提案：作成者に、オープンソースライセンスの下でソフトウェアをリリースするよう説得してみてください。それは誰にとっても有利なはずです-あなたがオープンソースライセンスの下であなたが望むソフトウェアを手に入れるので、プロジェクトをオープンソースにすることは長期的にソフトウェアをはるかに成功させる可能性が高いからです。