![[RSS]](/static/img/feed-icon-14x14.png)
Conservancy Blog
Displaying posts tagged GPL
(Software) Repair info on EnergyGuide labels: Conservancy replies to FTC's request
by on December 21, 2022
Software Freedom Conservancy has today submitted its reply to the FTC's request for comments on how repair information should be displayed on EnergyGuide labels. In particular, SFC has recommended that the FTC mandate a "Software Repair Instructions" section on the EnergyGuide labels that are already required on a variety of home appliances, including televisions, refrigerators, clothes washers, and dishwashers. This would not be a new notice requirement for most manufacturers, since it (currently) only requires manufacturers to provide the notice when they already had obligations under copyleft licenses to offer source code already. This merely changes the prominence of such notices, so that users can more easily see which products contain copylefted software (and thus software repair instructions) or not. This is important because many manufacturers make efforts to deemphasize or obscure their offers (if they have them at all), which prevents consumers from learning that they have rights with respect to their software.
We are very happy to see the FTC requesting comments on how repair information for home appliances can be better provided to purchasers of these products. While the FTC's EnergyGuide labeling program started out as a way for purchasers to better assess how much energy each appliance would likely use, and approximately how much that would cost them, the FTC has been taking a more holistic view of how appliance purchases impact the world, not just in terms of how much energy they consume while operating, but also how much energy is required to manufacture them and, consequently, how we can reduce the number of appliances going into landfills, reducing the number of new appliances that need to be manufactured. Free and open source software provides many answers to these repair and longevity questions, and we hope that appliance purchasers will be made more aware of this through the FTC's updated labeling requirements.
By making a lot more people aware that software repair information is available for a device, the chance of a repair community forming for that class of devices increases dramatically. And these communities are immensely helpful to device owners, both for fixing problems that may arise in the software (which can be shared quickly and easily after one person makes them to anyone with that device, regardless of their level of technical expertise), but also for maintaining that software long after the manufacturer has stopped supporting it, meaning they can keep that device operating safely for years to come rather than having to dispose of it, which increases landfill usage and needless new device purchases. We already have several examples of such communities, including SamyGO for older Samsung TVs, LineageOS for most Android phones, and OpenWrt for wireless routers. SFC has fought extensively to protect the right to install your own firmware on your devices. By showing people that software repair information is available to them, we can build many many more communities like these, keeping more devices lasting longer (and better serving their users' needs), and fewer devices in our landfills.
We recommend those interested in this issue read our submission to the FTC, and consider whether to make their own submission in support of this or similar (especially hardware) repair information requirements. While we hope our own submission carries weight and is deemed relatively easy to implement given that it requires no new information to be provided by most manufacturers, it would help for others to provide their own experiences with lack of easily-accessible software repair information to the FTC so they are aware of the extent of the problem. The comment period is open until December 27 (likely to be extended until January 31, 2023) and you can see more details about the FTC's request for submissions and submit your own comment here.
For those that do read our submission, note that the FTC has trimmed some of its attachments from the website. You can find the attachments here instead:
You may notice that SFC has suggested the FTC require manufacturers to provide a URL to their source code distribution website, while not mentioning other ways of fulfilling an offer for source code, which we normally request that manufacturers provide (such as offering the source code on a durable physical medium, e.g. a USB stick or optical disc). Our main reason for this usual request that manufacturers provide source code on a durable physical medium is that not everyone in the world has a reliable or fast Internet connection. As a result, if a manufacturer only provides source code over the Internet, the most disadvantaged people are further disadvantaged by not being able to download the source code for their device (most source releases are hundreds of megabytes, if not more).
With our reply to the FTC, we were trying to make the best argument based on current practices and the least amount of additional work for manufacturers (to improve the chance of our suggestion being adopted, and reduce the chance that a company could make any credible argument against it), while also keeping in mind the jurisdiction this ruling applies to (USA) and its Internet connectivity standards. Though not complete yet, the National Broadband Plan in the USA does have this aim: "Every American should have affordable access to robust broadband service". Given the balance of people in the USA already connected to broadband, and the strong intent to connect the rest, we felt it was practical to make the recommendation include only web-accessible source code as the labeling requirement applies only in the USA. Note that we still request manufacturers make source code available on a durable physical medium, and would advise the FTC to make this part of their labeling requirements as well if they felt it feasible to include.
Although we have much work to do to ensure that people purchasing free and open source software (as part of appliances and other devices they may buy) know that they can repair, maintain, and modify this software, steps like this from the FTC will bring us closer. We are looking forward to the FTC's decision on our recommendation, and hope to help more people access the information they need to make their devices work for them, for as long as they choose to keep them. Together we can improve our own lives, but also the lives of others, and our planet.
Trademark Was Made to Prevent Attack of the “Clones” Problem in App Stores
by on July 11, 2022
Suppose you go to your weekly MyTown market. The market runs Saturday and Sunday, and vendors set up booths to sell locally made products and locally grown and produced food. On Saturday, you buy some delicious almond milk from a local vendor — called Al's Awesome Almond Milk. You realize that Al's Awesome would make an excellent frozen dessert, so you make your new frozen dessert, which you name Betty's Best Almond Frozen Dessert. You get a booth for Sunday for yourself, and you sell some, but not as much as you'd like.
The next week, you realize you might sell more if you call it Al's Awesome Almond Frozen Dessert instead of your own name. Folks at the market know Al, but not you. So you change the name. Is this a morally and legally acceptable thing to do?
This is a question primarily regarding trademarks. We spend a lot of time in the Free and Open Source Software (FOSS) community talking about copyrights and patents, but another common area of legal issues that face FOSS projects (in addition to copyright and patent) is trademark.
In fact, FOSS projects probably don't spend enough time thinking about their trademark. Nearly ten years ago, Pam Chestek — a lawyer and expert in trademark law as it relates to FOSS and board member of OSI — gave an excellent talk at FOSDEM (2013), wherein she explored how FOSS projects can use trademarks better and to ensure rights of consumers — particularly when dealing with bad actors. Our own Executive Director, Karen Sandler, had also spoken about this issue as well. These older talks, in turn, spawned an ongoing conversation that continues to this day in FOSS policy circles.
Specifically, last week, we learned that the Microsoft Store was changing their policies, ostensibly to deal with folks (probably some of whom are unscrupulous) rebuilding binaries for well-known FOSS projects and uploading them to the Microsoft Store. Yet, this is a longstanding issue in FOSS policy. FOSS experts in this area would have been happy to share what's been learned over the last ten years of studying this issue.
The problem Microsoft faces here is the same problem that the MyTown market folks face if you show up trying to sell Al's Awesome Almond Frozen Dessert. The store/market can set rules that you will no longer be able to sell if you are found to infringe the trademark of another seller. The market could simply require the trademark holder to take trademark action themselves, or it could offer some form of assistance, arbitration, or other-extra-legal resolution mechanism0.
There is often temptation in FOSS to give special status to maintainers, or the original developer, or the copyright holder, or some other entity that is considered “official”. In FOSS, though, the only mechanism of officialness is the trademark — the name of the upstream project (or the fork). The entire point of FOSS is that for the code itself, everyone should have equal rights to the original developers, to the maintainers, or to any other entity.
We have faced this with our member project, Inkscape. While the Inkscape Project Leadership Committee has chosen not to charge for the version of Inkscape that they upload on Microsoft Store, we did see this very problem for many years before these app stores even existed. Namely, it was common for third-parties to sell Windows binaries on CD's for Inkscape in an effort to make a quick buck. We did trademark enforcement in these cases — not forbidding these vendors from selling — but simply requiring the vendors to clearly say that the product was a modified version of Inkscape. Or, if it was unmodified redistribution of Inkscape's own binaries, we required the vendor to note that the Inkscape project's website was the official source for these binaries.
I have often written to complain about copyright and patent law. I have my complaints about trademark law (and I've seen trademark grossly abused, even), but trademark laws tenets are really reasonable and solid: to ensure consumers know the source and quality of the products they receive.
The problem of concern here is one well handled by trademark. It doesn't need excessive app store rules; we don't need FOSS licenses to be usurped or superseded by Draconian policy. And, this solution to this particular problem has been long-known by FOSS. Pam's talk in 2013 explained it quite well!
The MyTown Market doesn't need to create a policy that forbids you from buying Al's Awesome Almond Milk on Saturday and reselling a product based on it on Sunday. They just need to let Al know his rights under trademark, and maybe offer a lightweight provisional suspension of your booth if the trademark complaint seems primia facie valid. But, most importantly, before it announces new rules with a 30 day clock, MyTown's leadership really should discuss it with the citizens first to find a policy that takes into account concerns of the people. Even if they fail to do that, there are MyTown's elected officials whose actions are accountable to the people. App store companies are accountable only to their shareholders, not the authors of the apps. Companies could benefit by learning that the FOSS community prioritizes respecting authors, protecting consumers' and users' rights, and by understanding that the line between user and contributor should blur. The FOSS marketplace functions because the community works.
Footnotes
0 I hesitate to even suggest that an app store should create an extra-legal process regarding trademark enforcement beyond the typical governmental mechanisms — lest they decide they have to do it. A major problem with app stores is that they create rules for software distribution that are capricious, and arbitrary. We all do want FOSS available on Microsoft, Apple, and Google-based platforms — and as such are forced to negotiate (or, rather, try to negotiate) for FOSS-friendly terms. Ultimately, though, the story of major vendor-controlled app stores is always the story of “just barely” being able to put FOSS on them, because the goal of these entities is to profit themselves, not serve the community. We prefer app stores like F-Droid that are community-organized and are not run for-profit.
Microsoft To Ban Commercial Open Source from App Store
by on July 7, 2022
Microsoft Will Even Prohibit Charitable FOSS Fundraising Through the “Microsoft Store”
A few weeks ago, Microsoft quietly updated its Microsoft [app] Store Policies, adding new policies (which go into effect next week), that include this text:
all pricing … must … [n]ot attempt to profit from open-source or other software that is otherwise generally available for free [meaning, in price, not freedom].
Yesterday, a number of Microsoft Store users discovered this and started asking questions. Quickly, those of us (including our own organization) that provide Free and Open Source Software (FOSS) via the Microsoft Store started asking our own questions too. While Microsoft has acknowledged the ensuing community outrage, they have not clarified their policy. In the meantime, this clause reverses long-standing app store policies, and is already disrupting commerce on their platform (with its tight countdown clock to implementation). In particular, Microsoft now forbids FOSS redistributors from charging any money for nearly all FOSS (i.e., “profit”). Since all (legitimate) FOSS is already available (at least in source code form) somewhere “for free” (as in “free beer”), this term (when enacted) will apply to all FOSS.
For decades, Microsoft spent great effort to scare the commercial software sector with stories of how FOSS (and Linux in particular) were not commercially viable products. Microsoft even once claimed that anyone who developed FOSS under copyleft was against the American Way. Today, there are many developers who make their living creating,supporting, and redistributing FOSS, which they fund (in part) by charging for FOSS on app stores. We in the FOSS community have long disagreed with Microsoft: we have touted that FOSS provides true neutrality regarding commercial and non-commercial activity — both are permitted equally. In short, our community proved Microsoft wrong with regard to the commercial viability and sustainability of FOSS.
Sadly, these days, companies like Microsoft have set up these app stores as gatekeepers of the software industry. The primary way that commercial software distributors reach their customers (or non-profit software distributors reach their donors) is via app stores. Microsoft has closed its iron grasp on the distribution chain of software (again) — to squeeze FOSS from the marketplace. If successful, even app store users will come to believe that the only legitimate FOSS is non-commercial FOSS.
This is first and foremost an affront to all efforts to make a living writing open source software. This is not a merely hypothetical consideration. Already many developers support their FOSS development (legitimately so, at least under the FOSS licenses themselves) through app store deployments that Microsoft recently forbid in their Store. The well-known Krita painting software and the video editing software ShotCut are both sold on Microsoft's app store (and will both soon be in violation of Microsoft's terms). Indeed, our own Inkscape project has unilaterally chosen to only request, rather than require, donations from Microsoft Store users, but this new term forces that decision upon Inkscape permanently. These represent just a few examples of developers and/or redistributors left out in the cold under Microsoft's new terms.
Microsoft counter-argues that this is about curating content for customers and/or limiting FOSS selling to the (mythical) “One True Developer”. But, even a redrafted policy (that Giorgio Sardo (General Manager of Apps at Microsoft) hinted at publicly early today) will mandate only toxic business models for FOSS (such as demo-ware, less-featureful versions available as FOSS, while the full-featured proprietary version is available for a charge). Any truly FOSS system is always “generally available for free” — since the developers do the work in public, and encourage others to remix and rebuild the software into binaries for all sorts of platforms. These are essential rights and freedoms that FOSS licenses give users and businesspeople alike. FOSS was designed specifically to allow both the original developers and downstream redistributors to profit fairly from the act of convenient redistribution (such as on app stores). No company that supports FOSS and its commercial methodologies would propose to curtail these rights and freedoms. So we're left quite suspect of Microsoft's constant claims that they've changed their tune about FOSS. They still oppose it; they've just gotten more crafty about the methods of doing so.
Selling open source software has been a cornerstone of open source's sustainability since its inception. Precisely because you can sell it, open source projects like Linux (which Microsoft claims to love) have been estimated to be worth billions of dollars. Microsoft apparently does not want any FOSS developers to be able to write open source in a sustainable way.
Finally, this is a known pattern of Microsoft's behavior. Rolling out unreasonable and unconscionable policies — only to “magnanimously” retract them weeks or months later — is a strategy that they've used before. Indeed, Microsoft employed this exact tactic when originally creating their app store (then marked under the predecessor brand name, “Windows Marketplace”). Initially, Microsoft banned all copyleft licenses from its app store, and when the obvious outrage came, Microsoft cast themselves as benevolently willing to amend the policy and allow FOSS on the Microsoft Store. Of course, we again (as we did then) immediately call on Microsoft to reverse their new anti-FOSS Microsoft Store Policies and make it explicitly clear in these Policies that selling open source is not only allowed but encouraged.
Nevertheless, we're cognizant that Microsoft probably planned all this, anyway — including the community outrage followed by their usual political theater of feigned magnanimity. It seems this is just Microsoft's latest effort to curtail the forms of FOSS activity that don't directly benefit them. Microsoft may say that they love Open Source, but only so far as they exclusively are the ones who profit from FOSS on their platforms.
Update on 2022-07-08: After we and others pointed out this problem, a Microsoft employee claimed via Twitter that they would “delay enforcement” of their new anti-FOSS regulation. We do hope Microsoft will ultimately rectify the matter, and look forward to the change they intend to enact later. Twitter is a reasonable place to promote such a change once it's made, but an indication of non-enforcement by one executive on their personal account is a suboptimal approach. This is a precarious situation for FOSS projects who currently raise funds on the Microsoft Store; they deserve a definitive answer.
Given the tight timetable (just five days!) until the problematic policy actually does go into effect, we call on Microsoft to officially publish a corrected policy now that addresses this point and move the roll-out date at least two months into the future. (We suggest September 16, 2022.) This will allow FOSS projects to digest the new policy with a reasonable amount of time, and give Microsoft time to receive feedback from the impacted projects and FOSS experts.
Give Up GitHub: The Time Has Come!
by on June 30, 2022
Those who forget history often inadvertently repeat it. Some of us recall that twenty-one years ago, the most popular code hosting site, a fully Free and Open Source (FOSS) site called SourceForge, proprietarized all their code — never to make it FOSS again. Major FOSS projects slowly left SourceForge since it was now, itself, a proprietary system, and antithetical to FOSS. FOSS communities learned that it was a mistake to allow a for-profit, proprietary software company to become the dominant FOSS collaborative development site. SourceForge slowly collapsed after the DotCom crash, and today, SourceForge still refuses to solve these problems0. We learned a valuable lesson that was a bit too easy to forget — especially when corporate involvement manipulates FOSS communities to its own ends. We now must learn the SourceForge lesson again with Microsoft's GitHub.
GitHub has, in the last ten years, risen to dominate FOSS development. They did this by building a user interface and adding social interaction features to the existing Git technology. (For its part, Git was designed specifically to make software development distributed without a centralized site.) In the central irony, GitHub succeeded where SourceForge failed: they have convinced us to promote and even aid in the creation of a proprietary system that exploits FOSS. GitHub profits from those proprietary products (sometimes from customers who use it for problematic activities). Specifically, GitHub profits primarily from those who wish to use GitHub tools for in-house proprietary software development. Yet, GitHub comes out again and again seeming like a good actor — because they point to their largess in providing services to so many FOSS endeavors. But we've learned from the many gratis offerings in Big Tech: if you aren't the customer, you're the product. The FOSS development methodology is GitHub's product, which they've proprietarized and repackaged with our active (if often unwitting) help.
FOSS developers have been for too long the proverbial frog in slowly boiling water. GitHub's behavior has gotten progressively worse, and we've excused, ignored, or otherwise acquiesced to cognitive dissonance. We at Software Freedom Conservancy have ourselves been part of the problem; until recently, even we'd become too comfortable, complacent, and complicit with GitHub. Giving up GitHub will require work, sacrifice and may take a long time, even for us: we at Software Freedom Conservancy historically self-hosted our primary Git repositories, but we did use GitHub as a mirror. We urged our member projects and community members to avoid GitHub (and all proprietary software development services and infrastructure), but this was not enough. Today, we take a stronger stance. We are ending all our own uses of GitHub, and announcing a long-term plan to assist FOSS projects to migrate away from GitHub. While we will not mandate our existing member projects to move at this time, we will no longer accept new member projects that do not have a long-term plan to migrate away from GitHub. We will provide resources to support any of our member projects that choose to migrate, and help them however we can.
There are so many good reasons to give up on GitHub, and we list the major ones on our Give Up On GitHub site. We were already considering this action ourselves for some time, but last week's event showed that this action is overdue.
Specifically, we at Software Freedom Conservancy have been actively communicating with Microsoft and their GitHub subsidiary about our concerns with “Copilot” since they first launched it almost exactly a year ago. Our initial video chat call (in July 2021) with Microsoft and GitHub representatives resulted in several questions which they said they could not answer at that time, but would “answer soon”. After six months of no response, Bradley published his essay, If Software is My Copilot, Who Programmed My Software? — which raised these questions publicly. Still, GitHub did not answer our questions. Three weeks later, we launched a committee of experts to consider the moral implications of AI-assisted software, along with a parallel public discussion. We invited Microsoft and GitHub representives to the public discussion, and they ignored our invitation. Last week, after we reminded GitHub of (a) the pending questions that we'd waited a year for them to answer and (b) of their refusal to join public discussion on the topic, they responded a week later, saying they would not join any public nor private discussion on this matter because “a broader conversation [about the ethics of AI-assisted software] seemed unlikely to alter your [SFC's] stance, which is why we [GitHub] have not responded to your [SFC's] detailed questions”. In other words, GitHub's final position on Copilot is: if you disagree with GitHub about policy matters related to Copilot, then you don't deserve a reply from Microsoft or GitHub. They only will bother to reply if they think they can immediately change your policy position to theirs. But, Microsoft and GitHub will leave you hanging for a year before they'll tell you that!
Nevertheless, we were previously content to leave all this low on the priority list — after all, for its first year of existence, Copilot appeared to be more research prototype than product. Facts changed last week when GitHub announced Copilot as a commercial, for-profit product. Launching a for-profit product that disrespects the FOSS community in the way Copilot does simply makes the weight of GitHub's bad behavior too much to bear.
Our three primary questions for Microsoft/GitHub (i.e., the questions they had been promising answers to us for a year, and that they now formally refused to answer) regarding Copilot were:
-
What case law, if any, did you rely on in Microsoft & GitHub's public claim, stated by GitHub's (then) CEO, that: “(1) training ML systems on public data is fair use, (2) the output belongs to the operator, just like with a compiler”? In the interest of transparency and respect to the FOSS community, please also provide the community with your full legal analysis on why you believe that these statements are true.
We think that we can now take Microsoft and GitHub's refusal to answer as an answer of its own: they obviously stand by their former CEO's statement (the only one they've made on the subject), and simply refuse to justify their unsupported legal theory to the community with actual legal analysis.
-
If it is, as you claim, permissible to train the model (and allow users to generate code based on that model) on any code whatsoever and not be bound by any licensing terms, why did you choose to only train Copilot's model on FOSS? For example, why are your Microsoft Windows and Office codebases not in your training set?
Microsoft and GitHub's refusal to answer also hints at the real answer to this question, too: While GitHub gladly exploits FOSS inappropriately, they value their own “intellectual property” much more highly than FOSS, and are content to ignore and erode the rights of FOSS users but not their own.
-
Can you provide a list of licenses, including names of copyright holders and/or names of Git repositories, that were in the training set used for Copilot? If not, why are you withholding this information from the community?
We can only wildly speculate as to why they refuse to answer this question. However, good science practices would mean that they could answer that question in any event. (Good scientists take careful notes about the exact inputs to their experiments.) Since GitHub refuses to answer, our best guess is that they don't have the ability to carefully reproduce their resulting model, so they don't actually know the answer to whose copyrights they infringed and when and how.
As a result of GitHub's bad actions, today we call on all FOSS developers to leave GitHub. We acknowledge that answering that call requires sacrifice and great inconvenience, and will take much time to accomplish. Yet, refusing GitHub's services is the primary power developers have to send a strong message to GitHub and Microsoft about their bad behavior. GitHub's business model has always been “proprietary vendor lock-in”. That's the very behavior FOSS was founded to curtail, and it's why quitting incumbent proprietary software in favor of a FOSS solution is often difficult. But remember: GitHub needs FOSS projects to use their proprietary infrastructure more than we need their proprietary infrastructure. Alternatives exist, albeit with less familiar interfaces and on less popular websites — but we can also help improve those alternatives. And, if you join us, you will not be alone. We've launched a website, GiveUpGitHub.org, where we'll provide tips, ideas, methods, tools and support to those that wish to leave GitHub with us. Watch that site and our blog throughout 2022 (and beyond!) for more.
Most importantly, we are committed to offering alternatives to projects that don't yet have another place to go. We will be announcing more hosting instance options, and a guide for replacing GitHub services in the coming weeks. If you're ready to take on the challenge now and give up GitHub today, we note that CodeBerg, which is based on Gitea implements many (although not all) of GitHub. Thus, we're also going to work on even more solutions, continue to vet other FOSS options, and publish and/or curate guides on (for example) how to deploy a self-hosted instance of the GitLab Community Edition.
Meanwhile, the work of our committee continues to carefully study the general question of AI-assisted software development tools. One recent preliminary finding was that AI-assisted software development tools can be constructed in a way that by-default respects FOSS licenses. We will continue to support the committee as they explore that idea further, and, with their help, we are actively monitoring this novel area of research. While Microsoft's GitHub was the first mover in this area, by way of comparison, early reports suggest that Amazon's new CodeWhisperer system (also launched last week) seeks to provide proper attribution and licensing information for code suggestions1.
This harkens to long-standing problems with GitHub, and the central reason why we must together give up on GitHub. We've seen with Copilot, with GitHub's core hosting service, and in nearly every area of endeavor, GitHub's behavior is substantially worse than that of their peers. We don't believe Amazon, Atlassian, GitLab, or any other for-profit hoster are perfect actors. However, a relative comparison of GitHub's behavior to those of its peers shows that GitHub's behavior is much worse. GitHub also has a record of ignoring, dismissing and/or belittling community complaints on so many issues, that we must urge all FOSS developers to leave GitHub as soon as they can. Please, join us in our efforts to return to a world where FOSS is developed using FOSS.
We expect this particular blog post will generate a lot of discussion. We welcome you to interact with SFC staff on our public mailing list about this effort.
Footnotes
0SourceForge is now built as a (apparently proprietary) fork of a different FOSS system (called Allura). SourceForge's CEO ignored our multiple inquiries asking if SourceForge really is running upstream Allura (i.e., has no proprietary modifications), and our repeated requests for a link that explains how a project can leave SourceForge for self-hosted Allura. The responses from SourceForge management were quite similar to those received since 2001 — when they first went proprietary.
1However, we have not analyzed CodeWhisperer in depth so we cannot say for sure if Amazon's implementation is compliant with the respective licenses. Nevertheless, Amazon's behavior here shows sharp contrast with Microsoft's GitHub: Amazon acknowledges the obvious fact that there are license obligations that deserve attention and care when building AI-assisted programming solutions.
