As of today, all new Red Hat-initiated open source projects that opt to use GPLv2 or LGPLv2.1 will be expected to supplement the license with the cure commitment language of GPLv3. The cure language will live in a file in the project source tree and will function as an additional permission extended to users from the start.
This is the latest development in an ongoing initiative within the open source community to promote predictability and stability in enforcement of GPL-family licenses. The “automatic termination” provision in GPLv2 and LGPLv2.x is often interpreted as terminating the license upon noncompliance without a grace period or other opportunity to correct the error in compliance. When the Free Software Foundation released GPLv2 in 1991, it held nearly all GPL-licensed copyrights, in part a consequence of the copyright assignment policy then in place for GNU project contributions. Long after the Linux kernel and many other non-GNU projects began to adopt the GPL and LGPL, the FSF was still the only copyright holder regularly engaged in license enforcement. Under those conditions, the automatic termination feature of GPLv2 section 4 may have seemed an appropriate means of encouraging license compliance.
By the mid-2000s the FSF had come to see the potential unfairness of automatic termination. Distribution of Linux-based products containing large numbers of GPL and LGPL-licensed components, under highly diverse copyright ownership, had become commonplace, and indeed was the cornerstone of Red Hat’s own business. Automatic license termination, as commonly understood in the community, meant that a single act of inadvertent non-compliance could, in theory, give rise to a large number of infringement claims, with no obligation on the part of copyright holders to notify the alleged violators prior to seeking legal recourse. With the publication of GPLv3 in 2007, the FSF introduced a modified termination policy that included mechanisms for license reinstatement where compliance errors were promptly fixed. But the large and ever-growing corpora of GPLv2 and LGPLv2.x-licensed code remained under the earlier approach. For some time, the FSF’s position was that developers and users concerned about this situation should upgrade to GPLv3 -- but that was not always possible or desirable.
In 2016 the FSF, along with the Software Freedom Conservancy, announced the Principles of Community-Oriented GPL Enforcement -- partly in response to tactics being employed by one litigant in the German courts. Among other things, the Principles call for extending GPLv3-style termination to GPLv2 works. By the end of 2017, over a hundred individual Linux kernel developers had signed on to a commitment advanced by the TAB to extend the GPLv3 cure provisions to all users of the kernel. Then, in a series of announcements, 10 major technology companies led by Red Hat (see November 2017 and March 2018 announcements) committed to extending the GPLv3 cure provisions to all their GPLv2, LGPLv2.1 and LGPLv2.0 code. Our new effort to promote adoption of the cure provisions directly by new Red Hat community projects takes this one step further.
We’ve also been working with existing Red Hat-led GPLv2/LGPLv2.1 projects to help them adopt the cure commitment. WildFly, GlusterFS and Pulp—providing core components of our JBoss Middleware, Red Hat Gluster Storage and Red Hat Satellite products—have done so. Some other projects we’ve been engaged with include Anaconda, Candlepin, Cockpit and Koji. If you maintain a GPLv2 or LGPLv2.x-licensed project, you may wish to adopt the cure commitment too. For now, you can do so by copying the text WildFly and GlusterFS are using; we anticipate that the standard commitment text for project use will be maintained in the GPL Cooperation Commitment repository hosted on GitHub.
You might wonder why Red Hat would bother to encourage adoption of the cure commitment on a project basis, given that we’ve already made our corporate commitment, or why we don’t just prohibit use of the v2 licenses in favor of their v3 successors or some non-copyleft alternative. This requires some understanding of Red Hat corporate culture.
License selection is a form of legal decision making, but for as long as I’ve been at Red Hat, engineers have been given significant discretion to choose licenses for the projects they maintain, within certain boundaries (for example, expectations to pick from a small set of widely-used, de facto standard licenses). This reflects not only our corporate traditions of developer empowerment, but also our view that engineers typically have the greatest competence to determine the appropriate license strategy for growing user and contributor communities around their projects. Earlier in Red Hat’s history, there was actually an expectation that our projects would be licensed under GPLv2, or LGPLv2.1 for libraries. While many Red Hat engineers continue to prefer these licenses, over the past several years growing numbers of Red Hat projects have been selecting GPLv3, the Apache License 2.0 and the MIT license. A prohibition on GPL-family licenses altogether might, unfortunately, be unworthy of comment in some other companies, but for Red Hat it would be unthinkable.
Because many Red Hat engineers continue to select GPLv2 or LGPLv2.1 for their projects, those projects over time are likely to incorporate contributions under those licenses from copyright holders other than Red Hat. That is largely because our projects use an “inbound=outbound” approach to contributions (increasingly along with the DCO). Were we to use asymmetrical contributor license agreements for our projects, as many other technology companies do, termination and enforcement of licenses by other copyright holders would be a non-issue for code specifically contributed to the project (though it would still be relevant for other third-party code copied into the project). But we have determined that the disadvantages of CLAs generally outweigh whatever benefits they are thought to have. For GPLv2 and LGPLv2.1 projects, then, adoption of the cure commitment at the outset will mean that all the GPL/LGPL license grants flowing into the project from contributions will be subject to the additional permission grant which the commitment represents.
We are extending the GPLv3 termination policy to users of our GPLv2/LGPLv2.1 code because we consider it the right thing to do. The cure permissions offer additional comfort that users of our code have reasonable assurances of quiet use of that code, even if there is a temporary license noncompliance by a third party redistributing our code, due to misunderstanding or otherwise. We also believe that community adoption of these rights will reduce the opportunity for illegitimate forms of license enforcement. We hope that others will also join in this endeavor to reassure the open source community that good faith efforts to fix noncompliance will be embraced
저자 소개
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.