Possible copyright compliance issues

[lun-4]

Patchcord requests original discord assets from canary.discord.com, as seen in the litecord.blueprints.static module defined here: https://github.com/dolfies/patchcord/blob/ec53058f9c8feb5739e46850609990057fb96be1/litecord/blueprints/static.py#L242

As the material provided in that URL is, by default, copyrighted to Discord, modifying/patching it in code means that Patchcord is serving derivative works from Discord's own code. Because of this mechanism, this leaves that whole section of code up into legal hot water on if this is "fair use" under current copyright law (I am not a lawyer and this is not legal advice. I am communicating a possible issue that Discord will, most likely, not see under a good light).

[dolfies]

👋 Thanks for the concern! Patchcord does indeed patch and serve Discord's code on-the-fly, but I believe it still falls under fair use. For example, the Wayback Machine patches files viewed through it to redirect all URLs back to it. Either way, Discord cannot DMCA the repository in good faith, as no Discord code is hosted on it.

Even in the worst-case scenario, Patchcord is only really a single private instance we use for datamining and old build exploration. This effectively makes any copyright issues a non-issue :). Selfhosters are free to fork the repo and remove the client serving if they're worried about copyright.

[lun-4]

IANAL so I can't really assert if what the Wayback Machine does would work because it doesn't do that on JS (I can be mistaken on this), and Discord could create the argument that since you are modifying JS instead of HTML/CSS it's worse, but they would need a real DMCA or a C&D to try to pull that off (and, to be honest, neither of us have the funding necessary to protect each other in court, so a C&D would shut us up pretty fast).

I expose this worry because this repository is public and clearly linked to the Litecord project, even if I'm not the maintainer of this fork, I still need to argue for the long-term project goals in a way that would give both of us enough shielding against Discord's legal arguments. Just the fact Litecord exists at all is a massive gray-area, and while I haven't received any threats, they always exist in the horizon, and decreasing risk is what I have to do so that I can continue my research.

Maybe that specific piece of code could be made into a separate service that you proxy_pass differently at the reverse proxy layer to prevent legal attacks of that caliber.

[dolfies]

IANAL so I can't really assert if what the Wayback Machine does would work because it doesn't do that on JS

It does actually, I ran into it when proxying from Wayback lol.

[lun-4]

It does actually, I ran into it when proxying from Wayback lol.

Apologies for the mistake, but that shouldn't invalidate the larger suggestions regarding project self-preservation. I don't enjoy the fact that I have to even worry about this in either of our projects, Asahi Linux's reverse-engineering policy shines some light on what I mean from a different perspective (as they're doing it on hardware, instead of an old client (which is still proprietary)):

“Clean-room” reverse engineering is often considered the gold standard to ensure good legal standing for a reverse engineering project. This involves having separate teams, one of which does the reverse engineering and writes documentation, and the other implements that documentation into the final product. This approach is not a legal requirement to ensure that the final product is free from copyright violations, nor does it absolutely guarantee such a result, but it is a fairly strong legal defense should copyright questions arise.

We recognize that a true textbook clean-room approach is not sustainable for most open source projects of this nature. Thus, we aim to ensure that Asahi Linux’s code and contributions are effectively equivalent to what a clean-room approach would produce, without mandating the overhead of a true clean-room process.

[dolfies]

I get what you're saying, but Discord does not have a good legal basis for going after either of the projects, and they know this. For example, Discord's known about Fosscord for ages now, which not only serves but also hosts the client, and they haven't done anything.

As Patchcord doesn't host any copyrighted Discord code, Discord cannot C&D or DMCA in good faith. Additionally, the principles of clean-room reverse engineering don't really apply here, as we only have access to client code, but we're reverse-engineering the API. If Discord wants to claim copyright violations from that aspect, they have to prove we had access to API code.

[Ashthetik]

I agree with Dolfies here, Discord hasn't a solid ground that can be a basis for a C&D or any other legal action since Patchcord doesn't deal harm, or any other issue to Discord or it's third party consumers. Having been subjected to a C&D in aligned with API mis-use of CleverBot. Discord's assets as depicted in their Branding Usage can be used without issue as long as used within guidelines (which is performed in Patchcord)

If it helps our usecase I can write up a formal review of the project disclosing how patchcord will be used.

[lun-4]

as we only have access to client code, but we're reverse-engineering the API.

This is a very good point, actually. I have asked some lawyers about the possible defenses of reverse-engineering but I feel I won't get much globally-useful information as it would be a cross-country case.

If it helps our usecase I can write up a formal review of the project disclosing how patchcord will be used.

I'm sorry but what do you mean by this? I am interested in finding out what protections the work we do have in a court of law, just in case, and also to satisfy my curiosity on what the hell did I do some 5 years ago.