Hacker News Reader

Comment by albertzeyer | Hacker News Reader

The code actually can produce every possible melody in MIDI. They simply have not stored every possible melody explicitly (uncompressed) on a hard drive (which is impossible, as the size is infinity).

However, if you interpret the program itself as a self-extracting compressed archive, they actually have stored every possible melody (in a compressed way).

So the question reduces to how much the type of compression matters here (is ZIP allowed? is TAR allowed? what about more sophisticated like PAQ? and what about this Rust code?). This is what I/we discussed here: https://news.ycombinator.com/item?id=22441328

View on HN

Gotta love programmers.

> So the question reduces to how much the type of compression matters here

If you compress, you can copyright the compressed bytes.

If you don't compress, you can copyright the uncompressed bytes.

As far as that copyright extending to derivations, e.g. decompressions, the answer indeed situation-dependent. For example, converting a copyrighted font from TTF to WOFF does not remove the copyright. But converting a copyrighted font from TTF to screen pixels to WOFF removes the copyright. (Sorry I don't have a reference; probably findable.)

The "self-extracting zip" derivation would probably fall into the latter category; that is, the copyright would not transfer.

---

But even if the copyright were maintained during your advanced decompression, one could argue that editing down to very specific portion of that extremely large body of work was a substantive/transformational derivation, which they could then copyright themselves.

Transformative works are very common in art. The most famous example is Duchamp simply adding a mustache to a print of da Vinci's Mona Lisa, and copyrighting that. [1]

[1] https://en.wikipedia.org/wiki/L.H.O.O.Q.

Is uncompression a derivation?

I updated my comment to make this more clear. tl;dr depends.

> But converting a copyrighted font from TTF to screen pixels to WOFF removes the copyright.

I hope nobody takes this as legal advice; I'm not a lawyer but I'm fairly certain it's wrong. The font would still be the same work.

Alright, you made me add references :)

It comes down to this: Typefaces/glyphs are not copyrightable. The font code that produces those glyphs is.

> Typefaces cannot be protected by copyright in the United States (Code of Federal Regulations, Ch 37, Sec. 202.1(e); Eltra Corp. vs. Ringer)...However, there is a distinction between a font and a typeface. The machine code used to display a stylized typeface (called a font) is protectable as copyright. [1]

In software, a similar "black-box" derivation process has happened many times, e.g. UNIX/GNU. Copyrights applies to software source code, but not software functionality.

Determining what is the "essential, creative work" in each case in a nuanced way is a matter for courts and armies of lawyers: Apple round corners, Oracle Java APIs, etc.

[1] https://en.wikipedia.org/wiki/Intellectual_property_protecti...

Presumably copyright law makes this allowance for type because the point of typefaces is to be reproduced.

That is in fact, the point of all digitized information, including recorded audio.

(But yes, I do agree that typefaces are exceptionally commonly distributed.)

Thanks for supporting your point :) I have to admit that the difference in copyrightability of fonts vs. typefaces is new to me.

Now at least the inane font-vs-typeface distinction made by modern designers has some practical distinction to it, albeit a legal one.

This is true of fonts, as per the copyright office's "Policy decision on copyrightability of digitized typefaces".

However the example here, and the situation with fonts seem different. It is the case that font data is viewed as utilitarian and uncopyrightable. So we have a copyrightable program, producing uncopyrightable data. The argument here seems that we have a copyrightable program producing copyrightable data.

> So the question reduces to how much the type of compression matters here

It doesn't matter at all. As 'patio11 correctly points elsewhere in the thread[0], this question boils down to the colour of the bits.

[0] - https://news.ycombinator.com/item?id=22441118

Here's the link to the original "What Colour are your bits?" blog post by Ansuz - very much worth reading

https://ansuz.sooke.bc.ca/entry/23

Every possible combination of 8 notes in 12 beats is not infinite. Assuming all quarter notes it's just (8^12)-(8-1)^12 = 54,878,189,535. If you factor in rhythmic variances, the number is much much larger, but still not infinite.

https://plus.maths.org/content/how-many-melodies-are-there

More correctly, it can produce every possible monophonic sequence of tones given infinite time, which in the article was further limited to monophonic 12-tone sequences across a single octave (any other limitations I missed?).

A melody contains more than a sequence of tones. The most heartless definition would at the very least include rhythm. For every sequence of tones they output, they only produce one out of hundreds of possible melodies for that sequence.

It is of course an interesting thought to consider the definition of decompression, but on the other hand, we should also limit the contributed idiocy to the bare minimum required to break the relevant idiotic rules.

Part of me wonders if the next step with this is some sort of DL model. I wonder if, trained on one set of melodies (defined in the intuitive sense) it would generate existing copyrighted melodies not in the training set.

By that logic, a program that simply counts up from 0 (with bignums, as long as the machine has enough memory), is actually a compressed form of every single piece of data or information that has ever, will ever or can ever be created.

Reply on news.ycombinator.com