Hello everyone, I am Hrishikesh, and this is my follow-up blog post concluding my experiences and the work I did during my 3.5 month remote internship with the FSF. During my internship, I worked with the tech team to research and propose replacements for their network monitoring infrastructure.

A few things did not go quite as planned, but a lot of good things that I did not plan happened along the way. For example, I planned to work on GNU LibreJS, but never could find enough time for it. On the other hand, I gained a lot of system administration experience by reading IRC conversations, and by working on my project. I even got to have a brief conversation with RMS!

My mentors, Ian, Andrew, and Ruben, were extremely helpful and understanding throughout my internship. As someone who previously had not worked with a team, I learned a lot about teamwork. Aside from IRC, we interacted weekly in a conference call via phone, and used the FSF's Etherpad instance for live collaborative editing, to take notes.

The first two months were mostly spent studying the FSF's existing Nagios- and Munin-based monitoring and alert system, to understand how it works. The tech team provided two VMs for experimenting with Prometheus and Nagios, which I used throughout the internship. During this time, I also spent a lot of time reading about licenses, and other posts about free software published by the FSF.

My primary tasks involved writing Ansible roles and small Python tools, as well as understanding how Prometheus and its ecosystem worked. I even picked up Golang and started contributing small PRs to the Prometheus project itself.

The final outcome was a documented repository along with all the Ansible roles that are capable of spinning up a fully functional Prometheus server with related tools and configurations specific to the FSF. It's not yet ready to be implemented, but is in a good position to be extended.

Even though this internship is unpaid, I would highly encourage anyone reading this blog post to apply for future internship positions with the FSF tech team because of the knowledge value it provides.

I would like to thank the FSF for providing me this internship, and hope that my work will extend their current network monitoring systems into the future.

Interested in interning for the Free Software Foundation? The application period for summer 2019 internships is open until March 31, 2019 -- see details here.

I've been making the argument that everything is a free software issue for a few months now. Back in November, I was lucky enough to speak at SeaGL and SFSCon, specifically on the issues proprietary technology poses in dating and maintaining romantic relationships.

I've been thinking about this since then -- the issues and infringements on user freedom we face when using technology to meet people, date, and fall in love. I think Valentine's Day is the perfect opportunity to share just some of these thoughts I've been having.

Meeting people

Many dating Web sites run proprietary JavaScript. JavaScript is code that Web sites run on your computer in order to make certain features on Web sites function. Proprietary JavaScript is a trap that impacts your ability to run a free system, and not only does it sneak proprietary software onto your machine, but it also poses a security risk. Any piece of software can be malicious, but proprietary JavaScript goes the extra mile. Much of the JavaScript you encounter runs automatically when you load a Web site, which enables it to attack you without you even noticing.

Proprietary JavaScript doesn't have to be the only way to use Web sites. LibreJS is an initiative which blocks "nonfree nontrivial" JavaScript while allowing JavaScript that is either free or trivial.

Many dating apps are also proprietary, available only at the Apple App and Google Play stores, both of which currently require the use of proprietary software.

Going out

When it's time to meet your online date in person, or spend time together with the person you're dating, more proprietary software is ready to crash the party, whether you're going out or staying in. Many restaurants run reservations entirely through Web sites, using software and JavaScript that is proprietary. Using ride sharing apps like Uber to get around puts users and drivers alike at all sorts of risks. Or, if you decide to have a romantic evening at home, you might find yourself tempted by freedom disrespecting, DRM-supporting streaming services like Hulu and Netflix.

DRM is an oppressive technology, prevalent among downloadable, online, and streaming media. It restricts your ability to use, reuse, modify, share, and really own the media you purchase. There are practical damages DRM causes: it prevents modifying media for accessibility needs; it keeps people from being able to access their media whenever they want or need to; and it stifles creativity through the prevention of re-use. However, most importantly, the type of control enabled by DRM infringes on your freedoms.

Luckily, there are DRM-free media options available to you. Whether you want to find movies, listen to music, or curl up and read together, there is the perfect DRM-free choice available now.

A few other points

There are lots of computing technologies people use to maintain our relationships, whether romantic, familial, or platonic. They share online calendars, they use Web sites like Amazon to purchase and send presents, and they use apps like Snapchat, WhatsApp, and Facebook Messenger to connect with one another every day. These are all proprietary tools, and the act of using them restricts our freedoms.

When the ways we connect with one another are proprietary, we're trusting our secrets, intimacies, and relationships to technology we cannot trust. Software freedom is a necessary step in building trust in our computing technologies. When code is visible, the people who create that code are accountable, but also we have the rights to use, share, study and modify, and share our modifications with one another.

Software freedom is important in all aspects of our life, and that includes romance. By valuing freedom in our relationships, we're not only respecting ourselves, but we're respecting the people with whom we have those relationships.

Free software is crucial for a free society, and we love being able to use technology that respects our rights. Spread the love this Valentine’s Day and spread the word about free software by sharing this graphic, which invites your friends and family to learn more about computer user freedom, with the hashtag #ilovefs:

Want to take your relationship with software freedom, security, and privacy to the next level? Ask a friend or loved one to be your cryptovalentine! It’s a great opportunity to teach the importance of encrypted communication AND to help someone you care about secure their communication from prying eyes.

• artanis-0.3.1
• autoconf-archive-2019.01.06
• bash-5.0
• bison-3.3.1
• c-graph-2.0.1
• diffutils-3.7
• ed-1.15
• freedink-109.4
• freeipmi-1.6.3
• gnuastro-0.8
• gnuhealth-client-3.4.3
• gzip-1.10
• libidn2-2.1.0
• mdk-1.2.10
• mit-scheme-10.1.5
• moe-1.10
• ocrad-0.27
• parallel-20190122
• readline-8.0
• recutils-1.8
• tar-1.31
• tramp-2.4.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.

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 at maintainers@gnu.org with any GNUish questions or suggestions for future installments.

The FSF Licensing and Compliance Lab is committed to helping free software developers around the world with their questions sent to licensing@fsf.org. Our primary goal is to support what we believe is the best legal tool we have for protecting the rights of users, copyleft. The Lab works toward that goal by offering licensing education, running certification programs like Respects Your Freedom, providing license compliance and enforcement for the GNU Project, and fielding licensing questions from the free software community.

In the course of this work, we often refer back to questions in the comprehensive Frequently Asked Questions about the GNU Licenses (FAQ). The FAQ is quite long, with over 150 questions. Looking at the Licensing and Compliance Lab's email referrals to the FAQ can help us gauge the questions that are the most frequent, or perhaps the most confusing. We'd like to share some of the insights we've gathered in our work to make our licensing resources as effective as possible. I amassed all the referrals to FAQ questions made by the Compliance Lab from the past 17 years in order to get a better understanding of what types of questions we field the most. This article will provide an overview of the most frequently referenced FAQ topics, and provide clarification and additional resources for more encumbered scenarios.

Unsurprisingly, we see a long-tailed distribution. Worded differently, we see great inequality in the number of references to FAQ questions. The top 20 most referred to questions (included below) account for over 60% of the references. The single most referenced question, on incompatible libraries, accounts for over 10% of all references. This question deals with using incompatible libraries with GNU General Public License (GPL) software. The solution, as outlined in the FAQ: If you want your GPLed program to link against a library not covered by the system library exception, you need to provide permission to do that. The FAQ then gives examples on how to explicitly provide that permission.

Though only accounting for a fifth of the FAQ, questions about combining work with code released under the GNU licenses account for about half of the lab’s references, making combining work the most frequently referenced topic. Richard Stallman published an excellent licensing guide on gnu.org regarding license compatibility and relicensing at https://www.gnu.org/licenses/license-compatibility.html. As Stallman states, "In general we say that several licenses are compatible if there is a way to merge code under those various licenses while complying with all of them." Even where two licenses are crafted in a such a way that they cannot naturally be combined, however, explicit relicensing provisions can enable code combinations that otherwise wouldn't be permitted. The linked article covers many such questions of compatibility in further detail, and we encourage you to give it a read when researching potential compatibility concerns.

Private use questions are quite common as well. The GPLv3 introduced explicit language guaranteeing the freedom to privately modify and run the covered work in order to alleviate ambiguity. Previously, in the GPLv2, such freedoms were regarded as implicit. Additionally, I’d like to highlight that the GPLv3 contains an explicit contractors' provision, permitting companies to give GPLed works to contractors operating exclusively on the companies' behalf. One concern the Compliance Lab regularly sees regards making copies of GPLed programs within a company, and whether such internal copying triggers the copyleft distribution clauses. The short answer is no. The FAQ goes on to explain: “The organization is just making the copies for itself. As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders. However, when the organization transfers copies to other organizations or individuals, that is distribution."

We continue to receive a multitude of questions concerning the output of GPLed programs. This is understandably a point of concern, as much of today's software and multimedia is produced using other software. As explained in the FAQ, “The output of a program is not, in general, covered by the copyright on the code of the program... The exception would be when the program displays a full screen of text and/or art that comes from the program. Then the copyright on that text and/or art covers the output." The GNU Compiler Collection (GCC) is one such example of this exception because portions of its GPLed source code can be included in a compiled program (GCC's output). That’s why its license includes the (aptly named) GCC runtime library exception. As explained in the exceptions preamble, "When you use GCC to compile a program, GCC may combine portions of certain GCC header files and runtime libraries with the compiled program. The purpose of this Exception is to allow compilation of non-GPL (including proprietary) programs to use, in this way, the header files and runtime libraries covered by this Exception.”

We used to see a lot of questions concerning the perceived differences of the copyleft provisions in the GPL between static linking and dynamic linking. Explained succinctly in the FAQ: “Linking [some program] ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination.” Satisfyingly, questions of this nature have been on the decline as the community continues to debunk this false dichotomy.

The FSF Licensing and Compliance Lab is proud to support free software activists worldwide. Providing resources for developers, hobbyists, and users, in addition to legal professionals, allows us to better spread the ideals of free software. These resources help build a common understanding of copyleft and encourage best practices in software licensing, helping the legal system work more smoothly for everyone. As always, we continue to welcome your questions sent to licensing@fsf.org. Resources like the FAQ and articles like this are made possible by your support. Here's what you can do to help continue and improve our educational resources:

• Keep up to date on all the latest in licensing news by joining our licensing-updates mailing list.
• Support our work by becoming a member or making a donation.

The top 20 most referenced FAQ questions

1. What legal issues come up if I use GPL-incompatible libraries with GPL software?
2. What is the difference between an “aggregate” and other kinds of “modified versions”?
3. A company is running a modified version of a GPLed program on a Web site. Does the GPL say they must release their modified sources?
4. Does the GPL require that source code of modified versions be posted to the public?
5. If I write a plug-in to use with a GPL-covered program, what requirements does that impose on the licenses I can use for distributing my plug-in?
6. What does it mean to say a license is “compatible with the GPL?”
7. Is there some way that I can GPL the output people get from use of my program? For example, if my program is used to develop hardware designs, can I require that these designs must be free?
8. Can I use GPL-covered editors such as GNU Emacs to develop nonfree programs? Can I use GPL-covered tools such as GCC to compile them?
   
9. Does the GPL allow me to sell copies of the program for money?
10. What does it mean to say that two licenses are “compatible”?
11. I'd like to incorporate GPL-covered software in my proprietary system. I have no permission to use that software except what the GPL gives me. Can I do this?
12. Can I write free software that uses nonfree libraries?
13. How are the various GNU licenses compatible with each other?
14. I have written an application that links with many different components, that have different licenses. I am very confused as to what licensing requirements are placed on my program. Can you please tell me what licenses I may use?
15. Can I release a nonfree program that's designed to load a GPL-covered plug-in?
16. If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
17. How can I allow linking of proprietary modules with my GPL-covered library under a controlled interface only?
18. Is making and using multiple copies within one organization or company “distribution”?
19. Can I apply the GPL when writing a plug-in for a nonfree program?
20. Can I modify the GPL and make a modified license?

Graph by Jake Glass, FSF intern. This image is licensed under a Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.