Displaying posts tagged GPL
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.
FSF's Stallman Applauds Conservancy's Linux Enforcement
byon May 11, 2017
In his statement, Stallman reiterates the importance of the Principles of Community-Oriented GPL Enforcement and the need for lawsuits, but only as a last resort.
We thank RMS for his support of our work and for asking more people to become Conservancy Supporters.
Why GPL Compliance Tutorials Should Be Free as in Freedom
byon April 25, 2017
I am honored to be a co-author and editor-in-chief of the most comprehensive, detailed, and complete guide on matters related to compliance of copyleft software licenses such as the GPL. This book, Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide (which we often call the Copyleft Guide for short) is 155 pages filled with useful material to help everyone understand copyleft licenses for software, how they work, and how to comply with them properly. It is the only document to fully incorporate esoteric material such as the FSF's famous GPLv3 rationale documents directly alongside practical advice, such as the pristine example, which is the only freely published compliance analysis of a real product on the market. The document explains in great detail how that product manufacturer made good choices to comply with the GPL. The reader learns by both real-world example as well as abstract explanation.
However, the most important fact about the Copyleft Guide is not its useful and engaging content. More importantly, the license of this book gives freedom to its readers in the same way the license of the copylefted software does. Specifically, we chose the Creative Commons Attribution Share-Alike 4.0 license (CC BY-SA) for this work. We believe that not just software, but any generally useful technical information that teaches people should be freely sharable and modifiable by the general public.
The reasons these freedoms are necessary seem so obvious that I'm surprised I need to state them. Companies who want to build internal training courses on copyleft compliance for their employees need to modify the materials for that purpose. They then need to be able to freely distribute them to employees and contractors for maximum effect. Furthermore, like all documents and software alike, there are always “bugs”, which (in the case of written prose) usually means there are sections that fail to communicate to maximum effect. Those who find better ways to express the ideas need the ability to propose patches and write improvements. Perhaps most importantly, everyone who teaches should avoid NIH syndrome. Education and science work best when we borrow and share (with proper license-compliant attribution, of course!) the best material that others develop, and augment our works by incorporating them.
These reasons are akin to those that led Richard M. Stallman to write his
Software Should Be Free. Indeed, if you reread that essay now
— as I just did — you'll see that much of the damage and many of
the same problems to the advancement of software that RMS documents in that
essay also occur in the world of tutorial documentation about FLOSS
licensing. As too often happens in the Open Source community, though,
folks seek ways to proprietarize, for profit, any copyrighted work that
doesn't already have a copyleft license attached. In the field of copyleft
compliance education, we see the same behavior: organizations who wish to
control the dialogue and profit from selling compliance education seek to
proprietarize the meta-material of compliance education, rather than
sharing freely like the software itself. This yields an ironic
exploitation, since the copyleft license documented therein exists as a
strategy to assure the freedom to share knowledge. These educators tell
their audiences with a straight face:
Sure, the software is
free as in freedom, but if you want to learn how its license
works, you have to license our proprietary materials! This behavior
uses legal controls to curtail the sharing of knowledge, limits the
advancement and improvement of those tutorials, and emboldens silos of
know-how that only wealthy corporations have the resources to access and
afford. The educational dystopia that these organizations create is
precisely what I sought to prevent by advocating for software freedom for
While Conservancy's primary job provides non-profit infrastructure for Free Software projects, we also do a bit of license compliance work as well. But we practice what we preach: we release all the educational materials that we produce as part of the Copyleft Guide project under CC BY-SA. Other Open Source organizations are currently hypocrites on this point; they tout the values of openness and sharing of knowledge through software, but they take their tutorial materials and lock them up under proprietary licenses. I hereby publicly call on such organizations (including but not limited to the Linux Foundation) to license materials such as those under CC BY-SA.
I did not make this public call for liberation of such materials without first trying friendly diplomacy first. Conservancy has been in talks with individuals and staff who produce these materials for some time. We urged them to join the Free Software community and share their materials under free licenses. We even offered volunteer time to help them improve those materials if they would simply license them freely. After two years of that effort, it's now abundantly clear that public pressure is the only force that might work0. Ultimately, like all proprietary businesses, the training divisions of Linux Foundation and other entities in the compliance industrial complex (such as Black Duck) realize they can make much more revenue by making materials proprietary and choosing legal restrictions that forbid their students from sharing and improving the materials after they complete the course. While the reality of this impasse regarding freely licensing these materials is probably an obvious outcome, multiple sources inside these organizations have also confirmed for me that liberation of the materials for the good of general public won't happen without a major paradigm shift — specifically because such educational freedom will reduce the revenue stream around those materials.
Of course, I can attest first-hand that freely liberating tutorial materials curtails revenue. Karen Sandler and I have regularly taught courses on copyleft licensing based on the freely available materials for a few years — most recently in January 2017 at LinuxConf Australia and at at OSCON in a few weeks. These conferences do kindly cover our travel expenses to attend and teach the tutorial, but compliance education is not a revenue stream for Conservancy. (By contrast, Linux Foundation generates US$3.8 million/year using proprietary training materials, per their 2015 Form 990, page 9, line 2c.) While, in an ideal world, we'd get revenue from education to fund our other important activities, we believe that there is value in doing this education as currently funded by our individual Supporters; these education efforts fit withour charitable mission to promote the public good. We furthermore don't believe that locking up the materials and refusing to share them with others fits a mission of software freedom, so we never considered such as a viable option. Finally, given the institutionally-backed FUD that we continue to witness, we seek to draw specific attention to the fundamental difference in approach that Conservancy (as a charity) take toward this compliance education work. (My recent talk on compliance covered on LWN includes some points on that matter, if you'd like further reading).
0One notable exception to these efforts was the success of my colleague, Karen Sandler's (and others) in convincing the OpenChain project to choose CC-0 licensing. However, OpenChain is not officially part of the LF training curriculum to my knowledge, and if it is, it can of course be proprietarized therein, since CC-0 is not a copyleft license.
Getting Started with Linux Development and Compliance: An Interview with Christoph Hellwig
byon February 22, 2017
Christoph Hellwig is a Linux developer, responsible for the code for several filesystems and the NVM Express drive. He’s a member of Conservancy’s GPL Compliance Project for Linux Developers and the plaintiff in the case against VMWare, which still awaits appeal. We recently had a chance to catch up with him to hear how he got started working on Linux, what advice he would give newcomers, and why he supports Conservancy’s work.
Q: How did you become interested in Linux? Is there a contribution you are most proud of?
CH: When I was a kid in Germany I started using Usenet and got myself into programming more or less by accident. That lead to learning about Linux and installing it at home. Soon after I started hacking kernel to make the sound card in my computer work under Linux.
Q: Why did you join Conservancy’s GPL Compliance Project For Linux Developers?
CH: I decided that fighting copyright violations on my Linux code wasn’t a task I could take on alone. Based on that I decided to join the Conservancy’s GPL Compliance Project for Linux Developers, which is a very open project and also includes other kernel developers I respect a lot.
Q: What advice would you give to someone who is starting out in the Linux kernel today?
CH: Try to scratch an itch instead of just looking for an easy task that looks good on a resume. For example fix something that annoys you or a friend. Or try to upstream support for an embedded device you use. Don’t send cleanup patches for random code—that’s a good way to be seen as someone who is only interested in polishing his or her resume with kernel commits.
Q: Why do you choose to support Conservancy, in addition to volunteering your time to promote free software and compliance?
CH: I am very impressed with Conservancy’s work. Not only in the compliance program where I work closely with the Conservancy, but also how it helps a lot of free software projects to manage their affairs.
Join Christoph and support Conservancy today! Supporters sustain all of this work we do, from fiscal sponsorship for projects, to compliance work on their behalf.