Wine Wednesday: Donate to help Conservancy and win a special potable prize!
byon January 7, 2020
Our highest donor on Wednesday wins a bottle of wine... signed by the Wine developers. Put your donation bid in now!
Photo by Karen Sandler, available under a CC.BY.SA license
For our Conservancy supporters who are legally allowed to drink, we have a fun challenge. One of our projects is named Wine (Wine Is Not an Emulator), and they help developers compile Windows applications for Unix-like (including free software) environments. Wine is invaluable for folks who must run one or two non-free things for work or some other collaboration but would prefer not to run a whole proprietary operating system.
ANYWAY. They have also given us a bottle of wine (the beverage) to give away. The bottle has been signed by Wine's lead developers at the 2019 WineConf. Our Executive Director, Karen Sandler spoke there about Wine and Conservancy. Check her out with the Wine folks below!
Tomorrow's highest donation (on Wednesday, aka TODAY), wins the wine. Donations must be at least $50 and you must be of legal drinking age where you live. You must be able to receive wine in the mail or be willing to help us arrange to get it to you via our global network of software freedom advocates and pals. Staff is also happy to try to deliver the wine in person at any of the free software events we're attending this year. All donations must be received by 11:59pm AoE.
Photo by Francois Gouget
Thanks for participating in Wine Wednesday! Your donations on Wednesday (and through the 15th) will be doubled by our generous matching donors. Put your donation bid in now!
 Little known fact: it turns out that most Wine developers prefer beer!
Toward Copyleft Equality for All
byon January 6, 2020
I would not have imagined even two years ago that expansion of copyleft would become such an issue of interest in software freedom licensing. Historically and for good reason, addition of new forms of copyleft clauses has moved at a steady pace. The early 2000s brought network services clauses (such as that in the Affero GPL), which hinged primarily on requiring provision of source to network-remote users. Affero GPL implemented this via copyright-controlled permission of modification. These licenses began as experiments, and were not approved by some license certification authorities until many years later.
Even with the copyleft community's careful and considered growth, there have been surprising unintended consequences of copyleft licenses. The specific outcome of proprietary relicensing has spread widely and — for stronger copyleft licenses like Affero GPL — has become the more common usage of the license.
As the popularity of Open Source has grown, companies have searched for methods to combine traditional proprietary licensing business models with FOSS offerings. Proprietary relicensing, originally pioneered by MySQL AB (now part of Oracle by way of Sun), uses software freedom licenses to compel purchase of proprietary licenses for the same codebase. Companies accomplish this by ensuring they collect all copyright control of a particular codebase, thus being its sole licensor, and offer the FOSS licenses as a loss-leader (often zero-cost) product. Non-commercial users generally are ignored, and commercial users often operate in fear of captious interpretations of the copyleft license. The remedy for their fear is a purchase of a separate proprietary license for the same codebase from the provider. Proprietary relicensing seems to have been the first mixed FOSS/proprietary business model in history.
The toxicity of this business model has only become apparent in hindsight. Initially, companies engaging in this business model did so somewhat benignly — often offering proprietary licenses only to customers who sought to combine the product with other proprietary software, or as supplemental income along with other consulting businesses. This business model (for some codebases), however, became so lucrative that some companies eventually focused exclusively on it. As a result, aggressive copyleft license overreading and inappropriate, unprincipled enforcement typically came from such companies. For most, the business model likely reached its crescendo when MongoDB began using the Affero GPL for this purpose. I was personally told by large companies at the time (late 2000s into early 2010s) that they'd listed Affero GPL as “Never Allowed Here” specifically because of shake-downs from MongoDB.
Copyleft itself is not a moral philosophy; rather, copyleft is a strategy that software freedom activists constructed to advance a particular set of policy goals. Specifically, software copyleft was designed to ensure that all users received complete, corresponding source for all binaries, and that any modifications or improvements made anywhere in the chain of custody of the software were available in source form to downstream users. As orginially postulated, copyleft was a simple strategy to disarm proprietarization as an anti-software-freedom tactic.
The Corruption of Copyleft
Copyleft is a tool to achieve software freedom. Any tool can be fashioned into a weapon when wielded the wrong way. That's precisely what occurred with copyleft — and it happened early in copyleft's history, too. Before even the release of GPLv2, Aladdin Ghostscript used a copyleft via a proprietary relicensing model (which is sometimes confusingly called the “dual licensing” model). This business model initially presented as benign to software freedom activists; leaders declared the business model “barely legitimate”, when it rose to popularity through MySQL AB (later Sun, and later Oracle)'s proprietary relicensing of the MySQL codebase.
In theory, proprietary relicensors would only offer the proprietary license by popular demand to those who had some specific reason for wanting to proprietarize the codebase — a process that has been called “selling exceptions”. In practice, however, every company I'm aware of that sought to engage in “selling exceptions” eventually found a more aggressive and lucrative tack.
This problem became clear to me in mid-2003 when MySQL AB attempted to hire me as a consultant. I was financially in need of supplementary income so I seriously considered taking the work, but the initial conference call felt surreal and convinced me that MySQL AB was engaging in problematic behavior . Specifically, their goal was to develop scare tactics regarding the GPLv2. I never followed up, and I am glad I never made the error of accepting any job or consulting gig when companies (not just MySQL AB, but also Black Duck and others) attempted to recruit me to serve as part of their fear-tactics marketing departments.
Most proprietary relicensing businesses work as follows: a single codebase is produced by a for-profit company, which retains 100% control over all copyright in the software (either via an ©AA or a CLA). That codebase is offered as a gratis product to the marketplace, and the company invests substantial resources in marketing the software to users looking for FOSS solutions. The marketing department then engages in captious and unprincipled copyleft enforcement actions in an effort to “convert” those FOSS users into paying customers for proprietary licensing for the same codebase. (Occasionally, the company also offers additional proprietary add-ons, improvements, or security updates that are not available under the FOSS license — when used this way, the model is often specifically called “Open Core”.)
Why We Must End The Proprietary Relicensing Exploitation of Copyleft
This business model has a toxic effect on copyleft at every level. Users don't enjoy their software freedom under an assurance that a large community of contributors and users have all been bound to each other under the same, strong, and freedom-ensuring license. Instead, they dread the vendor finding a minor copyleft violation and blowing it out of proportion. The vendor offers no remedy (such as repairing the violation and promise of ongoing compliance) other than purchase of a proprietary license. Industry-wide. I have observed to my chagrin that the copyleft license that I helped create and once loved, the Affero GPL, was seen for a decade as inherently toxic because its most common use was by companies who engaged in these seedy practices. You've probably seen me and other software freedom activists speak out on this issue, in our ongoing efforts to clarify that the intent of the Affero GPL was not to create these sorts of corporate code silos that vendors constructed as copyleft-fueled traps for the unwary. Meanwhile, proprietary relicensing discourages contributions from a broad community, since any contributor must sign a CLA giving special powers to the vendor to continue the business model. Neither users nor co-developers benefit from copyleft protection.
The Onslaught of Unreasonable Copyleft
Meanwhile, and somewhat ironically, the success of Conservancy's and the FSF's efforts to counter this messaging about the Affero GPL has created an unintended consequence: efforts to draft even more restrictive software copyleft licenses that can more easily implement the proprietary relicensing business models. We have partially succeeded in convincing users that compliance with Affero GPL is straightforward, and in the backchannels we've aided users who were under attack from these proprietary relicensors like MongoDB. In response, these vendors have responded with a forceful political blow: their own efforts to redefine the future of copyleft, under the guise of advancing software freedom. MongoDB even cast itself as a “victim” against Amazon, because Amazon decided to reimplement their codebase from scratch (as proprietary software!) rather than use the AGPL'd version of MongoDB.
These efforts began in earnest late last year when (against the advice of the license steward) MongoDB forked the Affero GPL to create the SS Public License. I, with the support of Conservancy, rose in opposition of MongoDB's approach, pointing out that MongoDB would not itself agree to its own license (since MongoDB's CLA would free it from the SS Public License terms). If an entity does not gladly bind itself by its own copyleft license (for example, by accepting third-party contributions to its codebases under that license), we should not treat that entity as a legitimate license steward, nor treat that license as a legitimate FOSS license. We should not and cannot focus single-mindedly on interpretation of the formalistic definitions when we recommend FOSS licensing policy. The message of “technically it's a FOSS license, but don't use” is too complicated to be meaningful.
A Copyleft Clause To Restore Equality
My friend and colleague, Richard Fontana, and I are known for our very public and sometimes heated debates on all manner of software freedom policy. We don't always agree on key issues, but I greatly respect Fontana for his careful thought and his inventive solutions. Indeed, Fontana first formulated “inbound=outbound” into that simple phrasing to more easily explain how the lopsided rights and permissions exchanges through CLAs actually create bad FOSS policy like proprietary relicensing. In the copyleft-next project that Fontana began, he further proposed this innovative copyleft clause that could, when Incorporated in a copyleft license, prevent proprietary licensing before it even starts! The clause still needs work, but Fontana's basic idea is revolutionary for copyleft drafting. The essence in non-legalese is this: If you offer a license that isn't a copyleft license, the copyleft provisions collapse and the software is now available to all under a non-copyleft, hyper-permissive FOSS license.
This solution is ingenious in the way that copyleft itself was an ingenious way to use copyright to “reverse” the rights and ensure software freedom. This provision doesn't prohibit proprietary relicensing per se, but instead simply deflates the power of copyleft control when a copyright holder engages in proprietary relicensing activities.
Given the near ubiquity of proprietary relicensing and the promulgation of stricter copylefts by companies who seek to engage (or help their clients engage) in such business models, I've come to a stark policy conclusion: the community should reject any new copyleft license without a clause that deflates the power of proprietary relicensing. Not only can we incorporate such a clause into new licenses (such as copyleft-next), but Conservancy's Executive Director, Karen Sandler, came up with a basic approach to incorporating similar copyleft equality clauses into written exceptions for existing copyleft licenses, such as the Affero GPL. I have received authorization to spend some of my Conservancy time and the time of our lawyers on this endeavor, and we hope to publish more about it in the coming months.
We've finished the experiment. After thirty years of proprietary relicensing, beginning with Aladdin and culminating with MongoDB and their SS Public License, we now know that proprietary relicensing does not serve or extend software freedom, and in most cases has the opposite effect. We must now categorically reject it, and outright reject any new licenses that can be used for it.
Talking To Friends and Family About Software Freedom
byon December 23, 2019
Many folks are heading home to family or getting ready to spend some time with their families of choice. At Conservancy, we believe that software freedom should be for everyone so that got us thinking about how we can help others gain control over their computing environment. We asked a few software freedom enthusiasts about whether or not they talk to family and friends about free and open source software. Luckily, they were willing to share their advice and encouragement. Perhaps, you'll find some ideas in here for talking to loved ones about software freedom too!
Adam Monsen is a SeaGL co-founder, a Seattleite and the Senior Director of Engineering at C-SATS R&D. His thoughts: "Free and open source software is critical in the context of medical devices. In 10 years we'll be able to install a 'perfect sleep', 'perfect focus' or 'no pain' implant. We need free and open source software implants for full control of our data for our privacy, our autonomy, and, ultimately, our freedom."
Alice Monsen is ten. She recently gave her first free software talk at SeaGL on using Krita to build RPG characters. Her advice: "Yes, we should always talk about free software. If it doesn't work how you want, you can change it!"Mako Hill is a free software activist and an Assistant Professor at the University of Washington in the Department of Communication. He says: "Although most free software folk are technologists who came for the software and stayed for the freedom, our family and friends usually care much less about software than we do. Conversations about freedom that are a hard sell with techno-phile crowds often resonate more easily with folks who are already skeptical about technology. Most of all, meet people where they are! Building a critical capacity to think about issues of technology, power, and autonomy is both a more effective strategy and a more important goal that trying to lead someone to any specific state of free software nirvana."
Abigail Cabunoc Mayes works for the Mozilla Foundation as Lead Developer of Open Source Engagement. She recommends, "Stories are the best way to connect with friends and family on a topic you care about. When it comes to free and open source software, I share my own experience writing software at a cancer research institute or the story of a group of rebels joining forces to break up a monopoly. Both stories show how our society is most innovative when we can publish and share this information for others to build on. These stories are why I want openness to be the norm in research and innovation."
Eric Schultz is the founder of Houdini a fund-raising platform that helps hundreds of non-profits and is a Conservancy member. Eric emphasizes respect: "I do talk to family about FOSS. My general advice is to be respectful of people's time and boundaries. Not everyone has an immediate need to have access to the source code of their technology but everyone has a need for the fundamental principles of digital autonomy and safety that underlie the FOSS ethos. Illustrating our commitment to FOSS ideals with empathy brings more user freedom and justice than tiring down any single person through persistent haranguing."
Conservancy donations get doubled through January 15th, so please consider donating today, or signing up a couple of friends. New donors get their donation tripled and anyone who signs up three friends gets a limited edition prize!
ContractPatch: Supporting Maintainers in Employment Agreements
byon December 19, 2019
Since we've launched ContractPatch, I've heard a lot of feedback from free software contributors about the successes they've had in negotiating their employment agreements. While not everyone has achieved full modification to the agreement, so far everyone who's reported back had a positive experience negotiating and many have been able to introduce improvements into their contracts. As we've mentioned before, generally employers won't give you something unless you ask for it and generally agreements are negotiable. As a developer or other contributor, you often know what your FOSS project needs better than your employer does even though they may depend on that project.
Recently, I was discussing this with a CEO of a company that (like many) depend on free and open source software for their business to succeed and he was kind enough to send me an example of one of the free software specific provisions that they included in their contract with an employee. The employee is a developer who maintains an important project, and was its maintainer even before the company's founding. This provision gave the employee confidence that they could continue their work for the project. Furthermore, this provision clearly demonstrates the company's commitment to support the project.
This part of the contract says:
For 10 hours each week, you will be free to continue your work as the [PROJECT] maintainer. The tasks you work on will be at your discretion, and you will hold the copyright to that work, so long as it is released under [COPYLEFT LICENSE]. For the remaining 30 hours per week, you will work at the direction of [COMPANY].
While the provision could certainly go farther in favor of the employee1, this provision clearly declares the intention of the company with respect to the employment relationship. The employee gets to choose how best to maintain and improve the free software project unfettered by the needs of their employer and also knows how much time is reasonable for them to use during work hours. Additionally, the provision allows the employee to keep their copyrights, which given the copyleft license, empowers the employee going forward and underscores the company's intention to stay in compliance with its license obligations. This provision is strong, but the contract could also address a procedure or process for how to handle a situation where the interests of the company and the interests of the project conflict. For example,they could also include a term that indicates the employee should mark the contributions during those 10 hours in some way, such as by using a personal address in all those Git commits. There are a range of provisions that employees already have in their contracts to help their free software work, this is just one example of a provision that is in effect for an employee right now.
Many free software contributors take jobs with the unwritten understanding that they will be able to continue working on their long-time free software projects. As Bradley quoted from the old telephone commercials on our FaiF episode that announced ContractPatch: “put it in writing!”. Without having that written agreement with their employers, employees find later that expectations can change. Managers change; companies get acquired; and, sometimes, what's promised on the interview just never turns out as expected! Often higher level management understands the importance of having an employee working on the free software projects that the company needs, but shifts in middle management can easily break that focus. Employees then may not feel comfortable escalating the problem. Ultimately, that results in decreased employee satisfaction and allows short-term quarterly goals of the company to take precedence over the free software projects that the company needs for long-term profitability. Explicitly giving the “freedom to FOSS” in employment contracts both provides long term benefits to all parties and brings sustainability to FOSS.
1 For example, the employee in question sometimes spends more than 10 hours on behalf of the project and has considerable leeway to exercise their judgement for the process in the course of their employment