This is an issue GNU has faced, they recommend optimizing for different things:
> If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can’t write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the Unix version irrelevant and dissimilar to your results.
> For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in memory and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler). — https://www.gnu.org/prep/standards/standards.html#Reading-No...
In fact RMS had experience from his competition with Symbolics: http://www.gnu.org/gnu/rms-lisp.en.html#foot-6
> The Symbolics source code was available at MIT, where I was entitled to read it, and at first that's how I found out about their changes.
> But that meant I had to make a special effort to solve each problem differently, in order to avoid copying Symbolics code. After a while, I concluded it was better not to even look. That way I could write code in whatever way was best, without concern for what might be in Symbolics' code.
(of course, this applies more to larger utilities, inopinatus’ comment https://news.ycombinator.com/item?id=24955918 should come in handy for smaller code snippets)
This was a factor in Intel's case with NEC over the microcode of their 8086 clone, and the judge ruled in NEC's favour, finding that similarities dictated by functional constraints were (subjectively) not creative expressions i.e. copyright did not apply.⁽¹⁾
Note this relates to copyright, does not extinguish patents, and actually relying on this precedent may require bottomless legal resources.
⁽¹⁾ NEC v. Intel: Breaking New Ground in the Law of Copyright. Contreras, Handley, & Yang; Harvard Journal of Law & Technology vol. 3, page 213 (1990). http://jolt.law.harvard.edu/articles/pdf/v03/03HarvJLTech209...
1. A commit to plainly remove the functionality (or lines of code)
2. A developer would rewrite the code with a set of variables they cannot use, but I suppose they'd also code without the original implementation as reference.
Each individual developer's implementation should be different enough that it would be easy to tell that it was independent crafted, although something like this hasn't been tested in court (at least to my knowledge!)
If the developer who does the rewrite uses the original as a reference, it will be likely that enough of the structure will creep through that the project will be at legal risk.
If you give me a sequence of integers from 1 to 1000 (which is not a creative work and therefore not copyrightable), and I selectively delete some of the integers such that the differences between adjacent numbers contains a fun message in ASCII, and publish that sequence, the result is copyright because those particular deletions add a creative element.
But if I just deleted every alternate number in the sequence, that wouldn't be copyrightable because it's not creative. (Although you can imagine some scenario when doing so might be creative, it would need some reason why it was.)
Basically, if Dev B does a change that passes some threshold of creativity, then they have a claim. If they just go through and delete all the blank lines and reformat in a standard way, they probably don't.
In your example, I think it would depend on which 20 lines and whether they were trivial changes to figure out.
ETA: discussed here, with a more in-depth link: https://news.ycombinator.com/item?id=24051655
I've always heard about this possibility but I wonder how one would rewrite code, should the need arise. Wouldn't it be hard to do without effectively making a derivative work?
Suppose that you remove the code, reimplement it but end up with something that's extremely similar to the original (which is very likely since after all you're doing the same thing). Couldn't the original author argue that it's still their code? How do you prove that you did the work and just happened with the same code because that's just the most straightforward way to do it?
It seems like the only way to avoid the problem altogether would be to have some sort of clean room design:
- Dev A reads the code to be removed, writes a spec for the functionality.
- Dev A removes the code.
- Dev B takes the truncated code and the spec and implements the feature.
But that seems very painful to do cleanly, in particular one could argue that B should be a third party who is not intimately familiar with the codebase, otherwise it could be argued that they knew the previous code.