Hacker News new | past | comments | ask | show | jobs | submit login

Not that you're under any obligation to suffer the peanut gallery, but I'm curious as to how it is that Micro Star v. FormGen (which I assume is your Duke Nukem reference) obviously applies more readily here than Galoob v. Nintendo and Sega v. Accolade. As far as I can tell, the key distinctions are in how permanent the derivative works are and to what extent the erstwhile infringement is forced by the platform owner as a condition of interoperability, which seem like they're debatable questions for third-party client apps.

Granted, maybe the DMCA makes these distinctions practically moot because a service can get away with just applying arbitrary restrictions via a "technological measure" now.




First, as a point of amusement - last i looked, companies were still suing people over duke nukem decades later: https://www.scribd.com/doc/208676148/GEARBOX-SOFTWARE-v-3D-R...

(too lazy to look up the resolution, but thought you might find it amusing)

So this is a totally reasonable question/debate to have.

I'll mix practical and academic views, but happy to discuss more of one or the other in detail.

The first answer I can give you is single-purpose apps/things have faired quite poorly in the copyright realm, any principled caselaw/etc aside. It just turns out to be really hard to convince a judge/jury (to the degree there are any fact specific questions) that an app you made with a specific purpose of displaying someone else's content, whose entire value is in displaying that content, is not a derived work of that content. It fits fairly squarely in the definition: "A “derivative work” is a work based upon one or more preexisting works, .... [in] any other form in which a work may be recast".

But even to the degree it doesn't end up a derivative work, it almost certainly ends up a distribution or reproduction or public performance the other work. So as a defense attorney trying to defend it, you have a pretty hard non-infringement argument simply because you have to simultaneously argue "it's not a derivative work, it's not a distribution, it's not a reproduction, it's not a public performance"

The line does get fuzzy somewhere, obviously - but one thing to keep in mind on that front is that derivative works are not like a single-parent-only structure. Something can be a derivative work of multiple works simultaneously :) They usually are. This app is a derivative work of apple's libraries/frameworks, LLVM libraries or whatever it was compiled with, etc. I also expect you'd agree that if someone copied the HTML/etc of youtube's website into the app and shipped it directly, it would a derivative work of that too. That is a clear transformation/adaption of an existing work.

So what's the practical difference here? That it's dynamically loaded and then modified? that seems like a hard place to hang your hat :)

Now mind you, i've actually made this argument before in the LGPL context, so i have taken both sides before depending on the facts/complexities :)

As an example, if i make a book, and there is no text on the pages, instead each page says something like "for the text of this page, please see characters <x>-<y> of page <a>-<b> of book <c>-<d>, ISBN number <e>", is my book a derivative work of the works it references?

it has no text or content on its own, and is only incorporating by reference.

There are reasonable arguments on both sides.

All that said, the practical line that gets drawn, for better/worse, is often around usually who is the agent/controller, and what dependencies exist.

IE it usually end up like this:

Me loading HN in a normal web browser - i'm creating a derivative work of the HN site in my browser, on my display. The web browser, shipped alone, not a derivative work of HN.

Me using an HN app that downloaded all of HN and updates it once a week on its own - the app is a derivative work of HN, and it's creative derivative works of the content on a regular basis. i'm using/ browsing these derivative works.

Here we are somewhat in the middle, but given the entire point of the app, who is doing the loading/modification, and the actual modification of content/styling, i think it falls a lot more on the latter side than the former.

At least for derivative works.

These days, to you other point, it rarely gets to the question of derivative works at all due to TOS/DMCA enforcement. You don't have a right to access the content at all except to the degree you are licensed to, app or not. Rather than argue about derivation, they'll just sue you for unauthorized reproduction or distribution, since that is more clear.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: