0

Hypothetical Scenario

  1. Developer, A, contracts with company, B, to write code, C, that accomplishes X.
  2. A writes C.
  3. A obfuscates C. (Obfuscation transmorphs C into C' which still accomplishes X but C' is very difficult to interpret by another coder.)
  4. A demonstrates to B that C' accomplishes X.
  5. B pays A.
  6. A delivers C' to B.
  7. At some time later, B hires another developer, D to do some code maintenance and/or upgrades.
  8. D informs B he can not interpret or work on C' because it has been obfuscated.

Question

Does B have any recourse against A?

Improve this question
10
  • 2
    Can you explain why this is not a trivial contract question? Either the contract specifies the readability and/or documentation of the source code, or it doesn't. If it does, then A has not fulfilled his side of the contract until he has delivered accordingly readable/documented code. If only functionality is specified then A has fulfilled his side when he delivers code that satisfies the contract.
    – feetwet ♦
    Aug 15, 2015 at 23:33
  • @feetwet: Yes, that is the direction I am seeking from an answer. So, for example, HOW would one specify sufficient "readability" in such contract language to protect B? Because I think obfuscated code is readable unless you define more precisely what readable means.
    – Alexanne Senger
    Aug 15, 2015 at 23:37
  • 3
    This is a tough question, and as a dev I think it's much harder on the content side than the legal side. My guess is you'd have better luck asking about standards for readability over at Programmers.SE. If they can be specified, they can be put in a contract. But frankly, whenever I've had to work on someone else's code that wasn't subject to peer review it might as well have been obfuscated! I guess, as a starting point, a contract could forbid explicitly running the deliverables through an obfuscator.
    – feetwet ♦
    Aug 16, 2015 at 0:05
  • 3
    As a programmer, I can say that obfuscation is an arbitrary description and frankly subjective. Sometimes I use 1 letter variable names, not to obfuscate, but because it doesn't make much difference and I like to keep it short. And obfuscation is entirely different from encryption or compilation. Technically speaking you could, time-consumingly, unobfuscate code. So I would agree with @feetwet, if they are doing no peer review, and they do not explicitly state that the code should be verbose, then I would say you have met the requirements of the project.
    – Madness
    Aug 16, 2015 at 0:34
  • 1
    @Joshua is pointing out that it's pretty easy to tell when code has been run through an obfuscator, so you could explicitly prohibit at least that by contract. (Of course, if such concerns became common then you'd probably start an arms race to create undetectable obfuscators ;) Looking at the answer Viktor just posted I'm wondering if maybe this is really a question about whether there are any industry standards that would be adequate to ensure code readability/reusability and be enforceable by contract.
    – feetwet ♦
    Sep 2, 2015 at 0:00

2 Answers 2

Reset to default
2

Depends on the agreement between A and B

If the agreement is to simply produce code that accomplished X then generally there is no recourse. (Some jurisdictions may have legal doctrines or laws that do provide recourse).

If instead the contract specifies some specific industry standards A must follow while accomplishing X, then B probably may sue for breach of contract.

Improve this answer
1

All other things considered I would deem it wholly inappropriate if a contract calls for source code (and this would be the default for an employment contract but not necessarily other kinds of contract for code), if the source code submitted is not the code as the developer wrote it for his own reading and how he intended to maintain it, I would consider that an actionable breach. In the GPL, they spelled it out in some verbiage that I am not inclined to repeat, but the form intended to be maintained is the form as needs to be provided.

As for deliberately writing it hard to maintain but he himself must endure the code as it is, that's a whole 'nother can of worms. You see, there are some who write bad to make themselves job security, and there are those who just write bad because they know it doesn't matter to the compiler.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .