Suppose your client asks you to build open source software for them. You begin doing the work and publishing updates on GitHub, but when you finish they tell you they don't like it and won't pay for your service. Due to your contract this is allowed.

Meanwhile the customer just took the code off of GitHub and started using it for free.

My question:

Are open source developers prone to this kind of scam?

Are there any laws in place to protect them?

Despite the contract is there anything that the developer could do? Could they change the license?

  • 40
    Don't get into a contract that allows them to not pay you. Ensure you will get payed for the code even though they don't like it or ensure you can get to keep the full rights until they pay you. Commented Jul 7, 2015 at 20:33
  • 16
    And if you do get into such a contract, don't publish your work for free to the world while they haven't paid you yet. Nobody forced you to put the code on Github. Commented Jul 8, 2015 at 7:46
  • 11
    You may have a case that "not liking" the code cant be claimed when they in fact use the code. Commented Jul 8, 2015 at 9:32
  • 5
    Open source is irrelevant here: just don't give them the product until they have paid, whether it is going to be ultimately open or closed source.
    – o0'.
    Commented Jul 8, 2015 at 12:53
  • @Lohoris I wouldn't be so sure. Open Source projects bring forth different abstract development environments unlike those in companies and organizations. I say that because of this, there would be many different implications involved when resolving this.
    – Zizouz212
    Commented Aug 11, 2015 at 16:29

10 Answers 10


I am not aware of this "scam" and am not aware of the issue being raised with the Open Source Initiative or other organizations promoting Free and Open Source Software (Free Software Foundation, Software Conservancy, EFF, etc.), nor other related areas such as the open content movement, and the Creative Commons. Of course this does not mean that dubious practices have not been attempted. I would also think, that any company/organization that operated like this would quickly gain a bad reputation.

Specific to laws: You are protected as the author of any work, including software, by copyright laws. In the U.S. you, as the author of original work, have the right to license your work in any way you like. While I would first recommend creating a contract that protects you regarding getting paid (regular pay based on hours worked, sign offs--and payment based on gateways/accomplishments, etc.) You could initially hold your code for review/approval (including the code hosted in a public repository like that of GitHub) as "All Rights Reserved" until you are paid, and then upon payment, assign an OSI Approved License. You could also write this into your contract if you really felt it was an issue.

So you do not need to change the license, simply assign "MySoftware, copyright Patrick Masson 2015, ALL RIGHTS RESERVED." The company is thus not able to use it until you change the licence to an OSI Approved option--which you will do once they pay you (and of course you too have provided for all of your responsibilities under the contract).

  • 1
    Excellent answer. Glad to see you're keeping in touch :)
    – ArtOfCode
    Commented Jul 7, 2015 at 21:29
  • 2
    I wouldn't advise "pay based on hours worked" as many jurisdictions use that as a criterium to decide whether you're an employee or a contractor. And as an employee, copyright may default to the company paying you. Paying per finished task avoids this trap.
    – MSalters
    Commented Jul 8, 2015 at 7:11
  • 5
    If your code relies on other open source software reserving the license might not be possible. (Or rather it will not be possible to reserve those rights while sending software to the customer for review)
    – Taemyr
    Commented Jul 8, 2015 at 8:42
  • 5
    "So you do not need to change the license, simply assign "MySoftware, copyright Patrick Masson 2015, ALL RIGHTS RESERVED."" or… just do not give them the sources. If you don't give them, they can't use them. "physically" is much stronger than "legally".
    – o0'.
    Commented Jul 8, 2015 at 12:55
  • 2
    Sure, when I said "don't give them the sources" I implied "don't put them in a public repo". Just upload them to a private bitbucket repo, don't give access to the client, don't convert it to public until he pays. Quite easy, I don't understand why all this isn't obvious.
    – o0'.
    Commented Jul 9, 2015 at 8:19

The fact that the software is open source doesn't change anything about the contract that the developer has with their client. If the developer has done the work, the client owes the money.

Contracts to deliver custom software (or many other services) often specify several stages of payments and delivery, and allow one party to suspend the contract if the other party has not fulfilled their obligations. For example, if the client misses a downpayment, the contract typically allows the programmer to suspend deliveries of the software. This works regardless of the license of the software.

Where having open source code may make a difference is that if the client doesn't pay, the developer loses the possibility of suing them for copyright violation in addition to breach of contract. If the client is using open source code, that's legal, regardless of any other contract they might be in breach of. On the other hand, if the contract is the only reason why the client has the right to use the code, then a broken contract may allow the developer to claim damages for copyright violation. (Consult your lawyer if it gets that far.)

Note that a contract to write code that will be open source does not imply that the code will be on Github. Most free/open-source licenses do not carry the obligation to distribute modified version; they only require, if they're copyleft, that any distribution includes source and that further distribution remains allowed. There are works with a license that require contributing modified versions back upstream if they're distributed at all, but they're rare. Unless the contract specifies that delivery is via Github (probably a bad idea as it puts a third party into the loop), the developer has the same means of blocking delivery as with closed-source code. Of course, the developer may want to distribute the code publicly for other reasons.

Inasmuch as the license permits, it would be a good idea to treat the code written as part of the project as proprietary until payment in full, at which point the code becomes open source. However a copyleft license may make it impossible, depending on the structure of the project.

A final note:

When you are finished you go to the customer and tell them you are finished. They tell you that they don't like your work and they won't pay you for your service. Due to your contract this is allowed.

If the contract allows the customer to decline to pay because they “don't like” the work, there's something seriously wrong with the contract, regardless of the license of the code. A party shouldn't be allowed to cancel the contract at will. There should be objective acceptance criteria that make it mandatory for the client to pay, even if they've stopped caring about the work. The most common type of acceptance criteria for software are functional: the software shall have this and that feature.


You run this "risk" whenever you put code on Github in a public repository with an open source license -- others can use it. Usually that is what is intended.

If you are developing this for a customer, then why would you give them the option to cancel the entire thing when the work is already done? That's a very unusual clause in a contract that's not at all in the developer's favor.

There are strong laws to protect developers -- contract law, copyright law, trade secret law, et cetera.

However, if you willingly got into a contract that allows the customer to cancel it at will, and you voluntarily made your code public to the world on Github, and you voluntarily put an open source license on it to boot... you have made clear formal voluntary choices not to want any of all that protection.

I can't call it a scam at that point.


Most legislations differentiate between rights of authorship, distribution (copyright) and usage (license); though terms, definitions and consequences may vary regionally and IANAL:

  • Author's rights (not copyright) can't be sold or transferred in any way, at least in Germany. If you've written the code, then you're the author. Period. In equivalence you can't make a contract to sell or transfer your human rights, e.g. become a slave. Such a contract would be invalid by law in developed countries.

  • Originally the author has the copyright. The author may grant non-/exclusive rights of distribution to another party even barring himself from distributing his work. However if there's no payment, there's no deal and the granted copyright is void. Contracts saying otherwise are likely invalid by law.

  • The copyright holder can provide licenses to anyone. However licenses can be changed. Paid for licenses usually expire after some time. Lifetime licenses need to be specified as such explicitly. They are valuable. Contracts not reflecting the value appropriately can be invalid by law. Not-paid for licenses can probably be revoked at will. After all the receiving party has not paid anything, so there's no obligation they receive anything. The other way round: If you received no money in exchange for the license, you can happily return any (i.e. no ) money received in exchange for revoking the license.

An open source license does not change anything of the above. Most licenses use the author's rights to grant copyright to everyone by default. "Copyleft licenses" do the same but require derivative work to do so, too.

However, if you as author charge for open source licenses, which is totally valid and seems to be the case, then anyone not paying but using your software is violating the license and thus commits what is commonly known as software piracy. Under some conditions it's punishable by law. In any case you have civil claims for the money they owe you. Please note:

  • Punishable by law means any perpetrator may be sentenced to go to jail or just pay a fine. Any fine does not go to the copyright holder. It's punishment for a crime. It goes to the state. A relevant crime would be to distribute the software commercially without holding the copyright. Using the software is not a crime. Giving it to close friends privately is in a gray zone.
  • Regardless of any crime and punishment you still have the civil claim. Making your claim is way easier, if there's a sentence over a crime. However even if there's no verdict "guilty" the civil claim may still hold. It's just on you to prove it's applicable, i.e. the software was used without valid license.
  • Author's rights can be transferred. It's called copyright transfer. You may still be the author, but you don't own the code any more. That said, good answer.
    – ArtOfCode
    Commented Jul 9, 2015 at 10:00
  • At least in Germany, you're not only still the author but you still retain all author's rights. However copyright is a different thing. Although it's with the author by default, it can be transferred. The transfer can even take place before actually authoring anything. Think of employees at a software company. The copyright of anything they produce at their job is with the employing company by default (see Arbeitnehmererfindungsgesetz). However the company can transfer it to the customer again even before actual work is performed. So copyright is not part of the author's rights...
    – NoAnswer
    Commented Jul 9, 2015 at 11:13
  • ... That's why I wrote "terms, definitions and consequences may vary regionally". In Germany it's a three tier (authorship, distribution, usage) highly differentiating (authorship can't be transferred, copyright can) approach. Author's rights include making changes to your work. This may even be required by law, i.e. if authoring a software is illegal under certain circumstances, e.g. removing a "save stream" feature from a video streaming player.
    – NoAnswer
    Commented Jul 9, 2015 at 11:16
  • @ArtOfCode funnily enough in Germany the author's rights were constituted to protect artists and works of art. You may be author but neither owner, distributor nor "in possession" of a work of art. All four of these are different roles with mostly distinct rights. Even "owner" and "in possession" are distinct. Think of a collector lending to a museum for displaying to the public. Isn't that appealing in context of your user name "ArtOfCode"?
    – NoAnswer
    Commented Jul 9, 2015 at 11:35
  • Indeed it is, thanks for the clarification. I've edited your answer to make this clear.
    – ArtOfCode
    Commented Jul 9, 2015 at 11:37

Many software developers create software for customers, and if the customer wishes as open source. That is no problem, because the customer and the software developer making a contract about it. If anyone is violating the contract (for instance the customer is not paying) it can be end up in court.

The situation you describe says between the lines that there was no written contract. That is always unwise, if you want to get money for work. but even in this case a verbal contract exists. Harder to proof, but still protected by law.


Many great answers, but I just want to add that this "problem" also exists in the proprietary world:

Imagine you are requested to develop a Python enterprise application. The customer will probably want to test it in their staging environment, which is very common for enterprise software. Open source or not, the customer has access to your application's source code at this stage.

  • 1
    The difference is that in the proprietary world, if the customer continues to use the code he is doing something illegal. If you release your code as open source you give everyone, including the customer, the right to do as they please with the code.
    – Taemyr
    Commented Jul 8, 2015 at 8:44
  • Not really a difference at all. Even in the proprietary world, the client has the right to do what he wants with code he owns. Ultimately, this contract is about work performed, not about copyright. Commented Jul 8, 2015 at 15:30

An important clause which should appear in any work-for-hire contract is that transfer of copyright (in this case "release under an open source license") doesn't happen before the transfer of money. Effectively, your work stays proprietary and doesn't become open source until you are paid.

When you publish your work on GitHub under an open source license, it is out there and free to everyone, paying client or not. When the client requests you to do this, you should insist on getting paid by the hour without giving a guarantee of satisfaction.

For more information about how you should design contracts when doing work for hire (open source or not) I recommend the aptly named talk "F**k you. Pay me." by Mike Monteiro.


The idea of getting paid when you are finished implies a fixed price contract. Most developers are against this type of contract due to the risk, but I'm not going to go there. What I will say, is that if you're doing fixed price contract, you don't have to produce the source until they pay you. Then they can push it up to a public github account if they want, or you can do it for them.

However, if they want to create a new piece of software as open source, they are probably doing this to reduce their cost, in which case, they will be attempting to get other contributors and you won't be doing a fixed price contract since that doesn't make any sense.

If they want you to modify an existing piece of open source software, I would suggest that you make an hourly arrangement with short invoicing cycles and short payment terms.

If they want you to modify an existing piece of OSS, and you are ok with a fixed price contract, a) you have a greater appetite for risk than is prudent, and b) fork the code to a private repo and only after the client pays you, do you issue a pull request to merge back into the original repo.

Another way for you to deal with this, is if the contract is small, demand payment upfront.

Also, I'd be very suspicious about any company who wanted to pay you to create OSS. There are reasons, but getting a consulting gig to create OSS is right up there with getting a job managing a unicorn stable.


The open source factor is just a red-herring. As a software developer/contractor you will be paid if, and only if, you deliver the software the client requested. And contrary to most of the answers above, rights to the work you do for a client remain with the client, not with you.

Note that I said requested, not wanted, they are two different things and it is normal for customers to not want the first draft of what is delivered. This is because what they requested is usually not what they wanted and they won't know what they want until they see it. You deal with that by agreeing on acceptance criteria. If the code fails the criteria, you don't get paid, if it passes, you do. If it turns out that it passes the criteria but is not what they want, you get paid and they have the option of setting new criteria.

Good sense says show them early and often as that way the client gets more input into the shape of the product which ensures they will be happier with the result (and happier to pay). It also means you can stage the software accordingly so they are not paying upfront for any garbage they can't use and you don't get stung for work they don't want. This is the basis for agile software development.

  • If the contract was negotiated in a sensible fashion, the rights to the work only belong to the client if you get paid. If you deliver unsatisfactory software, you don't get paid, but they don't get the rights to it, either.
    – Mark
    Commented Jul 8, 2015 at 21:39
  • You might need to check local laws, but if you do work for pay, that work belongs to the payer. As they are not buying a completed product from you, they are effectively, paying for your skill and experience. You might be able to argue in court that any rights revert to you if the contract is cancelled but that is down to the wording involved. You should not have an expectation of ownership at the outset.
    – Paul Smith
    Commented Jul 8, 2015 at 21:53

The subject matter is not what should be free in GitHub. It is about terms and consideration in contract law. The company should pay for your effort as defined in contract.

For example : If the content of contract is that I will pay you 5P in return for your service to fetch me a cup of water. It does not matter whether the water is free or belonging to you. I have to pay in consideration of your action of fetching.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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