1. By no means do I want to defend Skype here, but the prose in the linked documents isn't especially incomprehensible, at least not for documents of this type.
I teach contract drafting to third-year law students. It's hard work to take a complex if-then-else concept and render it in plain English.[a]
And here's the rub: Few clients want to pay lawyers to spend extra time on readability -- "good enough" (whatever that means) is the goal.
2. [EDITED TO ADD THIS:] It's not unusual for a private company's employee stock plan to include a "call" option that gives the employer the right to repurchase employee-owned shares when the employee leaves the company.
That makes sense when you think about it -- if you're a private company, you don't want a lot of random ex-employees owning dribs and drabs of your shares, especially if you're worried about the 500-shareholder limit (under current law).
On the other hand, for a company with an upcoming exit to buy back the shares at the employee's cost, instead of at a good-faith estimate of the stock's then-current value -- well, that does indeed seem unusual.
(EDIT: Some documents like this provide that, IF: The company wants to do its buy-back EITHER: (i) after an exit is announced, OR: (ii) if an exit is announced within 30 days or so after the employee's departure; THEN: The employee is entitled to the exit pricing for the buy-back.)
3. Again, not to defend Skype, but conceivably they might not have had a choice about the buy-back price, at least not without jeopardizing some kind of favorable income-tax treatment.
If I had to guess, I'd venture that, X number of years ago, some overzealous junior lawyer decided to draft the relevant documents so as to put the company in the strongest position s/he could. Now that zealousness may be tying their hands. I stress that I'm speculating here.
* * *
[a] If you have occasion to write a complex if-then-else sentence, try using all-caps and punctuation like this: IF: It rains at least one inch today but not more than two inches; AND: It doesn't rain tomorrow; THEN: You will turn on the sprinkler system tomorrow; AND: You will not do so the day after.
Of course not, you're supposed to consult your legal counsel(1) before signing such documents. What? Don't you have the mad cash to pay a lawyer to give such an important document its due consideration right after graduating and joining a startup?
(1) Everyone, everywhere should have an attorney at all times in order to check every single thing they do, say, or sign in a public or legal forum. That's why the advice everyone always gives in this sort of situation starts: "Of course, you should check with your attorney..."
HN is not youtube, where there's no threading of comments and where it's impossible to divine who you're responding to without the @name.
Here it's quite obvious who you're responding to, because your comment is indented under the comment you've replied to.
Also, while we're at it, replies that say no more than "I agree" or "I disagree" are generally frowned on here, since they're almost completely contentless and don't contribute to the discussion.
> Here it's quite obvious who you're responding to, because your comment is indented under the comment you've replied to.
Right now that's indeed true. If later on there were to be a lot of intervening comments, it'd be more difficult to tell immediately who the response was directed to. In that case, the @name convention likely would be helpful to readers.
> Also, while we're at it, replies that say no more than "I agree" or "I disagree" are generally frowned on here, since they're almost completely contentless and don't contribute to the discussion.
That's certainly true in the general case, when you have a random third party chiming in with his or her agreement.
In this case, though, the "I agree" was a useful clarification: It signaled, to someone who had responded to me with what could be interpreted as a challenge, that we were on the same page.
> Right now that's indeed true. If later on there were to be
> a lot of intervening comments, it'd be more difficult to
> tell immediately who the response was directed to.
Not really. Making relationships between messages clear is kind of the point of tree-structured comments.
It is the point, but it doesn't always work. I have had to use my mouse to record the current level of indentation and then scroll up to find the parent post on some sites.
But you do remember who said what without scrolling, even if it is 3 screens up? (do you even care WHO said it at all or just what was said?)
Also "use my mouse to record the level of indention" is wrong. It is perfectly visual.
"On some sites" - maybe, but not on HN. And we're discussing (on HN) a comment made on HN.
To me, your argument makes no sense and looks like a rationalization of "damn it, I'm used to seeing this style, and I'm going to find an excuse to use it on HN whether it makes sense or not"
When the leaves in the tree move around (or disappear) based on points/scoring/etc, it's still harder to parse than something like slashdot where the positions don't change.
I teach contract drafting to third-year law students. It's hard work to take a complex if-then-else statement and render it in plain English.
Is there a reason it needs to be in (harder to write and harder to understand) "plain English" rather than a "complex" series of if-then-else statements? Even dumb computers can understand if-then-else statements.
Or is the "plain English" more valuable because it leaves things open to interpretation after the fact?
I draft contracts for a living (IAAL). The goal is always to draft a contract so that any reasonably competent judge or juror could understand the parties' intent. A lot of lawyers (most?) are terrible at this. They say things like "in the event that" instead of "if". They pepper their sentences with meaningless crap like "any and all" or "unless the parties otherwise agree" or "notwithstanding anything to the contrary elsewhere in this agreement" – all of which are utterly superfluous.
The problem is rarely that the lawyer is invoking legalistic concepts. Sure, you might find a few references to statutory laws here and there in a commercial contract, but 99% of a typical commercial contract should be a simple statement of what the parties expect from each other.
Also, non-lawyers tend to get confused by concepts like indemnities, warranties, and limits on liability. These things are dead simple in reality, but lawyers have a nasty habit of dressing them up in coded language. The emperor has no clothes. There are a few places where "magic words" are required by law, esp. around intellectual property rights, disclaimer of seller's warranties, etc. These are the exception, not the rule.
It can get very difficult to clearly express business terms, but it's JUST LIKE WRITING CODE! Case statements, if-then-else, etc. If more lawyers approached contracts like code, contracts would be better. The problem is that contracts only have to "parse" in court. Runtime for contracts is a breakdown in the relationship, and no one believes that the relationship will break down until it's too late. Those of us who approach the contract as something that needs to parse before the shit hits the fan have a different problem: everyone thinks we're overdoing it because they refuse to consider the downside potential.
I could go on forever about this topic.
Since I said IAAL, I must say this is informational only, isn't legal advice, and I don't represent the reader as their lawyer.
Meta note: It's not clear that your last name is Terretta but that's what I'm assuming. Also, saying "the email system most of us use" on your profile is really confusing.
> mapping out "given this scenario, x, y and z happen".
I've used scenario tables in some contracts. Each row is a scenario. For each scenario, there are columns for Plan A, Plan B, and Plan C. (Some column entries for a given scenario might be blank.)
Having a contract validation test would be a worthy exercise for the party who didn't write the contract.
This sounds like a great service opportunity for startup/employee contract lawyers... if contracts are like code, then a parser (or maybe legal code pretty-printer) could easily allow a skilled professional to sift through code. Even easier if the contract is standard for a large company.
@thwarted, one of the things commonly taught in contract-drafting classes is to break down dense verbiage into (i) subparagraphs, or at the very least, (ii) numbered subdivisions -- like this sentence. See also the IF: ... THEN: ... example in my posting above.
Believe me, "plain English" is greatly desired by just about everyone, not least to head off later accusations of intentional obfuscation. But it takes time (which means legal fees), and to be honest, not everybody is good at it.
I guess my point is that that legalese "plain English" is harder to understand than if-then-else statements. And if it's harder to write to boot, then why bother? Even your example:
IF: It rains at least one inch today but not more than two inches; AND: It doesn't rain tomorrow; THEN: You will turn on the sprinkler system tomorrow; AND: You will not do so the day after.
is ambiguous and difficult to parse (I'm assuming you were using this an example not just for the caps and punctuation, but that this kind of ordering of statements is what is commonly used, even though it was a contrived example). At least two issues I see are:
- the terminology is based on today but requires knowledge about tomorrow.
This requires keeping more state to evaluate if the conditions are
being met for a longer time.
With this wording, it almost seems like it's setting me up to fail to
remember to turn on the sprinkler today.
This would be better worded as about today and having knowledge about
yesterday.
- The grouping of the last AND: isn't obvious as to if it's in the body
of the THEN: or an alternative/conjunction for the entire IF:
The intent would be a lot clearer as something like this (in some kind of mock-pseudo-code):
if ( (no rain-today) and
(rain-yesterday between 1 and 2 inches) and
(sprinker-not-on-yesterday)
) then {
you will turn on the sprinker
}
(at least, that's what I think your intent is, but I'm not quite sure since the goal is still somewhat impenetrable)
But even this could be better written with more abstraction, perhaps by defining what it means for the lawn to be sufficiently watered:
you will turn on the sprinker if (last time lawn received sufficient
watering was before yesterday)
sufficient watering is defined as ((sprinkler was on yesterday) or
(less than 2 inches of rain occurred yesterday))
(but, really, I'm not sure that matches your intent either).
A lot of the ambiguity in contracts today has to do with structure, and not so much content. This may seem counter-intuitive, but consider some examples:
1. Lawyers have a bad habit of using "inline definitions" in contracts. That means that in the middle of a long sentence, they'll throw in a parenthesis such as ("Defined Term"). Now, any coder will immediately see that the scope of the "variable" Defined Term is ambiguous without a clear statement of assignment or equivalence. This is a structural issue. The lawyer instead should have put in the contract's glossary: "Defined Term means..."
2. Lawyers tend to use "or" with imprecision. That's why you see many "and/or" in contracts. They either need to use better logic operators, or be precise about logical OR vs inclusive OR.
3. Lawyers get sloppy with timeframes. "Within 30 days of..." is a common formulation in a contract. Do you think the drafter means 30 days before or after? Probably not both. Stuff like this is just sloppy structurally.
4. Lawyers screw up grammar. Commas are really important. Say I list off three conditions: You will do X if (a) thing that might happen, (b) thing that might happen, and (c) thing that might happen with reference to some other thing. Notice the "with reference to some other thing" at the end? If that is preceded by a comma, some courts will apply it to all of (a) through (c). Otherwise, it might only apply to (c). Stuff like that happens all the time.
Now, sometimes ambiguity is OK, or even a good thing. Every question has its own time for an answer, and that time may not necessarily be in the contract. It's important to be pragmatic in a business setting.
Since I said IAAL above, I'm including the standard ethics disclaimer: this is informational only, not intended as legal advice, and I don't represent the reader as legal counsel.
Now, sometimes ambiguity is OK, or even a good thing. Every question has its own time for an answer, and that time may not necessarily be in the contract. It's important to be pragmatic in a business setting.
While I can appreciate being pragmatic in a business setting, I find this to be mildly offensive as someone who writes code that, if it isn't unambiguous and isn't explicit, will not do what I want or will crash. Wanting code to operate properly is pragmatic, otherwise you're just wasting your time. Why is leaving contracts ambiguous and open to interpretation pragmatic?
Now, I can see that it's not very pragmatic to quibble over wording/structure in a contract up front, that can just end up wasting time. This is tantamount to purposely writing pseudo-code into your .c file and expecting gcc to do something useful with it -- but programmers don't do that, (the good ones, perhaps those 10x more productive ones) try to write code the first time that the compiler will accept. It seems like it would be even more pragmatic, from a business standpoint, to be more precise in the wording and structure on the first pass and avoid (even the small) risk of there being debate over the interpretation later on. The only reason "being pragmatic" comes up is because it seems to be the norm to gloss over a bunch of stuff and purposely make it ambiguous (considering your 4 examples) rather than being, ahem, explicitly explicit.
I take your point, and it's definitely a fair one. Ideally, we would anticipate and iron out all disputes up front. In software development, that's exactly what we try to do!
In contracts, though, there are cases where a company will live with ambiguity because it has done an assessment of (1) the likelihood of a dispute, (2) its leverage vs the other party, and (3) its ability to prevail on the merits in the event of a dispute.
A contract is usually, although not always, a compromise between two or more parties with at least some divergent interests. In reaching a satisfactory compromise, sometimes you need to prioritize the parties' disagreements and move onward. That's why I mention the concession to ambiguity – because it just happens that way.
And guess what? There's a parallel in software development. Whether it's shipping dates, lack of resources, skills, whatever, software development is also often a compromise. We all know that stuff gets swept under the rug because it's an obscure edge case, or it only affects 0.x percent of the userbase, etc., etc.
My point and yours aren't mutually exclusive; I just wanted to acknowledge that sometimes reality intervenes and makes great things good enough.
@thwarted, it'd be great if we could use pseudo-code. (One of my colleagues once proposed using flow-charting.)
Unfortunately, many, many lawyers (and clients) are allergic to contract forms that don't look "traditional." I can say with great confidence that the typical reaction to a pseudo-code contract would be "WTF is this?"
So it's momentum and fear of change (which plays into a fear of no-one-will-need-a-lawyer-to-decode-this, perhaps). Makes sense, but obviously not ideal. What can we do to change this, if anything?
My take on the language was "Wait, what? That's a red flag." And I'm still not sure I agree. What is the point of vesting, and the various hoops to jump to get it, if it's obviated by a share re-purchase agreement?
Maybe people don't pay enough attention to this stuff, and maybe they should seek better advice. But it seems unethical to structure a contract to make it seem like you've got a right, without actually giving you the right.
I'd be curious about the corporate representations of just what "vesting" was, and wasn't, and whether the obfuscations could rise to the level of fraud.
@ianterrell, consider how often you've had to struggle to make sense of someone else's source code -- it's much the same with contract language. Seldom do lawyers go back and refactor their contract language for improved readability.
Sure, but I also don't ask lawyers to debug C++ for me.
In both cases we're talking about a highly specialized domain that takes, on average, years of training to be competent. And yet the engineer is expected to enter into a legal contract on equal footing with company lawyers?
There you've put your finger on it. That's why this is evil on Skype's part (or Silver Lake, or whoever); engineers - the "best and brightest" want to do engineering, and trust the business people to do business. If the business people figure it's just good business to screw the engineers over a barrel on the way to buying their yachts, the engineers are just plain SOL.
I will agree that the contracts are not incomprehensible. Honestly, if given that contract, I would have complained vociferously about the language, but I would have taken the time to parse it. (This is one reason I rarely sign contracts, I guess.) Of course, as a translator I regularly deal with the same kind of language but in German and Hungarian, so your mileage may vary.
"That's why this is evil on Skype's part (or Silver Lake, or whoever); engineers - the "best and brightest" want to do engineering, and trust the business people to do business."
If the parties involved really trusted each other, there'd be no need for a contract.
When there's serious money at stake you'd be naive (to put it in the kindest possible terms) to sign a contract that you didn't fully understand.
I can think of kinder possible terms: inexperienced, young, needing health insurance, broke, out-of-your-legal-depth, suggestible, susceptible to Kool-Aid.
There's a huge power disparity between a company and an individual. I suspect that there are many many cases where the individual got screwed for different reasons than naiveté.
Yes. Exactly. Naive in precisely the way that good technical people tend to be. Which is why it's just such a lucrative business model to screw them five ways from Sunday.
More specifically, I think it's probably more in the nature of technical people to imagine that if any screwing is going to happen, that the screwing will be to the benefit of the company, and thus to their own benefit as well. Whereas I think the business mentality can much more easily gloss over details like division of labor and cut straight to "make more money for me".
Your guess seems reasonable in general, given your experience, but if you read about the history of Kazaa and Skype, I bet you change your opinion.
Those guys are worldclass experts at ownership control, contracting, the whole nine yards. In fact, I believe there are still lawsuits ongoing in Australia just to find out who _owns_ the Kazaa network.(!)
I teach contract drafting to third-year law students. It's hard work to take a complex if-then-else concept and render it in plain English.[a]
And here's the rub: Few clients want to pay lawyers to spend extra time on readability -- "good enough" (whatever that means) is the goal.
2. [EDITED TO ADD THIS:] It's not unusual for a private company's employee stock plan to include a "call" option that gives the employer the right to repurchase employee-owned shares when the employee leaves the company.
That makes sense when you think about it -- if you're a private company, you don't want a lot of random ex-employees owning dribs and drabs of your shares, especially if you're worried about the 500-shareholder limit (under current law).
On the other hand, for a company with an upcoming exit to buy back the shares at the employee's cost, instead of at a good-faith estimate of the stock's then-current value -- well, that does indeed seem unusual.
(EDIT: Some documents like this provide that, IF: The company wants to do its buy-back EITHER: (i) after an exit is announced, OR: (ii) if an exit is announced within 30 days or so after the employee's departure; THEN: The employee is entitled to the exit pricing for the buy-back.)
3. Again, not to defend Skype, but conceivably they might not have had a choice about the buy-back price, at least not without jeopardizing some kind of favorable income-tax treatment.
If I had to guess, I'd venture that, X number of years ago, some overzealous junior lawyer decided to draft the relevant documents so as to put the company in the strongest position s/he could. Now that zealousness may be tying their hands. I stress that I'm speculating here.
* * *
[a] If you have occasion to write a complex if-then-else sentence, try using all-caps and punctuation like this: IF: It rains at least one inch today but not more than two inches; AND: It doesn't rain tomorrow; THEN: You will turn on the sprinkler system tomorrow; AND: You will not do so the day after.