Hacker News Reader

Comment by newjersey | Hacker News Reader

> If you go the route of using an (A)GPL core, make sure all 3rd party contributions are made under the terms of your CLA, or otherwise reject them.

If someone goes down this route, does the rejection have to be automatic? Does looking at a pull request without a CLA "taint" me in a way that I cannot implement it again? I am asking partly because I am curious and partly because I remember Drew DeVault (sircmpwn) used to have a big scary warning saying if I have looked at the official minecraft code, I should not contribute to truecraft (now archived I believe).

These are things I never worry about at work. I can look at stack overflow and copy x.filter(x => x.blabla...) and change the bla bla until my javascript works (I don't use filter every day so it is difficult to remember this syntax in my head).

Thank you in advance.

View on HN

Your comment intrigued me so I did a slight bit of digging.

> I remember Drew DeVault (sircmpwn) used to have a big scary warning saying if I have looked at the official minecraft code, I should not contribute to truecraft (now archived I believe).

The repository is indeed archived, but is still available on GitHub. It was changed in 2015 [0]. The older notice is as you recall:

> Pull requests will be rejected from authors who have read any decompiled official Minecraft code.

The current notice [1] adds some other ways the formerly rejected developers could get involved:

> If you are a developer, you have two paths. If you have not read the Minecraft source code, you are what we call a "clean dev", and you should stay that way. If you have read the source code, you are what we call a "dirty dev", and the way you can contribute is different. If you are a clean dev, you're welcome to contribute to this repository by adding features and functionality from Minecraft Beta 1.7.3, fixing bugs, refactoring, etc - the usual. Send pull requests with your work.

> If you are a dirty dev, you are more limited in how you can help. You can work on projects that are related to TrueCraft, but not on TrueCraft itself. Direct contributions that you can participate in includes the website and the artwork. You can also work on things like helping to build a community by spreading the word, participating in IRC or the subreddit, etc. You may also work on reverse engineering Minecraft to provide documentation for clean devs to use - see reverse engineering guidelines on the wiki for details on how you can do this. Under no circumstances may you ever share any code with a clean dev, decompiled or otherwise.

[0] https://github.com/ddevault/TrueCraft/commit/fcfd3886746fd1f...

[1] https://github.com/ddevault/TrueCraft#get-involved

> Does looking at a pull request without a CLA "taint" me in a way that I cannot implement it again?

I'm not a lawyer, but I'm under the impression that if someone wants to sue you for IP infringement over something like this, they can. Doesn't mean they'll win, but that can still cost you time and money defending yourself.

If you do look at the code, I'd make sure your implementation is far from how the contribution was implemented.

Here's what IP Watchdog says[1]:

> Copyrights cover the actual “expression” of an idea, but not the idea itself. In other words, it covers the lines of code but not the functions that they perform. The functions can be protected as trade secrets, or they can be patented. Sometimes it’s difficult for someone unfamiliar with IP law to separate the functionality from the expression in source code. This so-called “dichotomy between idea and expression” is particularly confusing with respect to software, and was addressed in the case Whelan Associates v. Jaslow Dental Laboratory and then again in Computer Associates v. Altai.

The article[1] then expounds upon literal and nonliteral copying and how it applies to source code.

[1] https://www.ipwatchdog.com/2017/02/07/facebook-oculus-zenima...

This didn't quite answer the gp's question.

There's an idea in some software communities that you can't "unsee" code. So if you've seen the code even once, you're "tainted" and you can't be permitted to work on the clean room implementation anymore. This tends to be used most often in projects attempting clean room implementations of proprietary software where they want to maintain clear provenance of the code.

The question is, is this based on actual case law or is it just an extreme form of paranoia?

It's not an extreme form of paranoia. I see it as a cost-analysis. It's cheaper to defend any copyright infringement criticism or lawsuit when using a pure clean room design.

We know that modified derived software can be sufficiently distinct from its base that the original copyright no longer applies. Quoting https://en.wikipedia.org/wiki/Clean_room_design :

> In NEC Corp. v Intel Corp. (1990), NEC sought declaratory judgment against Intel's charges that NEC's engineers simply copied the microcode of the 8086 processor in their NEC V20 clone. A US judge ruled that while the early, internal revisions of NEC's microcode were indeed a copyright violation, the later one, which actually went into NEC's product, although derived from the former, were sufficiently different from the Intel microcode it could be considered free of copyright violations.

However, such a lawsuit will be much harder and therefore more expensive to deal with.

It's much cheaper to make the argument that none of the developers had access to the original source or reversed-engineered design, so any similarities must be result of functional constraints or general knowledge.

Keep in mind that many of these "cleanroom" implementations are aiming to dodge patents, not just copyright

Clean room design cannot dodge patents.

If you have a patent then that protects your invention, even if I unknowingly and independently come up with the same invention.

Reply on news.ycombinator.com