4 ms·

Replying to your comment below. I am not missing your point. I am merely pointing out that your point is incorrect as a matter of law. Copyright does not cov

Replying to your comment below. I am not missing your point. I am merely pointing out that your point is incorrect as a matter of law. Copyright does not cover re-implementation. Copyright only covers copying. Your statement that IBM could sue company using a clean-room developed re-implementation of IMB's BIOS if IBM owned a copyright to their BIOS is incorrect as a matter of law.

dragonwriter 9y ago
> Copyright does not cover re-implementation. Copyright only covers copying. Coypright covers derivative works of copyright-protected works, as well as literal copies. If APIs are copyrightable, there is a very good case to be made that a reimplementation of an API implementation (not an API that serves a similar function, but an actual reimplementation) is a derivative work of the API itself.
- hcknwscommenter 9y ago
  An interesting argument. However, the Oracle Google case is not about derivative works. Google admitted to copying.
  - dragonwriter 9y ago
    > However, the Oracle Google case is not about derivative works. The Copyright Act, however, is; if APIs are protected by copyright, than making a derivative work of an API is an exclusive right of the copyright owner. Which is a key reason why there is widespread concern about the CAFCs ruling on API copyright. (OTOH, Google losing on fair use at the CAFC makes it more likely that the API copyright issue gets to the Supreme Court in this case rather than a later one, so it might be a good thing for resolving that concern.)
    - hcknwscommenter 9y ago
      Clean room reimplimentation is not considered a derivative work. Derivative works requires actually copying (and then derivatizing).
      - wtallis 9y ago
        > Derivative works requires actually copying No literal copying of text is required for something to be a derivative work. Transforming a work implementing an API into documentation describing the API would produce a derivative work of that API, if the API is protected by copyright. Transforming that documentation of the API into another implementation of that API would also produce another derived work of the API.
deong 9y ago
> Your statement that IBM could sue company using a clean-room developed re-implementation of IMB's BIOS if IBM owned a copyright to their BIOS is incorrect as a matter of law. To the extent that it's relevant here, that appears to be untrue. This hinges on the fact that with an API, you have to match it exactly, and there's no reasonable way to argue that someone could sit down and do a clean room implementation of the Java APIs that perfectly matched all 3000 classes and all the public interfaces of all those classes. You can do a clean room implementation of the Java Platform, but you can't do a clean room design of the Java APIs. The whole point you're trying to solve is to make something that's compatible with Java, and that requires knowing the Java APIs, i.e., it's not a clean room. If we extrapolate that back to IBM and clones, as long as the clone makers must come up with the same external API as the IBM BIOS, then this court would say that IBM absolutely could use copyright law to prohibit clones, because the clones would have to have copied the APIs -- not the code, but the names and types used in the APIs themselves, and IBM holds copyright to those names.
wtallis 9y ago
Clean-room reverse engineering produces an implementation that is not a derivative of the original implementation. But if the API itself is copyrightable as a separate work from the implementation, then you have to consider whether the API of the reverse engineered implementation is a derivative of the API of the original implementation. The answer to this question is rather obviously yes, since the reverse engineering process is all about separating the API from the implementation and copying only the former. Clean-room reverse engineering is only useful in a world where APIs aren't copyrightable.
- hcknwscommenter 9y ago
  > Clean-room reverse engineering is only useful in a world where APIs aren't copyrightable. I disagree. However, I am not aware of any caselaw on this point. It is an interesting logical twist you have added, but I fail to see how it must be that way in view of the fact that copyright explicitly allows clean-room type reverse engineering.
  - wtallis 9y ago
    > in view of the fact that copyright explicitly allows clean-room type reverse engineering. The legal status of reverse engineering is not at all clear-cut. There are many nuances depending on the circumstances, and much of it is determined by case law rather than statute. There's no clear basis for you to make claims about how this new class of copyright (on APIs) will interact with reverse engineering. However, it is much simpler to state that if APIs are a work subject to copyright, then it must be possible to make derivative works of APIs that are also subject to copyright absent any explicit exception or fair use right.
    - hcknwscommenter 9y ago
      Well of course it is possible to make derivatives of APIs that are also subject to copyright. My point is that it is also possible to make a clean room reimplimentation that is not a derivative work, which is much more valuable. Just don't copy is the lesson here.

dragonwriter 9y ago

> Copyright does not cover re-implementation. Copyright only covers copying. Coypright covers derivative works of copyright-protected works, as well as literal copies. If APIs are copyrightable, there is a very good case to be made that a reimplementation of an API implementation (not an API that serves a similar function, but an actual reimplementation) is a derivative work of the API itself.

hcknwscommenter 9y ago
An interesting argument. However, the Oracle Google case is not about derivative works. Google admitted to copying.
- dragonwriter 9y ago
  > However, the Oracle Google case is not about derivative works. The Copyright Act, however, is; if APIs are protected by copyright, than making a derivative work of an API is an exclusive right of the copyright owner. Which is a key reason why there is widespread concern about the CAFCs ruling on API copyright. (OTOH, Google losing on fair use at the CAFC makes it more likely that the API copyright issue gets to the Supreme Court in this case rather than a later one, so it might be a good thing for resolving that concern.)
  - hcknwscommenter 9y ago
    Clean room reimplimentation is not considered a derivative work. Derivative works requires actually copying (and then derivatizing).
    - wtallis 9y ago
      > Derivative works requires actually copying No literal copying of text is required for something to be a derivative work. Transforming a work implementing an API into documentation describing the API would produce a derivative work of that API, if the API is protected by copyright. Transforming that documentation of the API into another implementation of that API would also produce another derived work of the API.

deong 9y ago

> Your statement that IBM could sue company using a clean-room developed re-implementation of IMB's BIOS if IBM owned a copyright to their BIOS is incorrect as a matter of law. To the extent that it's relevant here, that appears to be untrue. This hinges on the fact that with an API, you have to match it exactly, and there's no reasonable way to argue that someone could sit down and do a clean room implementation of the Java APIs that perfectly matched all 3000 classes and all the public interfaces of all those classes. You can do a clean room implementation of the Java Platform, but you can't do a clean room design of the Java APIs. The whole point you're trying to solve is to make something that's compatible with Java, and that requires knowing the Java APIs, i.e., it's not a clean room. If we extrapolate that back to IBM and clones, as long as the clone makers must come up with the same external API as the IBM BIOS, then this court would say that IBM absolutely could use copyright law to prohibit clones, because the clones would have to have copied the APIs -- not the code, but the names and types used in the APIs themselves, and IBM holds copyright to those names.

wtallis 9y ago

Clean-room reverse engineering produces an implementation that is not a derivative of the original implementation. But if the API itself is copyrightable as a separate work from the implementation, then you have to consider whether the API of the reverse engineered implementation is a derivative of the API of the original implementation. The answer to this question is rather obviously yes, since the reverse engineering process is all about separating the API from the implementation and copying only the former. Clean-room reverse engineering is only useful in a world where APIs aren't copyrightable.

hcknwscommenter 9y ago
> Clean-room reverse engineering is only useful in a world where APIs aren't copyrightable. I disagree. However, I am not aware of any caselaw on this point. It is an interesting logical twist you have added, but I fail to see how it must be that way in view of the fact that copyright explicitly allows clean-room type reverse engineering.
- wtallis 9y ago
  > in view of the fact that copyright explicitly allows clean-room type reverse engineering. The legal status of reverse engineering is not at all clear-cut. There are many nuances depending on the circumstances, and much of it is determined by case law rather than statute. There's no clear basis for you to make claims about how this new class of copyright (on APIs) will interact with reverse engineering. However, it is much simpler to state that if APIs are a work subject to copyright, then it must be possible to make derivative works of APIs that are also subject to copyright absent any explicit exception or fair use right.
  - hcknwscommenter 9y ago
    Well of course it is possible to make derivatives of APIs that are also subject to copyright. My point is that it is also possible to make a clean room reimplimentation that is not a derivative work, which is much more valuable. Just don't copy is the lesson here.