オープンソースソフトウェア取引の落とし穴というPodcastがあったのでメモ。
オープンソースソフトウェアを用いる場合の契約条件として挙げられているものに、事前に使えるものをリスト化する、プロバイダーが情報権利（どのオープンソースパッケージが使用されているか、どのバージョンで、どのように使用されているかなど）を提供する義務を設定しておく等がありました。
These days the terms in contracts regarding open source are much more nuanced to manage risk.
There can be a preapproved list of open source and uses, and I'd say more often than not customary warranties of compliance and indemnities do not explicitly exclude open source software, but it really depends on the parties on the deal and, and you know, depends on what's appropriate for the parties at the time. We are also seeing more open source-specific contractual provisions come into play. For instance, an obligation for the provider to provide information rights (e.g. what open source packages are used, what versions, how they're used) and that is very important many times to facilitate the clients being able to comply with open source licenses that are relevant. We talk to the customer and the provider as clients and look for what's appropriate in a given deal.
Navigating Open Source Pitfalls in Transactions | Perspectives & Events | Mayer Brown
プロバイダーが情報権利（どのオープンソースパッケージが使用されているか、どのバージョンで、どのように使用されているかなど）を提供する義務を設定しておくというのは、特許庁のモデル契約書でも条項がおいてあったりすので検討してもよいかもしれませんね。
共同研究開発契約書ver2.0（AI編）
ai-v2-kyoudou_chikujouari.pdf (jpo.go.jp)
またイレギュラーなものとして、自社プログラムはクライアントに直接配布し、オープンソースソフトウェアは配布せず別途クライアントにダウンロードしてもらうという離れ業も紹介していました。こちらは、コンプライアンス的には大丈夫か疑問が残りますが、発想としては面白かったです。
It's not always the case. We've seen some pretty creative practical approaches to deal with open source issues. For example, we had a client that was trying to sell a software package that included copyleft open source, and, in order to avoid an argument that our client distributed the copyleft code and, with it, all the integrated proprietary code, our client persuaded the buyer that it was in the interest of both parties for our clients to transfer only the proprietary system code and let the buyer itself download the open source copyleft code and rebuild the product. Doing that also avoided an automatic grant of a patent license. There was skepticism at first, but, when people understood the open source issues at hand, they were very in favor of a creative way to avoid them.
Navigating Open Source Pitfalls in Transactions | Perspectives & Events | Mayer Brown
その他、セキュリティ関係では、タイポスクワッティング（typosquatting）という悪意のあるコードをオリジナルに含ませ、オリジナルと間違いやすい名前で再度コードを公開するということがオープンソースでも起こっているそうです。
Then there's what is sometimes referred to as typosquatting. Here, a hacker downloads the code, injects malware into it, and puts it back on the internet for others to download, but with a slightly modified name to trick careless developers. So, for example, instead of a package called Julian.js it may be Jullian.js or julian.js. And of course, the hacker isn't just necessarily doing this once. It may create a multitude of packages with lookalike names to fool unsuspecting developers. This is a significant problem today, in part because we don't have the equivalent of an iTunes store for open source, where a central authority reviews and verifies what's available for download.
Navigating Open Source Pitfalls in Transactions | Perspectives & Events | Mayer Brown
実際に事件も下記のように起きているようです。
オープンソースのコードの身元が正しいかは中央集権的にチェックする人がいないので、個人でも組織でもオープンソースを使う際は注意が必要だと感じました。
