Until January 15, the next $66,168 of support we receive will be matched!
$38,591 matched!
$66,168 to go!

[RSS] Conservancy Blog

Displaying posts by Bradley M. Kuhn and Karen M. Sandler

On Non-Fungible Tokens, Faces of Our Leadership, and Supporting Artists

by Bradley M. Kuhn and Karen M. Sandler on December 23, 2021

We were certainly surprised this week to be told that we (Karen and Bradley) were “for sale” at approximately US$200 each. It's not us personally that's for sale, of course. Rather, the sale is for financial derivative products that are based on digital images of us. Because of the connection to these financial derivative products (called NFT) to our work on ethical technology and FOSS generally, we share herein our analysis of the situation. And, in the unlikely event you were thinking about buying one of these risky financial derivatives — we give our recommendation for an alternative way that you fund both Software Freedom Conservancy and the artist who took the photographs in question while avoiding derivative products entirely.

Basic Backstory

Image of Karen M. Sandler taken on 2017-03-04 during the Faces of Open Source photo shoot

Photo © 2017 by Peter Adams, licensed CC BY-SA

On 2017-03-04, we (Karen and Bradley) sat for a photo shoot with a photographer named Peter Adams, who later released one photo from each of our shoots as part of a larger work called “Faces of Open Source”. We were surprised to learn that we were the only FOSS leaders (among those who had been photographed at that point) to raise the question of FOSS licensing for the photographs themselves. Sadly, Adams was not interested in licensing the series under a Free license. We nearly declined to continue with the photo shoot, but Karen had a compromise idea: if Adams agreed to license one good photo of each of us back to us under CC-BY-SA, we would agree to sit for the photo shoot. We both agreed to sign a release of copyright claims. Rarely do subjects/models hold copyrights anyway on photos (unless it's a selfie), so we determined, especially given that we were in town for the Southern California Linux Expo, this photo shoot was not much different (ethically and morally speaking) than walking around the conference and being photographed candidly, in which case we'd also not hold copyright. We did not relinquish any other of our rights and permissions, but we did agree that our photos could be part of the “Faces of Open Source” art project. We were really happy with the photos, and were glad we had CC-BY-SA photos to use. We appreciated that Adams took the time to prepare them for us.

Non-Fungible Tokens (NFTs)

There has of course been much discussion about NFTs and how they operate on a blockchain. We suspect most of our readers already know the technical details of how NFTs work. What we'd like to focus on is the high level description and how it relates to works of authorship and FOSS licenses.

First and foremost, note that, to our knowledge and understanding, sale of an NFT is generally unrelated to the copyright questions of the image. The NFT is (roughly) a cyptographically-signed checksum of the image. “Owning an NFT” simply indicates that — on some blockchain somewhere — a group of people who participate in that blockchain have cryptographically verified that the particular checksum is associated with you. NFT hawks liken this to “owning” the underlying work, but this is not true. Consider it this way: the “underlying holding” is the photograph itself, which has a financial value based on (a) the fame of the subject, and (b) the artistic ability of the photographer to get a good/intriguing photo of that subject. The NFT, by contrast, isn't the photo, it's “bragging rights” of having others identify that you paid some amount money for the blockchain participants to assent to your “ownership” of a checksum of that photo. The NFT's value, thus, may move in the same direction of the value of the copyright of the photo (or, say, a physical print of that photo), or it may not; there is no way to know. Moreover, we suspect, given the novelty of NFTs, that financial experts don't even yet have reliable equations to understand how NFTs financially relate to their underlyings (as exist for other financial derivatives like futures contracts and stock options). While many people investing in NFTs understand their nature and understand what they are spending money on, we also think there's a predatory component of this industry that exploits people who don't have a good understanding of how NFTs work. We fear that many other people spend money on NFTs without really understanding what they are buying.

Image of Bradley M. Kuhn taken on 2017-03-04 during the Faces of Open Source photo shoot

Photo © 2017 by Peter Adams, licensed CC BY-SA

Meanwhile, one need not have a copyright holdership or even a license to create an NFT of any given image. We could sell NFTs of the same images if we wanted to, even though we don't hold the copyright. We could sell NFTs of the extremely similar color images (shown here) that Adams' licensed under CC-BY-SA. But, we aren't going to do any of that. We think selling NFTs of these images is a silly thing to do.

A Few of the Problems with NFTs

NFTs have many problems, and we aren't going to list them all here, as many are outside the scope of ethical technology. However, the most concerning problem is that most NFT blockchains use “proof of work” systems to verify transactions, which costs computing resources (including intensive use of processors, that produces heat, wastes electricity, and risks wearing out the processors more quickly than more traditional uses). While NFTs are not yet widely adopted (and thus the costs in this regard are currently nominal) most researchers believe that long-term and widespread use of “proof of work” is ill-advised (for environmental and other reasons).

For our part, we probably would not have commented publicly on our concerns about these issues. But, Adams made NFTs for specific images of us, and there is mostly nothing we can do about it — other than state our opinion of it. We would be remiss if we didn't point out that other laws besides copyright are involved here. We are left wondering whether use of one's faces to promote NFTs in this manner could be construed as a violation of California's Right to Publicity Law, and standard releases often don't broadly grant any rights to endorse products like NFTs. (In this case, our rights releases were wholly narrowed to the “Content”, which here is the actual photo, and we were the “models”). It's unclear how far a right to publicity would extend as a legal matter, and we have no intent to explore that. We agree with others in the “Faces of Open Source” series that Adams made a mistake (ethically and morally) by not asking the subjects to agree to have their names associated with the sale of NFTs (particularly given the serious ethical technology considerations about NFTs).

Getting Artists (and Developers) Paid

One of the mission goals of Software Freedom Conservancy is to fund developers to work on FOSS (related to our member projects and initiatives). We believe strongly that folks who do Free Culture works should, similar to those who do Free Software work, get paid for that work. What's more, even though Adams chose not to make “Faces of Open Source” a Free Culture project (opting instead for a traditional proprietary model), we still think Adams should get some compensation for his work — especially for the two photos he licensed as CC-BY-SA. But we think NFTs is the wrong approach.

We originally proposed selling photos in this blog post as a method to raise funds for Adams' work, but Adams wrote to us and indicated that he had not been experimenting with NFTs as compensation for his past work but rather to both help fund future Faces of Open Source photo shoots and raise money for FOSS organizations like ours. So Adams and we all suggest that if you like FoOS, please donate to our current fundraising campaign and other organizations doing good work in this space.

The Hate-Mail We Expect

We know that many of our Sustainers and fans believe deeply that NFTs and other blockchain-related technologies like cryptocoins are world-changing technologies. We remain neutral on that point; we admit that we simply don't know how important these technologies will be long-term. However, we do encourage everyone to consider the ethical implications of technology like this. Plowing ahead with any technology simply because it's new and exciting often leads to unintended dystopian consequences (such as already occurred advertising-based, algorithm-controlled platforms from MMAGA companies).

Finally, this is of course not a full analysis of all the moral and ethical implications of NFTs. We do think NFTs might have some interesting use-cases, such as academic institutions verifying transcripts and degrees of students to third parties (and Karen loves some of the silliness connected with many NFT offerings). If done fully with FOSS, we don't object to further research and consideration of how NFTs can be used for good purposes. However, we approach with skepticism the notion that financial derivative transactions should receive the primary use-case focus around new technologies, as has happened with NFTs. We should evaluate all new technologies first and foremost with a question of how they can improve the lives of the most disadvantaged and underrepresented individuals.

First Update on the Vizio lawsuit

by Bradley M. Kuhn and Karen M. Sandler on November 30, 2021

Yesterday, we received from Vizio their first official response in our pending litigation against Vizio for their copyleft license violations. So, what was their response?

Did Vizio release the source code — as the GPL and LGPL require — for the modified versions of Linux, alsa-utils, GNU bash, GNU awk, BusyBox, dmesg, findutils, dmsetup, GNU tar, mount and selinux found in their TV’s firmwares? No.

Did Vizio propose a CCS candidate for us to review, provide them with additional feedback, so that we could help them get consumers who bought their TVs the source code they deserve? Nope.

Did Vizio argue that we had erred, and in fact, none of those programs we list above appear in their firmware? Not that either. (Unlikely though — after all, they surely know those programs are in their firmware!)

Instead, Vizio filed a request to “remove” the case from California State Court (into US federal court), which indicates Vizio's belief that consumers have no third-party beneficiary rights under copyleft! In other words, Vizio’s answer to this complaint is not to comply with the copyleft licenses, but instead imply that Software Freedom Conservancy — and all other purchasers of the devices who might want to assert their right under GPL and LGPL to complete, corresponding source — have no right to even ask for that source code.

That’s right: Vizio’s filing implies that only copyright holders, and no one else, have a right to ask for source code under the GPL and LGPL. While we expected Vizio held this position (since they ultimately ignored us during our discussions with them in years past), Vizio has gone a disturbing step further and asked the federal United States District Court for the Central District of California to agree to the idea that not only do you as a consumer have no right to ask for source code, but that Californians have no right to even ask their state courts to consider the question!

Vizio’s strategy is to deny consumers their rights under copyleft licenses, and we intend to fight back.

We believe in complete transparency of the copyleft compliance process, and so encourage everyone to read the filings. We’ve even paid the Pacer fees and used the Recap browser plugin, so that all the documents in the case are freely available via the Recap project archives.

Software Freedom Conservancy’s annual fundraiser is happening right now! Please help us continue our work by becoming a Sustainer. Donate now and have your donation matched by a group of generous individuals who care deeply about software freedom.

Tags: conservancy, law, licensing

Chasing Quick Fixes To Sustainability

by Bradley M. Kuhn and Karen M. Sandler on May 23, 2019

Various companies and trade associations have now launched their own tweak on answers to the question of “FOSS sustainability”. We commented in March on Linux Foundation's Community Bridge, and Bradley's talk at SCALE 2019 focused on this issue (video). Assuring that developers are funded to continue to maintain and improve FOSS is the focus of many organizations in our community, including charities like ourselves, the Free Software Foundation, the GNOME Foundation, Software in the Public Interest, and others.

Today, another for-profit company, GitHub, announced their sponsors program. We're glad that GitHub is taking seriously the issue of assuring that those doing the work in FOSS are financially supported. We hope that GitHub will ultimately facilitate charities as payees, so that Conservancy membership projects can benefit. We realize the program is in beta, but our overarching concern remains that the fundamental approach of this new program fails to address any of the major issues that have already been identified in FOSS sustainability.

Conservancy has paid hundreds of thousands of dollars to fund FOSS developers over the course of our existence. We find that managing the community goverance, carefully negotating with communities about who will be paid, how paid workers interact with the unpaid volunteers, and otherwise managing and assuring that donor dollars are well spent to advance the project are the great challenges of FOSS sustainability. We realize that newcomers to this discussion (like GitHub and their parent company, Microsoft) may not be aware of these complex problems. We also have sympathy for their current approach: when Conservancy started, we too thought that merely putting up a donation button and routing payments was the primary and central activity to assure FOSS sustainability. We quickly discovered that those tasks are prerequisite, but alone are not sufficient to succeed.

Just as important is how the infrastructure is implemented. GitHub is a proprietary software platform for FOSS development, and their sponsors program implements more proprietary software on top of that proprietary platform. FOSS developers should have FOSS that helps them fund their work. Choosing FOSS instead of proprietary software is not always easy initially. Conservancy promotes free-as-in-freedom solutions like our Houdini project and other initiatives throughout our community. We are somewhat alarmed at the advent of so many entrants into the FOSS sustainability space that offer proprietary software and/or proprietary network services as a proposed solution. We hope that GitHub and others who have entered this space recently will collaborate with the existing community of charities who are already working on this problem and remain in search of long-term sustainable, FOSS-friendly solutions.

Tags: conservancy, FOSS Sustainability

Choosing a GPLv3-termination Backport to GPLv2 (KESAP vs. GPLCC)

by Bradley M. Kuhn and Karen M. Sandler on May 11, 2019

About four years ago, Conservancy (in collaboration with the Free Software Foundation) published the Principles of Community-Oriented GPL enforcement. Our goal was to conduct our enforcement ethically and respectfully, treating today's violators as tomorrow's contributors. Accordingly, the Principles advocate a holistic approach to GPL enforcement that truly seeks to gain GPL compliance to advance software freedom. We were so happy about the way the Principles assisted the Netfilter team and we were excited that there was substantial interest in codifying these long standing ad-hoc Principles into a widely adopted and published consensus.

Ideas in FOSS also have a way of taking on a life of their own; we share our ideas in the hopes that others will build on them. We have been pleasantly surprised that the last Principle, “Community-oriented compliance processes should extend the benefit of GPLv3-like termination, even for GPLv2-only works”, received so much interest.

This interest led to two independent initiatives to “backport” the GPLv3 termination provisions — by way of an additional permission — to GPLv2-only-licensed works. Additional permissions to GPLv2 have been used for various purposes since the early 1990s (such as for the Bison exception). Additional permissions grant more leeway — relaxing some requirement of the default license — in an effort to reach some policy goal for the project. In this case, the additional permission softens the strict terms of the GPLv2 termination provisions, which state that any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. That means permissions under GPLv2 are instantly and permanently lost on even easily-correctable violations and require reinstatement of permissions by copyright holders. In contrast, the GPLv3 version gives downstream violators short time periods to comply and receive automatic reinstatement of permissions, via the following clause:

If you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

This improved policy can indeed be “backported” to GPLv2 via an additional permission.

Two Choices

Two efforts over the last year and a half have “implemented” these backports. The first released was the solution now used by the Linux community, which states:

Notwithstanding the termination provisions of the GPL-2.0, we agree that it is in the best interests of our development community to adopt the following provisions of GPL-3.0 as additional permissions under our license with respect to any non-defensive assertion of rights under the license, However:

[Quotes GPLv3 termination provisions as above]

We call this sub-document the Kernel Enforcement Statement Additional Permission (“KESAP”), as it is published as part of a larger document named “Kernel Enforcement Statement”. (The rest of that document does not contain legally binding terms.)

The second effort, inspired by this KESAP, was released later by Red Hat, which they call the GPL Cooperation Commitment (often abbreviated GPL-CC or GPLCC), but which we will call here “RHCC” to avoid any confusion with FSF initiatives around the GPL and license drafting, and because to most people in licensing, CC refers to “Creative Commons”. The RHCC is available on github.

Adopting One of the Additional Permissions

Conservancy finds both documents intriguing and worthy of additional study and consideration. Moreover, Conservancy has decided that we will adopt one of these GPLv3-termination-backport provisions for copyrights we hold, and advocate adoption for other copyrights held by contributors for our member projects. While we don't demand this of anyone (and won't make use of such an additional permission mandatory for our GPLv2'd projects), we make a strong recommendation for use of a GPLv3-termination-backporting additional permission.

We have for months carefully considered which of the two options is the best to adopt. This was a difficult decision, since the two are similar and both have some problematic aspects. While we applaud both the Linux community and Red Hat for promulgating these useful additional permissions, on balance we prefer KESAP, and so we are adopting and endorsing KESAP. Below we discuss our reasons for this choice between the two for those who wish more detail. Anyone interested can also listen to episode 0x67 of Free as in Freedom where we discuss these issues in detail.

Length and Complexity

KESAP is about half as long as RHCC. When you remove the direct quote in both documents that come from GPLv3's text itself (which obviously must be included in both), the RHCC adds 1,180 words and KESAP adds only 323.

The RHCC is also more complex. It adds additional defined terms, including redefining “We”, which is already a term used in GPLv2's preamble to refer to the FSF. It adds an irrevocability clause, which is not harmful, but it is unnecessary since unilaterally granted copyright permissions are generally irrevocable anyway. Furthermore, given that the word “irrevocable” doesn't appear in GPLv2, adding a redundant irrevocable clause could easily confuse license readers into thinking that GPLv2 itself is otherwise revocable even while the additional permission is not.

Aggressive Defensive Termination Violates Principles

Our biggest concern with both KESAP and RHCC is that they only apply in “non-defensive” situations. This allows copyright holders to fail to provide 30 days for violators to repair violations when those violators are already aggressors in some other form of litigation.

While we are somewhat sympathetic to those who might seek to use GPL enforcement to retaliate against other bad actions, we believe that even potential bad actors deserve the benefit of the doubt and the meager 30 days to repair a violation before facing aggressive enforcement tactics. Furthermore, defensive actions that bring the GPL into court as part of business dispute otherwise unrelated to free software are also the most likely litigation to generate bad legal precedent regarding the GPL. (Indeed, many of the lawsuits that have already been brought over the GPL are in this category. While so far these have settled out of court, there's no reason to expect that to always happen in the future.) We are disappointed that both sets of drafters feel that copyright holders should hold back this permission in those cases. As the Principles state, we continue to discourage any legal action (defensive or otherwise) against a copyright holder who otherwise succeeds in producing a compliant GPL'd source release within 30 days of violation notice. We ask Red Hat and the Linux community to also make this same cure commitment universally, perhaps in an updated version of these additional permissions.

We do note that RHCC is slightly better on this point, since it does narrow non-defensive via a defined term, but it does not narrow it enough to make a real difference, while also adding additional complexity. Moreover, the text specifically mentions legal proceedings and claims, which draws attention to the very activities that make nervous copyleft software adopters skittish.

Additional Permissions Should Not Codify Assent Mechanisms

RHCC has its own orthogonal assent mechanism, based on the presence of a file in the repository. This assent mechanism, while it seems similar to a traditional inbound=outbound regime, is actually novel and untested. The mechanism attempts to gain assent based on a specific date of inclusion of the RHCC file in a repository. Contributors, however, do not necessarily receive any notice of the addition of that file, and therefore their assent is unclear.

For example, imagine a pull request from two levels downstream that waits for merge for months. The modern DVCS-based software development process allows developers to work indefinitely on a forked copy of the repository and there is no way to know that the contributor had a copy of the repository that pre-dated the addition of the file, and they may not have a copy of the RHCC in their repository. When all is merged, it will appear that their commit postdated the addition of the RHCC, but the contributor may be unaware that the exception is added.

Furthermore, many projects already have licensing assent systems that are likely incompatible with one that is baked into the RHCC. Indeed, Linux itself has decided that they cannot make KESAP part of the DCO assent, since too many Linux developers already believe Signed-Off-By means assent merely to GPLv2-only-compatible licensing. The RHCC, when added to a existing project, cannot be adapted to fit a DCO process without modification of the DCO. Since Signed-Off-By tags rarely assent specifically to a version of the Project's DCO, RHCC is incompatible with a DCO-assent-based inbound=outbound assent system.

By contrast, the KESAP is flexible on assent. The entire KES, which includes the actual additional permission that is the KESAP, asks contributors to affirmatively assent with a patch that adds their own name to the file — explicitly indicating assent. Extracted from the KES, the KESAP text can be combined easily with virtually any assent mechanism in use in FOSS today. RHCC simply cannot.

Adding KESAP to your project

Linux is the gold standard of frictionless legal assent that is well-accepted by both individual hobbyists and contributors and corporate contributions and users alike. Recommending the Linux solution to this particular GPLv3-termination backport is simply the best way to quickly promulgate these additional permissions to GPLv2'd projects. We'll be working over the coming months to encourage, and hopefully assist, Conservancy's LGPLv2'd and GPLv2'd (or-later) member projects to implement KESAP. We will also relicense all Conservancy's own GPLv2 (or-later) copyrights to include the KESAP.

Tags: conservancy, GPL, law, licensing

Next page (older) »

[1] 2 3 4 5

Connect with Conservancy on Mastodon, Twitter, Facebook, and YouTube.

Main Page | Contact | Sponsors | Privacy Policy | RSS Feed

Our privacy policy was last updated 22 December 2020.