Displaying posts by Bradley M. Kuhn and Karen M. Sandler
Understanding LF's New “Community Bridge”
byon March 13, 2019
Yesterday, the Linux Foundation (LF) launched a new service, called “Community Bridge” — an ambitious platform that promises a self-service system to handle finances, address security issues, manage CLAs and license compliance, and also bring mentorship to projects. These tasks are difficult work that typically require human intervention, so we understand the allure of automating them; we and our peer organizations have long welcomed newcomers to this field and have together sought collaborative assistance for these issues. Indeed, Community Bridge's offerings bear some similarity to the work of organizations like Apache Software Foundation, the Free Software Foundation (FSF), the GNOME Foundation (GF), Open Source Initiative (OSI), Software in the Public Interest (SPI) and Conservancy. People have already begun to ask us to compare this initiative to our work and the work of our peer organizations. This blog post hopefully answers those questions and anticipated similar questions.
The first huge difference (and the biggest disappointment for the entire FOSS community) is that LF's Community Bridge is a proprietary software system. §4.2 of their Platform Use Agreement requires those who sign up for this platform to agree to a proprietary software license, and LF has remained silent about the proprietary nature of the platform in its explanatory materials. The LF, as an organization dedicated to Open Source, should release the source for Community Bridge. At Conservancy, we've worked since 2012 on a Non-Profit Accounting Software system, including creating a tagging system for transparently documenting ledger transactions, and various support software around that. We and SPI both now use these methods daily. We also funded the creation of a system to manage mentorship programs, which now runs the Outreachy mentorship program. We believe fundamentally that the infrastructure we provide for FOSS fiscal sponsorship (including accounting, mentorship and license compliance) must itself be FOSS, and developed in public as a FOSS project. LF's own research already shows that transparency is impossible for systems that are not FOSS. More importantly, LF's new software could directly benefit so many organizations in our community, including not only Conservancy but also the many others (listed above) who do some form of fiscal sponsorship. LF shouldn't behave like a proprietary software company like Patreon or Kickstarter, but instead support FOSS development. Generally speaking, all Conservancy's peer organizations (listed above) have been fully dedicated to the idea that any infrastructure developed for fiscal sponsorship should itself be FOSS. LF has deviated here from this community norm by unnecessarily requiring FOSS developers to use proprietary software to receive these services, and also failing to collaborate over a FOSS codebase with the existing community of organizations. LF Executive Director Jim Zemlin has said that he “wants more participation in open source … to advance its sustainability and … wants organizations to share their code for the benefit of their fellow [hu]mankind”; we ask him to apply these principles to his own organization now.
The second difference is that LF is not a charity, but a trade association — designed to serve the common business interest of its paid members, who control its Board of Directors. This means that donations made to projects through their system will not be tax-deductible in the USA, and that the money can be used in ways that do not necessarily benefit the public good. For some projects, this may well be an advantage: not all FOSS projects operate in the public good. We believe charitable commitment remains a huge benefit of joining a fiscal sponsor like Conservancy, FSF, GF, or SPI. While charitable affiliation means there are more constraints on how projects can spend their funds, as the projects must show that their spending serves the public benefit, we believe that such constraints are most valuable. Legal requirements that assure behavior of the organization always benefits the general public are a good thing. However, some projects may indeed prefer to serve the common business interest of LF's member companies rather than the public good, but projects should note such benefit to the common business interest is mandatory on this platform — it's explicitly unauthorized to use LF's platform to engage in activities in conflict with LF’s trade association status). Furthermore, (per the FAQ) only one maintainer can administer a project's account, so the platform currently only supports the “BDFL” FOSS governance model, which has already been widely discredited. No governance check exists to ensure that the project's interests align with spending, or to verify that the maintainer acts with consent of a larger group to implement group decisions. Even worse, (per §2.3 of the Usage Agreement) terminating the relationship means ceasing use of the account; no provision allows transfer of the money somewhere else when projects' needs change.
Finally, the LF offers services that are mainly orthogonal and/or a subset of the services provided by a typical fiscal sponsor. Conservancy, for example, does work to negotiate contracts, assist in active fundraising, deal with legal and licensing issues, and various other hands-on work. LF's system is similar to Patreon and other platforms in that it is a hands-off system that takes a cut of the money and provides minimal financial services. Participants will still need to worry about forming their own organization if they want to sign contracts, have an entity that can engage with lawyers and receive legal advice for the project, work through governance issues, or the many other things that projects often want from a fiscal sponsor.
Historically, fiscal sponsors in FOSS have not treated each other as competitors. Conservancy collaborates often with SPI, FSF, and GF in particular. We refer applicant projects to other entities, including explaining to applicants that a trade association may be a better fit for their project. In some cases, we have even referred such trade-association-appropriate applicants to the LF itself, and the LF then helped them form their own sub-organizations and/or became LF Collaborative Projects. The launch of this platform, as proprietary software, without coordination with the rest of the FOSS organization community, is unnecessarily uncollaborative with our community and we therefore encourage some skepticism here. That said, this new LF system is probably just right for FOSS projects that (a) prefer to use single-point-of-failure, proprietary software rather than FOSS for their infrastructure, (b) do not want to operate in a way that is dedicated to the public good, and (c) have very minimal fiscal sponsorship needs, such as occasional reimbursements of project expenses.
Update on 2019-04-01: Community Bridge was also discussed on episode 0x65 of Free as in Freedom, which is available in mp3 format and ogg format.
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 <firstname.lastname@example.org>
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.
SFLC: Escalation Disguised as “Settlement Offer”
byon December 22, 2017
Conservancy stands by our motion for summary judgment to dismiss Software Freedom Law Center (SFLC)'s petition to cancel our trademark. This remains the most resource-efficient way to dispense with SFLC's unwarranted attacks. We have received their latest escalation, disguised as a “peaceful settlement” offer. Instead of deescalating today, SFLC added inflammatory accusations against Conservancy and its employees. Obviously, we did not commit fraud; our legal counsel, Pam Chestek, has advised us that SFLC's fraud allegation is “unequivocally unfounded”. We will not let them further waste our time.
We cannot accept any settlement offer that includes a trademark license we don't need. Furthermore, any trademark license necessarily gives SFLC perpetual control over how we pursue our charitable mission. SFLC, our former law firm, helped us form and name our independent entity. Changing this arrangement now does not advance software freedom nor our mission. Our community remains best served by SFLC and Conservancy as independent entities.
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.