Open source projects, embargoes and NDAs

Vendors may only disclose to project members under an NDA.

This article is a companion piece to one that I wrote soon after the advent of Meltdown and Spectre, Meltdown and Spectre: thinking about embargoes and disclosures, and another which I wrote more recently, Security disclosure or vulnerability management?. I urge you to read those first, as they provide background and context to this article which I don’t plan to reiterate in full. The focus of this article is to encourage open source projects to consider a specific aspect of the security disclosure/vulnerability management process: people.

A note about me and the background for this article. I’m employed by Red Hat – a commercial vendor of open source software – and I should make the standard disclosure that the views expressed in this article don’t necessarily reflect those of Red Hat (though they may!). The genesis of this article was a conversation I had as part of my membership of the Confidential Computing Consortium, of which Enarx (a project of which I’m a co-founder) is a member. During a conversation with other members of the Technical Advisory Board, we were discussing the importance of having a vulnerability management process (or whatever you wish to call it!), and a colleague from another organisation raised a really interesting point: what about NDAs?

What’s an NDA?

Let’s start with the question: “what’s an NDA”? “NDA” stands for Non-Disclosure Agreement, and it’s a legal document signed by one or more individuals or organisations agreeing not to disclose confidential material[1]. NDAs have a bad reputation in the wider world, as they’re sometimes used as “gagging orders” within legal settlements by powerful people or organisations in cases of, for instance, harassment. They are, however, not all bad! In fact, within the technology world, at least, they’re a very important tool for business.

Let’s say that company A is a software vendor, and creates software that works with hardware (a video card, let’s say) from company B. Company B wants to ensure that when its new product is released, there is software ready to make use of it, so that consumers will want to use it. In order to do that, Company A will need to know the technical specifications of the video card, but Company B wants to ensure that these aren’t leaked to the press – or competitors – before release. NDAs to the rescue! Company A can sign an NDA with Company B, agreeing not to disclose technical details about Company B’s upcoming products and plans to anyone outside Company A until the plans are public. If it’s a “two-way NDA”, and Company B signs it as well, then Company A can tell Company B about their plans for selling and marketing their new software, for instance, to help provide business partnership opportunities. If either of parties breaks the terms of the agreement, then it’s time for expensive legal proceedings (which nobody wants) and the likelihood that any trust from one to the other will break down, leading to repercussions later.

NDAs are common in this sort of context, and employees of the companies bound by NDAs are expected to abide by them, and also not to “carry over” confidential information to a new employer if they get a new job.

What about open source?

One of the things about open source is that it’s, well, “open”. So you’d think that NDAs would be a bad thing for open source. I’d argue, however, that they have actually served a very useful purpose in the development and rise of the open source ecosystem. The reason for this is that companies are often reluctant to have individuals sign NDAs with them, and individuals are often reluctant to sign NDAs. From the company’s point of view, NDAs are more difficult to enforce against individuals, and from the individual’s point of view, the legal encumbrance of signing an NDA – or multiple NDAs – may seem daunting.

Companies, however, are used to NDAs, and have legal departments to manage them. Back in the 1990s, I remember there being a long lag time between new hardware becoming available, and the open source support for it emerging. What did emerge was typically buggy, often reverse-engineered, and rarely took advantages of the newest features offered by the hardware. From around 2000, this has changed significantly: you can expect the latest hardware capabilities to emerge into, say, the Linux kernel, pretty much as soon as the supporting hardware is available. This is to some extent because there are now a large number of companies who employ engineers to work on open source. The hardware vendors have NDAs with these companies, which means that the engineers can find out ahead of time about new features, and have support ready for them when they launch.

There’s a balancing act here, of course, because sometimes providing code implementations and making them open can give away details of hardware features before the hardware vendors are ready to disclose them. This means that some of the engineering needs to take place “behind closed doors” and only be merged into projects once the hardware vendor is ready to announce their specifications to the world. This isn’t as open as one might like. On balance, though, I’d argue that this approach has provided a net benefit to the open source community, allowing hardware vendors to keep competitive information confidential, whilst allowing the open source community access to the latest and greatest hardware features at, or soon after, release.

NDAs and security

So far, we’ve not mentioned security: where does it come in? Well, say that you’re a hardware vendor, and you discover (or someone discloses to you) that there’s a vulnerability in one of your products. What do you do? Well, you don’t want to announce it to the world until a fix is ready (remember the discussion of embargoes in my previous article), but if there are open source projects which need to be involved in getting a fix out, then you need to be able to talk to them.

The key word in that last sentence is “them”. Most – one could say all – successful open source projects have members employed by a variety of different companies and organisations, as well as some who are not employed by any – or work on the project outside of any employer-related time or agreement. The hardware vendor is extremely keen to ensure that any embargo that is created around the work on this vulnerability is adhered to, and the standard way to enforce (or at least legally encourage) such adherence is through NDAs. This concern is understandable, and justified: there have been some high profile examples of information about vulnerabilities being leaked to the press before fixes were fully ready to be rolled out.

The chances, however, of the vendor having an NDA with all of the organisations and companies represented by engineers on a particular project is likely to be low, and there may also be individuals who are not associated with any organisation or company in the context of this project. Setting up NDAs can be slow and costly – and sometimes impossible – and the very fact of setting up an NDA might point to a vulnerability’s existence! Vendors, then, may make the choice only to disclose to open source project members who are governed by an NDA – whether through their employer or an NDA with them as an individual.

Process and NDAs

What does that mean to open source projects? Well, it means that if you’re working with specific hardware vendors – or even dependent on specific software vendors – then you may need to think very carefully about who is on your security/vulnerability response/management team (let’s refer to this as the “VMT” – “Vulnerability Management Team” – for simplicity). You may need to ensure that you have competent security engineers both with relevant expertise and who are also under an NDA (corporate or individual) with the hardware vendors with whom you work. Beyond that, you need to ensure that they are on your VMT, or can be tasked to your VMT if required.

This may be a tough ask, particularly for small projects. However, the world of enterprise software is currently going through a process of realising quite how important certain projects are to the underpinnings of their operation, and this is a time to consider whether core open source projects with security implications need more support from large organisations. Encouraging more involvement from organisations should not only help deal with this issue – that vendors may not talk to individuals on your project who are not under NDA with them. Of course, getting more contributors can have positive and negative effects in terms of governance and velocity, but you really do need to think about what would happen if your project were affected by a hardware (or upstream software) vulnerability, and were unable to react as you had nobody able to be involved in discussions.

The other thing you need to do is ensure that the process you have in place for reporting of vulnerabilities is flexible enough to manage this issue. There should be at least one person on the VMT to whom reports can be made who is under the relevant NDA(s): remember that for a vendor, even the act of getting in touch with a project may be enough to give away information about possible vulnerabilities. Although having anonymous VMT may seem attractive – so that you are not giving away too much information about your project’s governance – there can be times when a vendor (or individual) wishes to contact a named individual. If that individual is not part of the VMT, or has no way to trigger the process to deploy an appropriate member of the project to the VMT, then you are in trouble.

I hope that more open source projects will put VMTs and associated processes in place, as I wrote in my previous article. I believe that it’s also important that we consider the commercial and competitive needs of the ecosystem in which we operate, and that means being ready to react within the context of NDAs, embargoes and vulnerabilities. If you are part of an open source project, I urge you to discuss this issue – both internally and also with any vendors whose hardware or software you use.

Note: I would like to thank the members of the Technical Advisory Board of the CCC for prompting the writing of this article, and in particular the member who brought up the issue, which (to my shame) I had not considered in detail before. I hope this treatment of questions arising meets with their approval!


1 – Another standard disclosure: I am not a lawyer! This is my personal description, and should be used as the basis for any legal advice, etc., etc..

2019年はEnarxの年でした

2020年はデモなど色々なプランを考えています!

 

私にとって2019年はEnarxプロジェクトがほとんどでした。

他のしなければいけない業務もあって、例えば顧客会議、IBM(7月に私の勤めるRed Hatを買収してます)の業務、Kubernetesのセキュリティやパートナー企業と協業など重要なことは色々ありました。しかしEnarxが2019年のハイライトです。

 

年始に私たちは実現できることがあると確信し、内部のリーダーシップチームに対して、達成可能であることの証明を課されました。

その課題に対して、私たちはAMDのSEVチップと五月のボストンでのRed Hat Summitでデモを行い、このブログでアナウンスをしました。

IntelのSGXチップセットと10月のリヨンでのOpen Source Summitでフォローアップをしています。2019年のEnarxの開発でとても大切なことだったと考えています。

 

チーム

 

Enarxは私だけのものではもちろん、ありません。Nathaniel McCallumと共にプロジェクトの共同創立者の一人であることは非常に誇りです。ここまで達成できたのは多くのチームメンバーのおかげですし、オープンソースプロジェクトとして貢献し使用している皆様のおかげです。貢献者ページにはたくさんのメンバーの名前がありますが、まだ全員の名前が挙がっているわけではありません。また、Red Hat内外の何人かの方から頂いたプロジェクトに対するアドバイス、サポートとスポンサリングはとても大切なものです。その皆様の名前を言う許可は得ていないので、ここではお話しせず、丁重に扱う事とします。皆様のサポートとそのお時間を頂けたことに非常に感謝しています。

 

ユースケースとパートナー

 

2019年に成し得た重要なことの一つに、皆さんがどのように「野良状態で」Enarxを使いたいのかをまとめたことと、その比較的詳細な分析を行い、書き上げたことです。

その全てが公開されたわけではないですが、(私が任されていることなんですけどもね)これは実際にEnarxを使用したいと考えているパートナーを見つけるのに不可欠です。まだ公表できませんが、皆さんも聞いたことがあるグローバル企業のいくつかから、また将来的に増えるであろうスタートアップ企業からも、とても興味深いユースケースが挙がってきています。このように興味を持っていただくことは、ロジェクトの実用化に不可欠で、Enarxはただエンジニアの情熱から飛び出しただけのプロジェクトではないと言う事なのです。

 

外部を見ると

 

2019年の重大イベントはLinux FoundationのOpen Source SummitでのConfidential Computing Consortiumの発表でした。私たちRed HatではEnarxはこの新しいグループにぴったりだと考えており、10月の正式発足でプレミアメンバーになったことを嬉しく思っています。これを書いている2019年12月31日時点では、会員数は21、このコンソーシアムは幅広い業界で懸念と興味を惹きつけるものだと言うことがはっきりしてきました。Enarxの信念と目的が裏付けされていると言うことです。

 

2019年に成し遂げたのはコンソーシアムへの参加だけではありません。カンファレンスで講演を行い、このブログ上やNext.redhat.comまたOpensource.comで記事を発表、プレスとの会見、ウェブキャストなどです。一番大切なのは六角形のステッカーを作ったことでしょう!(欲しい方がいらっしゃったらご連絡ください)

 

最後に大切なことを一つ。私たちはプロジェクトを公表していきます。内製のプロジェクトからRed Hat外の参加を促進するために活動しています。詳細は12月17日のBlogをご覧ください。

 

アーキテクチャとコード

 

他に何かあるでしょうか。そうだ、コードですね。そしていくつかのコンポーネントの成熟しつつあるアーキテクチャセットです。

私たちは当然これら全てを外部に公表するつもりですが、まだできていない状態です。すべきことが本当にたくさんあるのです。私たちは皆さんが使用できるようにコードを公開することに尽力していて、2020年に向けデモやそれ以外の大きな計画を立てています。

 

最後に

 

他にも大切なことはもちろんあり、私がWileyから出版するトラスト(信頼性)に関連する本を書いていることです。これはEnarxに深く関連するものです。基本的に、技術はとても「クール」なものですが、Enarxプロジェクトは既存の需要に見合うものですから、Nathanielと私はクラウドやIoT、エッジ、その他機密情報とアルゴリズムが実装される全てのワークロードの管理方法を変えていくいい機会だと考えています。

 

このブログはセキュリティに関するものですが、トラスト(信頼性)と言うものはとても重要な部分だと考えています。Enarxはそれにぴったりと合うのです。ですから、これからも信頼性とEnarxに関するポストをしていきます。Enarx.ioの最新情報に注目していてください。

 

元の記事:https://aliceevebob.com/2019/12/31/2019-a-year-of-enarx/

2019年12月31日 Mike Bursell

 

タグ:セキュリティ、Enarx、オープンソース、クラウド

 

“Unhackability” or just poor journalism?

An over-extended analogy about seat belts and passwords.

I recently saw a tagline for a brief article in a very reputable British newspaper which was “Four easy steps to unhackability”. It did two things to me:

  1. it made me die a little inside;
  2. it made me really quite angry.

The latter could be partly related to the fact that it was a Friday evening and I felt that I deserved a beer, and the former to the amount of time I’d spent during the week mastering our new expenses system, but whatever. The problem is that there is no “unhackable”. Just as there is no “secure”.

This, I suppose, is really what made me die a little inside. If journalists are going to write these sorts of articles, then they should know better. And if they don’t, the editor shouldn’t let them write the article. And if they didn’t write the tagline, then whoever did should be contacted, shouted at, and forced to rewrite it. And provide an apology.  Preferably a public one.

The article was about good password practice, and though short, contained sensible advice. For a more complete (and, dare I say, wittier) guide, see my article The gift that keeps on giving: passwords.  I was happy about the advice, but far, far from happy about the title.  Let’s employ that most dangerous of techniques: an analogy.  If, say, someone wrote an article on motoring about how to use seat belts with the tagline “Four steps to uninjureability”, anyone who knew anything about cars would be up in arms, because it’s clear that seat belts, useful as they are, and injury-reducing as they are, do not protect you from all injury when driving, even if employed perfectly correctly.  This is what made me angry, because the password article seemed to suggest that good passwords would stop you being technologically injured (see: here’s why we don’t let people play with analogies).

Because, although most people might understand about seat belts, fewer people – many fewer people – have a good idea about computer security.  Even the people who do understand lots about computer security aren’t immune from being hacked, however well they pursue good practice (and, to reiterate, the advice in the article was good practice).  It’s the same with motoring – even people who use their seat belts assiduously, and drive within the speed limit, and follow all the rules of the road, aren’t immune from injury.  In fact, no: motoring is better, by at least one measure, which is that (in most cases at least), there aren’t a whole bunch of people whose main aim in life is to injure as many other motorists as they can.  As opposed to the world of technology, where there really is a goodly number of not-so-goodly people out there on the Internet whose main aim in life is to hack[1] other people’s computers and do bad things with their data and resources.

As my friend Cathy said, “it gives people a false sense of security”.

Some actual advice

Computer security is about several things, about which the following come immediately to mind:

  • layers: the more measures or layers of security that you have in place, the better your chances of not being hacked;
  • timeliness: I’m not sure how many times I’ve said this, but you need to keep your systems up-to-date.  This may seem like an unnecessary hassle, but the older your software is, the more likely that there are known vulnerabilities, and the more likely that a hacker will be able to compromise your system;
  • awareness: sometimes we just need to be aware that emails can be malicious, or that that phone-call purporting to be from your Internet Service Provider may in fact be from someone trying to do bad things to your computer[2];
  • reaction: if you realise something’s wrong, don’t keep doing it.  It’s usually best to step away from the keyboard and turn off the machine before more damage is done.

There: a set of pieces of advice, with no ridiculous claims about how well they’ll serve you.  I’ll save that for another, lazier article (or hopefully not).


1 – mean “crack”, but I’ve pretty much given up on trying to enforce this distinction now.  If you’re with me and feel sad about this, nod quietly to yourself and go to enjoy that beer I mentioned at the beginning of the article: you deserve it.

2 – don’t even start me on using random USB drives – I even had an anxiety dream about this last night.

オープンソースと悪人と

この記事は
https://aliceevebob.com/2019/07/30/open-source-and-well-bad-people/
を翻訳したものです。
オープンソースのコードを書いている人にとって、オープンソースソフトというものは誠実なものに見えます。
コードを書いて、皆さんのような善人な方がコードを書き足し、テストをし、文書を作成し、ソフトを使うのです。
オープンソースとは、世界をどんなに良くしてくれていることか!

「悪の帝国と呼ばれる組織や会社」ですら、オープンソースを受け入れ、幸福と愛情あふれる場所になり、コミュニティを支援し、オープンソースは良いものとして採用し布教しているのです。

多くのオープンソースライセンスは、1組織がコードを書き換え、その書き換えたコードをリリースすることなく利益を得ることほぼ不可能なようにできています。
オープンソースの魂はライセンスで、実際に世界を良くしているのです。

この大部分には賛成します。

が、世間で鵜呑みにされたような憶測(それが何であれ)が広まっているのを見ると、不思議に思います。
というのも、オープンソースを使っている全ての人が善人ではないというのは皆さんご存知でしょう。

クラッカー(悪事を行うハッカー)はオープンソースを使います。
薬物の販売人もオープンソースを使っています。
人身売買者もオープンソースを使います。
テロリストだって使っているでしょう。
彼らももしかしたらパッチやテスト、文書作成に貢献しているかもしれません。実際はほとんどないと思いますが。でも一般的に彼らは善人ではないのです。

中には「まあ、中には少しはそういう人もいるかもしれないけど、耐えられる範囲だろう」と肩をすくめてしまうような人もいるでしょう。オープンソースで悪事を働く人に比べたらもっと多くの人がオープンソースによって助かっているでしょうから、引き続き喜んで貢献するでしょうね。
あるいは、オープンソースに貢献するのではなく、どうせ人のためにならないのだから、悪人度合いが低い方を受け入れてしまう、というところでしょうか。

これは実際に有効なことで、 ジョン・スチュアート・ミルの言う功利主義として知られています。(私は哲学者ではないので、非常にざっくりと話していることを了承ください)これはこう説明されることもあります。

「行動は、人類の幸福全体を促進するのにちょうど良く釣り合う」

私もオープンソースが「人類の幸福全体を促進」すればいいと願っています。問題は犯罪者だけが皆さんのオープンソースコードを使うわけではないことです。

実際に「日陰なコト」を行うビジネスもありますし、政府が批判する人間を抑圧することも、警察が市民を監視することもあるでしょう。
これも皆さんコードなのであり、悪事にも使われるのです。

悪事とはなんでしょう。
これは功利主義の哲学に対する反論でよく出ますね。何が良いことで何が悪いことなのかと定義するのは難しいのです。
法を遵守している我々一般の人は、人身売買をするのは悪いことだ、と思います。しかし、中にはグレーゾーンなものもあるのです。

例えばタバコ製造、石油化学の会社、プラスチックの製造業、LGBTQ+の人々を支持しない組織、銃の製造業などです。
意図的に範囲を大きくしています。また、最後の例はあえて選んでいます。

オープンソースの活動を初期に行なっていたのはESRで知られるエリック・レイモンドです。彼は銃を持つ権利をずっと支持しています。彼は公にされている批判をハッカーコミュニティに取り入れ、小銃保持の権利を声に出して支持しています。ESRにとってはこれが「自由」なのです。

彼を批判するつもりはないですが、これは賛成できません。
ただこれで彼が良いと考えているものは私が考えているものと違うことは明確でしょう。
LGBTQ+に関してはとてもリベラルに受け入れていますが、オープンソースのコミュニティにいる人がみんな同じ考えを持っているわけではないでしょう。
オープンソースコミュニティをリベラルだと述べていますが一般論として受け入れられていません。

ハッカーのための辞書として公表されているのですが、平均的なハッカーとは

ふんわりと穏健リベラル。従来の右派左派の政治全体を拒絶するリベラリストの代表を除く。
保守的に一般化して言うとハッカーはどちらかと言うと反独裁主義者。
つまり従来の保守主義と「極」左派は非常に珍しい。ハッカーは非ハッカーよりも大体
a)攻撃的な非政治主義で
b)特異的もしくは特異な政治アイデアを抱き実際日々そう生きようとしている

ジャーゴン・ファイル
少し古いかもしれませんが、この説明は多くのオープンソースコミュニティ内で、コミュニティの一部として意識している人たちが共感するものです。

ただオープンソースのコードの「良い使い方」は「良い組織」が決める、と言うのは、コミュニティとして明らかに賛成できかねます。
もしできたとしても、悪人とされる人々を止められるようなライセンスを作るのは非常に可能性が低いでしょう。
元の記事:
https://aliceevebob.com/2019/07/30/open-source-and-well-bad-people/
2019年7月30日 Mike Bursell

信頼と、オープンソースを選ぶということ

この記事は
https://aliceevebob.com/2019/06/18/trust-choosing-open-source/
を翻訳したものです。
ずっと昔、遠い遠いところで(よくある表現でしょ)、私はトラストとセキュリティという標準化文書の下書きに関わっていました。(標準化に関わっていたことがなければ恐怖に感じるでしょうけれど、関わったことがあれば普通のことですよ)
この文書は ETSI GS NFV-SEC 003: Network Functions Virtualisation (NFV);NFV Security; Security and Trust Guidanceと呼ばれ、セクション5.1.6.3は「推移的トラスト」についてでした。
複雑で長い文書で、とても自信を持ってできた仕事です。
(私は調査員の一人で、また文書のほとんど特にトラストのセクションを記述しました。)この文書は題名からもわかる通りトラスト周りの重要な問題に対応しているものです。

この中でこう定義されています。

「推移的トラストは、CがBを信用しているので、AはBというものを信頼する」

その文書のどこにもオープンソースソフトのことは書いてありません。
公平を期すために、どのソフトやベンダーにも偏らないように記述してあります。標準化に関わる多くの企業はベンダー仕様のソフトに注目しがちです。さらにいうと私は当時Red Hatに勤めていませんでした。

Red Hatに転職し、基本的に標準化の世界から遠ざかることになるのですが、オープンソースについては考えるようになりました。
また、トラストに関してももっと深く考えるようになりました。ビジネス、組織や企業でオープンソースをどうやって使うようになるのか、と。

オープンソースが「それ自体は」他のベンダーソフトと比べて特に安全ではないにしても、どうしてオープンソースがさらに安全性を高めることができるだろうか、と別の記事にも書いています。

どうしてこのことが信頼、特に推移的トラストに関わるのでしょう。
オープンソースとトラストがどうリンクするかについて私はずっと考えていました。大部分が拡散したトラストについてです。
拡散したトラストとブロックチェーンは同じように扱われることが多いです。喜ばしいことです。信頼とはブロックチェーンに確実に関係しているという事実を無視しがちな罠に陥いることが多いからです。暗に言われているだけでちゃんと定義していないからです。

ただし、ここで私が興味を持っているのは、オープンソースソフトを使用するかどうかを選択する方法としての分散した推移的な信頼(トラスト)です。
これは、オープンソースのセキュリティなどの非機能的な詳細についてだけに言えることではなく、ソフト自体の場合についてもです。

「オープンソースソフトを信頼しています」とは、どういうことでしょう?
それは、コードを書きテストをした十分な数の人間が私と同じような要件を提示している。ソフトを使用することのリスクを受け入れることができるだけ十分な経験がその人間にはある。そう私たちが決断しているということと同じなのです。

以下にさらに興味深いことを挙げます。

・ユースケースと要件に合ったデザインがされていると、アーキテクトと設計者を信頼している、ということ
・その設計に合ったようにコードが書かれていると開発者を信頼している、ということ
・お互いのコードのレビューがされていると開発者を信頼している、ということ
・ソフトが正しく文書化されていると、文書化チームを信頼している、ということ
・ユースケースに合ったテストが書かれ、行われ、チェックがされているとテスターを信頼している、ということ
・ユースケースに合った方法でデプロイしているとコードをデプロイした人を信頼している、ということ
・バグレポートをしているとコードをデプロイした人を信頼している、ということ
・バグレーポートを受け取った人がちゃんと修正していると信頼している、ということ

もちろんもっと色々なケースはあるでしょうが、話を進めるには十分でしょう。
ベンダー仕様のソフトを選択すれば信頼関係はもっと明確で絆が強いものでしょう。もし期待した品質のものでなければ別のベンダーに移行するか期待した仕様になるよう元のベンダーに作業するよう言うからです。

オープンソースソフトの場合はもっと漠然としています。
デザイナーやソフトウェアエンジニア、テスターなどの関与した人を見つけることは少なくともできるでしょう。でもその人たちに与える影響力はずっと小さいでしょうね。
おかしなパラドクスがあるのですが、ベンダーソフトには主張できてソフトウェアの方向性に対する影響力は比較的大きいです。(お金がかかってくるので)
ところが、オープンソフトに比べると欲しいものを得る事ができると確信したり、実際何が開発で起こっているかはっきりと見えません。

これはオープンソースだと、「私自身」が上にあげたどの項目にも参加する事ができるからです。
私、もしくは私の所属する組織は、アーキテクトにも設計者にも、文書作成やテスター、もちろんデプロイしたりバグ報告したり、どの役割にもなれるからです。
もしオープンソースへの影響は他の人と同等であれば、分散された信頼は推移する事が少なくなります。

作成、メンテナンス、要件やソフトウェア品質に対してみんな平等で、分散された信頼関係ネットワークの一部になります。
ベンダー仕様のソフトを買った場合に経験するような排除感は減るのです。

では、何故ベンダーからオープンソースソフトウェアを買ったりライセンスを得たりするのでしょう。
それは、そうすることで、上記に挙げた分散された信頼のネットワークの利点を得つつ、サポート、パッチ、トレーニングなど他のリスクを訴えることができるからです。

ソースから直接コードを得ることもできるでしょう。しかしこれはソフトを使用する人たちがそのリスクを選んだということではありません。またこれはオープンソースコミュニティに参加している人たちも例外ではありません。

信頼とは、とても複雑なものです。そして他のものや人を信頼するのも複雑です。別のブログでも少し書きましたが。
ただ私は決定したことに関して、どうして決定したのかと考え理解することは非常に大切なことだと思います。それはリスク周りの情報に基づいた選択をするのに必要だからです。
元の記事 https://aliceevebob.com/2019/06/18/trust-choosing-open-source/
2019年6月18日 Mike Bursell