Hacker News Reader

Comment by zdw | Hacker News Reader

I don't see the problem with this. People deserve to be paid for the work they do, and time they expend, which is irreplaceable.

If you take your car to the shop and can't pay for the work to be done, they put a mechanic's lien on it, and impound the car until the work is paid for. This is no different from that method, which is totally legal.

Similarly, I've met software developers who set timebombs in custom software they write for companies, with an easy to install patch that gets released when that company pays it's bill.

If you're out to screw someone over and take their work without paying them, then being deprived of the utility of the unpaid work is the minimum amount of damage you should expect.

View on HN

"If you take your car to the shop and can't pay for the work to be done, they put a mechanic's lien on it, and impound the car until the work is paid for. This is no different from that method, which is totally legal."

There is a big difference, actually. There is pretty standard protocol and work agreements for automotive repair. This developer may have exposed himself to a level of risk based on his own contracts and work arrangement. Why was the site up in the first place if he was not paid in full?

"Similarly, I've met software developers who set timebombs in custom software they write for companies, with an easy to install patch that gets released when that company pays it's bill."

Wow, this is just scary. The work relationship is doomed if the developer doesn't trust the customer or vice versa. If you are in the business of making money through software development, be skilled not only in developing but in assembling contracts and project plans that protect your interests.

So let's say that the customer always pays on time and the developer did build this sort of time bomb. (And let's assume no technical knowledge on the part of the customer. Therefore, the time bomb is never discovered.)

Are you saying that the relationship was negatively affected?

I would claim that the developer could mistrust the customer without elsewhere mistreating them.

My point is such that a "time bomb" of sorts would not be necessitated if the developer makes sufficient efforts to protect him/herself with good business practices.

That same client who pays on time and upholds his end of the agreement is left at risk through no fault of his own. Just doesn't seem fair in my opinion.

Will a dispute happen even with well authored contracts and business plans? Absolutely, but properly scoping the work, delivering to a schedule and keeping open communication with the client will greatly minimize that risk.

"let's assume no technical knowledge on the part of the customer. Therefore, the time bomb is never discovered"

That is a big assumption to make. Just because the customer is not technical does not necessarily mean that time bomb could not be discovered at some point in future. Probability might be low but you can never be 100% sure.

Intentionally increasing the attack surface of the product you deliver is not ethical. It's unlikely any developer in the situation you describe has tested the time bomb functionality well enough to exclude the possibility that an attacker could exploit it, either before or after the payment date or the cancellation patch. An aspect of the Hippocratic Oath applies here.

The case described in TFA seems better, since the developer retained possession of legitimate control mechanisms, and used those in technically legitimate ways. (That is, updating the content and functionality served at a URL is a legitimate activity that occurs regularly.) In effect he's more of an unpaid service provider than an unpaid IT contractor in this case. No one would expect their phone to keep working without paying the phone bill, and until he turns over control of the site he should be expected to use that control. It's not like he's using a backdoor here.

There are way, way, way too many ways for this to go wrong. What if you are indisposed (in the hospital, dead, etc) when it comes time to apply the patch? What if an attacker finds the security hole and exploits it before you apply the patch? And don't tell me this isn't a security hole (eg, a backdoor), because it could easily be or become one. Knowingly delivering compromised software is flat out unethical and borders on vigilantism and/or fraud. I don't condone one party failing to hold up their end of the deal when the other party has, and I don't think that "defacing" a website that someone doesn't legally own (they haven't paid for it) is wrong, but putting time bombs in software should never be done.

This seems much the same as a DRM mechanism on a single-player game that requires a live network connection to phone home to the server. In either case, you have software refusing to function unless its creator gives approval. The only difference is that this is known to the player of the game.

My post was a little more geared towards disputing that the work relationship is doomed if the customer and developer can't trust each other.

I had no intention of endorsing a time bomb approach, but just continued on that theme theoretically.

I thought I had expressed that through the sequence of my statements (assuming a possible case then showing that it is at odds with the trust assertion), but will try to be clearer in the future.

I definitely think there are some good replies to the actual practice of installing a time bomb, especially from pragmatism.

"There is pretty standard protocol and work agreements for automotive repair. "

We don't know the specifics of the agreement in question, but there's a general overarching 'protocol' in the services economy - I do work for you and you pay me. If you don't pay me, and your 'protocol' is to ignore my invoices... you reap what you sow.

> This developer may have exposed himself to a level of risk based on his own contracts and work arrangement. Why was the site up in the first place if he was not paid in full?

I mean, I'm a small fish compared to this guy, but I always have the site up and running before hand. Most of the time, I just outright buy the domain and transfer domain rights. This is exactly the kind of thing I do when the contract is violated- that is, when I deliver on my end, and there is a functional site, but they didn't pay.

What I'm saying is, I think you're assuming too much about the nature of how this guy does business. Money isn't about trust, it's about contracts; trust is just what gets the contract signed.

I was a small fish as well for many years, 5 as a freelancer and 5 as a small business owner. We all have to take those risks initially when getting started, "I can build you a site that looks like this for this much money!" But we concede those risks when we do so.

In all of my years I have only taken 2 sites down for non-payment. That was the extent of it though, no payment, no site. I personally would never feel comfortable using a clients domain as my own platform to state my side of the story, it's just not appropriate in my opinion.

I want to support fellow designer and developers but in this case I just can't blindly do so without hearing both sides on this or a bit more detail from the developer. The developer has posted little more than invoices were unpaid and he's shutting down the studio like P-Diddy. For all we know through his own initiative he exceeded the agreed scope of work and wants to be paid for it.

Maybe more information can be surfaced and we can rally behind this guy. Until then I've got to stay neutral and look at things objectively.

> I personally would never feel comfortable using a clients domain as my own platform to state my side of the story, it's just not appropriate in my opinion.

I would agree about this-I just throw up a site that looks OK with the company's contact information on it, or just take it down entirely.

This developer did expose himself to a real risk, and one he probably didn't even think of: that little site, which is essentially a text message, is driving my Chrome instance crazy. WTF did he code into it? Would I hire him?

>Wow, this is just scary.

It depends on how it's implemented. There's nothing wrong with the shareware model, surely?

> If you take your car to the shop and can't pay for the work to be done, they put a mechanic's lien on it, and impound the car until the work is paid for. This is no different from that method, which is totally legal.

The former is legal because it is specifically authorized by law. For example, here in Washington mechanic's liens are specifically authorized and regulated in the Revised Code of Washington chapter 60.04.

Unless website impounding is explicitly authorized and regulated in law, then you can't accurately say it is no different than a mechanic's lien.

Who owns the website? If I asked somebody to do a little work and fix up my existing website, I wouldn't expect them to hold it hostage in a billing dispute. But if they built the whole thing, I don't think I'm entitled to any of it until I pay.

I agree. The worst he should have done: bring the website to the state where it was before he replaced it with his website. Not hold hostage the hosting/domain which I'm sure the client didn't bought from him and if they did, at least the domain name was paid for. So route that into the void if you host it.

Typically - and I am purposely avoiding too fine a point on this - the copyright remains with the creator until payment occurs. Otherwise no transfer of rights has occurred.

> Unless website impounding is explicitly authorized and regulated in law, then you can't accurately say it is no different than a mechanic's lien.

Morally I can.

Actually you cannot. Even if, like me, you can see the justification for disabling the site a deadbeat client asked you to build, you cannot logically say that retaining possession of a car is the same thing as taking someone's online presence and turning it against them as a debt collection mechanism.

Putting up a notice on it makes it different, but if the developer simply disabled it, I don't see much difference.

> Similarly, I've met software developers who set timebombs in custom software they write for companies, with an easy to install patch that gets released when that company pays it's bill.

Not paying your bills is not legal, and the designer has a legal option.

Putting a timebomb in the software is also not legal, and probably a criminal offence in some places.

Can you provide a source for your last point there?

I also have read about people being charged/sued over this but Google hasn't helped me remember the case. It was a delivery company from memory.

But in general if you are putting things into the product outside of the contract you must see how this as a legal issue?

Also see why no Easter Eggs -http://blogs.msdn.com/b/larryosterman/archive/2005/10/21/483...

Providing a time-limited version for testing certainly is legal. Just make sure your client knows this and it's in the contract. Display a notice like "Note: this beta version of the software will not run after 1-4-2013".

Well, that's just a time limit and obviously there's nothing wrong with that.

But the concept of a time bomb is that it's hidden and can cause harm at some point.

(http://en.wikipedia.org/wiki/Logic_bomb)

Exactly. If the client was warned, removing the time bomb from the code wouldn't be hard.

Cryptography to the rescue! Years of research and expenditure on DRM says it should darn well be possible. It might also be possible to break it, but just imagine the irony of someone who refused to pay bills for contracted software dev work from one company, trying to hire a team to crack the DRM from the previous contractor?

Taking someone to small claims court over state lines is exceedingly difficult, let alone in another country.

How is a "timebomb" not legal? I think Microsoft call its version of this "Genuine Advantage". And the shareware community calls this a Trial Period.

That's a very good point.

Things like those should be Illegal.

Not the 'time bomb'/"genuine advantage' but the fact that people lie to you during the sale.

a Trial Period is explicit. Renting is explicity. time bomb and genuine advantage or how microsoft is selling Office at staples nowadays is not! it's criminal and devised to take money out of the likes who still pay AOL on top of Cable for Internet.

"time bomb and genuine advantage or how microsoft is selling Office at staples nowadays is not!" What do you mean?

microsoft is selling it's subscription model version of office, along with other software that is not subscription based.

so basically they are making people believe they are buying office when they are renting it for a year.

Genuine Advantage and related DRM philosophical issues aside, I don't see a problem with deactivating a product designed on behalf of a client who hasn't paid. Not warning them is tricky (and not sure if it even serves a purpose), but even if they sue you, just file a counter-suit for an unpaid invoice.

exactly, not warning them.

that's why when i see microsoft 'selling' office to people that are used to buying office and they do not realize they are 'renting' it for a year, i think it should be illegal.

>Taking someone to small claims court over state lines is exceedingly difficult, let alone in another country.

Taking someone to small claims court over state lines is not difficult at all. You simply serve the suit by certified mail. However, collecting on the suit, once you win a default judgment, can be difficult.

I think a "time bomb" would be legal if it disclosed in advance, in the contract language, and the client is aware of it before signing on the dotted line--as is the case with Genuine Advantage and shareware trial periods.

If it is hidden in the software without telling the client, it's a defect at best.

Edit to add: The nature of the relationship might matter too. There is a difference between a software purchase agreement, and a consulting "work made for hire" contract.

If you don't pay the mechanic, the mechanic doesn't get to put a sign out front saying "BOB DOESN'T PAY HIS BILLS. HE'S IMMORAL!"

If you don't pay the mechanic, you don't get your car. If you don't pay the webmaster, you don't get your website.

I recently saw a truck with (nice, magnetic?) signs on the doors warning other drivers not to do business with a local mortgage company and calling them out for bait-and-switch tactics. It seemed pretty effective.

At the tiny webshop/webhost I used to work at, we would just switch to a plain white page with a header saying "please contact accounts@host". Embarrassing enough to push for payment, but visitors needn't necessarily assume foul play.

Enabling people to save face is important - I doubt these fitness guys are going to be particularly cooperative after being shamed.

Actually, I see this quite often at shops all over. One posted the full name and amount of unpaid bills on their very large outdoor sign. Others post pictures of bounced checks. If the mechanic is the shop owner, he can do what he wants with his property.

And as far as I'm concerned, this applies to the web, too. If the web designer still owns the domain and server, go ahead and deface it to their hearts' content. If the client owns that stuff, however, the unpaid designer should just take back their work and let the client deal with the blank website.

I can say from experience that a blank website is very effective in getting a stubborn client to pay. Defacing them is probably taking it too far though, and I don't see how it could be more effective.

Time spent on collecting is also irreplaceable. I do a bit of freelancing, and honestly if the amount due were anything less than a few thousand dollars I'd probably just write it off, or sell the invoice to a debt collector for whatever fraction they would pay. I can make more money working for other clients in the time I would spend on collecting a small debt.

For something more substantial, you need to protect yourself by getting some of the money up front or as defined project milestones are met. And final delivery/live site should be held until final payment is received.

Debt collecting isn't the same across countries though, so it could be tougher depending on where and whom you're operating with.

I don't see what you're saying. No one credible would say that people don't deserve to be paid for their work. However, there's a proper way to go about getting that payment. Defacing their website is not the answer. Without even getting into the legalities, do you really want to send the message "I'm a vindictive asshole" to potential clients?

Reply on news.ycombinator.com