Is it permitted to develop for money on a commons clause project?

Question

An existing project which is licensed under Apache-2-with-Commons-Clause-1.0 should be advanced. A client wishes to pay me to write code in order that the code could be contributed to this project. Is payment for such work permitted?

Answer 1

Nothing in the Commons Clause talks about the development work itself, for which you would be paid. It only talks about the distribution of the software package under this license. So yes, payment for your contribution efforts is OK.

It needs to be mentioned that any license with the Commons Clause is not Open Source. It is not compliant with the definition of OSI and others. This category of licenses is called 'Source Available' (and strictly speaking it is out of scope of this site).

Answer 2

The Commons Clause 1.0, among other things, forbids you to offer paid services in relation to the software. That would include offers to extend the software with new functionality.

So, being hired (and receiving compensation in any form) to make changes to the software would be a violation of the Commons Clause 1.0.

There is a bit of a grey area when you are an employee of the company and you are asked to make changes to that software as part of your job. I can see wiggle room in the text of the Commons Clause that that might be allowed, but I am not sure if the authors of the software or a judge will look at it the same way.

Answer 3

Yes.

From the Commons Clause FAQ (emphasis mine):

Commons Clause only forbids you from “selling” the Commons Clause software itself. You may develop on top of Commons Clause licensed software (adding applications, tools, utilities or plug-ins) and you may embed and redistribute Commons Clause software in a larger product, and you may distribute and even “sell” (which includes offering as a commercial SaaS service) your product. You may even provide consulting services (see clarifying discussion here). You just can’t sell a product that consists in substance of the Commons Clause software and does not add value.

The clarifying discussion includes this rationale from Heather Meeker, who drafted the license:

Consulting would not be "a product or service whose value derives, entirely or substantially, from the functionality of the Software." The value of consulting doesn't derive from what the software does ("functionality").

Answer 4

I think you probably can do this. Before I go on, I must note that (a) IANAL/IANYL, and (b) I'm assuming (1) you're not an employee of the payer, so work-for-hire isn't an issue, and (2) you're writing your code without reusing any pre-existing code, third-party free libraries, etc. If (b)(2) is not true, this answer doesn't apply, and frankly, I think you've got an insoluble problem.

The CoCl licence says that

Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.

For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software.

It seems to me that your code does "derive value entirely or substantially from the function of the Software", since it's written solely to enhance the Software. Your authorship of the new code constitutes "a product or consulting service" in that context.

However, what CoCl says you can't do is be compensated to provide these to third parties. You (as Licensee) and the Licensor, between you, are the parties of the first and second parts.

I don't think there's any bar on your contributing the code to the project, and being paid to do so, provided the project is the sole rightsholder in the existing code. They will probably want to remain so, so it's likely the contribution will involve a Copyright Transfer Agreement, but that's a matter between you and the project, come contribution time. Make sure your contract with the payer specifies that you retain copyright to the work, so that you're free to do that if required.

Answer 5

If the copyright to the commons-clause licensed code is fully owned by a single legal entity (which I'll simply refer to as "the project"), they can just grant you an explicit exemption to the Commons Clause. Under the circumstances you describe, I see no reason why they wouldn't want to.

---

If the code has multiple copyright owners (either because there are multiple contributors who didn't all transfer their copyright to the project, or because the code was forked from or otherwise based on earlier commons-clause licensed code with a different copyright holder), however, things are different. In that case, another contributor to the project could claim that you are, in effect, selling an improved version of their commons-clause licensed code to a third party (the project) without their permission.

(The way the Commons Clause is phrased, it probably doesn't matter whether you're literally selling the improved code or simply providing a paid service to write said code. Either way, it still counts as Selling under the definition given in the Commons Clause.)

At that point, the question becomes whether or not the value of your improved version of the code "derives, entirely or substantially, from the functionality of the Software" written by the (hypothetical) objecting developer(s). Unfortunately, that seems like a nontrivial question. There is an argument to be made that it does not, since you're presumably only getting paid for your improvements to the code, and not for the original code itself (which the project already has full access to anyway). But there are also potential counterarguments that could be made, especially if your improvements are only things like bugfixes or other changes that have no intrinsic use or value without the pre-existing code. Would I trust myself to predict how a court would rule on such a case? No, not really, especially not without knowing a lot more about the details of the case.

So, to be safe, you really should try to get permission from all the copyright holders of the existing code. If there are thousands of them, or if some of them can no longer be contacted, well, then you may have a problem.

All that said, note that the worst thing that a potentially objecting copyright holder could do is sue you, personally, for copyright violation. They cannot sue the project for buying your services, since the Commons Clause only prohibits selling, not buying, and even if you're found to have violated the license by asking for money for your contributions, the code that you've contributed will not be tainted by the violation. Even in the worst case, the project will still have a valid license (or CTA) from you to your contributions, and from all the other contributors to theirs, and can legally distribute and build on the combined work.

(Strictly speaking, the specific license underlying the Commons Clause could impose additional conditions that would "taint" the combined code and make it undistributable in such circumstances. But I'm not aware of any Open Source licenses that would do such a thing, and certainly I see nothing in the Apache 2.0 license that I believe could have such an effect.)

So, in the end, it all comes down to whether or not you're willing to personally take the risk that someone owning the copyright to part of the existing code, who you haven't managed to get explicit permission from, will find out about you getting paid for your contribution and disapprove of that so strongly that they're willing to spend the time and money to sue you for what's likely to be meager and uncertain returns at best. In most cases, I'd rate the likelihood of that as pretty low. That said, if there happened to be e.g. a hostile fork involved in the history of the project, and if some of the original authors were still angry about it, I might reconsider that risk estimate.