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.
Plaid doesn’t let you transfer any money through their API, just read data. If Plaid gets compromised and your username and pass get leaked and used then most (all?) will detect the location change and confirm via SMS.
Every bank in the EU will have to have it or near equivalent very soon under the EU’s Payment Services Directive 2 which mandates API based access to accounts.
Sandboxes are already available under reasonable terms for many banks in for example Ireland.
If you used any IMAP accounts (not from Google), you would need to enter the password. And Spark will quietly send it to "the cloud" and keep it there, with servers accessing your mail whenever they please. This is kind-of mentioned in the Privacy Policy, but in a way that wasn't clear to me at all.
I found this unacceptable, so I can't use Spark, which I regret. I also lost trust for Readdle, so now, even though they make great apps, I am extra careful with handing them any sensitive information.
Storing the IMAP password is basically the same as storing the Gmail OAuth token in terms of access control, not sure why you think storing one is more evil or scarier than the other.
AFAIK Spark’s push notification service relies on checking for mail server-side (so that they don’t drain your battery with constant background refreshes, I suppose?), so I wouldn’t consider it sneaky.
Not sure, but I guess you can revoke an OAuth token and nothing changes for other apps (and you) on the Gmail/Google account side. On the other hand, if you have to change password...
I don't understand why TransferWise requires me to enter my bank username and password to verify my account. I believe it also uses Plaid behind the scenes, but I used to be able to select "other" bank and enter my routing and account number manually. But as soon as I do that it recognizes my bank and switches to the login screen and I have to abort because I don't want to give it to them. I contacted support and they were not helpful at all.
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
I don't, either. Bank bill pay handles most outgoing payments, and that comes with good guarantees. Everything else is on a credit card. I can get data out of the bank in spreadsheet format if it needs to go into some analysis program. Everything is online, but doesn't involve flaky third parties.
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 bank has many reasons to specifically not provide that functionality. And if your value proposition as a company is to farm people's financial data for your own purposes, all I can say is tread carefully.
It won't take much in terms of negative outcomes generated by increased attack surface to make bank/financial regulations even more strict.
This practice is a clear violation of just about every bank I've seen's security policy. Normal practice would be to negotlate a data sharing of some sort, but that happening would be dependent on your company's ability to generate increased visibility for, or traffic to the bank.
I don't either. It is, however, crazy to expect a bank to tolerate you granting a third, unknown party access to their data systems by sharing your personal credentials with the third party.
Your business with the bank entitles you, and only you; barring certain exceptions at their discretion, access to that data.
They do this to minimize risk and culpability in the face of a large number of adversaries that could extract value from possession of data on your personal habits.
It isn't sexy, but that is just the way it works. I've banged my head against the financial industry looking for ways to improve it, but at the end of the day, a lot of the rules and restrictions they put in place actually do make a frustratingly good deal of sense.
Think about this.
Suppose you and 1000000 other people hand login credentials for financial service X to company Y.
Company Y is basically a shell company wrapping a money laundering operation. Your combined set of login credentials becomes an ideal way to wash money into the financial system until everyone else in the financial network catches on. Then that company disappears, and sets up under a different name.
This stuff happens; and even if only some people don't notice, that's all it takes.
I'm working with a fintech company in Germany at the moment that asks users for their internet banking credentials. Apparently it's quite common in Germany.
That's very strange. Here in Norway we have a unified login system for banks and state services that lets you set up the login with your own bank then any other service that needs you to log in will delegate the login process to your bank and never needs any of your details except for your personnummer (social security number in US/UK I suppose). Then your bank either asks for a code from a one time pad or sends a message to the sim card on your mobile and asks you to confirm with a pin code. It then tells the other entity that you are who you say you are and you are connected. It's called BankID. Beats me why practically everywhere else is so primitive.
Yeah, I heard from a colleague (so anecdotal) that apparently it's because Germany in general is quite behind in terms of digital services, which in part is due to still very patchy broadband in large parts of the country.
Yep, same in Denmark. NemID. But it works with any bank, public service etc. The govt runs the IDP and any company or public institution that wants to utilize trusted user login will delegate authentification to the govt idp
Sofort? When it got introduced in Poland everyone was bewildered as it seemed to stupid to be true. But after some EU nagging banks that support advanced and secured interfaces must tolerate this abomination. Ah, and if you need a US visa you have to use it to pay for your application. Suspicious.
We're taking about end-users utilizing a third party service to get some kind of visualisation for their Bank accounts.
While German banks have a standardized API (FinTS), the normal authentication details are still necessary in order to use it, so basically all third party services demand them for that.
The only place where oauth2 is used is for single sign on between services of the same company and maybe - very rarely - you also get social auth from Facebook or similar.
No bank I've ever seen ever provided a public oauth API with which you could fetch data.
I work on PSD2 implementation for a local bank. Will solve is correct, not many banks implement it yet (but "final" deadline is approaching). Also there are rate limits for PSD2 APIs. And also the extremely costly license, which means that there will have to be middlemen reselling PSD2 access.
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 ...
This is ridiculous. In Poland, everyone implements online wire transfer with immediate confirmations by either:
- using a service like PayU or Przelewy24 that have accounts in every major bank (in-bank transfers are immediate), use bank API to initiate the transfer and provide a confirmation to the merchant when the money arrives on their account (they often allow manual or post-office transfer as a fallback, and Blik too)
- using a service like Blik, which is directly integrated with the bank
- using bank APIs directly
The first option is basically as wide-spread as credit card support; direct withdrawals pretty much don't exist there. A service that would ask for your banking login data and OTPs is unthinkable for me.
It's ridiculous how much of finance works on trust in some countries. It is mind boggling my easy for someone in the UK to steal someone's identity for the purposes of applying for credit cards and loans, and people happily give away their names, addresses, dates of birth, anything for random stuff like winning an iPhone or whatever.
No way anyone's ever getting my bank credentials, even though anything important is approved by phone. It's like giving someone the keys to your home and cash safe, and telling them to be careful with it please :)
The Netherlands mostly uses a system called iDEAL; I don’t know the details but it reminds me of Kerberos or Oauth2. Both parties establish trust with the intermediate server that guarantees confidential handover of transaction secrets without requiring more access than necessary.
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.
On the contrary, the fact that services like Plaid are able to exist, indicates otherwise. If banks had a problem with the implementation, they would send cease and desists.
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.
I just have a shitty memory, and if I game them, I won't remember what answer I gave. If I were to take that strategy I'd need to write them down, which is basically already a great sign of a terrible security policy.
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.
You have a contract at the point of agreement, not at the point of payment.
The question is really whether it is IP transfer on final payment or not. If the contract specifies IP is transferred only on final payment, then the developer keeps all IP until that point.
Now, something like building a website, it doesn't really make a whole lot of sense why this matters. If the person doesn't pay, they may not get the source code you've written, and they may not have the technical chops to deploy or use it. But think about a design agency instead.
Client hires a design agency to come up with a brand identity, logo etc. Client agrees to their standard terms - 50% upfront, remaining 50% on completion. They start work and come up with a few ideas. Client asks for a few changes, but they soon broadly settle on a design style. Before the agency gets to the point of completing all the deliverables, the client cuts off contact and does not pay. They're now in breach.
But, they think, we've got the logo, we don't need all the other stuff the agency were going to do. We're fine with the logo, and we're not going to pay. They can go to court, and the court might say "well, you paid 50%, you are entitled to the part performance before the breach". They might look at the design agency and conclude "they're not going to sue us, they're tiny and lawyers are expensive" and decide the risk of the breach makes it worthwhile.
There's also completely innocent scenarios you could imagine that lead to the breach: perhaps the working relationship breaks down. Perhaps the design agency don't answer the client's emails for a week and they refuse to pay.
But if the agency had 50% upfront AND IP transfer only on final payment, then if the company decide to reuse the work, they can't try and argue "well, part payment entitles us to part performance", plus you have a viable cause of action against them for breach of copyright violation in addition to breach of contract.
IP transfer on completion makes it clear what happens in the case of breach (which reduces legal uncertainty), and it increases the cost to the client of breaching, which hopefully has something of a deterrent effect.
My understanding is essentially people have contracts that essentially assign ownership of the copyright at point of completion rather that at the point payment.
In the monteiro talk he says that a lot of companies have default contracts for contractors, and say things to the effect of "it's just our standard contract there's nothing to worry about", IIRC he gives examples of contemporary contracts that require delivery on floppy disks. But also they try to have terms that essentially say all the work belongs to them, and you will be paid on completion.
e.g. if you don't finish the work - or they claim you did not (by applying feature creep offensively, etc). Then because you didn't finish they don't owe you money.
The other approach is that they fail to pay, you can't use (for example) the DMCA to pull down their site, or bring copyright violation suit against them because the IP already belongs to them. All you can do is sue for owed money but you don't have the leverage of stopping them using your IP, because it's not your IP anymore.
That is my understanding from his talk anyway - IANAL, and also I haven't done contract work myself (that's what my wife used to do, and she had a default contract produced by her own lawyer)
> If he's not paid, what validity does the contract have?
What does this mean? The contract is valid absent payment.
A contract has to have consideration for both parties to be a valid contract, but a promise of payment is a perfectly valid consideration and would make the contract valid.
This seems like very basic contract law 101 stuff.
The promise of payment is the consideration. A contract is literally an exchange of promises. When you go into a car dealership and buy a car, they are exchanging a promise (you get a car!) for your promise to pay them.
The refusal to pay is a failure to live up to the promise - that is what makes it a breach of contract. If not paying meant consideration didn’t exist, then nobody would be able to sue for breach of contract for non-payment. If breach meant the contract was invalid, you wouldn’t be able to enforce the contract.
Your interpretation would fundamentally defeat the purpose of almost all contract law.
The promise of payment itself is consideration. The refusal to honor that promise is the breach of the contract. The contract itself doesn't become invalid because one party breaches the contract. Again, such an interpretation would fully the entire purpose of contract law.
Because if you file a lawsuit with a signed contract, you probably get a summary judgement and can put a lien on the income of the other party. If you file a lawsuit without one you get to testify in court about what each party said and who knows where it ends.
That's what contracts are for. They specify a set of promises and what happens when they're broken. If necessary, courts will step in and enforce the contract terms.
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...
They could be taken to court and found guilty (I doubt they'd have the time to build up a fake clone with an entirely different codebase that produces the same results). It would become quite apparent to the contractor they're using their software. The contractors terms could include them paying for money lost in the whole process AND lawyer fees covered.
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.
Slightly pedantically - England and Wales. Scots law doesn't require consideration.
I'd certainly check with a lawyer though - it's been a long time since I studied it ( English law), but my understanding is that not paying is a breach of contract, and it doesn't necessarily make it void for lack of consideration.
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.
I imagine you then go to small claims court for breech of contract. Since the client made an effort to pay, but failed to pay the agreed amount, any judge will side with you.
Depending on how payment in the contract was stipulated, you could also refuse partial payments. If it did go to court, I don't think a judge would find that an offer of $1 counts as a good faith effort on behalf of your client.
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.
For contractors (in contrast to employees), it's not a "work for hire" by default. The contract must explicitly state that it's a "work for hire", and various other conditions must be met. From Wikipedia[1]:
On the other hand, if the work is created by an independent contractor or freelancer, the work may be considered a work for hire only if all of the following conditions are met:
- the work must come within one of the nine limited categories of works listed in the definition above, namely (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;
- the work must be specially ordered or commissioned;
- there must be a written agreement between the parties specifying that the work is a work made for hire by use of the phrase "work for hire" or "work made for hire."
It doesn't seem that software written by one person meets any of the nine criteria above. (A "collective work" seems to refer to something like a magazine that contains the writings of several authors.[2])
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?
That's not really how contracts work. A contract is only "void" if it contains something fundamentally illegal, or if someone was forced to sign it. And that would be determined in court, not automatically.
The guy who promised to pay is breaching the contract by not paying, and the contractor's recourse is to sue him in civil court for the money.
That depends very much on the terms of the contract and how the rights to the work were approached. If the rights were only to transfer upon payment, or not at all, then this action is entirely appropriate.
It sounds very much like this was a freelancer creating a product, not a contractor providing work.
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.
small claims court in my state (WA) is limited to aprox $5000.
This awkward area between $6k to $15k seems to be a sweet spot for abusive business practices (intentional or otherwise) because of the big time and financial commitment it takes to pursue.
EDIT: Also I should add that it's not guaranteed that legal fees can be reclaimed from successful litigation. This is probably the main reason I keep putting it off (and keep pinging them about it every 6 months, paper trail seems important)
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.
it's royaltees from xblig (xna on xbox360). they admitted to not paying me in email, but don't know where the money went.
I actually emailed msft legal about it aprox a year ago, which got traction for a couple months before their activity died off again.
so yes, as you say the general plan I'll probably go with is to retain a lawyer to send threatening emails. that'll cost in the area of $350. Just tried my best to resolve this without that drama.
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.)
If I were to hire you, can I trust that you would not publicly complain about a disagreement? This needs to be asked because this simple act, even though your anger is justified, calls into question your ability to act professionally.
I would recommend removing or rewording the complaint about the client.
Never, never, never publicly complain about a client in a way that can be linked back to you and/or your client.
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.
Fine, what a terrible thing to do to an experienced coder.
As an industry, we work so hard to build a culture of constructive critique via code reviews, of mentoring up new developers, of constantly improving our skills. We strive not to judge people for their code any more than we would want to be judged for our own.
Naming and shaming coders because they wrote bad code is just uncool, as it fights against the aspects of this work that make it enjoyable, and instead turns it toxic.
If a client has richly rewarded you for your work in good faith, is it not also a terrible thing to deliver a pile of crap? If I pay a developer thousands of dollars and the result is garbage, you can bet I’ll be judging them for it.
If I paid a photographer to take my wedding photos and they did a terrible job, am I a bad person for judging and shaming them to warn others who might be similarly conned? Or is it only developers who get the kid gloves treatment?
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.
I had a similar story. At 16, a summer friend came to me. He told me that he knew a company that needed a web app.
He got a 5500$ contract. It was so much for us, just high-schoolers.
We didn't know how to do a web app. I knew a bit of Python, him a bit of Javascript.
So a month during, we learned how to and built the app they asked with Django. I never learned so quickly!
After a month, we shipped the app. They had a lot of users (900+), so our app that worked well with a database of two people failed miserably.
We spent nights fixing its problems.
It used an external API that we had rate limiting problems with. I implemented a cache using Postgresql.
Then, they started to ask us for more features that weren't in the original contract. They said that if we wanted to get paid, we had to do them.
Eventually, we realized they weren't going to pay for us. We asked them to pay us, and they said yes. Then they said no, contact our lawyers. Their lawyers told us they wanted to engage charges because we didn't do the job well. They were still using our website without paying us! We contacted a lawyer and quickly realized that because of the legal fees (2500$ upfront + 500$/hour), it wasn't worth it to seek justice.
We were completely fucked.
Then, I remembered they used Heroku, which was based in the US and therefore applied the DMCA laws.
We sent them an email explaining the situation and, in under 48H, they took the website down. I will always remember that morning when my friend woke me up to show me their site down.
As we did the deployment, they took a week to re-deploy our app at a server under French jurisdiction (that we could never have taken down).
Then, their whole company ran out of business as customers were leaving and asking refunds because of the lousy service. They laid off everyone, but our app is still freely accessible at https://crypto-analyse.com.
This experience taught us many lessons:
- Never work for something that you're not paid for unless you're doing charity or working for yourself.
- Contracts are no guarantee
- They made a lot of money with our app. We could have made a lot more by just selling it ourselves.
And that's what we did! We just shipped our new app (it's an app to automate crypto trading with a conditions editor), https://kaktana.com
We now make more money than we had thought before, all of that using the experience we gained from that shitty deal.
Another take on this would be to open source components developed, but not the application itself, and be more subtle about the client mess. That's a better way to get some positive marketing out of what would be wasted time.
If a vendor doesn't pay you, call a collections lawyer.
Generally speaking the client owns the code whether or not they've paid yet. Of course if the client agrees this is fine. But it's not fine if the client hasn't agreed.
Stunts like this are a really bad idea. There's a right way to do it, and it works really well. Call a collections lawyer.
My understanding is that the person who produces the work produces generally owns the code until they are paid. Obviously it depends on the specifics of the signed agreement, but I'm curious why you think the client owns the code by default?
No actually most contracts assign full ownership and not a license.
What about partial payment? What about a payment dispute? in all these cases ownership remains as defined in the contract.
You could try to make a contract that works the way you describe but it would be unwieldy and I’m skeptical anyone would use it.
It’s really straightforward to call a collections lawyer. In most cases the money is paid after one or two letters.
Not paying money owed can have bad consequences. The collections lawyer reminds them of this, and the situation is remedied in short order.
On the other hand, pulling some cowboy stunt to teach them a lesson (like releasing their source code, or the related idiotic idea of sabotaging their website or business) could lead to paying significant civil and even criminal penalties.
This reflects badly on the developer who posted this. Though it is easy to sympathise, this is not professional behaviour. Learn from mistakes and move on focussing on finding good clients.
You could - or could start without it. The code is really nothing special - relies on Plaid for processing payments and small dB to keep user profiles...
it’s done well though, so could certainly build it up if this model is what you are looking for.
I'm trying to wrap my mind around what the author means by saying the value would come "from leveraging data to eventually create a rental marketplace where users can find the perfect apartment to move into."
Seems to be a payment platform, where landlords would register their rentals (apartment info, rent amount, etc) in order to charge renters. The platform owners would then take that data and use it to build a rental listing site (like Airbnb but for long-term rentals).
As someone who occasionally does recruiting for developers and always do some quick searches for GitHub profiles. You'd be dropped as a potential candidate on our team if we stumbled upon this, "After he signed and I began building he decided to pivot and not pay me."
Surely the guy not paying is the unprofessional one?
Sure, since "he signed", he could have probably taken legal action, but that's often a long and costly process. How is cutting your losses and walking away (but outsourcing the code you wrote) unprofessional?
And yet, I read his comment, and I read your comment, and if I had to choose who to work with in any capacity (I could be any of employer, employee, vendor, customer, purchasing agent in this arena), it would be him over you.
Just saying the word "professionalism" doesn't make you the one who is more professiional, or make your concept of professinalism the better one.
I'm a bit confused here. Do you think he should have accepted his fate and moved on to the next project? And at best just whine about it on online forums.
As a dev who does interviews/evaluations it would be a red flag for me, and would affect the lens through which I view every answer/interaction with the candidate.
I think there is a different way to phrase this, something like “this is the result of a collaboration that didn’t end up working out” or whatever. I get that it’s kind of mealy mouthed, but it avoids any aura of conflict in the evaluation.
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-...