Distributions
Copyright assignment and license enforcement for Debian
At DebConf 2015 in Heidelberg, Germany, Bradley Kuhn from the Software Freedom Conservancy (SFC) announced a new collaboration with the Debian project through which Debian contributors can engage the SFC to act on their behalf to conduct license-compliance efforts. The Debian Copyright Aggregation Project (DCAP) is a voluntary program, but it gives interested Debian developers a means to help ensure that others do not violate the licenses under which their work is published.
Kuhn's session was held on August 15. A video recording [WebM] has since been published, and an announcement has been posted on both the Debian and SFC web sites.
In his talk, Kuhn noted that Debian is one of the few free-software projects to have a fully democratic governance model and that it has remained a "staunchly non-commercial" project since the beginning. Those factors underscore Debian's concern for doing "the morally correct" things important to the hobbyist contributor. That is, Debian is composed of volunteers who make their contribution to Debian their first priority, with any affiliation to an employer coming after that. Consequently, Debian still acts on behalf of individual developers' wishes where a commercial entity might not.
Although Debian is fundamentally about people, he said, the project's most visible assets are those people's copyrights on the software in the Debian archive. Partnering with SFC on the Debian Copyright Aggregation Project is a way for individual developers to leverage those assets "to maximize fair treatment of others"—namely, by ensuring that the copyrights of individual Debian contributors are not violated by third parties failing to adhere to the terms of the relevant software license. The DCAP arrangements were agreed to in April by SFC and then Debian Project Leader (DPL) Lucas Nussbaum, with consultation from Software in the Public Interest (SPI).
DCAP has three dimensions. First, SFC can now accept copyright-assignment agreements from any Debian contributors who choose to participate. Participants can assign any subset of their copyrights that they choose to SFC. Second, any contributors who are not interested in assigning copyrights (which is an essentially permanent arrangement) also have the option of signing an enforcement agreement, under which the contributor can ask SFC to represent it as an "authorized copyright agent" in license-enforcement actions. That agreement lets the developer retain all of their copyrights, and merely allows SFC to conduct enforcement work on their behalf.
The enforcement agreement specifically does not empower SFC to pursue litigation, he added in response to an audience member's question. A contributor interested in making that arrangement could raise it with SFC, but it would require coming to a separate agreement.
Third, SFC will provide license consulting, advice, and compliance services to Debian on an ongoing basis, in coordination with the DPL. The consultation service means that SFC will provide a certain number of pro-bono hours each month to answer questions forwarded by the DPL and to provide policy-related advice.
In the long run, Kuhn said, copyright assignment is a practical tool. It is a sad fact that developers (like everyone else) inevitably pass away or drop out of the project, at which point defending their copyrights becomes arduous at best, if not impossible. Others simply forget to defend their copyrights because they get busy. For those that care deeply about protecting their contributions to free software, the aggregation project will hopefully make the process easier.
Copyright assignment can be a thorny issue, Kuhn admitted. Critics will point to copyright assignment as a tool that companies sometimes use to take decision-making power out of the hands of the developers they employ. But that strategy—which tends to involve producing a proprietary version of a software product as well as an open-source version—only works when the company gets 100% of the copyrights involved. Debian will always be a multi-copyright project, so there is no chance that anyone (the SFC included) could turn copyright assignments against it. Furthermore, he said, assigning copyright to SFC is different than assigning it to a company, because SFC is a US charity and, under US law, a charity cannot be sold.
DCAP is designed to be flexible. Participation is entirely optional, and the enforcement agreements can be canceled at any time (with 30 days notice). Kuhn noted that another former DPL, Stefano Zacchiroli, was the first to sign up for DCAP. Zacchiroli assigned all his copyrights in Debian to the SFC, "past, present, and future." Paul Tagliamonte, in contrast, assigned SFC a subset of the copyrights on his Debian contributions via DCAP.
Developers must currently contact SFC by email (at debian-services@sfconservancy.org) to sign up for the project, but the joint announcement indicates that a self-service enrollment system is under development. Kuhn ended the talk by noting that the copyright assignment and enforcement agreement options were there to provide Debian contributors with a range of options. He predicted that the enforcement agreement would be the more popular choice, particularly since Harald Welte's gpl-violations.org project had shut down, but that he was happy to be able to give something back to the Debian community after years of being a happy user.
[The author would like to thank the Debian project for travel assistance to attend DebConf 2015.]
Debian and binary firmware blobs
Debian's annual DebConf event is part conference, part hackathon; various teams and ad-hoc groups meet up over the course of the week to discuss future plans, get work done, and make decisions that are best reached with face-to-face conversation. At the 2015 DebConf, one of those face-to-face conversations dealt with the thorny problem of how Debian should handle binary firmware blobs. Because Debian is a dedicated free-software project, including proprietary firmware in the installation images offered to users is out of the question to most contributors. But that stance makes Debian impossible to install for at least some small percentage of would-be users—which is far from ideal. Nevertheless, the project may have hashed out a way to move forward.
The issue was explored in depth at an August 17 round-table discussion entitled "Firmware - a hard or soft problem?" The session was packed to overflowing; more than 40 people (plus one dog) attempted to cram into the meeting room. Moderating the discussion was Debian developer Steve McIntyre, who leads the debian-cd group responsible for creating and publishing the official Debian ISO images.
The root problem with binary-only firmware, he said, is that it is now quite common for computers—particularly laptops—to include components that cannot function at all without a loadable firmware blob. This includes "almost every WiFi chipset" on the market, which in turn makes it impossible for some users to even install Debian using the default ISO images—because those images quite deliberately do not include any non-free software. Various binary firmware blobs are available through Debian; they currently live in the "non-free" archive area alongside the Adobe Flash plugin and various other proprietary programs.
Most Debian project members recognize the inconvenience (and even counter-productivity) of this situation, and Debian has historically relied on an inelegant workaround. Namely, unofficial ISO images are built that include the binary firmware blobs necessary to bootstrap a Debian installation. To avoid being seen as an endorsement of non-free software, though, those unofficial images are not advertised and project members only direct new users to them reluctantly. "It's a pain," McIntyre said in summary.
Several possible solutions have been proposed in the past. One, for instance, was providing a downloadable tar archive of the all of the binary firmware. If the installer determines that a given system requires a firmware blob, it could point the user to the firmware archive URL. This approach was rejected as unworkable because fetching and loading the tar archive during installation may not be practical. Many of the target computers may not have a second USB port (the installation media occupying one, of course) and users may not be able to run off and find a second memory stick.
Putting the tarball on a second partition on the installer USB stick was discussed, but evidently Windows makes it difficult or impossible to use more than one partition on a USB stick. That would inconvenience Windows users trying to switch to Debian. Given those hurdles, the tarball approach was deemed to not make life easier for end users than the current, unofficial-ISO approach.
It had also been suggested that Debian could simply enable the non-free section by default, and count on educating users to keep the distinction between free and proprietary software clear. This, too, was rejected—even if those participating in the discussion favored it (which they did not), the change would require a General Resolution, and many similar votes have happened in the past, all reconfirming Debian's commitment to not enabling non-free by default.
The proposal that did garner support, though, was splitting the non-free section into two or more parts based on the type of content it contained. Non-free firmware would be one of those; possibly other sections (like one for non-free documentation) would be created as well. In any case, such a split would underscore that there is an important difference between non-free firmware needed to get Debian installed and other proprietary applications or libraries.
Most in the room seemed to agree that this split makes sense. After all, one member of the group said, at least hardware that needs loadable firmware offers the possibility that free firmware will be developed and can be used at a later date; firmware that is burned in does not offer that hope. Whether firmware will be the only section to be carved out into a separate archive component is a matter that is still up for debate. Several other divisions were suggested, but deemed out-of-scope for the session.
However the split is implemented (a task which will ultimately be up to the Debian FTP masters), the next question will be how the availability of the firmware archive should be communicated to the user. Enabling it by default remains out of the question, but the attendees agreed that it was best to communicate the situation to the user during the installation process and give them the opportunity to enable the firmware archive and continue. As of now, a user attempting to install Debian on a machine that requires binary firmware will see that install fail, and only find clues to how the situation can be resolved by reading through some not-well-advertised text files.
Most thought that a "friendly" explanation of the issue was needed—one that said, in essence, "Because the hardware manufacturer of this component does not provide software we can distribute, Debian cannot run on this machine unless you install this non-free add-on" and provided links to more details about the free-software issues involved. All agreed that the wording of this message was critical; several commented that they liked the message that Canonical started using several years ago in its alerts when non-free drivers were needed.
A question was raised in the session about including an "email the manufacturer to ask for free-software support" tool in the installer, similar to the "write your Congressperson" advocacy seen in politics. While most agreed that encouraging some form of free-software advocacy was a worthy goal, the consensus was that identifying the correct company to email might not be possible. In many cases, the real culprit is a chipset maker, not the device maker, and problematic devices routinely switch to new chipsets without changing their USB device IDs. Since those device IDs are all Debian has access to, it may not be possible to unambiguously decide who should get the user's advocacy email.
This is a topic with many angles and plenty of nuance; in the interest of simplifying matters, the participants even agreed to avoid the question of how non-free firmware would impact efforts to get Debian endorsed by the Free Software Foundation. The session had to be drawn to a close before any firm plans were put together. But, as of now, Debian does seem prepared to provide separate access to the non-free firmware many users need to start using Debian in the first place. Doing so without compromising the project's longstanding commitment to free software requires a delicate balancing act, but project members appear to willing to undertake the task.
[The author would like to thank the Debian project for travel assistance to attend DebConf 2015.]
Brief items
Distribution quotes of the week
I wish I could be there with you
In Heidelberg, fair German city
To share, in person, this my ditty
...
Free software, arguments, warmth, good cheer
Too soon all over 'til next year
All of the best are there / on 'Net
Here's hope that it's the best Debconf yet
Distribution News
Debian GNU/Linux
Debian and Software Freedom Conservancy announce Copyright Aggregation Project
Software Freedom Conservancy's Bradley M. Kuhn has announced the Conservancy's Debian Copyright Aggregation Project. "This new project, formed at the request of Debian developers, gives Debian contributors various new options to ensure the defense of software freedom. Specifically, Debian contributors may chose to either assign their copyrights to Conservancy for permanent stewardship, or sign Conservancy's license enforcement agreement, which delegates to Conservancy authority to enforce Free Software licenses (such as the GNU General Public License). Several Debian contributors have already signed both forms of agreement."
Debian Installer Stretch Alpha 2 release
The second alpha of the Debian installer for 'Stretch' (version 9) has been released. The biggest change in this version is the update of the Linux kernel from the 4.0 series to the 4.1 series.Squeeze non-LTS architectures moving to archive.debian.org
The Long Term Support effort for Debian 6.0 'squeeze' only covers i386/amd64 architectures. Non-LTS architectures will move to archive.debian.org. "This does not (yet) affect other Squeeze suites, like backports, but they will follow soonish."
Bits from the Wanna Build team
Mehdi Dogguy reports on the Wanna Build team meeting at DebCamp. "We have worked on getting arch:all packages buildable on our autobuilders. We've got a few patches added to make that happen. Architecture independent packages (arch:all) are now auto-built on dedicated amd64 builders. We tested our changes as much as we were able to and enabled arch:all uploads for Sid and Experimental. If your auto-built arch:all package doesn't make it through to ftp-master's archive, please do contact us so that we can have a look and get it fixed quickly."
Newsletters and articles of interest
Distribution newsletters
- DistroWatch Weekly, Issue 623 (August 17)
- DistroWatch Weekly, Issue 624 (August 24)
- openSUSE weekly review (August 13)
- openSUSE weekly review (August 22)
- Ubuntu Weekly Newsletter, Issue 430 (August 16)
- Ubuntu Weekly Newsletter, Issue 431 (August 23)
The State of Fedora: 2015 Edition (Fedora Magazine)
Fedora Magazine reports on Fedora project leader Matthew Miller's keynote at Flock, which is the Fedora contributor conference. He outlined the state of the distribution using some graphs and statistics and said "we’re doing very well as a project and it’s thanks to all of you". The use of Internet Relay Chat (IRC) by the project was another topic: "
Fedorans do like to work together. Last year there were 1,066 IRC meetings (official meetings, not just being in IRC talking), and 765 IRC meetings in 2015 alone. 'This shows how vibrant we are, but also is buried in IRC. There’s a lot of Fedora activity you don’t see on the Fedora Web site… I want to look at ways to make that more visible,' says Miller. There are efforts to make the activity more visible, says Miller. 'If I want to interact with the project, is somebody there? Yes, but we have millions of dead pages on the wiki… we need to make this more visible.' IRC is 'definitely a measure of engagement' but it’s also a high barrier of entry, says Miller. 'Wow that’s complicated. Wow, that’s still around?' is a common response from new contributors to IRC. The technology, and 'culture' can be confusing."
Sabayon Linux development in 2015
Sabayon developer Joost Ruis takes a look at recent developments in the Sabayon Linux project, including new Docker images. "These are forked directly from a Gentoo stage3 docker image. The result is a very clean chroot that is even closer to Gentoo. Our docker pulls in the stage3, adds Sabayon overlay, installs Entropy to a point where it can run. Then it checks the Portage database to list what packages are installed and replaces them with the packages from Entropy. (Ain’t that cool?). Now we can keep our minimal chroot current and easy make changes whenever we want. The docker base image is then being “squashed” so we can feed it as an image to our Molecule™ script that will build our iso images for us. With this move we also made the creation of spins more accessible to developers! Go fork us!"
Page editor: Rebecca Sobol
Next page:
Development>>