4 ms·

This is a frighteningly naive article. Consider the following extract: "There are at least three reasons to exclude software from patentability. First, softwar

This is a frighteningly naive article. Consider the following extract: "There are at least three reasons to exclude software from patentability. First, software development is an individual, creative activity, more akin to writing a novel than designing a jet engine...Second, software patents are especially prone to litigation...Finally, software patents are unnecessary because software is already eligible for copyright protection...As long as programmers write their own code from scratch, they can be confident they aren't infringing others' copyrights." The idea that software development is the sole province of the lone inventor is both wrong and irrelevant. The reason that our constitution facilitated patents was nothing to do with how many people invented something but rather with encouraging disclosure of the result. If we stipulate that software patents are frequently violated...so what? Without further analysis of why or whether specific improvements to the system would be helpful this is a dangling factoid - no more. Finally, the idea that copyright provides any kind of protection for software is so ludicrous the writer's naivety is laid bare. Copyright protects only the expression of an idea. In the case of a work of art such as a novel or painting the expression is critical to the work and copyright is a valuable protection. But if a programmer sits with original source code before him and rewrites it in another language thereby benefiting enormously from the original work but changing the expression completely they may indeed be programmers writing "their own code" but it certainly isn't "from scratch", and whilst he is right that "they can be confident they aren't infringing others" it is blindingly obvious that they have copied. Copyright is worthless if the expression doesn't matter and all that matters is functional equivalence. And guess what, users don't give a rat's ass how a program is expressed so long as it works.

binarybits 15y ago
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

binarybits 15y ago

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