8

I was considering porting some code into a new language. I got as far as opening the file and seeing the header which referred to some licensing situations that I am not comfortable with (a crayon license).

Several people have written documentation for this code, summarizing what it does. When they made their own ports (in ignorance of the licensing situation). Thus those docs are almost certainly written by people who have seen the code.

The Wikipedia article Clean room design says:

Typically, a clean-room design is done by having someone examine the system to be re-implemented and having this person write a specification. This specification is then reviewed by a lawyer to ensure that no copyrighted material is included. The specification is then implemented by a team with no connection to the original examiners.

So in this case the docs written by prior ports are the specification. I assert that for this particular case the docs can clearly not contain copyright material (because they only refer what the existing code does, not how it does it), so the lawyer step can be skipped, Which thus leaves me as the person re-implementing the specification.

  • 3
    I think the answer is going to boil down to: "IANAL, but it is practically impossible for a single person without an IP lawyer to have a sufficiently documented cleanroom process that would stand-up to serious (i.e. well funded) scrutiny in a courtroom. The 'best effort' clean-room process you describe would likely satisfy anyone willing to accept that you are acting in good faith. We can't know for sure without it being taken to court." – Lyndon White Nov 16 '17 at 4:25
  • But if you do the lawyer bit, and find a problem. Then do you then need to find a new programmer? – ctrl-alt-delor Nov 19 '17 at 17:57
6
+50

A clean room design is a preventative defence strategy in anticipation of copyright infringement claims. The idea is that a new creative work cannot infringe on the copyright of an earlier work if the new work's authors did not view the earlier work. A clean room design process implements this isolation by having different people handle reverse-engineering of the earlier work and creating the new work, with the two groups only communicating via a spec that can be more easily reviewed for non-infringement. If the two works have any similarities that would otherwise look like infringement, this process demonstrates that those similarities might merely be a consequence of the nature of the problem, and not a copied creative expression.

Because it is a preventative defence strategy, the value of clean room design manifests itself only when someone claims infringement against you. If that is unlikely to ever happen, you might feel comfortable with a bit of risk without taking further steps to mitigate it. Note that even with a clean room process, you can never entirely eliminate the risk of being sued for infringement and the risk of losing such a trial.

If you already have some kind of specification then sure, you can work from that. However, your claim that documentation of the earlier work may represent a non-infringing specification for the earlier work is highly dubious:

Several people have written documentation for this code, summarizing what it does. […] So in this case the docs written by prior ports are the specification. I assert that for this particular case the docs can clearly not contain copyright material (because they only refer what the existing code does, not how it does it), so the lawyer step can be skipped

The first problem is that there is a potential chain of infringement here. From the earlier work other (potentially infringing) ports were written, from which (potentially still infringing) documentation was created, on which you would base your reimplementation. It is entirely feasible that the other ports are not infringing, but basing your work on other ports does not necessarily isolate you from infringing the earlier work.

The second problem is that you argue that documentation of a software system cannot infringe on the copyright of that software system itself. However, copyright doesn't just protect implementation details. It protects creative expression, which may also manifest itself in the design of the software system, for example in user interfaces or the structure and organization (and naming) of APIs. If those are covered by the documentation, then reimplementing the documented design may very well infringe. Documentation is often more like a design document than a specification. And in any case, documentations, design documents, and specifications can all be creative works and therefore subject to copyright.

As a third point, you suggest that this were “clearly” non-infringing and therefore “the lawyer step can be skipped”. This misses the point of a clean-room process, which is to reduce as far as possible your risk of getting your newer work ruled as infringing. Getting your your process and various documents within that process review by legal experts is a core part of that. Clean-room reimplementation isn't a cargo-cult dance to please the copyright gods, but a legal strategy.

So I think it is difficult to implement a clean-room design on your own, and unlikely that your proposed process would stand up to scrutiny. This does not mean that you cannot reimplement the earlier work, or that you should ignore all practices of a clean room process. If you believe you can reimplement the earlier work without infringement then you can do that in good faith with or without a clean room process. But you may still value the future ability to testify before a court that you didn't look at the earlier work's source code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.