4 ms·

Algorithms alone don't cross the threshold for copyrightability, and code which only implements those (specially non-creatively as seen here) is not copyrightab

Algorithms alone don't cross the threshold for copyrightability, and code which only implements those (specially non-creatively as seen here) is not copyrightable.

nl 4y ago
It's true that algorithms alone don't cross the threshold for copyrightability, but just decompiling copyright code and using that is extremely risky. The carve-outs for interoperability might be useful here though.
- ascagnel_ 4y ago
  On other hand, there are no carve-outs for DRM, so this could still run afoul of that if it supports DRM'd playback. Edit: this explicitly does not support FairPlay DRM'd playback, so the lack of DRM carve-outs shouldn't matter, as awful as the lack of carve-outs is.
saurik 4y ago
FWIW, on the "non-creatively" angle, this is almost certainly some really simple algorithm that only looks really complicated as this is a direct translation of the obfuscated binary, and so I'm not sure you can analyze it using so simple a framework. (Apple uses an obfuscation technique that converts functions into massive switch loops, threading a control variable through on which math is done to figure out the next block of code to switch-jump through; they then use a duality between the bitwise logic and algebraic rings to turn what might be one instruction into five instructions in a different order, and often broken up by the inverted looping. I believe--but am not sure, as most of my knowledge of this stuff is from trailblazing myself over the years... I wrote the first decompiler for .NET a couple decades ago and have done a lot of work in the iPhone jailbreaking ecosystem on static analysis and runtime modification--that the literature-searchable terms for these are "parameterized control flow flattening" and "mixed-boolean-arithmetic".) So like, in some sense, this is not at all how someone else who understands how the algorithm works would implement it: it isn't like "oh yeah, there's one semi-obvious way to do it, and I did it that way", and one might definitely argue this is "creative". (I've personally avoided ever just copying and redistributing--even in translated form--logic from Apple like this, and that's part of the reason. It might still be OK, due to some fair use -styled exemptions relating to software interoperability, but the only ones I explicitly know about are with relation to reverse engineering to obtain that interop, not the part where you directly copy the resulting logic instruction-by-instruction.)
- EMIRELADERO 4y ago
  > So like, in some sense, this is not at all how someone else who understands how the algorithm works would implement it: it isn't like "oh yeah, there's one semi-obvious way to do it, and I did it that way", and one might definitely argue this is "creative". But the resulting output is automatically produced by an obfuscator. There's no creative human involvement in the process itself of how the obfuscated code came to be. Hell, the Copyright Office wrote extensive articles on why AI art can't be copyrighted.
  - saurik 4y ago
    Would you thereby claim (fwiw, you might, and you might even be right about it: I'm just trying to understand if you have a boundary) that extracting the underlying binary code and embedding it in this program with an emulator--instead of laundering it through rewriting the assembly instruction-by-instruction in Python--would be fair game?
    - EMIRELADERO 4y ago
      If the binary code involved was only the machine code which dealt with the encryption algorithm itself and not any sort of functionality or sequence, then yes. Courts have placed the burden on the program's "structure, sequence and organization". If one were to take a small sample out of a copyrighted binary which only implemented functionality and had no remains of the creative process behind it, I'd wager they would be in the clear. That said, I feel like machine code copyrightability is questionable on its face. A packaged binary with resources and assets such as text would be, but the machine code itself is a more complicated issue. Admittedly this would jeopardize libraries, since they don't contain any expressive elements like interactive programs do.

Algorithms alone don't cross the threshold for copyrightability, and code which only implements those (specially non-creatively as seen here) is not copyrightable.

nl 4y ago

It's true that algorithms alone don't cross the threshold for copyrightability, but just decompiling copyright code and using that is extremely risky. The carve-outs for interoperability might be useful here though.

ascagnel_ 4y ago
On other hand, there are no carve-outs for DRM, so this could still run afoul of that if it supports DRM'd playback. Edit: this explicitly does not support FairPlay DRM'd playback, so the lack of DRM carve-outs shouldn't matter, as awful as the lack of carve-outs is.

saurik 4y ago

FWIW, on the "non-creatively" angle, this is almost certainly some really simple algorithm that only looks really complicated as this is a direct translation of the obfuscated binary, and so I'm not sure you can analyze it using so simple a framework. (Apple uses an obfuscation technique that converts functions into massive switch loops, threading a control variable through on which math is done to figure out the next block of code to switch-jump through; they then use a duality between the bitwise logic and algebraic rings to turn what might be one instruction into five instructions in a different order, and often broken up by the inverted looping. I believe--but am not sure, as most of my knowledge of this stuff is from trailblazing myself over the years... I wrote the first decompiler for .NET a couple decades ago and have done a lot of work in the iPhone jailbreaking ecosystem on static analysis and runtime modification--that the literature-searchable terms for these are "parameterized control flow flattening" and "mixed-boolean-arithmetic".) So like, in some sense, this is not at all how someone else who understands how the algorithm works would implement it: it isn't like "oh yeah, there's one semi-obvious way to do it, and I did it that way", and one might definitely argue this is "creative". (I've personally avoided ever just copying and redistributing--even in translated form--logic from Apple like this, and that's part of the reason. It might still be OK, due to some fair use -styled exemptions relating to software interoperability, but the only ones I explicitly know about are with relation to reverse engineering to obtain that interop, not the part where you directly copy the resulting logic instruction-by-instruction.)

EMIRELADERO 4y ago
> So like, in some sense, this is not at all how someone else who understands how the algorithm works would implement it: it isn't like "oh yeah, there's one semi-obvious way to do it, and I did it that way", and one might definitely argue this is "creative". But the resulting output is automatically produced by an obfuscator. There's no creative human involvement in the process itself of how the obfuscated code came to be. Hell, the Copyright Office wrote extensive articles on why AI art can't be copyrighted.
- saurik 4y ago
  Would you thereby claim (fwiw, you might, and you might even be right about it: I'm just trying to understand if you have a boundary) that extracting the underlying binary code and embedding it in this program with an emulator--instead of laundering it through rewriting the assembly instruction-by-instruction in Python--would be fair game?
  - EMIRELADERO 4y ago
    If the binary code involved was only the machine code which dealt with the encryption algorithm itself and not any sort of functionality or sequence, then yes. Courts have placed the burden on the program's "structure, sequence and organization". If one were to take a small sample out of a copyrighted binary which only implemented functionality and had no remains of the creative process behind it, I'd wager they would be in the clear. That said, I feel like machine code copyrightability is questionable on its face. A packaged binary with resources and assets such as text would be, but the machine code itself is a more complicated issue. Admittedly this would jeopardize libraries, since they don't contain any expressive elements like interactive programs do.