Microsoft caused considerable consternation in the open source community over the past month, after unveiling a shake up to the way developers will be able to monetize open source software.
There are many examples of open source software sold in Microsoft’s app store as full-featured commercial applications, ranging from video editing software such as Shotcut, to FTP clients such as WinSCP. But given how easy it is for anyone to reappropriate and repackage open source software as a new standalone product, it appears that Microsoft is trying to put measures in place to prevent such “copycat” imitations from capitalizing on the hard work of the open source community.
However, at the crux of the issue was the specific wording of Microsoft’s new policy, with section 10.8.7 noting that developers must not:
….attempt to profit from open-source or other software that is otherwise generally available for free, nor be priced irrationally high relative to the features and functionality provided by your product.
In its current form, the language is seemingly preventing anyone — including the project owners and maintainers — from charging for their work. Moreover, some have argued that it could hold implications for proprietary applications that include open source components with certain licenses, while others have noted that developers may be deterred from making their software available under an open source license.
The policy was due to take effect on July 16 (tomorrow), but influential figures from the open source fraternity have been making their voices heard over the past few weeks, including Hayden Barnes, a senior engineering manager at open source software giant Suse. Barnes noted on Twitter that he was “disappointed” with the proposed policy change as it could prevent already underfunded open source developers from creating more sustainable projects.
In response, Microsoft executive Giorgio Sardo took to Twitter last week to confirm that the announcement had “been perceived differently than intended,” and it would delay enforcement of the new policy and clarify the wording.
As such, Microsoft gave its new policy a stay of execution, with this addendum bolted on to inform developers that nothing will change for now:
The policy change, announced on June 16, 2022, to 10.8.7 (Not attempt to profit from open-source or other software that is otherwise generally available for free, nor be priced irrationally high relative to the features and functionality provided by your product.) will not be going into effect on July 16, 2022. We have determined it could be perceived differently than intended, so we are revising this policy change to provide greater clarity.
With things currently in limbo, it’s worth taking a sideways look at the proposed new policy, including what ramifications it could have on the people behind the open source software, and whether Microsoft should serve as an open source gatekeeper at all.
Monetizing open source
For most people, the main issue with Microsoft’s policy change was the language it used. It’s reasonable to assume that the intent was probably to protect open source project maintainers and IP-owners, but the wording essentially threw all open source projects under the bus. So we can likely expect (though this is not certain) a revised policy in the future that permits the main “official” version of an open source app to continue monetizing, while others won’t be able to charge.
Halla Rempt, the core maintainer behind the popular open source digital paint program Krita, doesn’t seem overly concerned with these impending changes for exactly that reason.
“I’m still not 100% of the implications of the change — it seems to me that they’re actually happy with projects putting their own software in the store, but whether they’re still okay with us charging for it, I don’t know,” Rempt told TechCrunch. “For now, we’re continuing as is.”
Rempt also said that the income they get from Microsoft’s app store pays for around half of the app’s sponsored developers, meaning that a redrafted Microsoft app store policy that includes provisions that support project maintainers and IP-owners’ ability to monetize apps, would be a good thing.
While there hasn’t been any known third-party Krita apps on Microsoft’s app store so far, other open source software maintainers are having to contend with this problem.
Robin Krom is one of the chief developers behind Greenshot, an open source screenshotting app with millions of downloads. While Greenshot is available for Windows as a direct download, it’s not yet available via Microsoft’s official app store. However, there are at least two so-called “copycat” apps in Microsoft’s app store that use the Greenshot name — and one of those apps charges $3.69 to download.
From Krom’s perspective, there are problems with this, aside from the obvious fact that someone is cashing in on their hard work. In the future, Krom may decide to launch an official version of Greenshot in Microsoft’s store, but even before all that, brand confusion could still create more work for those behind the official Greenshot project.
“The [third-party] app uses our brand, [so] if there are issues with the app, the customers will come to us,” Krom told TechCrunch.
Such a scenario has yet to come to fruition, given that the third-party app in question is still relatively new to Microsoft’s store. But there are examples of similar issues emerging elsewhere in the open source world. For example, Elastic’s long-standing spat with Amazon over the (formerly) open source Elasticsearch project was partly about how Amazon was using the Elasticsearch brand name in its own hosted version of the product — Amazon’s cloud customers would often address Elastic with issues relating to the product, even though it had little to do with Elastic.
Trademark infringement is what we’re talking about here, and although Amazon and Elastic eventually resolved their dispute, it took a long-drawn out legal process to get there. This is something that smaller, independent open source project maintainers don’t have the resources to pursue, assuming they own the trademark rights in the first place, which many don’t — including Krom.
This is why Microsoft’s impending policy change — depending on its revised wording, of course — will be greeted warmly by many in the open source community.
“It feels morally wrong to take a free product from someone and sell it for a price, and have the original ‘vendor’ solve all the issues,” Krom continued. “[And] if due to his [third-party developer] work something doesn’t work, it is our reputation that is damaged.”
It’s worth stressing that Microsoft’s planned policy change, according to its current wording, will only impact apps that are actively trying to monetize. So free copycat apps will still be permitted. But if nothing else, banning commercial copycats will serve as a major deterrent to anyone considering doing so.
However, other prominent voices in the open source community are less concerned with the specific wording of Microsoft’s policy, than they are about the fact that Microsoft is trying to implement any form of controls at all.
FOSS for the win
Bradley M. Kuhn is a free and open source software (FOSS) activist, who serves as “hacker-in-residence” at Software Freedom Conservancy, a not-for-profit organization that provides support and legal services for open source software projects. In the aftermath of Microsoft’s policy change, Kuhn and his colleague Denver Gingerich penned an in-depth blog post outlining their issues with the new policy (as well as more long-standing gripes with Microsoft’s attitude to open source), and the main thrust of their argument was that the very nature of open source software is that it’s free of restrictions, with no favoritism over who can and can’t monetize it.
“We believe that the rights ensured by FOSS, as is well-enshrined in the licenses themselves, allow everyone to monetize FOSS,” Kuhn told TechCrunch. “FOSS licenses have always treated all commercial and non-commercial actively equally. It’s free as in freedom, but also it’s free as in market.”
While there are many different kinds of open source licenses available (whether they are all truly “open source” is a debate for another day), Kuhn is referring specifically to so-called “copyleft” licenses. Such licenses have few restrictions, but they do mandate that any software derived from an original open source must be released under a similar open source license. This runs in contrast to more “permissive” licenses that don’t impose such restrictions (meaning that private companies can easily adopt an open source project as part of a proprietary product).
Put simply, the spirit of open source is all about the freedoms it permits.
“Copyleft licenses require that you provide correct, complete, and corresponding source code to all customers, and have various rules about patents, but there are otherwise generally not intended to be serious restrictions on the ability monetize FOSS,” Kuhn said.
A recurring discussion point around Microsoft’s proposed policy change is the issue of “trademark” or “brand confusion,” but Kuhn argues that this is a totally separate issue to that of monetization, it’s already well-provisioned for in existing laws, and it’s not specifically a FOSS problem.
“Trademark rules control the rights to name and market a product under a particular name,” Kuhn said. “Trademark restrictions on using a name are completely compatible with FOSS and have long been encouraged. Now, this is not a FOSS-specific problem, but cloned software by fly-by-night entities and malware on app stores is a broader problem.”
While all of this is probably true, independent open source developers generally don’t have the resources to pursue what are often faceless entities over trademark violations (assuming that they actually own the trademark at all). And that is precisely why a policy that deters “fly-by-night” developers from capitalizing on the hard work of others, will likely be well received whenever it’s finally introduced.
Other issues
There are other issues at play though. As Kuhn and Gingerich pointed out, any policy that allows IP-owners to sell open source applications could be a green light to more “toxic business models,” whereby developers are encouraged to make basic versions of their software available for free, and hide all the good stuff behind a paywall. This is often referred to as an open-core model, something that many people argue undermines the broader open source movement.
And it would be somewhat remiss not to mention Microsoft’s thorny past with open source. To cut a War and Peace-esque story impossibly short, Microsoft once deemed open source software to be an evil entity, but in the intervening years — particularly since Satya Nadella became CEO in 2014 — Microsoft has worked hard to align itself with the open source world.
But there are many that remain unconvinced about Microsoft’s open source ethos. With its GitHub subsidiary monetizing the hard work of the open source community with Copilot, a proprietary AI-powered pair-programmer trained on open source project data, Copilot critics argue that the product doesn’t make it clear which codebases it “borrows” from, which is a problem given that transparency and correct attribution are cornerstones of open source.
Now that Microsoft is seemingly trying to prevent other developers from monetizing open source software in a similar fashion, this opens the door to accusations of double standards. If Microsoft can monetize open source projects, why can’t others?
“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),” Kuhn and Gingerich wrote last week. “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.”
TechCrunch reached out to Microsoft for comment several times prior to publication, but did not receive a response.