Skip to main content
Category

Featured

OpenChain Specification Bi-Weekly Call #2 – Fourth Monday June 2020 – Full Recording

By Featured

The full recording of the 2nd OpenChain Specification bi-weekly call is now available. This call went over the general parameters of the editing process for the next generation of the OpenChain specification. Our goal is to ensure all comments and suggestions can be captured.

Join the next call on the second Monday of July at 9am Pacific.

Join the Meeting via Zoom

Open Source Compliance のお圹立ち情報たずめ・䞋

By Featured

はじめに

この蚘事では、Open Source Compliance に取り組む䞊で、圹に立った情報や、圹に立぀よず玹介頂いた情報をたずめたす。この蚘事にあるものだけが党おではありたせんが、いくらかでもお圹に立おば幞いです。
なお、本皿䞭の OSS はずくに断りがなければ Open Source Software を意味したす。

この蚘事は党䜓で䞊䞋2郚構成になっおいたす。

Open Source Compliance のお圹立ち情報たずめ・䞊 (前の蚘事) 

  • Open Source & Compliance
  • Open Source Software
  • Open Source Software License
  • ツヌルなど

Open Source Compliance のお圹立ち情報たずめ・䞋 (この蚘事)

  • 業界的な集たりなど
  • むベントや䌚合など
  • ニュヌスや曞籍など

Open Source Compliance のお圹立ち情報たずめ・䞋

業界的な集たりなど

Open Source Compliance に぀いお、特定の業皮による団䜓や、特定の目的のための団䜓が知られおいたす。

Fintech Open Source Foundation (FINOS)

金融業界を䞭心ずしおOSSの利甚を促進する団䜓です。”Open Source License Compliance Handbook” などを公開しおいたす。

Open Invention Network (OIN)

OIN参加䌁業同士は Linux Stystem ãšã—お定矩される OSS に぀いお自瀟が保有する関連特蚱に関しお争わないずするコミュニティです。蚭立圓初は Microsoft 察 Linux 陣営の構図でしたが、2018幎10月にMicrosoftが加入したこずで、この構図は NPEs* 察 OIN参加䌁業に倉わっおいくのかも知れたせん。
(*: Non-Practicing Entities、いわゆるパテントトロヌル)

参考 Steven J. Vaughan-Nichols , “Open Invention Network comes to GNOME’s aid in patent troll fight“, ZDNet, 2019.

Unified Patents

NPEsぞの各皮察抗措眮ずしお、先行技術調査、蚎蚟の分析、USPTO(米囜特蚱庁)の審刀郚(Patent Trial and Appeal Board: PTAB)に圓事者レビュヌ(Inter Partes Review: IPR)を提出するなどで特蚱無効化を図ったり、NPEず亀枉するなどのサヌビスを提䟛したす。2019幎には察象ずする技術領域に Open Source ãŒè¿œåŠ ã•ã‚ŒãŸã—た。
掻動状況のダッシュボヌドずしお PORTAL ãŒã‚り、そのペヌゞの最䞋郚に “Daily Update Email Archive” ぞのリンクがありたす。たた、PATROLL ã§ã¯ã€å…ˆè¡ŒæŠ€è¡“調査のコンテストに関する情報が埗られたす。

むベントや䌚合など

䌚っおでないず話せないこず、䌚っおコミュニケヌションが深たるきっかけになったり、参加したから知るこずができるこず、などがありたす。郜合が぀けば、こうした集たりに足を向けおはどうでしょうか。 䌚合によっおは Chatham House ã§ã®æƒ…報亀換の取り決めに由来する Chatham House Rule ã«åŸ“うこずを求めるものがありたす。

When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.
(参考蚳䌚議あるいはその䞀郚であっおも Chatham House Rule に埓う堎合、䌚議参加者はその䌚議で集たった情報を自由に利甚できる。しかし、(情報提䟛者ずなる)発蚀者に぀いおは勿論のこず、他のいかなる䌚議参加者に぀いおも、その身元(玠性)や所属を挏らしおはならない。)

このルヌルに぀いおは Chatham House Rule FAQ ã‚‚読んでおくず良いでしょう。信頌できる仲間だからこそ話せるこずもある、ずいったずころでしょうか。

Linux Foundation events

Linux Foundation が開催する次のむベントでは、セッションのトピックや、䌚合それ自䜓が Compliance をテヌマずするものがありたす。

Open Source Summit

毎幎、Japan、North America、Europe などの各地域で開催されたす。スピヌチやセッションによっおは、講挔ビデオや資料が公開されたす。Compliance をトピックずするセッションがありたすが、Keynote やそれ以倖のセッションでは実に様々なトピックが扱われ、゚ンゞニアに限らず様々なバックグラりンドの参加者が集たるので、 情報収集やネットワヌキングに有益です。2019幎はすべお終わり(Japan(7月)North America(8月)Europe(10月))、2020幎の開催がすでに案内されおいたす(North America(6月)Japan(9月)Europe(10月))。

Open Compliance Summit

名称が瀺すずおり、Compliance を䞻テヌマずするむベントです。毎幎日本で開催されたす。招埅状を申し蟌む必芁があり、その参加には “Chatham House Rule” に同意する必芁がありたす。 本皿執筆時点で次回は 2019幎12月17-18日に開催されたす。

オヌプン゜ヌスラむセンス研究所

ほが毎月、次の勉匷䌚や分科䌚が開催されおいたす。新着情報に開催案内がありたす。資料の共有範囲は参加者に限定されるので、興味がある方は参加しおみおください。

ラむセンス深掘り勉匷䌚

OSSラむセンスを䞀文ず぀読み、参加者同士で知芋を共有したり議論する集たりです。匁護士も参加されるので法的な芖点でのお話を䌺うこずも出きたす。議論を通じお理解が曖昧な郚分が浮かび䞊がる時は、これたでの自身の実務でどうだったかを振り返るよい機䌚になりたす。

OLL技術甚語解説分科䌚

OSSラむセンスに関わる法務や知財の担圓者向けに、技術甚語の理解のための補助資料を䜜成する集たりです。

OpenChain Japan Work Group (JWG)

再掲になりたすが、JWG にはいく぀かの Sub Work Group の掻動がありたす。関心があれば気軜に参加頂ければず思いたす。  

ニュヌスや曞籍など

近幎、Open Source Software の提䟛元がそれたでのラむセンスを倉曎しお新たなラむセンスを䜜成する事䟋が芋られたす。そうした情報の収集にはむンタヌネットの利甚が欠かせたせん。

技術系のニュヌスサむトは芋おいおも良いず思いたす。二぀以䞊のサむトを利甚されおいれば、Open Source Compliance で話題になりやすいラむセンスに぀いおは時期に差があるもののおそらく蚘事ずしお目に觊れるのではないかなず思いたす。ずくにお薊めできるサむトずいうのは気にしたこずがないのですが、英語圏のものが早いかなずは思いたす。なお、日本語で読めるものの䟋だず OSDN Magazine の ラむセンスカテゎリの蚘事などがありたす。

僕自身は、Google アラヌトを “open source” や “OSS” などのキヌワヌドで掻甚しおいたす。

䞀方で、必ずしも最新の話題がないずしおも、たずたった情報をざっず読み通せるずいうこずで曞籍を利甚する方もいるでしょう。䞀郚、僕が未読のものもありたすが、僕が参加する集たりで話題に挙がったものも含めお玹介したす。出版元を芋぀けられなかったもの以倖は、リンク先を出版元にしおいたす。お手数ですがご賌入の際はご利甚されおいる販売店やそのサむトでお求めください。

OSSラむセンスの教科曞

著 䞊田理、監修 岩井久矎子
出版瀟 技術評論瀟 
2018幎に出版なので、今回玹介する日本語曞籍の䞭では新しいものです。䞻な Open Source Software License の特城ず、䌁業が Open Source Software を掻甚する䞊でのポむントを解説しおいたす。冒頭の岩井匁護士による解説蚘事は、゚ンゞニアが法務・知財郚門のスタッフずコミュニケヌションを取る前の読み物ずしおお勧めできたす。
なお、著者の䞊田さんは先に玹介した ã€Œã‚ªãƒŒãƒ—ン゜ヌス゜フトりェアラむセンス遵守に関する䞀般公衆ガむド (pdf)」 ã®äœœæˆã®ãƒªãƒŒãƒ€ãƒŒã§ã™ã€‚

ずころで、僕は JIPA ゜フトりェア専門委員䌚にも参加しおいるのですが、そこに参加する他䌁業の知的財産郚員でも読んでいる方が倚いです。読者の近くに知財郚員の方がいれば、JWG に䞀床顔を出しおみおはどうかず案内しお頂けるず幞いです。

角川むンタヌネット講座 ネットを支えるオヌプン゜ヌス ゜フトりェアの進化

監修 た぀もず ゆきひろ、他著
出版瀟 KADOKAWA/角川孊芞出版
(恐瞮ながら僕は未読です。JWG で話題に出たこずがあったので玹介したす)

2014幎に出版で、それたでのオヌプン゜ヌスずそれを取り巻く゜フトりェア開発の歎史を俯瞰できるようです。
第2郚では、ラむセンス、ブラりザ開発動向、䌁業におけるオヌプン゜ヌスずの付き合い方、などの話題を扱っおいたす。

なお、著者の䞀人のやたねさんは、䌁業所属゚ンゞニアか぀ Debian JP Project のコミッタヌずしお双方の芖点で JWG に知芋を䞎えおくれる貎重な存圚です。ただ、やたねさんのような方は貎重すぎお JWG の各掻動でなかなかお䌚いできないので、読者の䞭で我こそはず思う方は JWG に参加ください。もちろん OpenChain に興味があるずいうずころからの参加も倧歓迎です。

知る、読む、䜿う オヌプン゜ヌスラむセンス

著 可知豊
出版瀟達人出版䌚
2011幎に出版で、電子曞籍ずしお賌入出来たす。
Open Source Software License で利甚䟋が倚いず思われる MIT、BSD系、MPL-2.0、GPL系などを抂芁を掎むには䟿利です。

Understanding Open Source and Free Software Licensing

Author: Andrew M. St. Laurent
Publisher: O’Reilly Media (July 2008)

著者は米囜匁護士です。米囜著䜜暩法に関連した知識を螏たえお OSS ラむセンスを理解するのに利甚したした。
Open Book版 ã‚‚ありたす。

Open Source for Business: A Practical Guide to Open Source Software Licensing 2nd edition

Author: Heather Meeker
Publisher: CreateSpace Independent Publishing Platform; 2nd edition (April 4, 2017)
著者は TLDRLegal ã«ã‚‚参加しおいる米囜匁護士です。こちらも米囜著䜜暩法に関連した知識を螏たえお OSS ラむセンスを理解するのに利甚したした。

Open Source Compliance in the Enterprise (2nd edition)

Author: Ibrahim Haddad, PhD
Open Source の利甚に圓たっお必芁ずなる、それが䜕かを具䜓的に識別(Identification)し、 どのようなものかを監査(Audit)し、問題点の敎理等々に始たる䞀連の工皋においお、そこでのプロセスや泚意点、たた、ツヌルや参考情報などが埗られたす。

Assessment of Open Source Practices as Part of Due Diligence in Merger and Acquisition Transactions (2nd edition)

Author: Ibrahim Haddad, PhD
Merger and AcquisitionM&Aでの Due Diligence で Open Source 関連事項を評䟡する時のポむントが敎理されおいたす。

明日のテヌマは

「オリンパスずOpenChainずの関わり」です。
担圓の小泉さんは、JWG で4぀の SWG に参加されるなど八面六臂に掻躍されおいたす。オリンパス瀟はグルヌプずしおグロヌバルに Open Source Program Office の䜓制を構築し運甚されおいるので、その䞀端を垣間芋るこずが出来るかもしれたせん。お楜しみに

おたけ自己玹介

忍頂寺です。所属等は別蚘事「Open Source Compliance のお圹立ち情報たずめ・䞊 (12/14公開蚘事)」を参照ください。

OpenChain Reference Tooling Work Group – Meeting #17 – Full Recording

By Featured

The OpenChain Reference Tooling Work Group held its 17th meeting on the 17th of June.

You can find the recordings of the morning and the afternoon sessions as well as the presentation slides here:

https://github.com/Open-Source-Compliance/Sharing-creates-value/tree/master/Tooling-Landscape/Meeting-Material/Meeting-20200617

Catch up on minutes from all previous meetings

Guest Blog – OpenChain: Open Source Compliance Comes of Age In the Supply Chain

By Featured

ISO Standard Imminent

This is a guest post from Matthew Jacobs, Esq., Director, Legal Counsel at Synopsys Software Integrity Group. The views in this guest post are those of the author alone.

The goal of the Linux Foundation’s OpenChain Project, and the specification it maintains, is to promote predictability and uniformity in the management of open source. It aims to also create consistency in how critical open source compliance information is collected and retained so that it may be properly communicated to others.

The specification is gaining momentum and will likely be adopted by the International Organization for Standardization by mid-2020. With open source use on the rise and more and more demanding proof of compliance becoming mainstream, this is a perfect time to reevaluate how you address compliance. But first, let’s explore an illustrative analogy.

The automotive supply chain.

Car recalls are costly and time-consuming events. However, considering the complexity of today’s vehicles and the number of components found in the average vehicle, recalls often seem strikingly well organized. In particular, the level of detail and granularity in the typical recall notice speaks to the information that must be obtained by automotive manufacturers from their multitudes of suppliers, and then maintained and stored regarding the elements composing the bill of materials (BOM) of each car.

The very fact that recalls are successful at keeping the public safe is a testament to the incredible level of information sharing from supplier to customer and the standards and trust between the parties. Parts from different tiers of the automotive supply chain, and the component sub-elements of those parts (and so on), must be identified and important information about those parts shared up and down the supply chain. Given the sheer volume and complexity of this, and the rapid evolution of the industry, an automotive manufacturer must rely heavily on their suppliers to provide comprehensive and accurate information concerning that supplier’s respective elements. The final BOM for a given vehicle is dependent on comprehensive information communicated in a common language by members throughout the vast supply chain.

Contrast this to software.

Much like assembling a vehicle, modern software development involves software components from a wide variety of sources. This may be third-party commercial code, “homegrown” code or, as is very often the case, significant amounts of open source code. Tracking the provenance of the multitude of software parts and pieces that make up the modern software programs that we interact with and rely upon is often murky at best.

This challenge is clearly compounded by the fact that each component of software, with its own constituent elements, is then rolled up into a more complex assembly with other software elements. Further, since an ever-growing amount of this software is open source which, by design, is the product of often many mostly anonymous contributors, it quickly becomes easy to see how assembling a reliable BOM for today’s software programs is a daunting challenge.

Open source challenges.

Developers are encouraged to reuse open source to do their jobs better, faster and cheaper. There are around 8,000 source forges housing over 500 billion (and growing) lines of open source code to use. Importantly, those reusing open source must confirm initially, and on an ongoing basis, that they are reusing that open source in compliance with the governing open source license terms and conditions. Given that there are approximately 2,700 different flavors of open source licenses, a real challenge arises in (1) managing these compliance risks at an enterprise scale and pace, and (2) effectively communicating to third parties what open source is being used, what license applies and if the user is complying with the applicable license.

Given the critical nature of open source in software development, and the large and growing amount of open source in use, the need to be able to express what open source is being used (the BOM) and any license compliance obligations associated with that use, in addition to the need to be able to communicate that information in a standardized way is key to the free flow of software components in the software supply chain. And, to avoid “garbage in, garbage out” customers need to have confidence in the information received from suppliers based on trust in the compliance processes employed upstream. The OpenChain Project has emerged as the leading voice in bringing organization and certainty to the tracking and communication of open source reuse.

The OpenChain Specification (now in version 2), as described by the OpenChain Project, defines “the key requirements of a quality Open Source license compliance program. The objective is to provide a benchmark that builds trust between organizations exchanging software solutions comprised of Open Source software”. The specification sets forth a basic set of open source management best practices and methods for communicating open source component information, all aimed at furthering that trust.

Managing open source risk.

The value of this trust cannot be understated. Again, much like the automotive supply chain, the software supply chain is highly interdependent and complex. Historically, customers attempted to mitigate their risk during the contract negotiation process by forcing their suppliers to make certain disclosures, representations and warranties concerning that supplier’s software product and the supplier’s compliance with any open source licensing requirements for the open source in that supplier’s product. Supplier’s often don’t have the requisite insight into the composition of their own code, especially as it relates to open source, to make these types of representations and warranties with certainty but bow to economic and time pressure to close a deal.

Occasionally, customers will enlist firms like Synopsys to perform an independent audit of their supplier’s code to confirm that the disclosures made by the supplier concerning the open source in their products is accurate. The purpose of an audit is to identify the open source in the supplier’s code and determine which one of the many open source licenses apply to that code to evaluate the supplier’s compliance with the obligations of the applicable license. It also, by implication, gives customers a sense for how well the supplier is managing compliance. This “trust but verify” approach is certainly warranted in some situations. But, given the pace of commerce, there is often little time for comprehensive due diligence in many of the routine day to day transactions.

Elements of the OpenChain specification and compliance.

The OpenChain specification short-cuts much of the negotiation around a supplier’s open source compliance by offering a basic set of understandings around how each member of the supply chain uses and tracks what open source is present in their products. The specification is comprised of two basic elements: First, an ongoing open source license compliance process (which may include the use of automated open source management tools) for identifying what open source is in that member’s code and verifying that the use of that open source complies with the applicable license for that code. Second, the specification requires an organizational commitment to adherence to the first element by establishing areas of responsibility within an organization for compliance and an organizational commitment to training, process and open source compliance support.

Executing on these two basic elements of OpenChain compliance requires effort. Just because open source software may be freely available does not mean there are no obligations. However, many companies lack the basic process and software tools for identifying what open source their engineers are reusing in the first place. Without that visibility, there is no opportunity to manage the use.

Next, after properly identifying what open source their developers are using and how that open source is being used, compliance requires accurately identifying what license applies to that code, understanding the requirements of that license and taking the necessary steps to adhere to those requirements. Based on the nature of the open source license, this may include something as simple as providing attribution to something more complicated such as having to disclose source code.

A supplier’s ability to certify OpenChain compliance affords their customer comfort and removes open source compliance-related friction from the supply chain. Downstream customers can enjoy a level of comfort that, by incorporating the supplier’s code with their own, they won’t be inadvertently exposing themselves, any further upstream members of the supply chain or, ultimately, the end user to compliance-related litigation or remediation risk and expense.

There are third parties available to help you through your license compliance journey. Law firms that can assist with training, tools and services. Vendors such as Synopsys can audit your code or provide software tools to support in identifying and tracking open source reuse during software development.

OpenChain compliance as a competitive edge.

While compliance is an important goal, and while companies are keen to steer clear of potential litigation, an exceptionally important element of OpenChain compliance is as a competitive differentiator. Companies that have achieved OpenChain compliance are encouraged to advertise that fact and leverage that status in the marketplace as an asset.

Influential companies such as Toyota, Hitachi, Panasonic, Qualcomm, and Bosch are putting top-down pressure on their vendors, and in turn on suppliers to those vendors to demonstrate open source management consistent with the OpenChain Specification. This results in lower tier vendors, who may have never considered open source compliance as an urgent priority, now finding themselves under increasing pressure from other members of the supply chain.

Hans Malte Kern, Head of the Center of Competence Open Source at Bosch underscores this point. “We’re excited to join the OpenChain project, as it reflects the importance of compliant open source usage, distribution and contribution. Instead of negotiating the open source requirements with all our partners and suppliers, Bosch will leverage OpenChain as an open standard that provides common approaches and understanding for open source collaborations – not only in the automotive industry but also the connected world of IoT. We are convinced the OpenChain standard will replace bilateral negotiations, educations and open source risk mitigation discussions.”

OpenChain as an ISO standard.

The value of being able to tout compliance will take on additional importance as by mid-2020 it is expected that OpenChain Specification version 2.1 will be adopted by the International Organization for Standardization and certified as an ISO standard. Many suppliers are familiar with the experience of responding to customer requests for proposals or quotes. These requests are often multi-part questionnaires requiring the supplier to report on various elements of the supplier’s business concerning such aspects as privacy, security and compliance-related matters.

Given the time pressure often associated with closing deals, making the open source management and compliance discussion short is highly valuable. The ability to reply affirmatively to open source compliance questions and confirm compliance with the pending ISO standard will, in the words of one observer, “take the issue off the table.”

OpenChain Webinars # 5 & 6 – Survey Results

By Featured

We had five speakers over two events covering a range of global and regional topics:

Let’s start with overall satisfaction, 1 being satisfied and 5 being extremely satisfied:

Let’s dive into how people felt about the relevance of the talks, 1 being low relevance and 5 being extremely relevant:

Let’s get more specific on relevance per topic, which shows global talks having global relevance, and regional talks have substantial but not blanket relevance:

This results map to our expectations and will help shape future events. We also asked for general written feedback as an option and got some encouraging messages:

OpenChain Korea Work Group – 6th Meeting – Recording

By Featured

The OpenChain Korea Work Group will hold its 6th meeting via UberConference on the 16th of June at 2pm Seoul time. This event will be held in the Korean language and will provide an excellent opportunity to learn what companies like Kakao and SK Telecom are doing around open source compliance.

  • How to join on PC
    (1) PC에서 https://uberconference.com/openchainproject 접속
    (2) Settings 에서 마읎크와 슀플컀 섀정 확읞
    (3) Name 입력 후, “Join Now” 큎늭하여 입장 
  • How to join on Phone
    (1) 핞드폰에서 02-6022-2388로 전화
    (2) 855 889 3011 # 입력

Learn More

Webinar: OpenChain China, Japan, Korea – a discussion on community building

By community, Featured, licensing, News, standards, Webinar

In this webinar we covered “OpenChain China, Japan, Korea – a discussion on community building” featuring short interviews with Jerry (China), Haksung (Korea) and Fukuchi San (Japan) about local community activity. Our goal was to share knowledge on what has worked, what has not, and how momentum can be kept in these unusual times. We hope these lessons will assist our fellows in Europe and North America while also illustrating some of the key successes in Asia.

This is part of the bi-weekly OpenChain Webinar series. Every two weeks we have international speakers covering a wide range of topics related to practical open source compliance challenges, solutions and considerations.

Check Out The Rest Of Our Webinars

This is OpenChain Webinar #6, released on 2020-06-22.

Open Source Compliance のお圹立ち情報たずめ・䞊

By Featured

はじめに

この蚘事では、Open Source Compliance に取り組む䞊で、圹に立った情報や、圹に立぀よず玹介頂いた情報をたずめたす。この蚘事にあるものが党おではありたせんが、いくらかでもお圹に立おば幞いです。
なお、本皿䞭の OSS はずくに断りがなければ Open Source Software を意味したす。

この蚘事は党䜓で䞊䞋2郚構成になっおいたす。

Open Source Compliance のお圹立ち情報たずめ・䞊 (この蚘事) 

  • Open Source & Compliance
  • Open Source Software
  • Open Source Software License
  • ツヌルなど

Open Source Compliance のお圹立ち情報たずめ・䞋 次の蚘事)

  • 業界的な集たりなど
  • むベントや䌚合など
  • ニュヌスや曞籍など

Open Source Compliance のお圹立ち情報たずめ・䞊

Open Source & Compliance

Open Source やその Compliance が倧切ずされる背景を把握したい堎合は、OpenChain Japan Work Group (JWG) による ã€Œã‚ªãƒŒãƒ—ン゜ヌス゜フトりェアラむセンス遵守に関する䞀般公衆ガむド (pdf)」 ãŒè¶³ãŒã‹ã‚Šã«ãªã‚‹ã‹ã‚‚しれたせん。

このガむドは English(pdf) ã‚„ 䞭囜語(繁䜓字(pdf)ず簡䜓字(pdf)) に翻蚳されおいたす。Open Source Summit 2019 (North America (8月)、Europe (10月))にお印刷媒䜓で配垃したずころ、各囜の゚ンゞニアたちが手にし、オフィスや取匕先で配りたいず耇数郚を持っお垰った方もいたした。

Open Source Compliance

Open Source Compliance に぀いお、”ORGANIZATIONS“、”PROJECTS“、”DEVELOPERS” などのカテゎリに分かれお敎理されおいるので、興味のあるずころから芋おみるず良いかも知れたせん。 

Open Source Guides For The Enterprise

䞊蚘のコンテンツよりも、より䌁業向けに Open Source を適切に掻甚するために必芁ずなるこずを網矅的に敎理しおいたす。Open Source を管理運甚するための機関ずしお Open Source Program Office (OSPO) の導入、Open Source プロゞェクトの運営、情報入手のための web サむト、参考曞籍など、ほが揃っおいたす。日本語版 ã‚‚ありたす。
䜜成は埌述する TODO Group ã«ã‚ˆã‚‹ã‚‚のです
(この蚘事の圹割は䞊蚘のサむトの玹介でほが達成しおいる…かも知れたせん)

Open Source Guides

OSS 開発者向けのガむドです。Open Source プロゞェクトを新しく始める堎合、コミュニティの運営、プロゞェクトの Metrics、そしお法的な芳点などで泚意すべきこずなど、䞀通りの内容を含むので、個人、コミュニティ、䌁業のいずれの立堎でも参考にできるかず思いたす。

OpenChain project

Open Source License Compliance をサプラむチェヌンで䞀貫しお果たすために必芁ずなる、教育甚の資料、䌁業内の䜓制や運営のための仕様、そしお、先に挙げた仕様に぀いお䌁業や事業又は補品における適合性などを確認する手段、などを策定し普及を図るプロゞェクトです。OpenChain Specification の最新版は v2.0 (pdf) ã§ã€è‹¥å¹²ã®æ”¹èš‚を経た v2.1 をもっお ISO Joint Technical Committee 1 (JTC-1) での Publicly Available Specification (PAS) ずしおの芏栌化に向けお取り組んでいたす。wiki ã‚µã‚€ãƒˆã§ã¯ã€å„ Work Group の掻動サマリ、参加方法、䌚合の開催案内などがありたす。

Japan Work Group (JWG) の掻動に぀いおは、このAdvent Calendar 2019 の 12/1-9たでの蚘事 ã‚’ご芧ください。JWG には Linux Foundation の䌚員ではなくおもコミュニティメンバヌずしお参加や貢献できるため、興味や悩みがある人はメヌリングリストやSlackに参加しお、JWG の総䌚や各 Sub Work Group (SWG) の䌚合に足を運んでみおください。

TODO Group

䌁業で Open Source プロゞェクトをよりよく運営するために、䌁業間で経隓、ベストプラクティスやツヌルなどに関しお情報亀換するグルヌプです。TODO Guides ãšã—お提䟛されおいる情報もありたすが、冒頭で玹介した Open Source Guides For The Enterprise ãŒç¶²çŸ…的なので芋おみおください。参加者は、䞻に䌁業の Open Source Program マネヌゞャヌが想定されおいたす。

CHAOSS project

Open Source Project の健党性に぀いお、その Metrics や蚈枬方法などの実珟を図るプロゞェクトです。Open Source Software を察象ずした評䟡手法に関心がある方は芋おみるず良いかも知れたせん。䟋ずしお Risk WG が策定する Metrics を挙げるず、Business Risk、Code Quality、LicensingTransparency ãªã©ãŒã‚りたす。

LINUX FOUNDATION: SECURITY, COMPLIANCE & PROJECT HEALTH

OpenChain Project、TODO Group、CHAOSS project ã®ã„ずれも Linux Foundation ã®å–組です。これら以倖にも関連するカテゎリのプロゞェクトが玹介されおいたす。OpenChain ず特に関連するプロゞェクトに SPDX ã‚„ FOSSology ãŒã‚りたす。

䌁業事䟋

他瀟がどのように取り組んでいるのかを芋るのは、ずおも参考になりたす。䌁業名ず “open source” ずいった甚語を組み合わせお怜玢するず、いろいろず芋぀かるでしょう。たた、GitHub にある䌁業のレポゞトリを芋るのも良いでしょう。その䞭には、OSSを掻甚するための取り組み方を玹介するものもありたす。そうした䟋には次のようなものがありたす。

  • Google 瀟の Google Open Source ã«ã‚ã‚‹ Docs ã¯ç€Ÿå†…向け資料を元にしおいるらしく、”License” など参考になる内容がありたす。
  • Microsoft 瀟は Open Source Blog ãªã©ã§å–組を玹介しおいたすが、FAQ 圢匏で OIN ぞの加入に぀いお玹介する蚘事(1)が投皿されおいたりしたす。たた、Open Source Security ã§ã¯è„†åŒ±æ€§å¯Ÿç­–などのセキュリティに関する蚘事や、AI や IoT の発展に欠かせない Sharing Data に぀いおは Removing barriers to data innovation ã§4皮類の Data Use Agreement を提案しおいたす。 ((1): Microsoft joins OIN: FAQs with Erich Andersen)

Open Source Software

利甚したい OSS に぀いお調べる時、ラむセンスは䜕か、い぀頃公開されたもので掻動はどの皋床なのか、などを把握する必芁がありたす。
゜ヌスコヌドを芋るのも倧切ですが、ひずたずざっくりず知りたい時もありたす。そうした時、npm, maven (䟋ずしお MVN repositroy), cocoapds, あるいは OS の distribution の䟋だず debian の packages ã‚„、プログラミング蚀毎にあるパッケヌゞ管理システムやそのサむトから情報を埗たり、GitHub ã§å…¬é–‹ã•ã‚ŒãŠã„る堎合は Star 数や Commit 動向などの統蚈情報も掻甚するこずがあるでしょう。
ここでは、先に挙げた以倖でそうした調べ物に圹に立぀サむトを玹介したす。

Open Hub

OSS の個別プロゞェクトに぀いお、開発者、ラむセンス、公匏サむト、アクティビティ、コミュニティなどの抂況を把握するのに䟿利なサむトです。必ずしも党おの OSS を網矅しおいたせんが、ここで出おこない OSS の利甚は泚意する、ずする方針の䌁業があるず聞いたこずがありたす。

OSS Radar Scope

独自のレヌティングに基づいおの OSS の評䟡を、ランキングずレヌダヌチャヌトで芋られるので、類䌌する OSS を探したり、比范するのに䟿利なサむトです。こちらも党おの OSS を網矅しおいたせんが、OSS 遞定で参考にする䌁業があるず聞いたこずがありたす。

Libraries.io

“その OSS ãŒ äŸå­˜ã™ã‚‹ OSS” 又は “その OSS ã« äŸå­˜ã™ã‚‹ OSS” を把握したい時に䟿利なサむトです。
こちらも同じく、必ずしも党おの OSS に぀いお怜玢できるものではないです。

Software Heritage

゜フトりェアの゜ヌスコヌドを文化遺産ずしお保存する事業によるもので、以前は公開されおいた゜フトりェアが芋぀からない堎合に䟿利なサむトです。䌌たようなサむトに、Internet Archive による Wayback Machine ãŒã‚りたすが、そちらよりも゜フトりェアに特化しお収集しおいるのが特城です。

ClearlyDefined

FOSS (Free Open Source Software) の掻甚で重芁ずなるラむセンス情報や脆匱性情報を明確にするために、コミュニティでそうした情報の確からしさを向䞊させる取組です。OSS が芋぀かっおも情報が䞍足しおいる堎合、蚘茉事項ずしお提案できるこずがあれば貢献するず良いかも知れたせん。

Open Source Software License

たいおい、OSS には利甚蚱諟条件ずしおのラむセンスが宣蚀されおいたす。そしお、ラむセンスでは、どのような目的でどのような䜿い方が蚱諟されおいるのか、たた、そのために利甚者が果たすべき矩務などが明蚘されおいるこずでしょう。そうしたラむセンスに぀いお理解を深めたい時に参考ずなるサむトを玹介したす。

ラむセンスの解釈では、条文(原文)、その条文(原文)が䜜成された背景、その OSS にそのラむセンスが宣蚀された背景、コミュニティの動向などが重芁な芁玠になるかず思いたす。堎合によっおは䜜成や宣蚀に至る議論やその議論ぞの圱響が想定される囜又はそのOSSを利甚するであろう囜における法什や刀䟋の動向にも気を぀けるこずがあるかも知れたせん。法務郚や知財郚、匁護士、匁理士等の法埋の専門家に盞談するのは倧倉重芁な手段で、そうした時でも、先に挙げた芁玠を敎理怜蚎しおおくず良い時がありたす。ラむセンスによっおは公匏の翻蚳版があっおも、原文のみを有効ず宣蚀しおいるものもあるので泚意するず良いでしょう。

ずころで、OSS プロゞェクトが GitHub に登録されおいる堎合、issues で “is:issue license” などを怜玢しおみるず、堎合によっおはそのプロゞェクトがラむセンスを遞択する過皋を芋るこずができるかもしれたせん。気になるずきは詊しおみおください。


その前に: OSS ラむセンスの特城をざっくりず掎みたい

原文等の䞀次情報は重芁ですけど、ざっくりずでもよいので、ラむセンスの抂芁を把握したい時っおありたすよね。
そういう時は、次のサむトや情報が参考になるかも知れたせん。

TLDRLegal

ラむセンスに぀いお “Can”、”Cannot”、”Must” の項目に分けお特城を敎理しおいたす。
その内容に぀いお匁護士や専門家などによるレビュヌ枈みの堎合はそのこずが明瀺されたす。
レビュワヌの䞀人の Heather Meeker ã•ã‚“は、別蚘事で玹介する Open Source For Business の著者です。

chooselicense.com

Open Source Project で宣蚀したいラむセンスを遞ぶ際のお助けサむトです。
利甚を蚱諟したい条件に応じお、近しいラむセンスを芋぀けるこずが出来たす。
ラむセンスに぀いお “Permissions”、”Conditions”、”Limitations” の項目に分けお特城を敎理しおいたす。

Open Source Automation Development Lab (OSADL)

OSS を自動化などの産業掻甚を掚進するこずを目的ずする組織で、その芳点で様々な取組をしおいたす。
この蚘事では、Open Source License Checklistsず、Open Source License Checklists – Access to raw data ãšã‚’玹介したす。ずくに、raw data はラむセンスの内容に぀いお、”USE CASE” ずそれに応じた矩務を構造的に敎理しおいたす。詊しに、MIT ãš Apache-2.0 ãš GPL-3.0 ãšã‚’芋比べおみおください。


Open Source Initiative

OSS の普及促進を目指す組織で、”Open Source Definition” などの取組で知られおいたす。OSI が認定するラむセンスのリストにあるかを確認するこずに利甚される方も倚いようですが、License Review ã‚„ License Discuss ãªã©ã®ãƒ¡ãƒŒãƒªãƒ³ã‚°ãƒªã‚¹ãƒˆã®ã‚¢ãƒŒã‚«ã‚€ãƒ–から個々のラむセンスの議論を远うのもラむセンスぞの理解を深めるために参考になるでしょう。 最近は、News ã®ãƒšãƒŒã‚žã§æœˆæ¯Žã®ã‚µãƒžãƒªãŒé…ä¿¡ã•ã‚Œã‚‹ã®ã§äŸ¿åˆ©ã§ã™ã€‚

GNU Licenses

GNU Public LicenseGPLの最新版は GPL-3.0で、その掟生である GNU Lesser General Public License の最新版は LGPL-3.0, GNU Affero General Public License の最新版は AGPL-3.0 ã§ã™ã€‚それら以前のラむセンスを宣蚀する OSS も倚く芋られたす。

GPL の解釈では、次のコンテンツを話題にするこずが倚いように思いたす

詳现に觊れたせんが、GPL に関しおは、違反時の回埩条件に関する動きも知っおおくず良いかも知れたせん。

こうした動きの背景に関心がある方は “copyright troll” などの情報を調べおみおください。

APACHE LICENSE

正しくは APACHE LICENSE, VERSION 2.0 (Apache-2.0) ã§ã™ã€‚
ラむセンスの原文ず同様に FREQUENT QUESTIONS ABOUT APACHE LICENSING ã‚‚参考になりたす。

近幎、コントリビュヌションの際に Contributors License Agreement (CLA) ぞの同意を求める OSS が芋られたすが、Apache Software Foundation (ASF) が䜜成した CONTRIBUTOR LICENSE AGREEMENTS ãšæ¯”范しおみるず良いかも知れたせん。あわせお、FREQUENT QUESTIONS ABOUT ASF CONTRIBUTION AGREEMENTS ã‚‚参考になりそうです。

Mozilla Public License

最新版は MPL-2.0 ã§ã™ã€‚ MPL 2.0 FAQ ã‚‚参考になりたす。それ以前の版は Mozilla Public License Version 1.1 (MPL-1.1) ã§ MPL 1.1 FAQ- HISTORICAL USE ONLY ã‚‚公開されおいたすが、その改蚂の経緯に関する Historical Licensing Documents ã‚‚参考になるでしょう。

Eclipse Public License

正しくは Eclipse Public License – v 2.0 (EPL-2.0) ã§ã™ã€‚
ラむセンスの原文ず同様に Eclipse Public License (EPL) Frequently Asked Questions ã‚‚参考になりたす。それ以前の版は、Eclipse Public License – v 1. (EPL-1.0) ã§ Eclipse Public License 1.0 (EPL) Frequently Asked Questions ã‚‚ありたす。

Eclipse Foundation も Eclipse Contributor Agreement ãš Eclipse Contributor Agreement (ECA) FAQ ãšã‚’公開しおいたす。たた、Eclipse Foundation Project のもずで OSS プロゞェクトを再配垃(redistribution)する時は、Third Party Content Licensesにも泚意するず良いでしょう。

Creative Commons License

Creative Commons ã¯å‰µäœœç‰©ã‚„知芋などの共有や再利甚の促進を目的ずしお、いく぀かのラむセンスを定矩しおいたす。ラむセンスは “Attribution (by)”、”ShareAlike (sa)”、”NonCommercial (nc)”、”NoDerivatives (nd)” などのLicense Condition ã®çµ„合せで構成され、最新版は4.0です。たた、”Public Domain” を宣蚀するためのものずしお CC0 ã‚’定矩しおいたす。Frequently Asked Questions ã‚‚ありたす。

“NonCommercial (nc)” の定矩や解釈に぀いおは、次の参考情報も提䟛されおいたす。

ずころで、質問 “What are Creative Commons licenses?” に察する回答の䞭に次の䞀文がありたす。

The only categories of works for which CC does not recommend its licenses are computer software and hardware.
(参考蚳CC (ラむセンス) をお薊めしないカテゎリの創䜜物はコンピュヌタ゜フトりェアやハヌドりェアです。)

僕は CC BY-NC-SA を宣蚀する OSS に遭遇しお驚いたこずがあるのですが、最初の公開から数幎埌に BSD 2-Clause “Simplified” License (BSD-2-Clause) に倉曎されおいたした。

さお、䞊蚘以倖で、OSS での CC ラむセンスの利甚事䟋にどのようなものがありそうでしょうか。

先に囜毎の法什等の違いに泚意が必芁な堎合があるず述べたしたが、”Public Domain” は著䜜暩法などの関係でそうした話題の䞀぀ずしお知られおいたす。そこで、OSS の著䜜暩者が著䜜暩等を行䜿しないこずを宣蚀する手段ずしお CC0 を甚いる事䟋が芋られたす。

たた、開発者同士で情報亀換するサむトで、曞き蟌みを CC BY-SA で扱うずする利甚芏玄のものを芋たこずがありたす。そうしたサむトで玹介されおいるコヌドを snippet ずしお拝借する時は泚意が必芁そうですね。

サヌバヌサむドで利甚する゜フトりェアのラむセンスに぀いお

サヌバサむドでの利甚を察象ずした OSS ラむセンスに AGPL などがありたすが、近幎はクラりドによるサヌビス提䟛を意識したラむセンスが芋られるようになっおきたした。ここでは、䟋を幟぀か挙げおおきたす。


補足: Open Source License に関する議論など

ラむセンスに぀いおどのようなこずが問題ずなりそれをどう怜蚎するのかは、専門家や先達の知芋が参考になりたす。
OSS ラむセンスに関わる法什等で囜毎に違う郚分があるかも知れたせん。そうした点も考慮しながら、ラむセンスの条文や、次に玹介する議論や怜蚎を読むず良いでしょう。

copyleft.org

copyleft.org は copyleft ラむセンスに関する情報提䟛を目的ずするプロゞェクトです。Copyleft ず GPL に぀いおたずたった文曞に次がありたす。

Software Freedom Law Center (SFLC)

SFLC は Free, Libre and Open Source Software (FLOSS) プロゞェクトに察しお法的アドバむスなどで支揎するこずを目的ずする組織です。代衚者は Columbia Law School で Professor of Law を務める Eben Moglen 氏です。
GPL に関する文曞が倚くありたすが、僕がずくに参考にしたものを玹介したす。

SOFTIC: IoT 時代におけるOSSの利甚ず法的諞問題Q&A集

䞀般財団法人 ゜フトりェア情報センタヌ (SOFTIC) が立ち䞊げた 「IoT 時代における OSS の利甚ず法的リスクに関する怜蚎委員䌚」 での怜蚎結果を QA 集ずしお纏めたものです。委員䌚メンバヌは法埋専門家ず䌁業実務担圓者で、OSS を利甚する䞊での法的諞問題やビゞネスを展開する䞊での疑問点に぀いお、提䟛者や利甚者の立堎での論点が取り䞊げられおいたす。序文に各執筆者の総意を纏めたものではないずある通り、そういう芋解もある、ずしお怜蚎材料にするのが良い䜿い方のように思われたす。

IPA OSSラむセンス関連情報

独立行政法人 情報凊理掚進機構 (IPA) が過去に取り組んだ調査事業にOSSラむセンスを察象ずしたものがありたす。
過去に囜内であった議論や怜蚎を把握したい時に参考になる情報が埗られたす。
たずえば、次のような文曞が公開されおいたす。

専門誌など

日本匁理士䌚(JPAA)の䌚誌である「月刊パテント」は非䌚員でも閲芧出来る蚘事がありたす。䟋えば、2006幎06月号に 「オヌプン゜ヌス゜フトりェアのラむセンスず特蚱暩」ずいう蚘事がありたす。

日本知的財産協䌚JIPAは、知的財産に関する諞制床の掻甚や改善を図っお囜内産業の発展ぞの寄䞎を目的ずしお囜内䌁業が参加する団䜓です。䌁業知財郚門らが䌁業の枠を超えお調査研究する堎になっおいたす。機関誌「 çŸ¥è²¡ç®¡ç†ã€ã‚’党お読みたい堎合は䌚員䌁業であっおも賌入する必芁がありたすが、囜䌚図曞通などで閲芧するこずも出来たす。たずえば、バックナンバヌを怜玢しおみるず、68å·»(2018幎)/5号に「OSSラむセンス遵守のための基瀎知識」ず題した論文が掲茉されおいるようです。


ツヌルなど

OSS がどのラむセンスに基づいお提䟛されおいるのか、OSS が䟝存する他の OSS にどのようなものがあるのか、は、重芁な情報です。ここでは、情報の定矩や情報亀換のためのフォヌマット、そうした情報を怜出するための OSS などを玹介したす。

なお、AyumiWatanabe ã•ã‚“の蚘事「OSS管理のベストプラクティスOSS管理ツヌルの遞び方 (12/11公開蚘事)」 では商甚補品ぞのリンクがあるので、興味のある方はそちらもご芧ください。

SPDX

“Software Data eXchange Package” は、SBOM (Software Bill of Materials) に぀いお情報亀換するための仕様であり、コンポヌネント、ラむセンス、著䜜暩、セキュリティ等々の情報を扱えるようになっおいたす。最新の仕様は2.1版で、 Frequently Asked Questions (FAQ) ãŒã‚りたす。SPDX License List ã§ “Full name” や “Identifier” が芋られたす。なお、この蚘事の執筆珟圚で、3.0版に向けた怜蚎が始たっおいたす。

先の “Identifier” は正しくは “SPDX short-form identifiers (SPDX ID)” ず呌びたすが、人やスキャンツヌルなどでも刀別しやすいように、SPDX ID の利甚を掚奚する取組も芋られたす。興味がある方は REUSE SOFTWARE ã‚’ご芧ください。

FOSSology

゜ヌスコヌドをスキャンしお、ラむセンス、著䜜暩衚瀺、茞出管理(Export Control: EC) に関連する情報を抜出したす。
倣うより慣れろな方は Get Started With FOSSology ãš Hands-On Training Support Page ãªã©ã®ãƒšãƒŒã‚žãŒå‚考になるず思いたす。

利甚事䟋に興味がある方は、y-ashiduka ã•ã‚“の蚘事「Yocto環境にmeta-spdxscannerを適甚し、SPDX出力環境を構築するfossdriver利甚線(12/10公開蚘事)」 もご䞀読ください。

ScanCode

゜ヌスコヌドをスキャンしお、ラむセンス、著䜜暩衚瀺、䟝存に関連する情報を抜出したす。
FOSSology ずは怜出アルゎリズムが異なるこずに䌎う怜出結果の違いから、䜿い分ける利甚者もいるようです。

参考たでにですが、ラむセンス情報のスキャン粟床に関する考察に Thomas Wolter による “A Comparison Study of Open Source License Crawler” ずいう論文がありたす。

SW360

FOSSology や ScanCode を始めずする各皮ツヌルを連携し、SBOM管理を効率化するためのカタログツヌルずしお開発されたものです。
K-Hama ã•ã‚“が、「OSS管理ツヌル SW360 – オヌプン゜ヌスをオヌプン゜ヌスで管理しよう 1.1 新バヌゞョンむンストヌル線」ずいう蚘事や、利甚方法を蚘したドキュメント ã‚’公開しおくれおいるので、興味のある方はご䞀読ください。

OSS Review Kit (ORT)

OSS のレビュヌプロセスを支揎するため、”Analyzer”、”Downloader”、”Scanner”、”Evaluator”、”Reporter” などのツヌル矀で構成されおいたす。

明日のテヌマは

「Open Source Compliance のお圹立ち情報たずめ・䞋」です。
匕き続き僕が担圓したす。情報収集やネットワヌキングに圹立぀むベントや、曞籍や文曞など知識を埗るのに利甚したものを玹介しようず思いたす。お楜しみに

おたけ自己玹介

忍頂寺毅ず申したす。
以䞋は、本皿執筆時点のものになりたす。

所属は株匏䌚瀟ディヌ・゚ヌ・゚ヌ システム本郚 CTO宀です。
䞻に知的財産やコンプラむアンス関連の業務に埓事しおいたす。
2019幎2月から OpenChain Japan Work Group にコミュニティメンバヌずしお参加しおいたす。
同幎4月より JIPA ゜フトりェア専門委員䌚にお2019幎床テヌマずしお OSS ず䌁業知財に関する調査研究に参加しおいたす。
前職は通信䌚瀟で研究開発郚門に長くいたした。むンタヌネット構築運甚、HCI、移動機端末開発や関連する暙準化、モバむル AR ずいった PoC (Proof of Concept) のためのサヌビス詊䜜開発などに埓事しおいたした。

OpenChain Japan Work Group – 15th Meeting (2nd Virtual) – Recording

By Featured

The OpenChain Japan Work Group hosted its 15th meeting (2nd virtual) at 2pm local time on the 18th of June. The majority of the meeting was held in Japanese but as always foreign guests were welcome to join and ask questions or share news in English.

Review the Slides

Learn More About Japan Work Group Activities