Are open source developers at risk of being scammed?

Question

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?

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.