Displaying posts tagged GPL
Congratulations to Tesla on Their First Public Step Toward GPL Compliance
byon May 18, 2018
Conservancy rarely talks publicly about specifics in its ongoing GNU General Public License (GPL) enforcement and compliance activity, in accordance with our Principles of Community Oriented GPL Enforcement. We usually keep our compliance matters confidential — not for our own sake — but for the sake of violators who request discretion to fix their mistakes without fear of public reprisal. As occurred a few years ago with Samsung, we're thrilled when a GPL violator decides to talk about their violation and works to correct it publicly. This gives us the opportunity to shine light on the real-world work of GPL and copyleft compliance.
We're thus glad that, this week, Tesla has acted publicly regarding its current GPL violations and has announced that they've taken their first steps toward compliance. While Tesla acknowledges that they still have more work to do, their recent actions show progress toward compliance and a commitment to getting all the way there.
Conservancy has been engaging with Tesla on its GPL compliance since June 2013, when we advised Tesla that we had received multiple reports of a GPL violation regarding Tesla's Model S. Customers who purchased Tesla's Model S received on-board system(s) that contained BusyBox and Linux, but did not receive any source code, nor an offer for the source. In parallel, we also asked other entities to advise Tesla about GPL compliance. We know that Tesla received useful GPL compliance advice from multiple organizations, in addition to us, over these years.
For our part, since we first contacted Tesla, we have been working with them collaboratively in various ways to convince their original upstream providers, NVIDIA and Parrot, to disclose complete, corresponding source (CCS) releases for all GPL'd binaries found in Tesla's Model S. During that time, Tesla privately provided Conservancy with multiple rounds of “CCS candidates“. (These are source code releases that are not yet complete and corresponding as required by the GPL.) Conservancy in turn reviewed their CCS candidates and provided technical feedback on how to improve the candidates to reach compliance. In this process, we provide detailed reports explaining how the candidate releases fall short of GPL's requirements. This part of the process is the longest, most difficult part of GPL enforcement. We often wish we could celebrate the triumph of moving from a no-source-or-offer violation to the next step of “incomplete sources provided”1. However, we also can't lose sight of the fact that compliance means meeting all GPL's requirements, so we don't convey false hopes with an incomplete release. We must ultimately remain focused on user freedom in our efforts.
This week, Tesla took a new and different approach. Tesla elected to publish its incomplete CCS candidates, on the online software development collaboration site, GitHub. While our preference is that companies provide adequate CCS immediately, we realize that this can be a challenging process and recognize that Tesla has struggled for years with upstreams to yield proper CCS. We believe Tesla's new approach also has merit, because it allows the entire community to discuss and contribute in public and collaboratively assist Tesla in complying with the GPL. In a case like this, engagement in the community may be an ideal way to transparently assure that compliance is achieved.
We look forward to facilitating Tesla with this new approach to compliance. Toward that end, Conservancy has created a public mailing list to discuss Tesla's source release (and, ideally, to also discuss other CCS candidates if other GPL violators choose to also take this approach.) The first post to this mailing list is our CCS candidate evaluation report 1, written by our Compliance Engineer, Denver Gingerich.
CCS reports have been the standard document of GPL enforcement since 1998. Conservancy has probably produced hundreds of such reports since we began. However, this marks the first time that circumstances have allowed us to share such a report with the public without violating our Principles. We're excited to do that, thanks to Tesla's willingness to engage everyone in their GPL compliance process.
We know many of you, particularly those Linux-savvy folks who bought Tesla vehicles, have reached high levels of frustration with the lengthy time this GPL compliance effort is taking. Nevertheless, this situation shows precisely why patience is essential for successful enforcement work; it gives us the opportunity to welcome violators to become contributors to the copyleft software community. Our community's history is filled with such success stories. To that end, we ask that everyone join us and our coalition in extending Tesla's time to reach full GPL compliance for Linux and BusyBox, not just for the 30 days provided by following GPLv3's termination provisions, but for at least another six months.
We welcome those interested in the CCS evaluation process to join the mailing list, as this marks one of the few opportunities to engage pubilcly in CCS evaluation. Additionally, anyone who holds copyrights in Linux may join our enforcement coalition of Linux Developers by writing to <email@example.com>
1 While Tesla partly corrected the violation yesterday by making some offers for source, the source provided is not complete, corresponding source with complete “scripts used to control compilation and installation of the executable”. Denver's email outlines the specific, current compliance failures.
Copyleft compliance misconception #1: Companies check their source builds before publishing
byon February 15, 2018
We often hear from people that are confused about why companies fail to meet their copyleft compliance obligations - it seems fairly straight-forward to do, so why don't they all do it? In its many years of experience attempting to help companies comply with the GPL and other copyleft licenses, Conservancy has seen first-hand how many of the expectations software users have about how a company would release source tend to not be met the majority of the time. This post is Conservancy's first in a series on these common misconceptions about copyleft compliance, which will hopefully provide some insight for people wondering why these expectations are seemingly seldom met.
Misconception #1: Companies check their source builds before publishing
If you use or develop free and open source software, you probably find it natural for software projects to make building and installing their software as easy as posssible (or at least to provide contact points in case it is not). This is because getting people to use or contribute to such projects depends on these projects being straight-forward to build and install, otherwise people would just use something else (since normally they would have little invested in a project they can't build or install).
As a result, when companies publish source code as a result of their obligation to comply with the copyleft licenses in the software they distribute (usually this is their primary motivation - in rare cases (so far as we see it) companies are motivated primarily by engaging with the free software community, which we naturally try to encourage as much as possible), they do not have the same incentives as you would normally expect of a project distributing free and open source software. Consequently, companies tend to spend most of their time ensuring that whatever product they're selling to you (be it a router, Blu-ray player, smartphone, etc.) performs the functions it's intended to perform and meeting their bare obligations when it's shipped. They don't spend very much time working on the build and installation experience for those who would like to modify the software running on it after they receive it.
Furthermore, determining which parts of the device's overall build and installation process a company considers to be confidential is often not done, or is done under pressure so close to release time that the company does not wish to try untangling the portions they consider confidential from the portions that they are required to release in order to fulfill their obligations under the copyleft licenses for the software they chose to use.
What we normally see as the outcome of this (in the hundreds of source releases we've evaluated) is that the source code companies provide is nowhere close to meeting the requirements of GPLv2 (which is the copyleft license we most often see being violated), which state that companies must provide "the complete corresponding machine-readable source code" for all the GPLv2-licensed software on the devices they distribute and that "The source code for a work means the preferred form of the work for making modifications to it [which includes] the scripts used to control compilation and installation of the executable."
There are a variety of reasons that a company's source release might fail to meet the above requirements. In many cases we find that the versions of the source packages they provide are nowhere close to the versions of the binaries they distribute. Or their source release is missing entire source packages - i.e. they distribute a binary for Copylefted Project A, but do not provide any source code for Copylefted Project A, even though they might include source for Copylefted Project B.
Even if the above issues are not present, most often we find that there are no scripts at all for installing the software on the device (either in machine- or human-readable form), and any scripts we might find for controlling compilation of the executable are little more than what the original maintainers of the source package provided (which normally means people outside the company shipping the device). As a result, the compilation does not succeed because any changes the company made to the original source package are not considered in the build instructions (the company likely got it to build at least once, in order to ship it on the device, but decided not to document or share that process in their source release). This is particularly frustrating to the people who report the violations to us, as they often want access to the source code to do something particular with the devices they own.
After seeing this pattern in dozens of different source releases from dozens of different companies, it is clear to us that companies do not normally check to see if the source they release can actually be built and installed. Rather than being motivated primarily by meeting the perceived legal requirements of copyleft licenses and thus releasing markedly incomplete source code, our hope is that more companies will start to see the primary motivation for source releases as a way of engaging with the free software community, from which correct build and installation instructions (and indeed fully compliant source releases!) will naturally follow. We've already seen community development projects like SamyGo and OpenWRT form around Samsung TVs and Linksys routers and we hope other companies will see the benefits and help build such communities right from the start.
How Additional Permissions (aka Exceptions) Impact a Project's License
byon October 20, 2017
When first learning about FLOSS (Free, Libre and Open Source) licenses,
most of us learned them by their specific names, and generally when someone
What license is your project under?, the answer is a short
GPLv3-or-later. However, since the
earliest advent of FLOSS licenses, the concept of “additional
permissions ” — or, the older term for it:
“exceptions” — have been an essential part of the
licensing infrastructure of our community.
The first additional permission for a copyleft license dates back to the Bison license. Since the 1980s, the GNU project gave an exception to the GPL for Bison to assure that typical uses of Bison — which copy some of Bison's own source code into the program's output — did not cause the GPL to apply to that output. This exception was simple, straightforward, and necessary. Users of parser generators would be surprised to learn that using Bison to generate their parser would cause their work to be governed by copyleft. Additional permissions are a scalpel-like tool for authors of copylefted software that carefully craft project policy to best fit their community. Indeed, these exceptions became such an important component of GPLv2 licensing that GPLv3 formalized the concept in the actual license text, defining the term “additional permission ” in GPLv3 itself.
This name better described the purpose of these clauses. Historically, the FSF called them “exceptions”. Throughout the 1990s and early 2000s, software authors deployed these solutions in creative ways, and it became clear that the phrase “license exception” was a poor descriptor (particularly given that “taking exception” is often considered a bad thing)! Slowly, the term “additional permission” became preferred.
Additional permissions are now quite prevalent. Some pursue esoteric policy goals, but most are simply stated and achieve a narrow goal. While additional permissions often make it impossible to name a project's license as simply “GPLv2-only”, the intended policy is usually clear by quickly reading the additional permission(s).
By way of example, despite our common shorthand of saying that Linux's
license is GPLv2-only, the details are more complicated. Linux's license has a
additional permission regarding syscalls. Specifically, this
additional permission states that the copyleft terms
do not cover user
programs that use kernel services by normal system calls. This means
that even though GPLv2 is a strong copyleft and seeks to apply to any
derivative and/or combined work with Linux under copyright, downstream may
license parts of combined works that
use kernel services by normal
system calls under terms other than GPLv2. While some contributors'
code in Linux is licenses without this additional permission (such as plain
GPLv2-only), most Linux contributors license their copyrights under
“GPLv2 with the syscall exception”.
This week, the Linux community began a process to add another additional permission to Linux's license. As with the syscall exception (and any other additional permission), copyright holders must opt-in to grant this additional permission (and a long list of copyright holders have already done so for the new Statement). Conservancy has lauded this effort, since this additional permission allows violators (in some cases) to officially receive permission from those copyright holders to operate under the GPLv3 termination provisions. Copyright holders who participate in Conservancy's GPL Compliance Project for Linux Developers have long followed this, anyway (first informally, and then more formally in adherence to our Principles of Community-Oriented GPL Enforcement). The Linux Kernel Enforcement Statement formalizes this practice as an opt-in additional permission for Linux's license.
Fortunately, copyleft-based additional permissions (aka license
exceptions) aggregate reasonably well. Specifically, additional
permissions are fully compatible with the main copyleft license. At their
option, downstream can usually remove the additional permission and
distribute under the main license. Sometimes, licensing experts will talk
effective license of a work. In practice this means:
given a codebase that combines copyrighted material under many different
licenses, and possibly many different additional permissions and
exceptions, what's the lowest common denominator licensing requirement
that, if met, will satisfy all the licensing requirements of all of the
relevant licenses? With most copylefted works, this often does simplify to those easier
This begs the question: what's the effective license of Linux? Well, more than likely, it's simply GPLv2-only. The reason is this: all the copyrighted code that comprises Linux is (at least) licensed under GPLv2-only. A overwhelming majority is under “GPLv2 with the syscall exception”, and (with this week's announcement) an ever-growing swath will be licensed under “GPLv2 with the syscall exception and with the Linux Kernel Statement additional permission”. Not every copyright holder whose code is in Linux will grant either exception. Thus, the abbreviation to GPLv2-only, as a moniker for Linux's effective license, remains accurate.
Additional permissions are handy tools when building a community around a codebase, particularly when some community members have reservations about some aspect of the standard copyleft license. Copyright holders can grant an additional permission — even one that isn't strictly necessary — to quell concerns and clarify the licensing infrastructure.
Finally, all this begs one more question: Why aren't additional
permissions to copyleft licensing (particularly after they were formalized
in detail as part of GPLv3 itself) more widely utilized? My anecdotal
theory is that licensing remains a difficult area of comprehension for
FLOSS contributors and adopters. Like everyone whose primary expertise
lies elsewhere, licensing novices prefer simple buckets that are easily
understood; difficult concepts often dive deeper than necessary for typical
daily work. While licensing geeks like me enjoy pondering and exploring
the flexibility provided by additional permissions, many developers prefer
a simple moniker to describe a project's license. As such, you'll even
hear licensing experts oversimplify to describe a project's license. As
one of my undergraduate Computer Science professors said to me,
professors will oversimplify until you're graduate students, because we've
yet to figure out the topological sort necessary to tell you the whole
story in proper order such that we avoid these oversimplications that make
Goodbye To Bob Chassell
byon July 3, 2017
It's fortunately more common now in Free Software communities today to properly value contributions from non-developers. Historically, though, contributions from developers were often overvalued and contributions from others grossly undervalued. One person trailblazed as (likely) the earliest non-developer contributor to software freedom. His name was Robert J. Chassell — called Bob by his friends and colleagues. Over the weekend, our community lost Bob after a long battle with a degenerative illness.
I am one of the few of my generation in the Free Software community who had the opportunity to know Bob. He was already semi-retired in the late 1990s when I first became involved with Free Software, but he enjoyed giving talks about Free Software and occasionally worked the FSF booths at events where I had begun to volunteer in 1997. He was the first person to offer mentorship to me as I began the long road of becoming a professional software freedom activist.
I regularly credit Bob as the first Executive Director of the FSF. While he technically never held that title, he served as Treasurer for many years and was the de-facto non-technical manager at the FSF for its first decade of existence. One need only read the earliest issues of the GNU's Bulletin to see just a sampling of the plethora of contributions that Bob made to the FSF and Free Software generally.
Bob's primary forte was as a writer and he came to Free Software as a technical writer. Having focused his career on documenting software and how it worked to help users make the most of it, software freedom — the right to improve and modify not only the software, but its documentation as well — was a moral belief that he held strongly. Bob was an early member of the privileged group that now encompasses most people in industrialized society: a non-developer who sees the value in computing and the improvement it can bring to life. However, Bob's realization that users like him (and not just developers) faced detrimental impact from proprietary software remains somewhat rare, even today. Thus, Bob died in a world where he was still unique among non-developers: fighting for software freedom as an essential right for all who use computers.
Bob coined a phrase that I still love to this day. He said once that the
job that we must do as activists was “preserve, protect and promote
software freedom”. Only a skilled writer such as he could come up
with such a perfectly concise alliteration that nevertheless rolls off the
tongue without stuttering. Today, I pulled up an email I sent to Bob in
November 2006 to tell him that (when Novell made their bizarre
software-freedom-unfriendly patent deal with Microsoft)
had coopted his language in their FAQ on the matter. Bob wrote
I am not surprised. You can bet everything [we've ever come up
with] will be used against us. Bob's decade-old words are prolific
when I look at the cooption we now face daily in Free Software. I acutely
feel the loss of his insight and thoughtfulness.
One of the saddest facts about Bob's illness, Progressive Supranuclear Palsy, is that his voice was quite literally lost many years before we lost him entirely. His illness made it nearly impossible for him to speak. In the late 1990s, I had the pleasure of regularly hearing Bob's voice, when I accompanied Bob to talks and speeches at various conferences. That included the wonderful highlight of his acceptance speech of GNU's 2001 achievement award from the USENIX Association. (I lament that no recordings of any of these talks seem to be available anywhere.) Throughout the early 2000s, I would speak to Bob on the telephone at least once a month; he would offer his sage advice and mentorship in those early years of my professional software freedom career. Losing his voice in our community has been a slow-moving tragedy as his illness has progressed. This weekend, that unique voice was lost to us forever.
Bob, who was born in Bennington, VT on 22 August 1946, died in Great Barrington, MA on 30 June 2017. He is survived by his sister, Karen Ringwald, and several nieces and nephews and their families. A memorial service for Bob will take place at 11 am, July 26, 2017, at The First Congregational Church in Stockbridge, MA.
In the meantime, the best I can suggest is that anyone who would like to posthumously get to know Bob please read (what I believe was) the favorite book that he wrote, An Introduction to Programming in Emacs Lisp. Bob was a huge advocate of non-developers learning “a little bit” of programming — just enough to make their lives easier when they used computers. He used GNU Emacs from its earliest versions and I recall he was absolutely giddy to discover new features, help document them, and teach them to new users. I hope those of you that both already love and use Emacs and those who don't will take a moment to read what Bob had to teach us about his favorite program.