Matcher interview with Emily Dunham - 2024 Fundraiser

by Daniel Takamori on December 19, 2024

CC-BY-NA 4.0 Emily Dunham

Next up in our matcher interview series is Emily Dunham (edunham). Having been involved in free software for almost 20 years, her work has spanned all kinds of places from working at Mozilla with the Rust community to being a developer advocate and now being at Okta. Thanks to Emily for the incredible interview!

SFC: Tell us a bit about yourself! Where are you from, what are some of your hobbies?

edunham: I'm from the middle of nowhere, grew up off-grid in a tiny community where I still live and volunteer to this day. I've been working remotely in tech since around 2014, in various ops and automation roles for a series of Californian tech companies. I'm barely aware of how fundamentally this forestry-community upbringing shaped my worldview, except for how it causes the culture shock of bay-area thinkers being okay with planning only a year or a quarter ahead.

I have a rotating portfolio of hobbies where if I share about too many at once, it starts to sound like I'm exaggerating for comedic effect. Right now, in November of 2024, my free time is going to a combination of revisiting Skyrim Special Edition and addressing my backlog of "that seems like a neat idea, but..." topics with the fallible but well-read tutelage and co-thinking of claude.ai and, soon, local more-open models. (Claude is very helpful for bootstrapping into a toolchain to deliver similar benefits while being less at the mercy of some distant corporation choosing to keep offering it as a product, not unlike learning to brake and steer in an automatic vehicle before learning to drive a manual). There are a lot of surprises about AI that each individual who meets it has to have for themself at this moment in history, so I'm working on getting those out of the way without sounding too silly about it, because that seems like a prerequisite for making any useful contribution to our collective thought about and understanding of it. I'm quiet on the socials these days, but that might change as I continue building out the cognitive prosthetics to let me do more of the things I want to. I'm also halfway through a couple baby quilts for friends who are expecting next spring (if you're wondering, AI is unhelpful past the point of uselessness so far with quilting).

SFC: Why do you care about software freedom? How long have you been involved?

edunham: I care because it's good for me -- like I care about my garden because fresh veggies are delicious, or I care about keeping on top of routine maintenance around the house because it's super inconvenient to have to fix things if one lets them get to a point where they break.

I think everyone has their version of Stallman's printer story, and mine is the high school robotics team. We had these huge corporations throwing money and resources, especially "free" licenses for expensive software, at us left and right. This confused me, and I asked "why" enough times to eventually get the picture: They wanted us to build marketable job skills with specific proprietary technology so that we would go to employers and demand that they buy us a license for expensive proprietary software. They wanted us to invest our time in skills that they could then hold for ransom. We have plenty of mythology about the importance of thinking very carefully before entering that kind of contract with a more-powerful-than-human entity, so I thought through it carefully, and declined the offer.

My rule of thumb for investing time in learning a software tool is that I must be able to take that tool with me, online or offline. Software is cognitive prosthetics, and I'm lucky enough to have a choice among many options, unlike physical prosthetics like Karen's augmented heart. The tools I can keep with me through my life, without depending on money or an employer to maintain my access to the skills I've invested my own time in refining, tend to be free software.

SFC: How do you use free software in your life?

edunham: Free software is the invisible infrastructure that facilitates basically every benefit our species derives from computers. We hide it well, because free software often chooses raw power over generic usability -- it's like the logistics areas of an airport rather than the public spaces. But let's say I drive to the store to get some groceries. Maybe the traffic is bad, so I pull up google maps to get its opinion of the fastest route. First, I'm using an Android phone, so there's decades of Linux work underpinning its existence. But even on an iPhone, GPS "just works" and knows where the device is at by receiving signals from satellites and cell towers. How do those signals turn into a location? It's basically because all the devices agree on exactly what time it is, and they do that using the NTP stack and referencing public timeservers. (if you know with enough precision when a signal was sent and when it was received, and you know the speed at which it propagated, you know the distance it traveled. so from there it's just triangulation with multiple satellites or cell towers) Maybe I check my bank balance on my phone as I walk into the store, to make sure I know how much is in the account for the debit card I'll pay with later. My ability to do that safely instead of having my banking details easily stolen relies on encryption that's usually implemented using free software tools. And then the food at the store, from all over the world -- that got into the store through supply chains that use servers, databases, sometimes mainframes, and I'd challenge you to name any one of those systems with no load-bearing free software utility in its creation and maintenance. XKCD 2347 holds true. That's barely scratching the surface, as there's a whole lot more free software and right-to-repair concerns in growing the food before it even touches those systems!

SFC: On the spectrum on developer to end user, where do you lie? And how do you think we could do better bridging that divide?

edunham: The closest tech stereotype to how I relate to development is that of "ops guy". I love automation -- there's something so satisfying and grounded about working in a feedback loop where I am among my own customers. It often sidesteps that philosophical quagmire about what a more distant user's problem "really is" and when it's "really solved".

edunham: I think you could do better at reaching out to people so un-technical that they don't even realize they're the end users. You do targeted outreach to non-technical people in political positions of power, and I'll bet you're learning insights about what works and what doesn't that would scale excellently to the populations who vote for those people as representatives of their way of being. In other words, I suspect that your model of communicating with lawmakers has a lot of room for trying to scale to their constituencies.

SFC: What's got you most excited from the past year of our work?

edunham: Selfishly, you held FOSSY, which was like everything I missed out on by being a rural middle schooler during the early OSCON days. In the bigger picture, your DMCA work is ground-breaking, and the continued focus on right to repair should be of great interest to anyone who likes eating food that comes from farms where farmers wear these amazing mechanical exoskeletons of agricultural equipment to produce produce at a literally superhuman scale.

SFC: Do you think we are doing a good job reaching a wider audience and do you see us at places you expect?

edunham: I'm blissfully unaware of how wide an audience you reach. It's one of those problems where if nobody was successfully dealing with it, I'd feel like I "had to" help out more directly... but that kind of work is definitely not above the fold in my list of ways i'd rather be spending my time, so I'm grateful that you have it handled.

SFC: Have you been involved with any of our member projects in the past?

edunham: I'm doing this interview on an Etherpad as we speak, connecting using hardware running OpeWrt. I use Git on a daily basis to get my work done... Wine gives me games, Selenium gives me automation even when things don't offer a featureful api. I worked at the OSU OSL back in the day and did more direct ops support for some of the projects, but the intersection of my time availability, interests, and skillset doesn't have me contributing directly to any Conservancy projects at the moment.

SFC: How do you see our role amongst the various FLOSS organizations?

edunham: I get the luxury of not caring deeply about who does what role in the FLOSS organization landscape. I categorize you loosely as an organization that focuses on interfacing with the US government and helping it notice and course correct when it accidentally passes legislation that violates the principles on which it was founded. Translating modern tech concepts into "normal" human terms is really hard, especially when the people you're talking to might hold the belief that they already know the things which are worth knowing, so having as many unique approaches as possible to this challenge seems to bring far more value than trying to somehow consolidate them all. It's like by having a lot of organizations which each specialize in a high-impact area of opportunity, we demonstrate the engineering principle of building many simple utilities that excel at their tasks.

SFC: Do you think we do a good job standing up to the organizations with more corporate funding?

edunham: I think you do a good job of standing up to the organizations which are accidentally anti-freedom, and working within their worlds to explain how freedom is good actually. I hope you're not standing up to other software freedom organizations except when absolutely necessary, because the potential impact and good of working together is on a whole other scale from the potential good of infighting about less-important details.

SFC: What other organizations are you supporting this year?

edunham: I'm actually not that into the whole "donate money to charity" thing as a first line of social impact, because I'm uncomfortable with the harmonics of systems where giving money incentivizes asking for more money. I support my community by volunteering as an EMT and firefighter; I support local businesses by spending at them even when it's more expensive or less convenient than buying the same thing online. And I support roads and schools and stuff, along with the other side effects, by paying my taxes. But I happen to work at a larger corporation that offers a holiday giving match, and I strongly believe that corporations should do more to support the FOSS that they rely on, so what better way to combine these beliefs than leveraging their matching funds program to double a donation to Conservancy?

[permalink]

Tags: conservancy, fundraiser

Linux banned Russian contributors. Does my FOSS project need to worry about U.S. Sanctions?

by Rick Sanders on December 12, 2024

Since the Linux project removed a number of entries from the MAINTAINERS file, all of whom were putatively Russian, in October, we've been receiving questions about U.S. sanctions against Russia and what, if anything, we should do about them. As I explain below, our position is that such drastic action, though defensible, is unnecessary.

What would compel the Linux project to take action against specifically Russian contributors—and is it a good enough reason such that other FOSS project should follow suit? The Linux project has access to the lawyers of the Linux Foundation, after all. Unfortunately, the Linux project's initial announcement said only that the removals were due to various compliance requirements. The announcement added that the Russian contributors can come back in the future if sufficient documentation is provided. But it didn't say what sort of documentation would be required. Linus Torvalds added a little clarity when he said that "sanctions" were the cause.

Speculation quickly centered on Executive Order (“EO”) 14071, one of the U.S. sanctions against Russian. It had recently been expanded to include software development and IT services, just a month before the Linux project's announcement. (EO 14071 dates to April 2022, but its scope is expanded from time to time to include new industries.)

The problem with this theory is that EO 14071 doesn't apply to contributions from a Russian national to a software project (even though it now applies to software development). It is true that, when a Russian national makes a copyrightable contribution to a software project governed by the GPL, the Russian national enters into a contractual relationship with (at least) all downstream distributors. But EO 14071 doesn't sanction any and all contractual relations with Russian nationals. It only prevents the provision of certain software- and IT-related services (including software development and consulting) to Russian nationals from a “U.S. person”. In other words, EO 14071 works in reverse to the Linux project's situation.

So, if it's not EO 14071, could it be some other U.S. sanction? There are, after all, quite a number of them. On October 24, James Bottomley provided something of an answer. Citing Linux Foundation lawyers, Bottomley wrote that the Linux project means to exclude companies on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company the list. (OFAC is the Office of Foreign Assets Control, a division of the Treasury Department, in charge of maintaining these sorts of sanctions. SDN means “Specially Designated Nationals,” i.e., persons and businesses, as opposed to entire regimes.) Under this analysis, the documentation referenced in the initial announcement would be paperwork tending to prove that the contributor did not work for such a sanctioned company.

Alas, this doesn't tell us very much. Not only are there several U.S. sanctions against Russians, which cover different activites and serve different purposes, but each of them affects its own set of (overlapping) Russian parties. Wading one's way though these sanctions is a slog that almost no FOSS projects can possibly wade through. You have to parse the actual statutory and regulatory language, review later regulations and executive orders that might alter the sanction's scope, check whether a given Russian individual or entity is subject to that particular sanction (because two given sanctions don't necessarily apply to the same Russians), then check whether your activity or relationship with that Russian individual or entity is covered by the sanction. (On the upside, the U.S. government provides a handy website that allows you to check which sanctions, if any, affect a particular Russian person or entity. But, even if you can be sure you've checked the right person/entity, you still need to determine whether the sanction actually applies to your own activity.)

This is a lot of work. And I think that explains the Linux project's cautious approach: namely, suspending all Russian contributions to the project temporarily; then checking each contributor, case-by-case; and (presumably) reinstate them if they don't show up on any sanctions list. Even this strategy might not be feasible for many if not most projects. They might be more reliant on Russian contributions, be less able to withstand the blowback from sudden suspensions, or simply lack the legal resources.

In my view, none of the Russian sanctions prevents Russians from contributing to American-based software projects governed by the GPL. While the approach taken by the Linux project is reasonable and understandable, I do not believe SFC's projects to take similar actions at this time.

Besides, the spirit of FOSS, I think, requires a bias toward acceptance of otherwise valid and competent contributions. The goal is great software that, in many cases, affirmatively improves people's lives. Rejecting good contributions undermines that goal. Further, rejecting otherwise good contributions does nothing to further the sanctions' goals. The sanctions are primarily intended to punish Russia for, and to degrade its ability to conduct, its interference in U.S. elections, its flouting of international rules, and its aggression in Ukraine. It is difficult to see how rejecting Russian contributions furthers any of these goals.

There remains one final mystery. Some of these Russian sanctions are several years old, so why is this an issue now? My best guess is that EO 14071 brought the issue of Russian sanctions to Linux Foundations's attention because it was explicitly directed at software development. Even if EO 14071 was found to be inapplicable, Linux Foundation couldn't ignore the whole raft of other Russian sanctions, which would take time to sort through.

Ideally, we could keep geopolitics (and lawyers!) out of FOSS. But that's not always possible. U.S. sanctions are one reason. There's no harm in being cautious, so long as the spirit of FOSS is respected. Different projects and organizations will reasonably come to different conclusions on this matter.

Links to the documents referenced above:

• OFAC FAQ 1128, which sets forth various expansions of EO 14071:
• OFAC FAQ 1187, which explains what's covered by "IT consultancy and design services."
• OFAC's webpage re: Russia-related sanctions
• OFAC's Sanctions List Search

[permalink]

Tags: law, resources

2024 Fundraising matcher interview with Patrick Masson

by Daniel Takamori on December 5, 2024

CC-BY-NA 4.0 Patrick Masson

We're so happy to feature our incredible matchers this year! Thanks to all of them for contributing to our largest match goal yet. Today we're talking with Patrick Masson, Executive Director of the Apereo Foundation.

SFC: Tell us a bit about yourself! Where are you from, what are some of your hobbies? Social media?

Patrick: I am currently the Executive Director of the Apereo Foundation. Apereo was established in 2012 as a non-profit organization and works to support and develop open source software for higher education. The foundation's mission is to assist academia in developing, adopting, and maintaining open source software for teaching, learning, and research. Before Apereo, I was the General Manager of the Open Source Initiative. I have also worked in higher education as a CIO of The State University of New York, Delhi, and CTO at the University of Massachusetts, Office of the President. I started my career as a Scientific Illustrator, moving from pen and ink to computer-generated imaging, thus leading to my later roles in academic computing and free and open-source software.

I live in Albany, New York, moving here from southern California (San Diego and Santa Monica) about 20 years ago. I am on Mastodon at @massonpj@fosstodon.org. I have a Twitter account, but it is dormant and redirects to Mastodon. I'm on LinkedIn but rarely participate. In addition to working at Apereo, I am an adjunct professor at The University at Albany, teaching "Open Source Princinples and Practices" in the College of Computing & Information. I also served on my local school board for four years, 2014-2018. I enjoy playing hockey and biking (slow touring, nothing serious) with my wife, Jamie. We have two sons--and despite all my tutelage and advocacy, one works for Microsoft as a software engineer developing very proprietary video games--Thanksgiving is tough ;-).

SFC: Why do you care about software freedom? How long have you been involved?

Patrick: I first discovered Free Software in the early 90s while working at UCLA. My work focused on medical and scientific visualization. Many of the tools we used from academic and research initiatives were readily shared. The idea of "software freedom" was not well established (or perhaps known to me) then. Rather, universities worked under traditional, collaborative models where peers created cohorts of practice around shared research interests and efforts. The software was just another output of research to be peer-reviewed, edited, built upon, and used by researchers as needed (That sounds like "software freedom"). While we did use software that today carries an OSI Approved License (remember this is before the OSI was founded), including Linux, NCSA HTTPd, some FTP servers, etc., most of the software was community-built, where collaboration, cooperation, and co-creation, were the drivers. No one thought about this beyond the software-specific use cases driving development at an institution or across research efforts. While not labeled as such, the ideals or ethos, practices, and benefits of software freedom took root with me then.

SFC: How do you use free software in your life?

Patrick: I use free and open source software daily and emphasize its use, from my home computing (mobile phone, laptop, and desktops) to professionally at the Apereo Foundation. Working for an organization advocating and supporting free and open source software, I feel it is essential that "we eat our own dogfood." As such, my work computer runs Linux and only FOSS tools/applications, and we strive to deploy FOSS for our business and administrative computing, e.g., Drupal for our website, CiviCRM for our constituent management, BigBlueButton for web conferencing, XWiki for our document management, etc. Truth be told, a few legacy systems are in place, but as opportunities arise to migrate, I expect to do so. How can we convince the institutions we reach out to that FOSS is a viable option if we've not also selected that option?

SFC: On the spectrum on developer to end user, where do you lie? And how do you think we could do better bridging that divide?

Patrick: Like many in our industry, "career advancement" often requires moving away from developer to administrative roles. So, while I am--and always will be--an end user personally and an advocate for free and open source software within the organizations I work with, I do not do any significant development (coding) of software these days. I suppose it could be said that my "development" efforts today are focused on developing organizations that create and maintain free and open-source software and the communities of practice that make it all possible. My efforts (building awareness, fostering adoption, and promoting contributions) include developing an authentic ecosystem beyond software communities were free and open source software--and even the ideals/ethos--can thrive throughout industries and institutoins.

SFC: Tell us about how Apereo is forwarding software freedom and about your role in the org.

Patrick: I joined Apereo just over two years ago. At the time, Apereo primarily served as a fiscal sponsor for open source software developed by academic and research institutions. As free and open source software has become operational on campuses and fundamental to research activities, Apereo is extending its role in supporting educational, administrative, and research computing through software freedom. Many campuses have opportunities through grant funders and consortia initiatives to adopt and even develop their own free and open source software. Campuses, too, rely on open source software created internally or even developed and deployed by trusted third-party service providers. In response, Apereo offers "OSPO as a Service" and "Foundation as a Service." support models where campuses can access Apereo expertise and services to manage their own internal open source software projects locally or outsource their initiatives to the Apereo Foundation. Despite the long history of the practice, especially in higher education where many free and open source projects began, software freedom is still poorly understood by many outside technology fields (i.e., faculty, researchers, administrators). Apereo is working to foster authentic engagement to realize the maximum benefits of software freedom.

Institutions of higher education have an inherent understanding and an appreciation for software freedom as it aligns with and supports academic freedom. Guiding principles include the open exchange of ideas and the pursuit of knowledge. Both prioritize transparency, collaboration, and the freedom to explore, modify, and share work without undue restrictions. In higher education, academic freedom empowers scholars to research and teach freely, fostering innovation and critical thinking. Similarly, software freedom enables developers to study, adapt, and improve code, driving technological progress and accessibility. Together, these principles create an ecosystem that values intellectual curiosity, shared learning, and the democratization of knowledge. Apereo's vision is for an academy where both flourish and mutual support creates a thriving environment for education and technology to grow together.

SFC: What's got you most excited from the past year of our work?

Patrick: FOSSY, FOSSY, FOSSY!!! While there are several activities SFC undertook this year (and has undertaken for many years, hosting several important projects, Outreachy, license protection, general advocacy etc. etc., etc.), organizing and delivering a software freedom-focused conference was for Apereo (and me personally) a highlight. It is not simply because it provides a forum for peer communities of practice to meet after such a dearth of opportunities (due to COVID, OSCON shutting down, etc.), but because the event so well aligns with Apereo's direction and strategy.

For Apereo, the event is a perfect opportunity to work with the free and open source community--projects, foundations, industry, experts, advocates--to introduce the higher education community--institutions, faculty, researchers, administrators--through shared interests and activities. Rarely do these two groups interact, and Apereo--because of FOSSY and SFC--has another touch point to facilitate greater engagement and productivity; we were thrilled to run the FOSS for Education track and are excited to submit a proposal again for the track in 2025. SFC's work to grow and mature the event is phenomenal and inspiring. I am sure FOSSY will continue to grow in size and impact, and Apereo is dedicated to supporting it as best we can through community and contributions.

SFC: What issues happened this past year that you were happy we spoke about?

Patrick: While the history and activities undertaken by SFC related to AI and LLMs extend back to 2020, the recent announcement, "Aspirational Statement on LLM-backed generative AI for Programming," was uniquely prominent for Apereo and higher education. While there are many issues related to AI, two fundamental concerns among institutions of higher education are bias and reproducibility. AI is taking higher ed by storm--if you attended the recent EDUCAUSE Annual Conference, you know what I am talking about. However, real concerns should be evident considering how and where AI "solutions" are being marketed.

A core tenet of research is reproducibility. Research reproducibility suffers significantly when AI models, particularly LLMs, and the datasets used to train them are closed-source or proprietary; transparency, black box algorithms, independent verification/validation, accessibility/equity, etc., are all issues that may impact research and hinder discovery. The same applies to administrative systems where bias, ethical concerns, and a general lack of accountability can impact student and faculty affairs.

I was also delighted to see SFC's response was "aspirational" and delivered in a tone to help and contribute.

SFC: Do you think we are doing a good job reaching a wider audience and do you see us at places you expect?

Patrick: I think SFC--like other organizations working with shared values and a common vision, like Apereo--is in a tough spot. Despite the 30 years of history, many organizations are either unaware or unengaged with free and open source software. Gone are the early days (2004-2012?) where open source was the hot topic, marketing magic, and investors' and industry's funding choice. While the adoption and dependency on FOSS are greater than ever (especially in higher education), actual support and participation by those who most rely on sustainable communities and the projects they produce are declining (disappearing?).

Reaching a wider audience is a real challenge, considering reaching the current audience- which should already be engaging- is so difficult (and frustrating). I honestly believe organizations will come to appreciate the importance of supporting the FOSS core to their business and operations, especially with growing external pressures (e.g., the Cyber Resiliency Act, Software Bill of Materials) combined with new opportunities (e.g., increased funding from granting organizations). While several new organizations are popping up--which, in my opinion, are simply chasing the latest money and buzz--those like SFC, with years of services, credibility with the community, and authenticity in practice, will emerge as fundamental resources and valuable services for organizations that choose to best leverage FOSS for their benefit and the benefit of others.

SFC: Have you been involved with any of our member projects in the past?

Patrick: While most of my involvement has been as an end-user (e.g., I have several scientific illustrations created in Inkscape and published in medical and dental textbooks and journals), I have been most active with the Teaching Open Source project run by Heidi Ellis and Greg Hislop. Considering the project's focus on using open source software and technologies to teach computer science and other disiplines, it's probably obvious why I am involved.

SFC: How do you see our role amongst the various FLOSS organizations?

Patrick: "Supporting the supporters." I rely on SFC as a resource for Apereo's foundational work, which extends Apereo's capacity and capabilities in service to our constituents in higher education. Examples include policy analysis and advocacy, copyleft compliance, the aforementioned "Statement on LLM-backed generative AI," etc. In this sense, SFC serves a similar role to the OSI, where organizations like Apereo, whose focus is "FOSS outward facing," i.e., connecting with end-users, benefit from SFC's "FOSS inward facing," i.e., connecting with FOSS organizations on broader issues impacting their constituent communities.

SFC: Do you think we do a good job standing up to the organizations with more corporate funding?

Patrick: Times are tough for FOSS foundations, and funding from all sources should be pursued. I think SFC does a good job with corporate sponsorship- everyone knows what SFC is all about, and SFC has stayed true to its mission and is authentic in its practices. I do not feel SFC has compromised its credibility or shied away from issues based on corporate support.

SFC: What other organizations are you supporting this year?

Patrick: I am committed to supporting the FOSS projects and foundations I use (rely on) personally or professionally. I consider this no different than those who pay annually for proprietary software. Both models need funding to develop software, but FOSS is a better deal for the consumer: lower TCO, funds that support development--not profits, the ability to help shape the project (features and functions), etc. It is simply a better/smarter business decision for organizations (and individuals) to pay for FOSS than proprietary software.

[permalink]

Tags: conservancy, fundraiser

OpenWrt One: manufacturing software freedom

by Denver Gingerich on December 3, 2024

Software cannot run without hardware. To have software freedom, we need hardware to run our software. Sadly, the vast majority of hardware is not built with software freedom in mind. Too often, we are beholden to the big hardware companies that sell us our laptops, phones, routers, TVs and other devices. Few manufacturers today build devices with user modifiability and longevity in mind. And it's getting worse. Hardware is becoming more and more locked down, making the need for devices that will work in our interests more and more acute.

Software Freedom Conservancy announced on Friday, in conjuction with our OpenWrt member project, that the first router designed from the ground up by the OpenWrt community is now shipping. OpenWrt developers and SFC staff have been coordinating over the past year to design and produce a hardware device (link is to an unofficial reseller; the official seller will have more in January) that showcases the best of what OpenWrt has to offer. From the upstream-first approach, to the up-front source code availability, no stone was left unturned in ensuring the device would give people flexibility and control over the software (and hardware) that runs their network.

SFC works toward GPL compliance across the industry, so the devices running Linux out there (which now include toasters, dishwashers, fridges, and dryers, as well as laptops, phones, routers, and TVs) all comply with the copyleft terms that give you the right to modify and reinstall changes onto your device. GPL enforcement is one way we tackle this problem, but we constantly seek other approaches. In the case of OpenWrt, we have yet another example that shows the device manufacturers that haven't yet complied with the GPL (and given users the rights they are owed) how to do it right — to give people what they want and what the GPL requires.

We are very excited to watch the interesting applications you find for your OpenWrt One. We're amazed and impressed to learn some people are already running Doom and other software that just won't run on a router that you buy from one of the big name router brands. :) We think it's important for people to have the freedom to make their software work for them, to explore, and enjoy their software experience. The GPL and other copyleft licenses exist to make this possible.

The OpenWrt One is admittedly not perfect. It's sadly a prime example of hardware from recent eras that relies on a few binary component firmwares (in this case, for small parts of the wifi, 2.5 GbE port, and RAM calibration). It is difficult to construct modern hardware without a few of these binary blobs. While this reality is a travesty, we are excited that nearly all the source code for the software on the OpenWrt One is freely licensed. This ensures the maximum possible ability to repair and improve the device. We hope the device will last, and someday, since the binary parts are electronically upgradable, future users can replace the binary component firmwares as FOSS replacements become available. The design and distribution of the OpenWrt One shows that it is not only possible to distribute a device containing both copylefted and non-FOSS code, but that it is also cost-effective and straight-forward to comply with the relevant licenses, and allow users to modify and reinstall the device from source.

SFC wants to build this future of freedom for all your electronics (especially those running Linux and other GPL'd software). I work every day through private channels (and the courts, when needed) to get companies to respect your rights under the GPL. I'm ecstatic that we're now creating new hardware to show the world what is possible when we put software rights first! We're excited for everyone to join us on this journey, and encourage you to read our OpenWrt One launch announcement for more details on this first step.

We just started our annual fundraiser and we'd be thrilled if you could support us by becoming a sustainer. For a limited time, until January 15 (or $204,887 of donations), all donations will be matched, so renew or become a Sustainer today! Thanks for helping us bring software freedom (and hardware respecting it) to everyone!

[permalink]

Tags: GPL