7 ms·

Reverse engineering a file format is different from reimplementing an API.

• ummonk 8y ago
  In what way?
  • KingMachiavelli 8y ago
    The crux of re-implementing an API is that the name and structure of the replacement has to be the same otherwise it won't work as a drop in replacement. If I reverse engineer a file format I don't have to name any of my code the same as the original or structure it in the same way.
    • ummonk 8y ago
      You need to structure any files you read or write to the exact same way or they won't be compatible with the other software. File formats are directly analogous to APIs.
    • ndnxhs 8y ago
      A file format is just an api that gets saved to the drive. Many file formats are just json/XML files in a renamed zip
      • treis 8y ago
        Except that you don't have a copy of a file format in your code. The code you have reads and writes to the format and does not need to be a copy.
        • candiodari 8y ago
          True, but there's many parts that you do have to copy into your source code: * magic numbers at the start of the file format * all sorts of enums that you just have to know, names and numbers and the correspondence between them * names of data types and classes are often needed * there are often many "standard" things that will be in both the original source and the duplicate because it's the industry standard (things like bold text in any word format or parallel constraints in cad files). They will mostly match in all programs of the same time And that's just the beginning. You could make an argument that all of those fall under copyright. And they shouldn't. So it really isn't that far from an API.
          • treis 8y ago
            If you copyright all those things then you aren't copyrighting the file format. You're copyrighting a bunch of code you wrote to read/write the format. Which (virtually) everyone agrees is something subject to copyright.
            • monocasa 8y ago
              If you copyright the magic numbers and xml tag names, how can anyone write a competing implementation?
              • treis 8y ago
                You can't copyright something as simple as a number or tag names.
                • monocasa 8y ago
                  That's literally what this case is about, the tag names on functions. The appeals court already threw out one de mininis argument.
                  • treis 8y ago
                    The point is that file formats are qualitatively different than APIs. If I have a doc file that is: <doc> <author> ..... Then in my code I have a parse method: Def parse_doc(xml) self.Owner = Person.new(xml[:author]) .... End And a corresponding write method. My code is original and contains nothing written by whoever created the file format beyond short and simple tag names. It's much different than copying a class structure and method signatures.
                    • monocasa 8y ago
                      Other than the tags, the Harmony code was completely original too, with the exception of the nine line range check code that was the only literal copying Oracle could find.
        • int_19h 8y ago
          > Except that you don't have a copy of a file format in your code. Except you do in many cases - there are many serialization systems out there where you describe your structures as types, and they generate the serializers for you. Just look at protobuf as one example. Is a protobuf declaration an API? If not, how is it different from any other API that declares a bunch of structs?
          • treis 8y ago
            I haven't used protobuf so I might be mistaken here, but it's not necessary to use the same variable name. In other words, I can use date_of_birth and you can use birthdate so long as we both agree that the first item in the message is the date a person was born. So you can reverse engineer a protobuf message without creating a direct copy.
            • monocasa 8y ago
              Adding schema metadata to protobuf messages is a pretty common pattern.
        • yellowapple 8y ago
          I think that assessment would be stretching the definition of "file format". Neither the file nor the thing producing/consuming the file "have a copy of [the] format", since a file format is an abstract thing to which the file itself and producer/consumer adhere. The format of the file is not (last I checked) the thing that's copyrightable; rather, it's the specific producers and consumers which are. Same deal for an API; the API itself is not (supposed) to be copyrightable, while the producers and consumers are indeed copyrightable (as is the documentation).