8

As an individual freelancer, I'm writing some code for my customer's commercial closed-source project. The customer don't mind me to open-source this code, but they would like the code to be available for use only in open-source projects, but not in commercial projects, or at least not in closed-source projects.

I plan to continue maintaining the open-source version of this code and use it in my other open-source projects. As well as I plan to continue cooperation with this customer and fix problems with the closed-source project.

My current ideas are:

  • Make a GPL fork from the initial release of the code

    • Pros: easy;
    • Cons: if someone submits a patch to the GPL fork, I can't port it to the private fork, because the patch is GPL; I can port only my own patches;
  • Make a GPL fork and also ask contributors to sing CLA CTA for transferring rights to the patches to me

    • Pros: all patches from GPL fork can be ported to the private fork;
    • Cons: nobody likes signing CLA CTA; also I'm not sure how to make the signing process correct - first because I'm an individual, second because IANAL;
  • Maintain a single version of the code licensed under GPL with a special exception for specific customer (company)

    • Pros: single repo to both projects is ideal!
    • Cons: I can't find examples of such exceptions - are there? Does GPL allow it at all?

What do you think about this ideas and are there better solutions?

3
  • 4
    open-source and commercial are not mutually exclusive. Actually open-source implies that the code can be used commercially, too. Disallowing that puts the license out-of-scope for open-source. GPL explicitly allows any use - on the conditions outlined in the license, namely to open-source and GPL-license any derivative. Jan 31 at 11:53
  • @planetmaker thanks, this is a good point. I think that while potential competitors of my customer will have to open-source derived work, it's acceptable even if it's a commercial product. However, if there is a good way to make this code "semi" open-source, i.e. keep the source code public, accept contributions, but forbid commercial usage, this could be an option too.
    – gavv
    Jan 31 at 12:08
  • 1
    I edited the question, it's now "but not in commercial projects, or at least not in closed-source projects"
    – gavv
    Jan 31 at 12:28

3 Answers 3

6

Bart's excellent answer covers most of the points I'd have made, but you do ask about contributions, and I think that's worth addressing as well.

That issue rather hinges on whether you see the projects as divergent: the commercial project uses the code you wrote (and which the company owns), and does its own thing with it; meanwhile, you are reusing that code in a GPLed project, which accepts contributions, and develops on its own. In such a scenario, contriibutions are simple: they'll be made under GPL, and the whole of your open project will remain under GPL. This is, to my mind, the best scenario.

If on the other hand you see the projects as evolving in parallel, where the company wishes to continue to use contributions made by third-parties to your project in their commercial codebase, that could get really problematic. You will have to decide whether to restrict contributions to your project to people willing to sign a CLA that permitted the company to reuse contributions under a commercial (ie, non-free) licence. This could get quite messy, and it seems likely to me that your project would quickly get forked, the fork being happy to stay GPL-only and thus requiring no CLA.

6
  • Regarding how I see it: I expect that I'll be maintaining the closed-source fork, at least for a while, that's why ideally I'd like to be able to sync them. The customer don't mind to sync changes from closed-source fork to open-source one, and the problem is with the backward sync..
    – gavv
    Jan 31 at 12:43
  • "This could get quite messy, and it seems likely to me that your project would quickly get forked, the fork being happy to stay GPL-only and thus requiring no CLA." - yeah, a very good argument against CLA.. Especially given that the project is not big, and maintaining a (non-CLA) fork is feasible.
    – gavv
    Jan 31 at 12:46
  • No CLA means that third-party contributions can't go from the public version to the closed version (well they can, but only at the cost of the company being required to distribute their version under GPL).
    – MadHatter
    Jan 31 at 13:01
  • I though that in CLA, I can ask contributors to transfer copyright to me, and this case I would be able to redistribute that patch under any conditions?
    – gavv
    Jan 31 at 15:41
  • 2
    @gavv you're confusing a CLA and a CTA. The former is a licensing agreement, and specifies the terms under which a contribution may be used (including whether it may be relicensed); the latter is a transfer agreement, and actually transfers the rights. CTAs are even less well-liked than CLAs, so it's best to stick with CLAs if they'll suffice, as they could in this case. Very few contributors will be prepared to give you all the rights to their contributions just so you can funnel them into a commercial project.
    – MadHatter
    Jan 31 at 15:56
8

The customer don't mind me to open-source this code, but they would like the code to be available for use only in open-source projects, but not in commercial projects.

This triggers me that it seems that your customer thinks that you are creating a work-for-hire for them and that they (the customer) will own the copyrights on the code.

It is imperative that you first get clarity on who owns the copyrights on the code that you write for this customer, because that lies at the basis for what your options are.

If your customer owns the copyrights, you can not decide on which license will be used for that code in your own projects. You must ask your customer under what license terms they are willing to give you the right to further use the code. You can propose some common open-source licenses as options, but none of them will forbid commercial usage.

If you own the copyrights, then the option with the fewest headaches is to just maintain a GPL version and give that also to your customer. The drawback for them is that they need to provide (access to) the source code when they want to sell the product on. The advantage is that they have the right to make changes without involving you.

6
  • Thanks. I would like to give copyright to my customer because it's the most safe option for them. I think it's a decent thing because it guarantees that I can't give this code code to someone else under non-GPL (if I choose GPL) conditions. Yes I understand that in this case I can not decide, but I can just negotiate it with the customer. They don't mind to use GPL.
    – gavv
    Jan 31 at 12:22
  • One thing that concerns me is how to get a public proof that the customer really intended to release it under GPL. For example, I could ask them to push the initial code to github from their account, but I'm not sure if this can help, from the legal point of view.
    – gavv
    Jan 31 at 12:27
  • 3
    Generally, it's enough to have a written declaration from the company that they are giving you a copy under the terms of (eg) GPLv3.
    – MadHatter
    Jan 31 at 12:38
  • @MadHatter Thanks!
    – gavv
    Jan 31 at 15:42
  • 1
    If the OP owns all the code then they could also simply license it to their client under a non-GPL license. This only presents an issue going forward if they later enter a situation where they don't own all the rights, such as by accepting code from someone else under GPL terms, or copying code from another project subject to the GPL. They would not then be able to provide updates to the client under the original terms. Feb 1 at 15:36
4

Copyright owners aren't bound by their own licensing terms. If your customer owns the copyright to the code (as you suggested in a comment they would), then they can license it under the GPL, and still do whatever they want with it.

If you own the copyright, you can dual-license the code. Each user accepts one of the licenses and ignores the other. The GPL can't prevent that because anyone who chooses a different license can ignore everything the GPL says. You don't need to modify the GPL.

If you want to accept patches from people who aren't willing to dual-license or transfer copyright, then you'll have to maintain two codebases. I don't think you should worry about what the closed-source license or CTA should look like, because YANAL. The company could benefit from the free third-party contributions that open source projects tend to attract. If they want that benefit then they ought to do the work associated with it.

2
  • 1
    If the customer owns the copyrights, then you can not "just license it under the GPL". The customer must license it to you under the GPL. Feb 1 at 7:23
  • @BartvanIngenSchenau I meant you can put "this file is distributed under the terms of the GPL" at the top of every source file you write, etc., but you're right, the wording wasn't ideal.
    – benrg
    Feb 1 at 8:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.