GitHub Open Source Software Survey 2017

GitHub recently released the results of its 2017 Open Source Survey. The survey is an open data project conducted by GitHub and its collaborators. It was designed to gather data on open source software development practices and communities. Information was gathered about the attitudes, experiences, and backgrounds of those who use, build, and maintain open source software.

The survey discovered that the open source community highly values project documentation (which nevertheless is frequently overlooked), experiences infrequent but highly visible negative interactions, and does not reflect, demographically, the wide usage of open source software around the world.

A summary of the survey results is here.

Open source software risk factors

The risks of using open source software in the development of a new software program have been discussed and debated over and over. Some risks may be exaggerated or misunderstood, but more often than not they are simply ignored. 

A good summary of various risks associated with the use of open source software is included in an SEC filing made by Cloudera, Inc. in connection with its recent IPO. The Risk Factors section of Cloudera’s Form S-1 Registration Statement includes the following risk issues with respect to the commercial use of open source software in hybrid open source-proprietary software products:

  • because of the nature of open source software, there may be fewer technology barriers for competitors who wish to make competing products;

  • lack of control over the future course of development of the open source components used in the hybrid product;

  • if individual open source programmers who are not employees of the company do not continue to develop and enhance the various open source components of the hybrid product, the hybrid product itself may suffer from a lack of further development and enhancement;

  • any court ruling that a certain open source license is not enforceable, or that certain open source components may not be reproduced or distributed, may negatively impact the distribution or development of the commercial hybrid product;

  • for the more widely-adopted open source components, there is a higher risk of intellectual property infringement claims;

  • under the terms of certain open source software licenses, the developer of the hybrid product could be required to publicly release the source code of its proprietary software, and to make proprietary software available under the terms of open source licenses, if the open source software and proprietary software are combined in a certain manner;

  • if the license terms of open source software components change, re-engineering or alternative solutions may be required;

  • developers of open source software generally do not provide warranties, support, or infringement indemnification, but customers who license the hybrid product may demand these items; and

  • if certain open source software is supported by a foundation, the commercial business could be affected by decisions made by the foundation or by claims or disputes involving the foundation.

The Cloudera SEC filing includes more detailed descriptions of these, and other, risk factors.    

Black Duck open source survey

Black Duck Software recently released the results of its Open Source 360° survey. The goals of the survey were to identify areas where open source software development is thriving and the risks associated with the continued growth of open source software. 

One of the most interesting findings of the survey was that 66% of the survey respondents were concerned with the loss of intellectual property or other licensing risks associated with open source software.

Information about the survey can be found at a post under Black Duck’s news blog.

How to save copyleft

In an article published in the International Free and Open Source Software Law Review (Vol. 9, Issue 1), Professor Eben Moglen describes some significant issues he has with the current state of Free Software and copyleft (the article is an edited version of Professor Moglen’s speech at the SFLC Fall Conference 2016). Some in the Free Software movement have expressed concern that the Free Software philosophy, copyleft, and the GPL may be less relevant in today’s open source software environment.

According to Professor Moglen, in order to address this issue, advocates of Free Software should be less concerned with enforcing compliance with the terms of the GPL and more concerned with making the “great idea” of copyleft more appealable to a younger generation of people who write and share programs. In order to do this, copyleft needs to be made “simpler to use, quicker to understand, and better at doing all the jobs it’s supposed to do.”

Professor Moglen states that “[w]e need to refrain from going unnecessarily to war. … This is not war time. This is diplomacy time.” In other words, enforcing compliance with the GPL is not very important when faced with the larger issue of a current lack of interest in, or understanding of, the idea of copyleft and the real benefits of Free Software.

The article can be found here.

Toyota system built on Automotive Grade Linux

Toyota will be including a Linux-powered infotainment system in the 2018 Camry. The system is built on Automotive Grade Linux (AGL), which is supported by the Linux Foundation with the backing of more than 100 automakers, suppliers, and tech firms. The Toyota implementation is the debut of the AGL platform. The platform will also soon be integrated into vehicles from Ford, Mercedes Benz, and Mazda.

Automotive Grade Linux is a project at the Linux Foundation that is planning the open source development of all software systems in vehicles, including software for connected cars and autonomous driving. 

The Artifex case and dual licensing

The initial court ruling in the Artifex v. Hancom case suggests a point in favor of using a dual licensing plan for open source software. Artifex offers a commercial license for its Ghrostscript product for customers who wish to use Ghostscript in their own commercial products. There is a license fee for a commercial license. Artifex also offers use under the Affero GPL for those who do not want to pay for a commercial license.

Artifex’s allegations against Hancom included a breach of contract claim. One of the key factors in the court’s decision to allow this claim to go forward was Artifex’s dual licensing plan. The allegations regarding Artifex’s dual licensing structure (including the fee for the commercial license) were, according to the court, sufficient to plead damages for Artifex’s breach of contract claim.

This ruling means that a dual licensing plan (a commercial license for a fee along with a no-fee open source license) could be helpful in proving damages in the event a breach of contract claim is filed against a commercial user who improperly relies on a no-fee open source license as authorization for using another party’s open source software when a commercial license is available.

DoD open source license procedure

When the U.S. Department of Defense launched its open source project in February, 2017, the intent was to use a proposed Defense Open Source Agreement (DOSA) for project contributors in an attempt to use contract law to “attach” open source licenses to individual projects. The DOSA was proposed as an alternative to using an existing open source license or creating a new one. DoD allowed a short period of time for the public to comment on the proposed agreement.

After receiving public comments on the proposed DOSA, DoD decided to move away from the proposed agreement and contract law in general and focus on the contribution process itself. Now the plan is to use widely-adopted open source licenses for projects when copyright is applicable. The intent is to not attach licenses to code written by government employees because code written by government employees within the scope of their employment is not eligible for copyright protection under U.S. law. For contributions that do qualify for copyright protection, a Developer Certificate of Origin will be used to designate a license.

The Developer Certificate of Origin asserts and provides that the code contributor is the creator of the contribution (or has the authority to distribute it) and that the contributor is making the contribution available under the specific license associated with the project.

More information can be found on the github FAQ page.