Which FSF- or OSI-approved licenses limit corporate usage in spirit, but not in letter?

Question

A common desire in the Free and Open-Source Software world is to release some code in a way that approximates two ideals:

1. The software is in the public domain and its techniques are common knowledge
2. The software is unusable for corporate purposes

When the shape of the software cannot itself ensure the second property, perhaps because the software is attractive for a variety of commercial applications, then the license is often used instead in order to prevent software misuse. (Indeed, I have found dozens of queries here along these lines.) However, there are two well-known obstacles to a licensing solution; there's the first property I've listed, and there's also the fact that corporations may decide to ignore the terms of a license.

I don't think that anything can be effectively done about this second obstacle; corporate coders will not stop copying code from Stack Exchange anytime soon. However, about the first obstacle, I have heard many tales; which FSF- or OSI-approved licenses technically allow corporate usage but are toxic and forbidden in practice?

Answer 1

Frame challenge: neither the FSF nor OSI have point 2 as a goal. To quote the FSF:

“Free software” does not mean “noncommercial”. A free program must be available for commercial use, commercial development, and commercial distribution. Commercial development of free software is no longer unusual; such free commercial software is very important. You may have paid money to get copies of free software, or you may have obtained copies at no charge. But regardless of how you got your copies, you always have the freedom to copy and change the software, even to sell copies.

The freedom to use software for whatever you like, including corporate uses, is important to the FSF, and the OSI has historically been even more corporate friendly.

The GPL and AGPL sometimes seen as being corporate-unfriendly, since it is difficult for organisations to re-use GPL or AGPL components in software they wish to exercise monopoly rights on. But it's worth noting that some companies choose to licence their products under these licences for precisely this reason (MySQL being one example of this), since it allows them to limit competitors ability to exercise monopoly rights on products containing their components.

One seemingly corporate friendly "licence", that has consequences for businesses, is public domain (which isn't technically a licence, and isn't OSI approved, although the FSF do regard it as free software). SQLite is dedicated to the public domain, but it's also possible to buy a licence from one of the companies that does much of the development work on it. The reason companies feel compelled to do this is that whilst copyright law has been largely standardised internationally, public domain has not, so companies that need to operate internationally prefer to buy a licence, which saves them having to consider the legal implications of releasing a product containing SQLite in all the countries they operate in.

Answer 2

While the question is valid, the broadest ideal of open-source is to make all software open-sourced, including that which is used for profit.

Broadly, some strong-copyleft OSS licenses have a "viral" property, requiring prohibiting anything not under the same license from linking to that component, others are permissive or non-viral. The GPL and AGPL represent extreme virality, the LGPL is mostly non-viral, the MIT is strongly permissive, and public domain is absolutely permissive.

In my experience, the most common use of viral licenses is to dual-license the product. That is, companies will release the product under GPL for free, and also offer a paid commercial license. In some cases, the commercial version even requires per-user licensing. In effect, the GPL version serves as a free trial, protected from production use by its license, rather than some DRM scheme.

I currently architect software that is commercial in function, but, due to its critical nature, we maintain a strict open-source-only policy for all components not created in-house. Not a byte can go in unless we and others can inspect the line it's been compiled from. Having started my coding in the OSS community, I do my best to have this go both ways.

At the same time, the nature of our primary software renders the legal cost of assessing the risks in releasing its code prohibitive. We contribute to libraries and packages that we use, but can't open-source the complete product. In a perfect world we could and would - but there are products that are by their nature only useful to a closed list, like owners of specific hardware (such as aircraft), or entities with a special legal status. In such cases, "herd security" cannot be relied upon to weed out the vulnerabilities, because no external party is interested in reviewing or improving such narrowly-specific code.

This means that industries like ours can use MIT, Apache or LGPL components, but not GPL or AGPL. In all of the cases where we were interested in viral-licensed components, and where the creators were reachable to discuss licensing, they offered a paid license. Some of the times it was worth it, other times we updated non-viral OSS to our standards instead.

So, licenses that restrict corporate usage most often do so in order to sell it, not to prevent it. For that purpose, prohibition in spirit is meaningless if it's not done in letter.

The purpose of promoting open-source software is not always best served by choosing the most extreme copyleft license. The application needs to be considered. Some software exists in millions of copies, other can never possibly have more than one running instance. The most extreme licenses restrict their use cases to only one facet of the software world, while permissive or compromise licenses trade some risk of proprietization for enhanced applicability.

Answer 3

To answer my own question, here is a small sampling of possibilities.

First, there are licenses that are approved by both standards bodies, the FSF and the OSI, but which are often not acceptable in corporate codebases. A gold star goes to Affero GPLv3 (or later), which is banned at Google and almost certainly banned at any place which bans GPLv3.

Speaking of which, GPLv3 is a fine license for this purpose as well; it caused Apple to write their own C++ standard library and stop contributing to GCC. Similarly, GPLv2 is not allowed on Apple's phone app store. The GPL is also why Google wrote their Bionic C standard library; "we want to keep GPL out of user-space".

But let's go beyond the FSF's offerings. Google publishes a handy list of banned licenses. The Common Public Attribution License, CPAL, is on this list. So are versions 1.1 and 1.2 of the European Union Public License, EUPL. These licenses behave like AGPLv3 in various ways, and this "Affero" behavior is what landed them on Google's ban list. Nonetheless, CPAL and EUPL still designate open-source software, and are FSF- and OSI-approved.

Finally, what if we only care about one standards body, but not the other? The FSF considers some public-domain attributions, like Creative Commons Zero, the Do What the Fuck You Want To Public License, WTFPL, as well as the Unlicense, to be reasonable licenses for Free Software, but folks may not see software licensed with them as Open Source, since they are not OSI-approved. Google employees are not, by policy, allowed to contribute to projects using these public-domain-like licenses.

Answer 4

Don't forget that in the world of contracts and the law, the "spirit" is essentially irrelevant. The "letter" of the contract is everything. When the letter and the spirit of a contract/license differ, that's where courts come into the picture. Courts make decisions and interpretations based on the letter of the law since the parties to the contract aren't mind-readers and can't reasonably know anything that's not explicitly included in the text or in established law.

The license you want will largely depend on what exactly you mean by "unusable for corporate purposes". There are a couple of ways to interpret that:

• I don't want a corporation to use my software for any purpose
• I don't want anyone selling verbatim copies of my software
• I don't want people charging money for software that incorporates my code
• I don't want anyone to use my code in projects that are not themselves open source
• I don't want anyone to modify my software without publishing their changes to it

A strict reading of the question sounds like you're talking about the first option, but that's not really something that you can limit with a license. A corporation is simply a legal construct that allows a group of people to act as a collective body. This obviously includes businesses, but can also include things like universities, museums, charity organizations, and even the FSF itself. It also doesn't cover a self-employed consultant acting as an individual person, even when they're doing the sorts of things normally done by a "corporation". The legal definition of a corporation varies from locale to locale, so this would be a very impractical limitation for a license and I'm not sure it would accomplish much. For those reasons, I'm going to assume this isn't what you meant. This sort of restriction is also a probable violation of the FSF's "Freedom 0", which would make it non-free (James_pic gives more detail in his answer).

Regarding the second and third interpretations: I don't think that you can incorporate these restrictions and still have "free software". These specific reasons are given as why the FSF does not consider the Aladdin Free Public License (among others) to be free software.

For the fourth interpretation, you're looking for a strong copyleft license like the GPL. Weak copyleft (like the LGPL) is not sufficient to guarantee this.

For the fifth interpretation, you can achieve this through a number of different licenses (including the GPL). Be aware, though, that most of the time, the modified source code only has to be provided to those who receive a copy of the program. Modifications don't have to be submitted back to the original author (and in many cases, it might not even be possible to do so).

In all of these cases, though, you're not prohibiting "corporate usage" across the board. A strict, viral copyleft like the GPL will probably chase off the largest number of potential users, but corporations can still use the code if they're willing to abide by the restrictions. For example, Red Hat writes a lot of GPL code as part of their enterprise Linux distributions, and hardware vendors often publish fully GPLed Linux drivers for their devices. Many of the GPL's "viral" aspects only take effect when the software is distributed, so a corporation can modify it for internal use and keep those modifications secret (example: modifying gcc to support a custom FPGA core used in the company's products). No matter how "distasteful" you try to make the license conditions, there will always be situations where a corporation finds your license acceptable. The only way to ensure that no corporation ever uses your code is to use a restrictive, closed license, but at that point you're not free at all.