2 ms·
Here are my thoughts. Let's assume the poster's former employer is trying to sue them into submission. That's a plausible claim as that kind of thing does happ
by cletus 11y ago
Here are my thoughts.
Let's assume the poster's former employer is trying to sue them into submission. That's a plausible claim as that kind of thing does happen.
Well, if true, that strategy is clearly working.
Why do I say this? Because no competent lawyer would let their client post something like this. It can only hurt you. Make any statement of fact that helps the plaintiff and they'll use it against you. Make a statement that doesn't help them? Well they were going to dispute that anyway so who cares?
So I can only conclude the Shred Video doesn't have competent legal representation and thus is probably going to be or are being bled dry by litigation unless they can find a source of funding, which, as noted, is more difficult with a lawsuit hanging over your head.
One thing I've consistently done is when I've left a job I've never taken any hardware with me nor a single line of source code. It can only hurt you. Obviously I don't know if that were a factor here but the poster has stipulated one of the founders did have a Smule laptop with company source code on it. Woops.
Consider this a lesson learned: either don't offer to help your former employer when you're working on something else or get them to release any current or future claims to your company or IP before you do. Also, you probably want to get paid upfront. A separate contract should govern such work and it should state clearly that the former employee has access to the source code at the employer's request and the employer relinquishes any claims resulting from that source code. Employer might not go for that. Fine. Walk away.
As Paul Sutter stated, this is an emotional appeal. I too suspect there was fault on both sides here without knowing the facts.
One question I have is: when did the founders start working on what became their startup? That matters. If there's a crossover with their employment then that's potentially a problem.
In California the law is pretty generous with side projects so this might actually be OK but here's the thing...
If the plaintiff through discovery finds source code commits to the project that occurred before they finished working for Smule then even with Californian law they have a problem because the plaintiff has now established:
1. The founders started working on this before terminating employment; and
2. They claimed otherwise.
It's (2) that gets you into trouble because it hurts your credibility when making any other claims.
This is why any competent lawyer will not allow you to make such public statements. Let me repeat: it can only hurt you.
The founders are making the mistake of trying to win this in the court of public opinion. That doesn't matter for this particular plaintiff I suspect. So they've just given him a bunch of ammunition as every statement will be carefully parsed and fact-checked and any inconsistency will be used against them. Even if a statement is ambiguous and was intended one way but can be interpreted another (that can be disproven), it's a problem.
I had a threat of a lawsuit once that basically amounted to someone using the threat of it to get out of paying a fairly substantial amount of money. Not life-changing but certainly annoying. The lawyer I spoke to at the time (side note: free legal consultations where you shop around a potential case can really help) gave me this advice:
"Don't respond (to emails, phone calls, etc)."
If they file suit, they file suit and you can deal with it then. Until then don't give them any ammunition.
Other facts that may matter here are any patents Smule has or are pending and if the founders are listed as inventors. Something like "algorithmically annotating a video to music" is the sought of nonsense patent the USPTO might grant and may later be invalidated as being overly broad and generic but again that puts you in the position of having to either show non-violation or to invalidate the patent. Neither is quick or cheap.