Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Parent Full thread

He is encouraged to use open-source code to achieve results faster, but he's not allowed to give anything back to the community that developed it. His grander ideas are shelved, because the bank just wants quick fixes to its old, messy platform. When someone offers him a better job, free of the legacy system's constraints -- one that pays four times as much, as Aleynikov's new job with Teza Technologies did -- the bank enlists the FBI's help in going after him for saving some code on an outside server.

One reason that this is an outcome of the Aleynikov case is that Michael Lewis made it so, despite the fact that it does not appear to be true: in both the Second Circuit review of original federal case and according to his own lawyer's stipulations in the new state case, the finding of fact is that the majority of the code he took was not, in fact, open source. In fact, his own expert witness in the first case was (according to filings, which may be missing context or additional facts) only able to conclusively identify a few files of open source code.

The idea that Aleynikov was victimized by Goldman's unwillingness to cooperate with open source projects is a hacker-friendly narrative. We should generally be wary of hacker-friendly narratives, like the FBI dragnetting Google searches of pressure cookers; they tend to turn our brains off.

Corrections welcome; I've read some of the filings in this case, but not all of them, and on this issue I am allergic to Lewis' reporting, which I believe to be uncharacteristically and dramatically shoddy.

The double jeopardy aspect of this case is what troubles me. He was cleared by a federal court of the crime, but they found an obscure statute under which to charge him at another level of law for what was essentially the same action. The only reason this was successful is because Goldman Sachs is, well, Goldman Sachs and the amount of power they wield is frightening (even to a federal judge).

But that's beside the point: this article is presented not as an honest retelling of the facts, but as a window into how engineers might perceive this case, and the impacts that perception has on banks' abilities to recruit the best talent. And from that perspective, it's spot on: it drags into the open a lot of poor practices that banks have and how they're a poor fit for the hacker culture present at the top level of engineering talent. Even if that doesn't represent reality, it reinforces that perception: young engineers graduating from college and looking for a job have a certain negative connotation with banks as a result.

This reminds me of an epiphany I had at my first programming job at a major bank:

If you want to work in software, try to go for companies whose main product is software.

These are the companies that will take software quality seriously because their bottom line depends on it.

These are the companies that will constantly try to improve their craft by exploring new technologies because it helps them maintain their competitive advantage.

These are the companies that will truly value talented software engineers because they have the potential to make a positive impact in the products that define the company.

If the company's focus is on anything other than software, whatever you're working on becomes a means to another, more important end. Your work then becomes that much less valuable, and you, that much more replaceable, to the company because they're only looking for the bare minimum functionality out of the software you develop to enable whatever it is the company does that really brings home the bacon.

I realize this is probably an over-generalization, and exceptions will definitely exist, but so far from my experiences in job searching, this seems to hold in an overwhelming majority of cases.

>If you want to work in software, try to go for companies whose main product is software.

I used to think this before I worked at a software company. The problem is software companies have far more time pressure, particularly small and medium sized companies. "We'll go out of business if we miss this deadline" doesn't result in high quality code.

The best code I've seen was written for a telecom. The company had the resources and the patience to do it right, and (more importantly) the people in charge knew what they were doing.

I agree. A large business that uses software for a core revenue-producing source, is capable of doing fantastic work on that source.

A software company providing that same product as a vendor, would be unlikely to have the motivation and focus to do it the same way.

Key for me, is the principal/agent distinction. If you are using something as principal, for revenue, your motivations are very strong. If you are producing it as agent, for someone else's revenue, trickier. By definition, less money for you to get it right as agent for someone else.

That said, there may be dozens to hundreds of ancillary software processes at a large business which are done very poorly, but any smart business of size will take great care of where the money comes from.

I'd think the problem you're seeing has more to do with the size and available resources of the company rather than the sector it operates in. Any company in its early stage growth period has to prioritize time to market over most other priorities, but this is true for startups in all sectors and not limited to software.

Comparing an established telecom with a predictable revenue stream versus a software startup doesn't exactly make for a fair comparison.

If you instead keep the size and available resources at least somewhat consistent, and look at software written for say a large telecom vs a large software company, or say a software startup vs a hardware startup, for instance, I think the tendencies I outlined in the original post will still hold in an overwhelming majority of cases.

>He was cleared by a federal court of the crime, but they found an obscure statute under which to charge him at another level of law for what was essentially the same action.

I am not knowledgeable about the specifics of this case, but the way that you stated the situation, this isn't double jeopardy.

Double jeopardy concerns trying someone for the same crime. If it is a different law that he is charged with (even for the same 'action' as previously charged), it isn't double jeopardy.

I thought there were rules to prevent this. Otherwise, if someone gets acquitted of, say, a murder charge, the prosecutor could go for it again but with a manslaughter charge instead.

Generally true, but state law and federal law are considered "dual sovereignty".

Ah, so it's just like how someone could be acquitted of murder, but still face a civil wrongful death suit?

Double jeopardy doesn't apply to civil cases.

Yeah, my problem with it is that the US has so many laws that pretty much anything we do is illegal in a couple of different ways. Especially with computer crimes, where a judge/jury (and sometimes the lawyers involved) may not have the technical understanding to comprehend what's going on. It defeats the purpose of double jeopardy protection if prosecutors can just go back, find another law that was passed 200 years ago but maybe applies in some theoretical sense, and charge you under that law.

The entire basis of the US criminal system is that in the case of prosecutorial misconduct / incompetence, the benefit of the doubt goes to the accused. It's better to let a guilty man go free than to lock up an innocent one. If we're eroding that basic premise through an increasingly opaque legal system, that's a big problem.

> Even if that doesn't represent reality, it reinforces that perception

Is that a good thing?

I know this is the law of the land but -

Any programmer's own code is open to whatever they want to do with it.

I want to put my code on pirate bay ? I should legally be allowed to do so.

The question that needs to asked is how is it allowed for companies to prevent the author of a codebase from using it on their own disgression ?

There is a price to pay for this - we do not allow those poor multinational to profit massively.

Programming in 2015 is socialism at its finest. How many programmers do you know who work on isolated codebases ?

We live on the shoulder's of giants. Allowing companies to force programmers to hide or take ownership from their own code is bad practice, and harms human innovation.

It also allows companies to force modern day serfdom on their knowledge employee.

If you don't want someone else to own the fruits of your labor, don't work for someone else. Programming offers you an unparalleled opportunity to do that.

> Any programmer's own code is open to whatever they want to do with it.

Here's a hypothetical. Apple hires someone and pays them handsomely to build critical software for the iWatch. After he leaves Apple, is he allowed to take that code to Samsung?

Code is worthless, so yeah ... no harm done. Apple genius is in convincing people to buy their stuff.

Solutions to problems aren't worthless. A "critical" solution is worth a lot, and presumably Samsung paid the engineer a lot to build it.

Code is worthless. The person that wrote it can be priceless.

Then what's the point in even bringing it along?

Who funds the code keeps the code.

You fund yourself have fun doing whatever you want with the code.

Company funds the code they are the owner of the code since they paid for the code.

If your analogy holds you write code for a client on contract. After you give them the code you can't just give/sell the code to the compeditor or put the code on paste bin for everyone to see. You would be unethical and open for a lawsuite.

In some legislations this is exactly what happens: you're not granted any rights you didn't explicitly pay for. I don't think that this is a bad thing -- it errs on the side of the naive contractor, rather than the naive employer.

From memory transfer of copyright requires a written contract in the US; so be it your employment contract or a freelancers contract it needs to be written down. I have had contracts where I have successfully negotiated having that clause removed. Just because someone pays you to write code doesn't necessarily mean that at the end they own the copyright. Some jurisdictions however have implicit transfer of copyright in work for hire situations so consult a lawyer and make sure it is always written down.

No. In the US, works created by employees in the scope of their employment are considered "for hire" explicitly by statute: 17 USC 101.

It's also true, as my sibling commenter points out, that boilerplate contracts have CYA "for hire" provisions in them.

This is a bit of a silly digression, right, because if WFH was going to exonerate Aleynikov, his very-expensive lawyers would have deployed it as an argument. But it would be dangerous for readers to rely on an Internet argument that their own employee work contributions might be their own property, so it seems worth correcting this.

WFH is very relevant for contractors (who are by definition not employees), but less so for full-time employees like Aleynikov.

Incidentally: you don't have to answer questions about US law "from memory". The answer to this question --- which, by the way, is a whole pamphlet the Copyright Office publishes specifically to resolve confusion on this question --- is a Google search away.

Title 17 Circular 92 Chapter 2

§ 204 . Execution of transfers of copyright ownership

(a) A transfer of copyright ownership, other than by operation of law, is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed or such owner's duly authorized agent.

So it would seem that I didn't realise that there was a clause "other than by operation of law"; but you will also note that my last statement of my comment said that you should get a lawyer...

Your argument here being that 17 USC 101's plain and simple definition of "work for hire" is "invalid"?

    A “work made for hire” is—
        (1)a work prepared by an employee within the scope of 
        his or her employment; or

    (no further qualification is made regarding A.1)

No that is not my argument; what I am saying is that we are both right. If there is a matter that is covered under the law, for example work for hire (which is covered under title 17), then there is no need for a written contract (or other written conveyance of transfer). If however the transfer happens under a matter not covered by law then a written contract is required; say for example a transfer as a part of the sale of a company.

But my final point is still valid (as is supported by standard employment contracts covering IP rights even though it is covered under title 17) that if something is important to you get it written down in a contract and make sure it is checked by your own lawyer.

"Work made to hire" means that the programmer never owned the copyright in the first place. The employer owned it from the moment it was created. There is no transfer of ownership taking place to document.

You may be thinking about EU law.

I don't know whether this is universal to the EU, but in Germany it works the way you describe: even if you get paid to do it, unless you're explicitly granting exclusive rights, you only grant a non-exclusive right.

For example, if you hire a freelancer to write you software, you don't have anything other than simple usage rights unless you signed a contract with them explicitly granting you additional rights. Even if you gave them a bunch of requirements and defined deliverables.

This is a case where the braindead application of existing copyright (e.g. how this works for commissioned literature) actually resulted in a good thing.

Do you mean to imply that Goldman's employment contract somehow neglected the bog-standard "work for hire" clause that every other employment contract pretty much ever has included?

> Any programmer's own code is open to whatever they want to do with it.

Sure, if someone else didn't buy it from them by paying them a wage.

> Any programmer's own code is open to whatever they want to do with it.

Should I be allowed to sell the exclusive rights to all of my code to my employer, in exchange for a salary? Or do you want to deny my ability to make that contract -- that is, deny me the right to full ownership of my code?

If your employment contract includes the "work for hire" clause (which nearly all of them do, as a matter of course), and you don't get it waived, then no, it's not your code to do with as you please.

Reminder: your employment contract does not need to say anything about WFH for your code to be considered WFH. Employee code is generally WFH.

No, they don't have to. They still often do, however. And when they do explicitly include such verbiage, it's easier to get it waived or amended (as I've been able to do at nearly every position I've ever taken). Counsel is far more likely to modify an existing clause than to add a new one, IME.

But if he or she is an employee its not their code the Law is quiet clear on that.

Ford line workers don't own the cars that come of the line do they.

They don't own the raw materials. In programming there rarely are raw materials in that sense. The comparison is silly.

Under US law commissioned works may "belong" to the commissioner. Under German law, for example, they don't, unless that's explicitly part of the contract.

If anything, software is comparable to other commissioned works like art, literature or architecture.

But anglo saxon employment law does consider it the same

American employment law isn't exactly known to be employee-friendly in the first place, so that's hardly surprising.

I don't have a problem with companies that have a work-for-hire clause, but I do get a little jumpy around ones that have an "anything you do, even at home, still belongs to us" clause.

Reply on news.ycombinator.com