5 ms·

Thanks for reading my article, and for sharing your perspective on it. However, I don't think you understand how copyright law applies to computer software. Tra

Thanks for reading my article, and for sharing your perspective on it. However, I don't think you understand how copyright law applies to computer software. Translating a computer program line-for-line to another programming language doesn't avoid liability for copyright infringement. If it's "blindlingly obvious" that a copy was made, a court is going to say infringement has occurred. I recommend reading about clean room reverse engineering. That's what you have to do to copy software without infringing its copyright. It's doable, but in most cases it'll be more, not less, work than writing your own software from scratch.

ScottBurson 15y ago
It's true (AFAIK; IANAL) that if you are reading someone's source code and writing your own based closely on theirs, you may well still be infringing their copyright. But the parent has an valid point nonetheless. If you do a clean room reimplementation of a program, then you are off the hook as far as copyright goes. Yet the user may not be able to tell the difference. In short, the user cares about the functionality of the program, not its expression (the source code). I think that's a valid argument that copyright protection is not entirely sufficient for software, and that patents could have a useful role to play. Personally, I think the problem with software patents today is that the obviousness bar is far too low -- we're patenting problems, not solutions. See my comments elsewhere on this page.
- binarybits 15y ago
  But clean-room engineering is almost always slower than writing the software from scratch. Which, AFAICT, is what most companies actually do except in the rare case where they need to achieve interoperability with an existing product (like the early PC clones where bug-compatibility with the IBM PC was essential). Right?
  - ScottBurson 15y ago
    I don't know if it's slower or not. It takes a certain amount of time to develop a functional spec; you have a head start if you have a working example in front of you. I think the main reason you don't see more clean-room reimplementations is simply, as you say, that level of compatibility is rarely necessary -- indeed, it's often considered undesirable, even by the users.
  - petegrif 15y ago
    That doesn't make any sense. It is the same as writing the software from scratch. The only difference is that the behavior of the original software which is being copied is effectively the spec.
petegrif 15y ago
I am afraid that it is you who evidently does not understand my point. I am not suggesting that some imbecile may transcribe in a manner to blindingly obvious that they may run into trouble. What I am suggesting is that access to the code for anyone with an IQ over 50 is a HUGE help in building your own version and that this assistance is not inhibited by copyright. I am extremely familiar with clean room reverse engineering. You are absolutely mistaken if you believe that 'That's what you have to do to copy software without infringing its copyright.' Reverse engineering actually has a rather different history. Given a device, say a chip, take the inputs and outputs of said device which defines the machine's behavior. Now design and build a machine which reproduces such a mapping. This practice was frequently associated with 'clean room' protocols. The key point is that the team had absolutely NO access to the source code. And because such a clean room team would never hire anyone who had previously had such access they could be confidently said to have reverse engineered the behavior from the APIs alone. This is a VERY different situation.

ScottBurson 15y ago

It's true (AFAIK; IANAL) that if you are reading someone's source code and writing your own based closely on theirs, you may well still be infringing their copyright. But the parent has an valid point nonetheless. If you do a clean room reimplementation of a program, then you are off the hook as far as copyright goes. Yet the user may not be able to tell the difference. In short, the user cares about the functionality of the program, not its expression (the source code). I think that's a valid argument that copyright protection is not entirely sufficient for software, and that patents could have a useful role to play. Personally, I think the problem with software patents today is that the obviousness bar is far too low -- we're patenting problems, not solutions. See my comments elsewhere on this page.

binarybits 15y ago
But clean-room engineering is almost always slower than writing the software from scratch. Which, AFAICT, is what most companies actually do except in the rare case where they need to achieve interoperability with an existing product (like the early PC clones where bug-compatibility with the IBM PC was essential). Right?
- ScottBurson 15y ago
  I don't know if it's slower or not. It takes a certain amount of time to develop a functional spec; you have a head start if you have a working example in front of you. I think the main reason you don't see more clean-room reimplementations is simply, as you say, that level of compatibility is rarely necessary -- indeed, it's often considered undesirable, even by the users.
- petegrif 15y ago
  That doesn't make any sense. It is the same as writing the software from scratch. The only difference is that the behavior of the original software which is being copied is effectively the spec.

petegrif 15y ago

I am afraid that it is you who evidently does not understand my point. I am not suggesting that some imbecile may transcribe in a manner to blindingly obvious that they may run into trouble. What I am suggesting is that access to the code for anyone with an IQ over 50 is a HUGE help in building your own version and that this assistance is not inhibited by copyright. I am extremely familiar with clean room reverse engineering. You are absolutely mistaken if you believe that 'That's what you have to do to copy software without infringing its copyright.' Reverse engineering actually has a rather different history. Given a device, say a chip, take the inputs and outputs of said device which defines the machine's behavior. Now design and build a machine which reproduces such a mapping. This practice was frequently associated with 'clean room' protocols. The key point is that the team had absolutely NO access to the source code. And because such a clean room team would never hire anyone who had previously had such access they could be confidently said to have reverse engineered the behavior from the APIs alone. This is a VERY different situation.