Is there a generally accepted "anti-copyleft" clause or license?

Question

I would like to publish code for an application under an open source license like BSD, MIT, or Apache 2 which allows for changes and derivative works to be contributed back to the open source project or kept fully proprietary if the developer wishes, but where the code or derivative works can never be re-licensed under a GPL/Copyleft license. My concern is some group taking my code, relicensing it as GPL/copyleft, and then amassing enough momentum behind their GPL fork to dilute the momentum of the proprietary-able, commercial-friendly open source version.

In other words, users/companies may:

• Distribute binaries without the source code (proprietary product)
• Distribute source code with or without their additions
• Submit changes back to the project

But may NOT:

• Take code from the project and re-license it as GPL or any other form of license which COMPELS a user or company to distribute the source of their derivative works, making it untenable for use in corporate environments.

Is there a license or generally accepted clause that could be added to the BSD or Apache 2 license to accomplish this intent?

Answer 1

the code or derivative works can never be re-licensed under a GPL/Copyleft license

Ironically, I think the best practical strategy to accomplish this is to license your work under a (very weak) copyleft license that is incompatible with other existing copyleft licenses. Your proposed terms are not "permissive" as the term is used in FLOSS parlance: much like the mechanics of the GPL, you want your license to say, "Everyone may use this however they like, except for this set of restrictions that may never be removed." Your set of restrictions happens to forbid "licensing under conditions that compel downstream source disclosure" instead of the GPL's restrictions that require source disclosure. In other words, whereas the GPL's opponent in employing copyleft is non-free licensing terms, your opponent in employing copyleft will be copyleft terms (except for your own copyleft terms).

The like-minded folks in Redmond are prepared to aid you: the Microsoft Public License (Ms-PL) is a reasonable choice to accomplish this goal. The MS-PL imposes copyleft terms on source distributions only, while binary distributions carry only the minimal requirement that they be licensed under "a license that complies with this license". Since the Ms-PL does not impose any particular requirements for binary distributions beyond attribution, this compatibility is quite easy to satisfy. (It is my guess that Microsoft deliberately engineered this license to be as permissive as possible while remaining incompatible with the GPL.)

On a strategic note, I advise you to consider this decision carefully, for the practical reason that GPL compatibility is a valuable asset in a license. Without it, downstream authors will be unable to make use of GPL'd code and your own code in software they distribute: you force them to choose between GPL options and your own offering. Using a simple permissive license allow anyone to use your code in proprietary projects just as you would like, though it will also allow for a future when some downstream modifications of your project (authored by some other person) might not be available to authors of proprietary software. Weigh your dissatisfaction of such a possible future against a possibly loss of interest in your project for its GPL incompatibility.

Answer 2

To my knowledge there is no such license. Note that this license may not be considered an open-source license. In no case would such a license be a permissive license that could be compatible with MIT or Apache 2 projects. Any wording to exclude copyleft licenses would probably also exclude any other open source licenses, so that your software would only be usable either in projects using the same license or in closed-source projects. That seems undesirable.

In general, permissive open source licenses and copyleft open source licenses both try to maximize freedom. They generally have the same intention, but take different avenues. It is important to recognize that both approaches have merit, even if you prefer one of them:

• Permissive open source licenses try to maximize freedom for immediate users of that code, i.e. developers. E.g. code under the MIT can be used freely in open source and closed source projects. This freedom comes at the expense of user's freedom, who may not be able to view and modify the code if they received the software as closed-source.

• Copyleft open source licenses try to maximize end user freedom, so that everyone who receives a copy of the software can read and modify the source. This is only possible by restricting how that code may be used, i.e. only in a manner that does not strip end users of their freedom.

  The motivation for copyleft is not a sense of fairness that modifications should be contributed back to the community, but a sense of end-user freedom.

There are licenses that try to find a balance, for example the LGPL: this restricts the copyleft properties only to the LGPLed component, but does not affect the whole software system in which such a component is used.

If you were to create a license that would exclude copyleft licenses, this fails to be a permissive license because it does restrict how the code can be used. You are much closer to copyleft ideas: in order to protect the freedom to freely decide whether modifications can be published as closed-source or under the same license, you sacrifice compatibility with other open-source software.

Answer 3

If you release your code under a permissive license, it is not possible for anyone to "relicense" it under a less permissive one like the GPL. By issuing a permissive license, you grant everyone the right to use your code in any way you choose. If someone, say, adds your code to a larger GPL'd product, that does not in any way affect your original license: everyone can still use your code in any way your license permits, even if they happen to find it as part of something with a more restrictive license like the GPL. You have granted them the right to use your code--but you have not granted them the right to control anyone else's use of it. That right remains with you. If your code is included in a GPL'd product, that product's license cannot add restrictions on the use of your code, only on the larger product as a whole. Even if its license claims to apply to your portion of the larger product, such words are legal hot air. You, and you alone, control who uses your work.

Most of the popular licenses allow mixing and matching of software products that work together without affecting each other's individual licenses. Android, for example, is Apache licensed, but requires the Linux kernel (GPL) and SQLite (public domain) to operate.

Answer 4

Just to add my 5¢, I agree with the great answers above that suggest an Open Source license such as BSD might be what you want.

However, if you want to be as far as possible from copyleft (which might be a wrong choice), then there is a "license" that suits your goal well. The strongest "anti-copyleft" is called all rights reserved: a proprietary, traditional copyright.

No one can stop you from redistributing your proprietary source code publicly, if you wish to. You can still redistribute binaries and charge money. You can even sub-license the sources to some commercial companies under even more convoluted terms.

But, your software wouldn't be Open Source. No Open Source distribution would include you code, neither source, nor binary. Are you okay with that?

You might get into mixed distros, like nVidia drivers years ago were. There was a binary blob with no source code, and people used it anyway, because everybody loved to use their accelerated OpenGL. But to pull this off your program needs to solve a very special problem, extremely well.

Mostly, such behaviour provokes a rewrite from scratch under GPL. Think about the GNU userland, for example.

Answer 5

The BSD license basically already does what you're asking for, or at least effectively.

GPL-ed programs sometimes use BSD modules. When they do that, they obey the BSD license which says that the license is to be preserved in source code redistributions. Users of the GPL-ed program are free to take a BSD source code module from there and use it under the BSD terms.

A BSD-licensed module doesn't become GPL-ed when it is used in a GPL-ed program. That is a misunderstanding. Each piece of the program retains its respective license. What is legally required is that all the licenses in the combination must be compatible. A piece of BSD-licensed code can be combined with GPL-ed code because it is compatible with the GPL.

An article on license compatibility on the GNU website, written by Richard Stallman explains it thus:

In a combination of programs under lax licenses, each part carries the license it came with. When the code is merged to the point that the parts can't be distinguished any more, that merged code should carry all the licenses of the merged parts. Since all the licenses are lax anyway, this causes no practical problem except that the list of licenses gets long.

People who take BSD code and then alter the license with additional GPL-like restrictions are acting in bad faith and should be called out.

The BSD license doesn't exactly say that it must be preserved verbatim, but rather:

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Still, the strict, cautious interpretation of this is: hands off; do not add additional restrictions.

We could contemplate making a small modification to the BSD license which clarifies that no new restrictions may be added to the reproduced copyright notice, conditions and disclaimer. Even if that is found to make no effective difference, it would raise enough uncertainty that it's not worth it compared to using the standard license that large numbers of people and organizations understand.

Answer 6

The OpenSSL license is also a major headache in terms of GPL incompatibility, to the extent that there are LGPL replacements to remove the legal uncertainty.

The code is still used though, as there is a common interpretation that the incompatibility was not intended and the copyright holders are unlikely to enforce this license.

If you create a deliberate incompatibility and communicate that this is intended, expect nobody to even look at your code. The OpenSSL license situation has already eaten up several man-millenia of volunteer work.

It is absolutely certain that no Linux distribution would include it, as a legal requirement for inclusion is license compatibility with all other packages. You would get a friendly request to fix your license, and if you refuse as this would violate your intention, your package would become blacklisted.

Also, keep in mind that the C library on many distributions is LGPL licensed. Unless your license permits linking (= creating a derivative work) under these license terms, it also becomes illegal for you to provide binaries on your own web page.

In short, it's a bad idea that has absolutely no useful purpose.

Answer 7

The answer to the question is No, there is no generally accepted open source license that is used by people who are specifically antithetical to copyleft. A person could make a custom license like that, but you should ask yourself why you are doing it.

The original question mentioned a valid concern that an open source project might be relicensed under a different copyright and then compete with the original. But, that's an argument for copyleft, not against it.

I was there in the 1990s when people realized that Microsoft had taken BSD code and relicensed it in their proprietary (closed source) products. In particular, Microsoft lifted the TCP/IP stack from BSD so they could compete with this "Internet" thing that UNIX had. Some BSD-license proponents claimed Microsoft's action was a "win" because their work would be used widely. I saw it as a loss and many developers (including me) switched to using the GNU General Public License (GPL). The GPL defends developers by preventing companies from taking without giving back.

If you want to make an open source project, but you're worried about someone stealing your project's momentum by making something that competes with you, then copyleft isn't the problem, it's the solution.

Answer 8

Not sure why nobody has mentioned it, but there is an excellent Mozilla Public License 2.0, that accomplishes exactly what you want.

If your code is licensed under MPL, then it can be freely used either by itself or as part of another project. The only restriction that MPL places is that your files (and your files only) have to still be available under the MPL terms. As this blog post puts it:

If your code is licensed under MPL 2.0 however, everybody retains the freedom to use your code as they please, but any enhancements to your open-source code have to be shared back. Sounds much fairer to me, and hopefully to you too.

A GPL project would also be able to use your code. However, they will be forced to dual-license your files under MPL and GPL. The GNU website explains this:

When you receive work under MPL 2.0, you may make a “Larger Work” that combines that work with work under those GNU licenses. When you do, section 3.3 gives you permission to distribute the MPL-covered work under the terms of the same GNU licenses, with one condition: you must make sure that the files that were originally under the MPL are still available under the MPL's terms as well.

Answer 9

I would like to publish code for an application under an open source license like BSD, MIT, or Apache 2 ... but where the code or derivative works can never be re-licensed under a GPL/Copyleft license.

Any additional restriction you place on the licensee usually renders the license a "non-free" license. This is an example of that happening. If you put such a restriction into a license, it would become a non-free (ie, proprietary) license.

How does that work? Because it would be impossible for anybody redistributing your code to do so under any open source license, whether permissive (BSD, MIT) or copyleft (GPL etc). They would only be able to re-license it under your proprietary license or a compatible proprietary license. The point of free software is binary: that there are no restrictions (except so called "reasonable" restrictions, like the requirement to preserve copyright notices), and that it can be re-licensed under widely-used open source licenses.

Thus, you may as well just license it under a completely proprietary license where they cannot redistribute at all. Claiming that your code is "free software" or "open source" would really just be dishonest.

That said, there is really no reason for you to do so. You can simply just license the code under a permissive license like BSD or MIT, and achieve all of your goals.

Licensees can:

• Distribute binaries without the source code (proprietary product) ✔️
• Distribute source code with or without their additions ✔️
• Submit changes back to the project ✔️

And assuming that they are using the code in a proprietary product, licenses cannot:

• Take code from the project and re-license it as GPL or any other form of license which COMPELS a user or company to distribute the source of their derivative works, making it untenable for use in corporate environments. ❌

That is, simply by including your code in a proprietary product means that they already are prevented from re-licensing it as GPL. Licensees could only re-license your code as GPL if they included it in a fully GPL licensed project, which would also mean that none of the rest of their code would be proprietary-friendly either. A company wishing to create a proprietary product is still welcome to use it under a permissive license by obtaining it directly from you.

Answer 10

Writing a new license can cause more problems rather than helping you, unless you invest in lawyers. It's better that you choose an already existing license. There's a list of GPL-incompatible licenses here.

However, a substantial number of such licenses were "fixed" in newer versions, so you must either explicitly specify the license version number that is GPL-incompatible, or choose one that never turned compatible nor seems to have the will for doing so.

Let me add that I understand (and agree with) your position, although I think your wording wasn't the best: you should have avoided talking about "momentum", as it can be interpreted as that you don't want to be less popular than a GPLed fork of your work. The problem here is not being popular, but that somebody modifies your code, by fixing bugs and adding more features, but they license their changes under the GPL, so the original author of the code cannot benefit from such contributions unless he "surrenders" to the GPL and releases the original code under the GPL.

However, I believe that a permissive license should allow a non-copylefted code to be included in a copylefted project. The only requirement I would add is: "if you do any modifications to my source code files, your modifications/additions/contributions must be done under the original license: only if you simply include my code into yours, you are allowed to use a copyleft license for your project while keeping my license intact" (note that I used quotes here not for saying I would add a clause like that in an existing license, but that what would be my will with my software)

Answer 11

To my considerable surprise, I recently discovered that somebody has created a so-called "BSD Protection License" which appears to be designed to specifically solve this problem.

The text of the license may be found here or here. It is quite lengthy, so I won't quote it in full, but I will summarize it as follows:

• It allows verbatim redistribution of the software "as you receive it" in much the same way as the GPL, the MIT license, and most other open source licenses. This clause does not specifically mention the disposition of any source code, so presumably if you receive binaries without source, you can redistribute them as such. You're required to include a copy of the license and a copyright notice. This is all fairly typical.
• It allows redistribution of modified software, under a license which "expressly prohibit[s] the distribution of further derivative works." This is highly unusual for an open source license, but by itself it does not make the license non-free, as long as the license provides an alternative option.
• It also allows redistribution of modified software under the same license (i.e. copyleft). The modifications must be clearly indicated, which the GPL also requires, and copyleft extends to "any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof" - no exception for "mere aggregation."

Opinions vary on whether this is a free license. The Fedora wiki page, linked above, tersely describes it as "Free, but GPL-incompatible," but Debian thinks it's non-free, because the scope of its copyleft is even broader than that of the GPL. They also didn't like the wording of the "implied acceptance" section and suggested reusing the GPL's wording instead. Both of those problems are arguably fixable.

As for how effective it would be... that's unclear to me. If you keep the arguably non-free expansive copyleft, then it's certainly never going to be incorporated into a GPL project in any way, but this copyleft will extend to and prohibit all sorts of perfectly reasonable conduct, which could be problematic. For example, if somebody packages together your software with a bunch of other, unrelated software (e.g. in a Docker container or Linux distro), the license would arguably infect the entire package, which is probably not what you want and might create gratuitous license conflicts. If the copyleft were weakened, then it might strike a more appropriate balance here.

Overall, however, I'm not really impressed by this license. The sole beneficiaries of the "take proprietary" option are, presumably, developers who want to get into the business of selling the software. But since the "take proprietary" option is extended to the world at large, those developers would just end up competing with each other. If they would have used the GPL with a CLA, they could've gone proprietary without any competition (other than the inevitable non-relicensed fork, of course). If you want to take parts of the software proprietary and release other parts under copyleft, you can do that with a CLA too. And, of course, it's much harder to get people to contribute to your open source project when your license is screaming at the top of its lungs that you intend to take their contributions and go proprietary. So the license does not appear to provide substantive advantages over the CLA model, from the self-interested (greedy) perspective of the person choosing a license for their software.