This thing wants the password for your bank account? WTF? That's way more than it needs. Enough info to authorize an ACH transfer, maybe. But the login password for your bank account? No way.
That voids Bank of America's security guarantee.[1] If you provide info for an ACH transfer, and the other party abuses that info, it's reversible. If you provide login info and the other party abuses that info, it's not.
If you aren't comfortable with that you better not use any fintech apps like Cash App, Venmo, Wealthfront, Robinhood, any Intuit products, etc. These services use Plaid (like this app does) or similar APIs like Quovo, Yodlee, etc. Even financial institutions themselves like Citi Bank, American Express, Chime, PayPal, etc use these APIs to link your accounts.
And to be clear, the app itself never has access to your credentials. This all happens in an iframe that tokenizes your credentials.
Well of course I won't use anything like that! I find it mind-boggling that people even consider giving a third party their bank account login+password. It's like saying "yes, I want to be robbed of all my money, please take these credentials and spread them forth to whichever leaked data pile they might end up in".
My bank considers transactions done using login credentials to be final. There is no recourse if someone steals your money.
Last year an iOS mail application called "Spark" (otherwise a great app) decided to quietly upload my login and password to their cloud servers so that their servers can access my mail for me. I dropped the app immediately (https://jan.rychter.com/enblog/spark-email-app-why-i-dont-us...).
This should not be considered acceptable. If you want to let users authorize external access to account data, use Oauth2.
The project uses plaid. The pass is entered into plaid widget and never sent to me. I only get a key for reading user data through plaid. Payments are done by adding Dwolla to plaid. Also pretty secure and what i believe venmo uses
You list an amazing number of apps and services, but that doesn't seem to reassure me of the idea of giving up your credentials.
That's way too much enthusiasm for the new and shiny app, way too little awareness that in this world people are out to get what's yours, way too little concern for questionable security at every single layer of computing, way too much trust in the banking system, way too careless about the information about you that you give to strangers.
Not something that people I know who are good with money would do.
Wealthfront at least lets you select "my bank isn't in this list" (even if it is) and then you get the UI to enter your routing and account numbers. So no, it doesn't require your bank's user/pass.
I don't know why it isn't well-advertised, I wouldn't use it otherwise.
Out of the app you mentioned only Intuit products, TurboTax specifically asks for bank account password. The rest just use account number is ACH for verification.
Yes, but this is increasingly common in online services. Reputable services like Wealthfront also work like this, requiring your bank login to work. The fact that Plaid has their entire business built around providing “bank logins as a service” speaks to that.
I don’t like it either, but I’m not sure how you could get archaic banks and low-tech consumers to adopt something better.
I work at a bank that has a vendor that uses client credentials in order to html scrape their account pages. Most banks refuse to generate consumable methodologies for other financial services to use their data, so they go about it the hackiest way possible.
The instructions asked me to provide account, card number and OTP login code... then it’s just a matter of scraping all my past 10 years transactions and keep the session alive to snoop on exactly how many condoms I buy...
The idea behind the thing seems to be to initiate a wire transfer (which cannot be refunded as easily as direct withdrawal) and provides the merchant with an immediate confirmation of the same. I've never used Sofort for pretty much that reason that they want your online banking credentials and then automate stuff behind your back.
I've sometimes used giropay, though, which does the same, only directly through your bank's online banking interface. So you're interacting with your bank, not a third party; but that third party gets confirmation about the transfer. Still more of a hassle than direct withdrawal ...
German law at least forces them to declare that they do so if they were doing that. Otherwise they would break a lot of laws. IANAL, but I believe that might actually get some people in jail.
I remeber that banks were very much opposed to that service when they started out, warning people off (against the banks ToS, grounds for sccount termination etc.) and trying to block Sofort from their servers. I honestly don't know how the banks were placated in the end.
I am not sure how much information they get from your account. Could be just the balance and transaction confirmation. Also, you need a separate transaction authorization. The log-in information is not enough to initiate a transaction.
Well, the fact that banks traditionally allow reverting fraudulent transactions is becoming more and more of a unique selling point.
So it would seem obvious that they want customers to give out their passwords so they become victims of fraud, only to then learn that the bank has excellent fraud protection (contrary to let's say cryptocurrencies).
That is pure speculation of course. Hanlon's Razor would suggest "banks are too stupid to implement good auth", which, having worked both outside and inside the banking industry, I would strongly agree with.
In France banks have pretty good auth and also they are obligated by law to provide API, so that you can have third parties app without ever giving your credentials.
> Well, the fact that banks traditionally allow reverting fraudulent transactions is becoming more and more of a unique selling point.
Playing fast and loose with security because the bank will be on the hook (at financial cost to the bank) does not seem like a moral or ethical thing to do, and banks would be likely to pull transaction reversion from anyone who tried to use it as a feature.
When I created this product [1], it required the end user's bank credentials. (I am using the past tense because I don't know if it does that anymore -- I'm not working there nowadays.)
I was sure that was an insane idea, as nobody was going to give us their user and password and let us log on to their banks as the clients. (To be honest, we were using an Intuit API which might have prevented us from creating transactions, but I could still have saved them and used them outside the API.)
When I left (for unrelated reasons), they had a few thousand clients.
You Need a Budget[0] also asks for your banks credentials to read transaction data off the ledger. I've seen this done by a number of budgeting softwares to keep their transaction ledger up to date. (It's nominally read-only usage, but of course once you give them the password there's no control over that.) Honestly I don't find compromising my security to be worth the five minutes it takes to catch up on my transactions once a week. In my experience this sort of feature is not at all uncommon.
Those questions are irrelevant, btw. It's the answers that matter, for safety. Someone could know your dog's name or mother's maiden name, but if your answers are "Doginator2000" and "Iron Maiden", you'll be safe and anyone trying to gain access will be locked out.
Hey guys its cool to see that you like my project. Unfortunately these types of things happen to independent contractors often and theres not a whole lot you can do about it but learn from mistakes. I used some awesome tech for the first time in this one like react-native-web which is now in Expo and react-spring for those sexy animations. Im happy for any of you guys to use this project as a boilerplate, learn some stuff from it or make fun of my code
Have you ever seen mike monteiro’s “fuck you pay me” talk?
Assuming that your contract leaves you with copyright until you’re paid you could always have dmca’d them when they deployed. But that’s the vindictive side of me :D
That's an awesome talk.[1] It's one of those ones that you can see once, and whenever a particular topic is brought up (in this case non-payment of a contract) you immediately remember multiple parts of it, even a decade later.
I much prefer billing by hours/days with clear payment terms in the MSA, and iterative delivery,. Clients understand that if they don't pay, they're not going to get much. Project-based estimates with up-front payment probably is good for clients unfamiliar with software development processes, but I avoid projects like those.
Happened to me before so I can really feel your frustration. What I have learned, because it's not always easy to ask for 50% upfront, is to split the project into many phases and ask for payment when a phase is implemented. Hope you won't have to deal with a client like that in the future.
The more you charge, the less likely it is to happen. Also, requiring some money up front before you begin weeds out many of the worst clients. Early on, it might be 10% of your clients that try to not pay. As you gain more experience, you can weed these clients out through a combination of the aforementioned things and just getting a better "feel" for when to turn down a job.
Or do like I did and end up working full-time for a client that does pay well. That brought my non-payment rate down to 0%.
Personal data point - in my six years of doing this (not fulltime), zero.
You can mitigate this risk in the following ways:
* Focus on taking in referrals; you're less likely to get hosed if you know a way back to them.
* Fixed contract + payment plan. As much as you can, negotiate one and have everyone sign it.
* Get clients in your geographic proximity. Spend a lot (say, 3 hours) of unbilled time with them in advance of closing a deal. This gives each party a chance to suss out the other. As with the first bullet point, you're less likely to get scammed because you probably know where they work.
I find it odd that the license is MIT here. Since he ultimately wrote this gratis, that license means his client could easily return and use it gratis, whereas a license such as AGPLv3 would help ensure he'd actually get paid if this client decided it wanted to use it again.
I used MIT because I have no future use for this. I create projects like this all the time. If you use this as a boilerplate for your next startup and get rich let me know. I'll be happy to hear i could help someone out
He said the client pivoted to another product idea. I doubt he's going to use someone else's code he didn't pay for then find another developer to work on it...
The AGPLv3 considers network use to be distribution so the client would have to publish the source. They could still use it for free, but it would have to remain open source.
Most contracts always have a clause about IP which usually states the work done for the project is the clients' IP regardless of you got paid or not. The smarter thing to do without violating this clause is to add "Fuck you pay me" sort of notices inside the application that doesn't allow the user to use the software until you get paid AKA kill switch. Kill switches are pretty easy to implement and you usually obscure key parts of your code. The other way, which is the best way is to use some complex programming language that the client will require a LOT of effort to understand that he might as well pay you. Eg. Haskell, Elixir, Scala, etc. Generally speaking, functional programming languages can be designed to look complex. Eg.
def validate(_vin, vin_arr) when length(vin_arr) != 6, do: {:error, "VIN has incorrect length."}
def validate(vin, [_, "ma3", _, "0", "0", _] = _vin_arr) do
case String.length(vin) do
17 ->
{:error, "You must include the full VIN. Including the last two extra digits. It may not be included in your RC book. You may need to get it from your chassis."}
19 ->
{:ok, :valid}
_ ->
{:error, "VIN has incorrect length."}
end
Normally, the whole app I develop usually will sit inside my Google Cloud account and the handover is done only when payment is made. The types of clients I work with normally don't care about source code, they just care about the working app. These days I avoid clients who are pretty nosy with asking for source code access upfront as it's a huge red flag for me, as like the OP, my personal experience also has been bitter with these clients running away with the source code.
I run an IT shop, not a restaurant to serve you first and wait for your cheque. Sorry.
I run a dev shop and that's not how our contract works.
Here's our transfer of work clause:
"Transfer of Work. Except for any portion of the deliverables subject to license terms (collectively, the “licensed materials”), Stratosphere initially owns all rights in the work created. Subject only to Stratosphere’s receipt of the fees and costs described in the applicable SOW, Stratosphere assigns all of its right, title and interest in and to the deliverables (other than the licensed materials) provided to you by Stratosphere under that SOW. Licensed materials are copyright of their original authors and provided subject to the terms of their applicable licenses or the license terms described in the SOW. You may not use licensed materials other than as described in the SOW or their applicable licenses."
In case you're wondering, our lawyer is Gabe Levine, the same lawyer in the famous "F*ck you, Pay Me" talk by Mike Monteiro.
INAL but even if you did not get paid does not automatically means the result of work for hire belongs to you. If you are a contractor this is a smart thing to explicitly stipulate in the contract.
Also NAL, but my understanding is that if no "consideration" (something of value) changes hands, the contract is null and void. This is why people sell things for $1 instead of giving them away, or why executives take $1 salaries instead of working for free. Thus, if he really never received anything of value for the work, it's as if the contract never happened, and ownership of the IP remains with the person who created it.
It probably is better to explicitly stipulate this in the contract, to avoid any misunderstandings or protracted legal battles.
I would check with a lawyer in your jurisdiction before assuming that non-payment voids the contract. See, for example, the judgement in this UK case:
> Finally, although the First Assignment records both that Mr Dichand and Dr Spaziante were to receive one US dollar as consideration for the assignment of the PCT Applications and further records that they both acknowledged receipt of the dollar, it was never paid by HTI. Mr Edenborough argued that as a consequence the contract was void for lack of consideration. I think the consequence is that Mr Dichand and Dr Spaziante may or may not have a claim against HTI for an outstanding debt of 50 cents each.
My NAL understanding is it doesn't matter if payment actually took place (otherwise how to enforce any normal sale transaction?), it's just whether an agreement that included consideration was in place.
ie, the fact that the contract included consideration makes the contract valid.
however if one side is in breach i think it's fair for the other side to go ahead and breach their responsibility also. in a case like this, anyway.
Absolutely. One of the most important clauses in our agency's MSA, and one of a small handful I consider non-negotiable, is the clause which says that the IP ownership of any work does not transfer until the work has been paid in full.
We don't negotiate on that clause, even under threat of losing very large contracts. IP ownership is the only real leverage contract developers have to get paid.
There are two reasons why that does not make a lot of sense.
Firstly, the term "work for hire" refers to a quite specific situation where the copyright for work you create is not held by you as an individual but by the company employing you. It does not apply to contract work except for a very limited set of circumstances, such as work done for motion pictures in the USA.
Secondly, it is difficult to understand how exactly the client could come to hold any rights over code that they didn't pay for. If you have a contract saying "I'll do X if you pay me $Y" and they don't pay you $Y, you don't have to do X. Even if the contract had some kind of farcical "we still own everything even if we don't pay" language, that's about as meaningful as a clause promising that leprechauns are real. A contract is an agreement in which there must be consideration (ie, something of value) for both sides. What value is there in doing work for free?
The copyright of a work belongs to its creator by default. (That's U.S. law; no contract is required to make that happen.) A standard contract for a contractor will stipulate that the copyright will be assigned to the client upon payment. If payment never occurs, the copyright stays with the work's creator.
> The copyright of a work belongs to its creator by default. (That's U.S. law; no contract is required to make that happen.)
If it meets the criteria for a work-for-hire, the contracting party is the creator from the beginning for copyright law purposes (this is significant for reasons other than those under discussion; copyright transfers can reversed by the legal creator during a legally-specified window that occurs a few decades after the transfer, but a work-for-hire can't be recovered this way by the actual creator, since they aren't the legal creator), and owns the copyright unless specific contract terms specify otherwise.
There would have to be a pretty interesting contract that states if the client defaults that they retain ownership of any work related. They may likely be able to make some claims around any IP related.
But you can put anything in a contract, so whose to say.
Assuming he is in the United States, and was a contractor rather than an employee, I don't think it would be a work for hire.
To be a work for hire, a work must either be by an employee within the scope of their employment, or if by a contractor must meet three conditions:
1. it must be specially ordered or commissioned,
2. the written agreement with the contractor must explicitly say it will be a work for hire, and
3. it must fall into one of nine specific categories of works: (1) a contribution to a collective work, (2) a part of a motion picture or other audiovisual work, (3) a translation, (4) a supplementary work, (5) a compilation, (6) an instructional text, (7) a test, (8) answer material for a test, (9) an atlas.
Generally software fails on that third point. With software the copyright generally belongs to the contractor.
The employer can put something in the contract that requires the contractor to assign the copyright to the employer, but if the employer than breaks or cancels the contract the contractor has no need to do that.
Note: whether or not the person is an employee or contractor is determined by the common law of agency rather than by what the parties call their relationship.
There was some US case law quoted here where the court decided the contractors owned the copyright, and the client only had a (very broad) license.
That said, it's smart to explicitly write it in the contract; I believe a typical formulation is that the developer owns the copyright until payment, when it transfers to the client.
IANAL either, but it looks like (under US copyright law), contracted work is pretty explicitly not work-for-hire. See https://www.copyright.gov/circs/circ09.pdf -- contracted work is only work-for-hire in an explicitly enumerated set of circumstances.
Don’t understand why someone would throw away their integrity by doing this. When a client refuses to pay, the standard procedure is to take them to court and then make them pay what is owed + attorney fees.
Instead, this developer has put himself on industry blacklists by doing this. No way he’ll be trusted with sensitive projects. Don’t do this.
Perhaps he's aware that every action that anyone ever takes, is approved of by some people and disapproved of by others, and your only choice is between who approves of you and who disapproves of you.
I for one, approve of this resolution a hell of a lot more than courts and suits. They are tools you may be forced to use sometimes. It's great that the system is there for when you need it. But they are merely detestable necessities, not my first or preferred choice.
Did it occur to you that by advertizing this attitude, you may have caused yourself to be blacklisted, even if only informally? Probably not.
It's a favor and a pleasure to be blacklisted by some people or organizations. It's the trash taking itself out.
Throw away their integrity? Not sure I'm following. If the dev wasn't paid then they own the work product and they are free to do whatever they want with it. Isn't that what ownership means? Going to court is a cumbersome process that not everyone wants to deal with.
Whoever didn't pay should be the one on the blacklist - not the dev who is free to make whatever decision they want with a work product they own.
Taking them to court is not standard at all. For one thing, in the US, parties normally bear their own attorneys' fees, regardless of who prevails in court. See https://en.wikipedia.org/wiki/American_rule_(attorney%27s_fe.... So even if this dispute actually did ever go to trial, the coder wouldn't be made whole. Unless the dollar amount in question is very high, no rational actor would bother going to court. (The contract might include a provision awarding attorneys' fees to the prevailing party, but see the next point -- nothing from nothing leaves nothing.)
For another, an attorney wouldn't even take this case in the first place. The relevant expression is "you can't get blood from a stone." What good would suing do when your adversary is a defunct LLC, or a wantrepreneur whose credit-card debt likely exceeds his or her assets?
There are no 'industry blacklists' for small consultant developers.
And I really doubt any legitimate operation would blacklist somebody for their entirely legal actions after a contract was broken.
If you hire me to build a book case for you, but then you decide to not pay me after the work is done, should I just destroy the book case and hope for better luck next time? Why couldn't I give the book case away for free?
Most of us are developers and can easily empathize with the OP, but any prospective employer seeing this will wonder about the other half of the story.
Agree that it's not the most professional look. However, the sort of client with the concern you mentioned has an NDA, IP agreement, lawyers... I don't think they'll care much.
The greater risk to the contractor is that this advertises that they deal with shitty clients who don't have those things in place. Working with what sound like fly-by-night clients signals that you're not able to be picky about your work.
If I were the contractor here, I'd bury the project and sprinkle some holy water on it, pursue legal action, and get on with my life. I wouldn't draw attention to what is essentially a failed project. It's naive for the contractor to think that everyone will accept his side of the story regarding the project's failure. From a distance, the failed project is more visible than the flaky client.
I don't know, the attention is also advertisement for himself. And HNs front page is pretty good. People say his code base is not bad, so if I would need contracting in the field right now, I would check this guy out.
It sounds like the client abandoned the project altogether, rather than taking receipt and not paying. So it’s more like a project that was started but never finished — and now the developer is giving it away because there’s nothing else to do with it.
I'm assuming there wasn't enough written agreement for either side to sue the other. Couldn't it be the other way around, though? If the client thinks this is unfair, they can go ahead and sue the developer. (Or use an NDA next time. Or actually pay the guy for his work god damnit)
I'm in a kind of similar situation in that Msft owes me aprox $7k in royalties but they lost track of it internally. I've been pinging them every 6 months about this for the last 4 years, hoping to avoid litigation.
in the usa, you can't expect a lawyer to take a case without paying their fees up front. So $5000+ for any case.
Assuming you win, you are still looking at years before you might actually get paid (if ever).
That, plus a huge time and cognitive investment, means i'ts not surprising he took this route.
This story sounds a little fishy to me. If they just "lost track of it" you don't need to sue. You need to dig out your executed contract with MS, and your set of unpaid invoices and start making phone calls. Ultimately if that fails, pay a lawyer a few hundred to send a letter to the address in the "Notices" section of the contract, demanding payment. That'll get the attention of someone who will get you paid.
Otoh if there is an actual dispute (MS disagrees that they owe you money) then you need to walk away. Nobody is going to sue MS for $7k.
In the future I think I will add a clause in contracts that work for hire will be open source if payment in agreed terms is not received. It would be a good bargaining chip for getting crazy indemnity clauses removed.
I don't agree with that assessment, but I do wonder why mention the client or client non-payment at all. If he wants to bother to mention the breach of contract, he should go all in and publish the client's name. Otherwise, just publish it as code written on his own time. (Which it was, at the end.)
I have some other project I'm working on now. No plans to continue with this one. I just wanted to give it away so people can learn some new stuff so my effort didnt go to waste completely
This is not standard procedure at all: in most legal systems the cost to sue greatly exceeds the loss. Standard procedure is to take risk reduction measures in advance such as requiring payment up front, source code escrow, only working for clients with a known history of honest business dealings, etc.
If this person is an indie contractor doing this as a side hustle, I don't think it's a huge deal. I would still omit the story and label it as some open source project from the get go.
If this person runs a shop where there's a bigger reputation at stake, I'd agree with what you said.
I wonder if the reverse has happened. Where a client pays for a project, and gets code, but it's terrible. So, open source it with attribution to the original developer and an appropriate README analysis of the low points.
Edit: Wondering if it has happened doesn't mean I'm promoting it as a terrific idea.
But why would you opensource terrible code? Even if you want to write an essay about bad practices, it sounds easier to write it just taking extracts to illustrate the points.
That said, attributing those extracts that you are criticizing would be pretty bad form, maybe even basis for a defamation suit. So, sounds messy either way.
Maybe the execution is shit but the idea behind it is interesting enough that you'll pick up some community developers that will code you something for free.
Said client probably picked the wrong people in the first place, and if they couldn't tell then how could they tell now?
I think most small-end jobs end up going to shit for more reasons than bad code, I'm still trying to understand the whole dynamic of how it all goes to crap.
I'd also just like to add if your hypothetical was the case would said developer ever care? I doubt it, they'd just move on to the next sucker.
Readit News
That voids Bank of America's security guarantee.[1] If you provide info for an ACH transfer, and the other party abuses that info, it's reversible. If you provide login info and the other party abuses that info, it's not.
[1] https://www.bankofamerica.com/online-banking/online-banking-...
And to be clear, the app itself never has access to your credentials. This all happens in an iframe that tokenizes your credentials.
My bank considers transactions done using login credentials to be final. There is no recourse if someone steals your money.
Last year an iOS mail application called "Spark" (otherwise a great app) decided to quietly upload my login and password to their cloud servers so that their servers can access my mail for me. I dropped the app immediately (https://jan.rychter.com/enblog/spark-email-app-why-i-dont-us...).
This should not be considered acceptable. If you want to let users authorize external access to account data, use Oauth2.
2) The Cash app only has my routing number and account number.
3) PayPal only has my routing number and account number.
4) My credit card only has my bank’s routing and account number.
Despite these restrictions, the world keeps on spinning round and round.
That's way too much enthusiasm for the new and shiny app, way too little awareness that in this world people are out to get what's yours, way too little concern for questionable security at every single layer of computing, way too much trust in the banking system, way too careless about the information about you that you give to strangers.
Not something that people I know who are good with money would do.
I don't know why it isn't well-advertised, I wouldn't use it otherwise.
Deleted Comment
I don’t like it either, but I’m not sure how you could get archaic banks and low-tech consumers to adopt something better.
Laws that require banks to provide APIs so that any other service, including other banks, can consume the user's banking data.
Deleted Comment
The instructions asked me to provide account, card number and OTP login code... then it’s just a matter of scraping all my past 10 years transactions and keep the session alive to snoop on exactly how many condoms I buy...
Criminals
I've sometimes used giropay, though, which does the same, only directly through your bank's online banking interface. So you're interacting with your bank, not a third party; but that third party gets confirmation about the transfer. Still more of a hassle than direct withdrawal ...
I remeber that banks were very much opposed to that service when they started out, warning people off (against the banks ToS, grounds for sccount termination etc.) and trying to block Sofort from their servers. I honestly don't know how the banks were placated in the end.
So it would seem obvious that they want customers to give out their passwords so they become victims of fraud, only to then learn that the bank has excellent fraud protection (contrary to let's say cryptocurrencies).
That is pure speculation of course. Hanlon's Razor would suggest "banks are too stupid to implement good auth", which, having worked both outside and inside the banking industry, I would strongly agree with.
Edit: if anyone is interested it looks like it’s an EU directive https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A...
Playing fast and loose with security because the bank will be on the hook (at financial cost to the bank) does not seem like a moral or ethical thing to do, and banks would be likely to pull transaction reversion from anyone who tried to use it as a feature.
When I created this product [1], it required the end user's bank credentials. (I am using the past tense because I don't know if it does that anymore -- I'm not working there nowadays.)
I was sure that was an insane idea, as nobody was going to give us their user and password and let us log on to their banks as the clients. (To be honest, we were using an Intuit API which might have prevented us from creating transactions, but I could still have saved them and used them outside the API.)
When I left (for unrelated reasons), they had a few thousand clients.
[1] https://www.prbc.com/
[0]: https://docs.youneedabudget.com/article/142-troubleshooting
Banks need to provide APIs, IMO.
It's also security lunacy to allow apps unfettered access to your accounts, acting as you.
This is why in Europe we have stuff like PSD2 in the works...
Dead Comment
Assuming that your contract leaves you with copyright until you’re paid you could always have dmca’d them when they deployed. But that’s the vindictive side of me :D
To be clear, this is a strong second endorsement.
1: https://creativemornings.com/talks/mike-monteiro--2/1
Why would this matter? If he's not paid, what validity does the contract have?
Whose idea was it to use react-native-web?
It heavily depends on the kind work and the clients you target and accept.
Some tips:
* always demand partial payment up front (usually 20-50%, depending on contract size and length)
* set milestones with additional payment required upon completion (for bigger jobs)
* have a contract that only transfers usage rights and copyright upon final payment
You can always get screwed over or have bad luck (client goes bankrupt, ...), but some prudence in selecting work goes a long way.
When starting, I learned to stay away from anything gambling and real estate related.
Or do like I did and end up working full-time for a client that does pay well. That brought my non-payment rate down to 0%.
You can mitigate this risk in the following ways:
* Focus on taking in referrals; you're less likely to get hosed if you know a way back to them.
* Fixed contract + payment plan. As much as you can, negotiate one and have everyone sign it.
* Get clients in your geographic proximity. Spend a lot (say, 3 hours) of unbilled time with them in advance of closing a deal. This gives each party a chance to suss out the other. As with the first bullet point, you're less likely to get scammed because you probably know where they work.
Dead Comment
a) So would any competitor to the client.
b) The client can use the AGPLv3 version gratis too, even if they modify it, as it will be on their own server anyway.
The AGPL covers using code in servers. They would have to provide code for any server side changes.
I run an IT shop, not a restaurant to serve you first and wait for your cheque. Sorry.
Here's our transfer of work clause:
"Transfer of Work. Except for any portion of the deliverables subject to license terms (collectively, the “licensed materials”), Stratosphere initially owns all rights in the work created. Subject only to Stratosphere’s receipt of the fees and costs described in the applicable SOW, Stratosphere assigns all of its right, title and interest in and to the deliverables (other than the licensed materials) provided to you by Stratosphere under that SOW. Licensed materials are copyright of their original authors and provided subject to the terms of their applicable licenses or the license terms described in the SOW. You may not use licensed materials other than as described in the SOW or their applicable licenses."
In case you're wondering, our lawyer is Gabe Levine, the same lawyer in the famous "F*ck you, Pay Me" talk by Mike Monteiro.
Wow, that's awesome. And thanks for sharing that clause :)
Set up frequent milestones and get paid for them.
It probably is better to explicitly stipulate this in the contract, to avoid any misunderstandings or protracted legal battles.
> Finally, although the First Assignment records both that Mr Dichand and Dr Spaziante were to receive one US dollar as consideration for the assignment of the PCT Applications and further records that they both acknowledged receipt of the dollar, it was never paid by HTI. Mr Edenborough argued that as a consequence the contract was void for lack of consideration. I think the consequence is that Mr Dichand and Dr Spaziante may or may not have a claim against HTI for an outstanding debt of 50 cents each.
http://www.bailii.org/ew/cases/EWHC/IPEC/2018/1142.html
ie, the fact that the contract included consideration makes the contract valid.
however if one side is in breach i think it's fair for the other side to go ahead and breach their responsibility also. in a case like this, anyway.
We don't negotiate on that clause, even under threat of losing very large contracts. IP ownership is the only real leverage contract developers have to get paid.
Firstly, the term "work for hire" refers to a quite specific situation where the copyright for work you create is not held by you as an individual but by the company employing you. It does not apply to contract work except for a very limited set of circumstances, such as work done for motion pictures in the USA.
Secondly, it is difficult to understand how exactly the client could come to hold any rights over code that they didn't pay for. If you have a contract saying "I'll do X if you pay me $Y" and they don't pay you $Y, you don't have to do X. Even if the contract had some kind of farcical "we still own everything even if we don't pay" language, that's about as meaningful as a clause promising that leprechauns are real. A contract is an agreement in which there must be consideration (ie, something of value) for both sides. What value is there in doing work for free?
If it meets the criteria for a work-for-hire, the contracting party is the creator from the beginning for copyright law purposes (this is significant for reasons other than those under discussion; copyright transfers can reversed by the legal creator during a legally-specified window that occurs a few decades after the transfer, but a work-for-hire can't be recovered this way by the actual creator, since they aren't the legal creator), and owns the copyright unless specific contract terms specify otherwise.
But you can put anything in a contract, so whose to say.
To be a work for hire, a work must either be by an employee within the scope of their employment, or if by a contractor must meet three conditions:
1. it must be specially ordered or commissioned,
2. the written agreement with the contractor must explicitly say it will be a work for hire, and
3. it must fall into one of nine specific categories of works: (1) a contribution to a collective work, (2) a part of a motion picture or other audiovisual work, (3) a translation, (4) a supplementary work, (5) a compilation, (6) an instructional text, (7) a test, (8) answer material for a test, (9) an atlas.
Generally software fails on that third point. With software the copyright generally belongs to the contractor.
The employer can put something in the contract that requires the contractor to assign the copyright to the employer, but if the employer than breaks or cancels the contract the contractor has no need to do that.
Note: whether or not the person is an employee or contractor is determined by the common law of agency rather than by what the parties call their relationship.
That said, it's smart to explicitly write it in the contract; I believe a typical formulation is that the developer owns the copyright until payment, when it transfers to the client.
Nice timing, in that I just wrote about this exact topic a few days ago at: https://nickjanetakis.com/blog/protecting-your-code-and-ip-w...
I'd just take them to court if an invoice followed by "fuck you, pay me" didn't work.
Instead, this developer has put himself on industry blacklists by doing this. No way he’ll be trusted with sensitive projects. Don’t do this.
Perhaps he's aware that every action that anyone ever takes, is approved of by some people and disapproved of by others, and your only choice is between who approves of you and who disapproves of you.
I for one, approve of this resolution a hell of a lot more than courts and suits. They are tools you may be forced to use sometimes. It's great that the system is there for when you need it. But they are merely detestable necessities, not my first or preferred choice.
Did it occur to you that by advertizing this attitude, you may have caused yourself to be blacklisted, even if only informally? Probably not.
It's a favor and a pleasure to be blacklisted by some people or organizations. It's the trash taking itself out.
Whoever didn't pay should be the one on the blacklist - not the dev who is free to make whatever decision they want with a work product they own.
For another, an attorney wouldn't even take this case in the first place. The relevant expression is "you can't get blood from a stone." What good would suing do when your adversary is a defunct LLC, or a wantrepreneur whose credit-card debt likely exceeds his or her assets?
He won't be trusted with sensitive projects that he doesn't get paid for.
It would be defined in the contract, but usually the contractors never own the copyright to code written for other people.
Anyway, I agree with the other comments that this is unprofessional and immature. We have a civil court system to deal with these kind of issues.
And I really doubt any legitimate operation would blacklist somebody for their entirely legal actions after a contract was broken.
If you hire me to build a book case for you, but then you decide to not pay me after the work is done, should I just destroy the book case and hope for better luck next time? Why couldn't I give the book case away for free?
The greater risk to the contractor is that this advertises that they deal with shitty clients who don't have those things in place. Working with what sound like fly-by-night clients signals that you're not able to be picky about your work.
If I were the contractor here, I'd bury the project and sprinkle some holy water on it, pursue legal action, and get on with my life. I wouldn't draw attention to what is essentially a failed project. It's naive for the contractor to think that everyone will accept his side of the story regarding the project's failure. From a distance, the failed project is more visible than the flaky client.
in the usa, you can't expect a lawyer to take a case without paying their fees up front. So $5000+ for any case.
Assuming you win, you are still looking at years before you might actually get paid (if ever).
That, plus a huge time and cognitive investment, means i'ts not surprising he took this route.
https://petersonbakerlaw.com/
Otoh if there is an actual dispute (MS disagrees that they owe you money) then you need to walk away. Nobody is going to sue MS for $7k.
Yeah, go for it.
From what I can tell, it can only reduce the number of pompous jerks attempting to milk me for free work...
I guess he is hoping someone start using this project and asks him to expand or customize it.
If this person runs a shop where there's a bigger reputation at stake, I'd agree with what you said.
Dead Comment
Edit: Wondering if it has happened doesn't mean I'm promoting it as a terrific idea.
That said, attributing those extracts that you are criticizing would be pretty bad form, maybe even basis for a defamation suit. So, sounds messy either way.
Not applicable in this particular case I think...
I think most small-end jobs end up going to shit for more reasons than bad code, I'm still trying to understand the whole dynamic of how it all goes to crap.
I'd also just like to add if your hypothetical was the case would said developer ever care? I doubt it, they'd just move on to the next sucker.