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.

This week I had a chance to add a NeuG, a True Random Number Generator, to the Free Software Foundation network. The NeuG exclusively uses free software and was developed in Japan by NIIBE Yutaka. A random number generator (RNG) is a device used to generate random numbers for computers. Without getting into a philosophical argument, we humans tend to take the concept of entropy (randomness) for granted. If we wish to produce random data, we simply do so. Computers, on the other hand, do as we tell them to do. They follow a set of instructions provided by a programmer and follow each instruction precisely. So there is no way to ask a computer to give us a random number because we would have to tell the computer in advance what the number is. There are some ways around this. For example, we could use a system's current timestamp as a seed, or starting point, for producing random-seeming numbers by using an algorithm. This approach will create the illusion of entropy, but if someone else knows both the timestamp used for the seed and the algorithm used to generate the random numbers, the sequence of the random number generator can be calculated and predicted.

To solve this problem, a True Random Number Generator (TRNG) is needed. A TRNG takes samples from various sensor data. Then it either uses the collected samples as a raw source of entropy or passes the collected sensor data to a final step for conditioning. The process of conditioning is used to remove bias (trends in the samples taken from sensor readings) from the random numbers produced by the TRNG. In general, conditioning is the process of passing samples collected by the entropy source to a cryptographic hashing algorithm (a one-way mathematical function). Thus, the bias is stripped out of the output and true random numbers can be collected.

At this point, you might ask, "But why are random numbers so important in the first place?" The most common uses of a TRNG include generating cryptographic keys, input for a simulation, and games (including video games and slot machines). If you have a program that requires non-deterministic data, a TRNG can be used to provide it. Our use case at the FSF is to generate strong cryptographic keys. In the age of mass surveillance, the ability to generate strong keys is increasingly important.

Most RNGs function by taking samples from various sources of input from analog sensors. A NeuG uses four sensors for input, and reads them with a STM32F103 microcontroller. These sensors take input from the voltage reference pin on the STM32F103 (VRef), a temperature sensor (Temp), and two analog input pins on the STM32F103 (A0 and A1). These inputs are then combined into the following pairs: VRef and A0, Temp and A1, VRef and A1, and Temp and A0. Next, the sensor data is converted into a digital signal and passed four times through a cyclic redundancy check (CRC) module. Finally, the data is sent to a SHA-256 function to condition the output before it is ready for use via USB.

Overall, the NeuG is easy to set up and install on a network. The device appears as /dev/ttyACM0 and requires no extra software for use on GNU/Linux operating systems. In the coming weeks, I will use a NeuG and am very curious to see how it performs for our use cases at the FSF. Here's more information about the NeuG, including the full source code. To try one out yourself, pick up a NeuG TRNG from the FSF Shop.

Join the FSF and friends today, Friday, May 1, from 2pm to 5pm EDT (18:00 to 21:00 UTC) to help improve the Free Software Directory by adding new entries and updating existing ones. We will be on IRC in the #fsf channel on freenode.

Tens of thousands of people visit directory.fsf.org each month to discover free software. Each entry in the Directory contains a wealth of useful information, from basic category and descriptions, to providing detailed info about version control, IRC channels, documentation, and licensing info that has been carefully checked by FSF staff and trained volunteers.

While the Free Software Directory has been and continues to be a great resource to the world over the past decade, it has the potential of being a resource of even greater value. But it needs your help!

If you are eager to help and you can't wait or are simply unable to make it onto IRC on Friday, our participation guide will provide you with all the information you need to get started on helping the Directory today!

• apl-1.5
• ccrtp-2.1.2
• ccscript-5.0.5
• dejagnu-1.5.3
• ed-1.11
• emacs-24.5
• gcc-5.1.0
• global-6.4
• gnucash-2.6.6
• gnumach-1.5
• gnutls-3.4.0
• hurd-0.6
• icecat-31.6.0-gnu1
• libmicrohttpd-0.9.40
• libtasn1-4.4
• linux-libre-4.0-gnu
• mig-1.5
• nano-2.4.1
• nettle-3.1
• ocrad-0.25
• parallel-20150422
• sipwitch-1.9.7
• source-highlight-3.1.8
• ucommon-6.3.1

For announcements of most new GNU releases, subscribe to the info-gnu mailing list: https://lists.gnu.org/mailman/listinfo/info-gnu.

To download: nearly all GNU software is available from https://ftp.gnu.org/gnu/, or preferably one of its mirrors from https://www.gnu.org/prep/ftp.html. You can use the url https://ftpmirror.gnu.org/ to be automatically redirected to a (hopefully) nearby and up-to-date mirror.

This month, we welcome Ruben Rodriguez as a new co-maintainer of GNU LibreJS.

A number of GNU packages, as well as the GNU operating system as a whole, are looking for maintainers and other assistance: please see https://www.gnu.org/server/takeaction.html#unmaint if you'd like to help. The general page on how to help GNU is at https://www.gnu.org/help/help.html.

If you have a working or partly working program that you'd like to offer to the GNU Project as a GNU package, see https://www.gnu.org/help/evaluation.html.

As always, please feel free to write to us, maintainers@gnu.org, with any GNUish questions or suggestions for future installments.

In this edition, we conducted an email-based interview with Matt Lee, a lead developer of The List, which is licensed under the GNU Affero General Public License version 3 (AGPLv3), or at your option, any later version. Matt is the technical lead at Creative Commons. Matt has been working in free software for over a decade and is a notable contributor to the GNU project and a former Campaigns Manager at the Free Software Foundation, as well as co-founder of Libre.fm and GNU social. Currently Matt is raising funds to produce a film this summer, Orang-U: An Ape Goes to College, which he plans to edit using entirely free software and release under a CC BY-SA license.

Can you tell us a bit about The List?

No one can be everywhere at once. But everyone can.

NGOs, journalists, government agencies, and cultural institutions all need photographs to tell their story and educate others. But there’s no way for those organizations to be in the right place at the right time, every time. That’s where we come in.

Through The List, organizations will provide lists of locations, people, and events that they need photographs of. And when users are in the right place at the right time, they can claim an item from the list and publish a photograph of it.

What inspired the creation of The List?

The List powered by Creative Commons is an experiment to see if we can make it easier for people to contribute to the public commons. There are millions of places for images that exist in the public commons in our daily lives, from newspaper articles to photos and illustrations on Wikipedia. The List hopes to bring the people who have a need for such images and the people who may take them, together.

How are people using it?

Right now we're still prototyping things and we're working on getting some real world items into The List, but the way it works is pretty simple: you fire up the app, choose some categories of things you're interested in such as pets, beverages, etc. Then we show you an item that matches the category, and the requesting organization (Wikipedia, FSF, etc.) can choose to add it to your list or not. After you go through this process a couple of times, you wind up with a personal to-do list of images. Taking an image is easy, too: just tap it, tap the camera and take your photo. Or you can upload a photo you've already taken. The photo is then sent to some servers at Creative Commons, where we add metadata and produce a variety of thumbnails of the image, before sending it over to the Internet Archive for permanent storage. And moments later, the image is in the gallery in the app on your phone.

What features do you think really sets The List apart from similar software?

I don't think there's anything else like this out there. For the first time, there's an application that makes it quick and easy to contribute to the public commons, and we do that by hiding a lot of the detail away from the user. For example, instead of presenting a choice of the six Creative Commons licenses, we choose one and all images are licensed in the same manner. It's also a license that's compatible with Wikipedia and other similar projects—Creative Commons Attribution 4.0.

Why did you choose the AGPLv3 as The List's license?

In addition to The List mobile app, there's a web app in development too. We based the web app and the processing code on GNU FM, a project I started back in 2009 that powers music communities such as Libre.fm. That code is under the AGPL as well, and it's a code base I am intimately familiar with. So much so that we're using it for another project too: a new federated search project at Creative Commons.

How can users (technical or otherwise) help contribute to The List?

The first thing you can do is if you have an Android phone, come try one of the public beta releases on the website, https://thelist.creativecommons.org.

If you're good at Android programming, you'll find our Android app in our source code under app/.

If you're look at PHP, look under webapp/.

And if you'd like to make some improvements to our website, they're up there too under www/.

We have a really simple contributor agreement up there too. And we licensed that under CC0, if you'd like to use it for your own project.

All of this and more can be found at https://github.com/creativecommons/list.

What's the next big thing for The List?

The next big thing will be a proper public release. We're already talking to the F-Droid folks, and we'll be in all the places you normally find apps for your phone. And F-Droid will have the pure, free software experience.

*Enjoyed this interview? Check out our previous entry in this series, featuring Rainey Reitman, Activism Director for the Electronic Frontier Foundation, about their new EFF Alerts mobile app.