Slashdot Mirror
Does Drawing on Experience Infringe on Other's IP?
Daniel Paull asks: "I recently asked one of our developers to draw up a design for a specific component. After a few hours he returns telling me that he'd solved a very similar problem a previous place of employment and that they had developed a "neat" solution. The developer then became concerned that a ground-up re-implementation of these design patterns and principals may infringe on the other companies intellectual property or breach some copyright laws. This developer is talented and experienced - that's why we hired him. The question is, at what point does 'drawing on experience' cross the line and invade others IP?"
It almost sounds like a reverse engineering of it, without the exact code base, its not an exact copy of it.
But it would have be carefully thought out.
You need to ensure that the previous company doesn't hold any patents on it. You also need to consider whether the employee may have signed a confidentiality agreement with the previous company. Finally, if the previous company is not a direct competitor it probably isn't going to concern them as much as if they are an arch rival. Similarly, if it isn't a core component of the product it probably won't concern them as much as if it was a key competitive advantage. Otherwise, I think as long as it is built from scratch (i.e. no code, design documents, etc. from previous company are used) and it is developed solely based on experience I'd think you would be safe.
when he knowingly violates a patent
A patent the only form of IP that's protected by law. Trade secrets are also protected implicitly, and usually explicitly in employment contracts. Even if it's not patented, using your former company's ideas may be breaking the rules of your contract with them, or even the law. YMMV.
This kind of question really requires Professional Legal Advice and may depend on the context, e.g. is he reimplementing something trivial like a command line argument parser or something non-trivial like highly optimized kernel code for a specific device? Anywhere as for my opinion, I Am Not A Lawyer (IANAL) but the kinds of IP that matter in this case are Copyright & Patents.
Copyright Issues: If his reimplementation of the solution from his former job is a cut & paste of old code to new then there probably most likely are issues since most corporations own copyright on code written by employees. Reimplementing the same strategies from memory should not affect copyright [unless he has a photographic memory].
Patent Issues: If the technology he worked on was patented by your employee's former employer then there will be licensing issues which depend on how he signed over the patent to his former employers.
There are also the Non-compete clauses in employment contracts which although do not strictly have anything to do with IP law can severly restrict what knowledge you can obtain from him and in severe cases may require you to fire him like in the CrossGain vs. Microsoft situation
most NDAs have a time limit (you may not compete with us for xx years). I believe a california Judge ruled that, for the software industry, anything beyond 6 months was excessive and unenforceable, due to the rapid advances in the industry.
If it's been 2 years or more, it's fair game. If it's been less, get someone else to do it.
Which is fine to a point, but what's wrong with drawing on the collective experience of /. to figure out what to do?
because he asked a legal question and I think the most used phrase in this thread has been "IANAL".
All you have to do is compare the public opinions of the States' lawyers with those of the Microsoft lawyers and you will realize that you can just punt.
/. even if the poster is a lawyer.
But, it is not too hard to understand that some things you must just stay away from. Examples are "copying large quantities of code or designs". Now to some that may seem obvious.
But, I recall hearing from engineers in the late 70's that if you look at the schematic of the original Apple what you see is the schematic of the HP 2640A Communications Terminal (which sported an Intel 8008 chip). And, yes, had RAM and a display as well as communications. Now, who was that fellow, anyway?
The point here is that an awlful amount of work has been shared around Silicon Valley for years. Some of was legit. And, some was not.
But, in any particular case, if you are in doubt, by all means contact your legal counsel and get some guidance. Failure to be upfront with your own lawyers is only likely to get yourself and your company in hot water.
What ever you do, do not rely upon general information or discussions you may hear on
NexuSys - Linux support by the best
I had a lawyer explain his opinion of the laws...which was pretty much similar to your thoughts...you can't copy the code, but you can take your experience. I was careful to make sure he noted this view in the NDA I was being forced to sign.
BTW, I had another a contract that specified that I could not accept work from a potential client of the company within three years of the two month contract. I asked the lawyer if he could name a single company that was not a "potential client." He could not; so I refused to sign the legal documents.
While an independently developed "clean room" implementation of an "idea" specified in his description cannot infringe a copyright, it could still impinge on trade secrets or breach of a fiduciary duty. Of course, independent implementation via clean room will never be a defense against patent infringement.
This is not to say that the hypothetical, in every case, precludes re-solving problems previously solved -- nothing of the kind. The hypo is too broadly stated, and the devil is in the details. Short answer to the question: Ordinarily, drawing on previous experience is ok, except when it isn't. (Hey, I'm a lawyer, absent the meaningful details, which could swing a result either way, that is the best we can do.)
However, where a trade secret claim is available with respect to the architecture for the previous "neat" solution, the clean room approach will fail. That trick works only for copyrights.
There is a brief description of cleanroom developing here and a million other places. But, the point is that it is not enough to recreat a system without looking at the code when you recreate it. The coders also have to be clean. They can't have seen the code. They have to recreate the system from the specifications. Sometimes these are specifications created by a "dirty" team. Sometimes they are already public. But, clean room engineering doesn't save energy on development and isn't what they are trying to do here. It is just a way of building a compatible product without infringing. The issue here is how many of your skills can you take with you as a "right to work" issue versus how much does the company keep as a property right. The standards I have seen come down to how important the code is to the company. If this insight is the key to the business model for a product, you can't take it. If it is ancillary, you probably can. But, ask your lawyers. Make it their issue now, rather than later.
In general all IP protection mechanisms (copyright, patents, trademarks) are supposed to cover implementations, not ideas.
Not true, at least in the United States or Europe. Patents are--and always have been--allowed to cover a process, art, or method. See e.g. Title 35, part II, chapter 10 of the US Code, "Patentability of Inventions" for the legislative authority to cover this. This wording is basically unchanged for over a century--though in 1952 wording was added forbidding patents on things that are "obvious to a skilled practitioner of the art" (the courts had been enforcing a similar prohibition since a Court ruling in 1850). Going back into history, European governments routinely granted method patents since at least the mid 1500s.
_Business_ method patents are new, but patenting ideas and methods rather than implementations isn't anything new.
Copyright and trademark, on the other hand, are supposed to cover particular expressions of an idea (and with trademarks that expression is limited to how it is used in a particular field).
Sumner
rage, rage against the dying of the light
If the prior work wasn't patented, and was not a closely held secret, then reimplementation seems fair. In my career (logic/chip design), I've done many things I like to think were clever, but they wouldn't be novel enough to patent - instead they should be considered good practices. I don't see anything wrong with recycling lessons learned.
Of course, "trade secrets" seems like a vague term to me - in the logic/chip business, patents are the main form of IP, but I expect there is a whole body of precedents in that regard.
However, main point ("ideas can not be patented") still stands. Idea needs to be developed to patentable things (which includes processes, arts and methods).
You are really muddying the waters here. Ideas certainly can be and have been patented. It is only "abstract ideas" that can't be patented.
From the USPTO site:
A patent cannot be obtained upon a mere idea or suggestion. The patent is granted upon the new machine, manufacture, etc., as has been said, and not upon the idea or suggestion of the new machine. A complete description of the actual machine or other subject matter for which a patent is sought is required.
Note the key phrase "complete description". You simply need to provide sufficient detail describing the idea. It is clearly not the case that "ideas can not be patented". In fact, I would state that "every patent describes an idea".
As an example from the software patent side, I can't just patent the abstract idea of "unbreakable encryption", but if I have an idea for a particular algorithm, and I can explain it sufficiently, then I certainly can apply for a patent. Note that the algorithm doesn't have to be practical with today's technology, and I don't have to provide an implementation, just a complete description.
The same goes for other patents. There are thousands of patents on devices that have never been built and proceses that have never been implemented . I would suspect the same is true of software patents.
For what it's worth, I'm against most software patents simply because they don't pass my interpretation of what's "obvious to a skilled practitioner in the field". I also believe quite strongly in the idea that "knowledge should be free".
"Scientists prove we were never here."
-- Devo