Come chat with us at general@chat.sfconservancy.org 🎉

by Daniel Takamori on June 21, 2021

Last Thursday we launched our new chat platform chat.sfconservancy.org! Conservancy's main chat room, which used to be on Freenode, is now available at the following locations:

1. The primary room, on XMPP at general@chat.sfconservancy.org (also via the web)
2. A bridged IRC room, at #conservancy on irc.libera.chat
3. The bridged room that Matrix provides, at #xmpp_general_chat.sfconservancy.org:matrix.org

We've taken the opportunity of leaving Freenode to change technologies to something we think reflects our ideals. XMPP is a decentralized, open standard and widely used chat platform that supports many of the common features we've come to expect in the new era of chat. Given that we've been using IRC, almost anything would be a strict upgrade when it comes to features. We also wanted to make it as easy as possible for newcomers to start chatting.

We evaluated and tested a multitude of options: XMPP, Matrix, RocketChat, Mattermost, Zulip, ircv3, etc and permutations of bridging support. Given the near parity of features that we care about (we even support reactions now 👍), some reasons we chose XMPP over the others are the longevity and fundamental independence of the XMPP protocol, that we found the matrix-bifrost bridge to work better with Matrix users coming in to XMPP than XMPP users joining Matrix channels (but hope in the future to see this support get better!) and staff familiarity with XMPP. There is also a really healthy and growing ecosystem of XMPP clients and you'll find some recommendations below.

Note: similarly to IRC, your connection to the XMPP server is encrypted, but due to the nature of chat rooms, we cannot provide E2E encryption of the channel itself. Nevertheless here are a list of clients that support OMEMO (which is the standard for E2E encryption for XMPP).

Clients 💻 📱

• Web: Movim, jsxc (for use with NextCloud)
• Linux: Dino IM, Gajim
• OS X: Beagle
• Windows: Miranda
• Android: Conversations
• iOS: Monal

Server 🖥

• Linux: Snikket

And here are some other tools which I think are interesting:

• Biboumi allows you to connect to IRC channels from your XMPP client. We are using this instance.
• matrix-bifrost allows you to bridge from Matrix to XMPP. It's a bit hard to run yourself but Matrix runs one for you!
• matterbridge is what we're using to bridge from XMPP to IRC. It has a plethora of options and is a great tool if you want to bridge yourself into walled garden platforms but use your own FOSS client.

We're excited about the possibilities of what XMPP will bring our community. Specifically helping our projects use more free software where possible. Communication is one area that we particularly think is important to remain free and in our (collective) hands. The proliferation of chat software over the years is a well noted problem, and this is one area that free software both outperforms proprietary options and promotes interoperating standards and giving back the freedom of users to use the software that works for them.

So which ever client and connection you choose, we're excited to hear from you 💻🌉💻

[permalink]

Tags: conservancy, resources

I'm Pono Your New Community Organizer

by Daniel Takamori on May 18, 2021

Hi there, my name is Daniel Pono Takamori and I'm the new Community Organizer and Nonprofit Problem Solver here at Conservancy! My background is in running free software as infrastructure so you might've filed a ticket with me somewhere in the past :) I'm looking forward to this new non-technical role as community support. Being able to bring my skills to help further software freedom here at Conservancy is a very exciting new chapter to me. With projects ranging from programming languages to make programming languages, to community building and mentorship programs, the breadth and spread of projects is incredible. Conservancy projects really help keep you grounded in the varied relationships all people have with software. I'm so grateful for the opportunity to learn from people with different backgrounds, approaches and lived experiences.

I recently gave a keynote at SeaGL 2020 and found the experience of being able to share my non-technical thoughts about technical subjects very invigorating. Speaking more to the human experience of computing technology and the effects computers can have on us. It's with this lens that I hope to bring a more nuanced and compassionate view to the world of software freedom. It's easy to get lost in the billion dollar industries that rely on our labor, but at the end of the day we are people working together with people.

Going forward in this new remote friendlier world, I'm hopeful for more accessible communication. Both with remote friendly conferences, more free software being used to communicate and a more universal understanding that we are people first. While my day to day will probably be lots of email and meetings, I'm excited to find ways to help augment communities with tools like Apache STeVe and freeing projects from proprietary communication tools. Please help me help you by letting us know how Conservancy can be better. Whether it's a more active social media presence, IRC office hours, or if there's an event or project you think we should know about.

I can't believe that after volunteering with Conservancy and contributing to member projects, I now have the honor of championing the great work that WE do.

[permalink]

Tags: conservancy

Understanding Installation Requirements in GPLv2

by Denver Gingerich on March 25, 2021

According to our Principles, we always begin discussions with GPL violators privately. Many of these discussions are ongoing at any time. Recently, we received many questions about GPLv2's requirements regarding installation of modified versions of GPLv2'd software on the device on which the software was distributed. GPLv2 was drafted in anticipation of future uses of the software, and includes specific license text regarding installation:

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

Unfortunately, we find that GPL violators often ignore (sometimes inadvertently) this part of that license text, which has always been of great importance: “the scripts used to control … installation of the executable”.

When a system is 100% FOSS “by design”, meeting this requirement is easy. We applaud the many community-oriented commercial projects that build their own hardware and give their users complete software freedom, such as the LulzBot Mini 3D Printer. We wish that all companies would follow that example and grant customers universal software freedom. Unfortunately, that is currently not realistic, even in the medium term.

Copyleft advocates have always contemplated that some companies will choose to ship proprietary software on the same device as the GPL'd works. Indeed, GPLv2 foresaw this possibility and permits that “mere aggregation” — as long as compliance is achieved for the GPLv2-covered works included on the device.

Indeed, GPLv2 was drafted as a forward looking license. Great care and attention was given to what the future might bring in software, and assure that in the future, GPLv2 defended software freedom adequately. In 1991, the year of GPLv2's drafting, one did not need to look that far ahead to see that general-purpose computers would find their way into devices other than servers, desktops and laptops. It was common, for example, in 1991 to have printers with full computers inside to handle various functionality of those printers. Famously, even back then, software freedom activists were quite frustrated that printer companies and their licensees would not liberate the proprietary software on these printers. Such activists, aware of this problem, sought to fix bugs in this printer software. They demanded source code for their printers, not because they sought to build their own printer from scratch and use that software, but because they wished to modify that source, fix the bugs, and reinstall the liberated printer firmware. This problem was well understood at the time of GPLv2's drafting, and GPLv2 was clearly drafted with this issue and use-case in mind.

To that end, GPLv2 included a clear obligation to provide “the scripts used to control … installation” that function for the GPLv2'd works. GPLv2 assures, to the purchaser of an embedded product, their absolute right to receive the information necessary to install a modified version of the GPLv2'd works. Meanwhile, rules for the legitimately proprietary works remain the prerogative of the licensors of that software. Since we have often been asked, we want to communicate this point with complete clarity and transparency: we would never require that any of the proprietary software on the device continue to function (or even be present) on the device after installation of a modified version of the GPLv2'd works on any device. However, installation of the GPL'd works must succeed and operate in a useful and functional fashion on the device.

Installation is where the proverbial rubber meets the road with software freedom. Of course, we honor the esoteric value of the freedom to study, and that right is important. But much more important, and a key reason that the GPLv2 was created, is the software freedom to reinstall a modified version. That means the right to fix bugs, the right to try out your improvements, and the right to remove privacy-disrespecting anti-features. It's the right that our community needs the most. The GPLv2 was designed to assure bug-fixing. Furthermore, the drafters knew that, on embedded systems and devices, you need to know how to install those fixes. Scripts can be technical artifacts like shell scripts, but can also be merely a recipe and/or guidance — written instructions that explain how to succeed at install.

We know that other software freedom organizations share this view. Conservancy is spearheading the ongoing effort to make this clarity widely known. Below is a simple statement of this position, phrased in other words:

The GPLv2 does not have any specific requirement for preservation of the ability to reinstall proprietary-software-centric vendor-provided firmwares (even if such firmwares contain some GPLv2'd works) on embedded systems, provided that the downstream user (i.e., the consumer with the device) can build, install, run, and (repeatedly and successfully) reinstall a firmware containing at least the copylefted components (such as Linux+Bash).

Not only is this consistent with what the license text says and requires, but it is also consistent with GPL's general policy goal. In our GPL compliance discussions, violators sometimes argue that, in order to install a modified version of the software received on a device, the user should build a new device themselves from scratch (instead of installing those GPLv2'd works on the device they have already). We don't believe that the original intent of the GPLv2 requirements for “the scripts used to control … installation of the executable” included that expectation, nor is that position supported by the license text. GPLv2 was written in a time after embedded devices already existed, and the intent is clear.

Our position is by no means controversial, but we do expect some will seek to argue it is controversial. We encourage you to consider their motives, funding sources, and licensing models. For our part, we published this policy statement to clarify repeated questions that companies distributing devices with GPLv2 software have recently raised in our GPL enforcement actions for Linux, BusyBox, and other software. We look forward to continuing the (sadly) long road toward compliance with these companies, in accordance with The Principles of Community-Oriented GPL Enforcement. We greatly appreciate the work that both individual contributors and companies put into their software and communities. It is our obligation, as copyleft activists, to ensure that GPLv2's rules apply fairly to everyone.

Finally, we encourage others to link to this statement when discussing GPLv2's “the scripts used to control … installation of the executable”.

[permalink]

Tags: conservancy, GPL, law, licensing

On the Recent Announcement by FSF's Board of Directors

by Karen Sandler on March 23, 2021

In response to Sunday's announcement by the Free Software Foundation, we ceased our few remaining activities that intersect directly with the FSF. Most notably, our Outreachy member project exited the FSF from participating in that program — both through mentorship and sponsorship. One project participant in Outreachy's May 2021 round planned to rely on FSF funding. We will not accept those funds from the FSF, and instead Conservancy will pay for that intern ($6,500) from our own general funds. It is my deepest hope that these actions, along with others all over the FOSS community, will catalyze much needed changes at the FSF.

[permalink]

Tags: conservancy, diversity, Outreachy