Skip to content, sitemap or skip to search.

Personal tools
Join now
You are here: Home Blogs Licensing Why doesn't the FSF release GPG-signed copies of its licenses?

Why doesn't the FSF release GPG-signed copies of its licenses?

by Donald Robertson Contributions Published on May 07, 2015 12:42 PM
While verified copies of our licenses can be useful, this is unfortunately a project that sounds straightforward at first, but all the corner cases found in the wild muck it up.

One relatively frequent request we receive is for the FSF to provide GPG-signed copies of our licenses. GPG is a tool that lets users cryptographically sign or encrypt documents and emails. A GPG-signed document lets anyone who receives it know that they have received the exact same document as the one that was signed. By providing signed documents, users will be able to easily ensure that they have received an unmodified copy of the license along with their software. It's also possible that some system of signing the documents could help projects tracking the use and adoption of various free software licenses. Providing these signed documents is a simple task: run a command and publish the documents. A trivial investment of resources, or at least that is how it appears at first.

The reality is that projects can comply with their duty to provide a copy of a license while also modifying the format of the license documents to meet their own needs. To our knowledge, there's no simple way to correctly identify when a document is the proper license, given that the formatting or structure of the document can vary between distributions. Many distributors even put the license at the end of a longer document or manual. If a valid copy of the license were to fail our check, resolving this issue could waste resources and lead to further problems. We don't want to cause undue grief for projects that are properly licensed under a free license, simply because they want to shift around some white space on the license, wrap the lines at different points, or store the document in a different encoding system.

We turned to our licensing team for ideas about how to reap the same benefits with fewer false failures. Possibilities included flattening the document and removing white space before generating a hash of the document. But testing showed that some valid copies of licenses in the wild would fail this check. There doesn't seem to be a simple method that will accurately verify that the text of the document is unchanged, without constricting the ability of free software developers in how they format the document.

The fact remains that even if users could check that a document they receive is a legitimate, unmodified copy of a GNU license, that doesn't mean that the accompanying software is free of impermissible restrictions. Additional restrictions on the software do not need to be written into the license. In fact, proprietary developers have mastered the art of using many different documents to place restrictions on their software, and the same can happen when a user receives a piece of software that purports to be under a free license. Additional restrictions could be hidden in a README file, a manual, or even a separate licensing or TOS document.

In the end, while it would be convenient and useful to verify via command line that a document is a genuine copy of a GNU license, the problems this can cause are unfortunately more trouble than they are worth. The license, like the documentation, is among the few things distributed with software that are meant exclusively for humans to understand, not for computers to process. After all, it's always great for users to take the time to read the license themselves.

Document Actions

The FSF is a charity with a worldwide mission to advance software freedom — learn about our history and work.

fsf.org is powered by:

 

Send your feedback on our translations and new translations of pages to campaigns@fsf.org.