Notice of GPL Violation regarding My Contributions

[discus-sions]

I am hereby notifying you that your project, TOHE, is currently violating the GPL license under which my contributions to this project are included.

Below, I have listed all of my contributions and relevant information about each contribution.

1. Exile Confirm
   

   TownofHost-Enhanced/Patches/MeetingHudPatch.cs

   Line 423 in 3676f64

   var player = GetPlayerById(exiledPlayer.PlayerId);

   
   

https://github.com/discus-sions/TownOfHost-TheOtherRoles/blob/4b50c5fa45864abcedf9e82fb5fda60030e29fba/Patches/MeetingHudPatch.cs#L292

2. Split RPC
   TOHE:
   

TOHTOR:

The reasons for these violations are stated in #1271.
I want to inform you that because this is the first time you've violated my copyright, you can automatically gain back your license if you solve this issue within 30 days, as stated in section 8 of the GPL version 3:

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

[Tommy-XL]

If you find another one, it would be better to report it immediately

[NikoCat233]

Reasonable

[0xDrMoe]

Thank you for notifying us of your concerns regarding Town of Host Enhanced (TOHE) and its compliance with GPL 3.0. We take all licensing requirements very seriously, especially for contributions from community members like yourself. We acknowledge receipt of this notice as your formal notification under GPL 3.0, Section 8. We are committed to addressing the issues you’ve outlined within the 30-day period to restore compliance and resolve any outstanding concerns.

Our team will start reviewing the files and contributions you specified, including the Exile Confirm and Split RPC modifications. We will ensure that all relevant files and documentation necessary for full functionality under the GPL are appropriately available and accessible. Any identified gaps will be resolved, and we’ll keep you updated throughout this process.

Please feel free to contact [email protected] if there’s additional information you’d like us to consider. Thank you again for bringing this to our attention.

[MattTheOnlyOG]

Findings through in depth review of the GPL 3.0:

GPL 3.0 requires that the "Corresponding Source" be made available with the binary. This includes all files, code, and scripts needed to build, install, and run the program. If an API key or token is necessary to run the program fully or access core functionalities, the lack of that key could be seen as an incomplete “Corresponding Source.” Give then TOHE has provided a dummy key, allowing any user to access the core functionalities and gain complete access, this would not be a violation of the GPL 3.0.

Precendents in the open-source community (GitLab and GitHub API Usage):
Some open-source projects use GitLab, GitHub, or other external APIs to enhance funcitonality without requiring users to access these APIs. They typically provide options like dummy keys, alternative configurations or instructions to set up personal keys. As long as the core functionality of the software does not solely depend on these APIs, these projects have been ruled GPL-compliant.

In addition, some software, like open-source weather or map applications, use external APIs for additional features (like displaying weather or maps). Many of these projects offer placeholders or allow users to substitute their own API keys. As long as users can modify, build, and use the core program without these APIs, the projects have historically been deemed compliant with GPL. This approach alligns fully with TOHE's model if the API's functionality is indeed optional.

My legal interpretation by the Free Software Foundation:
While the FSF doesn't offer explicit guidance on API keys, it has generally held that a programs functionality must be fully accessible to users through the "Corresponding Source." However, if certain features are considered "non-essential" or enhance functionality without limiting the core usage of the software, the FSF has supported using optinal API configurations, provided the software is fully usable without proprietary APIs.

GNU GPL-Compatible projects with optional APIs:
LibreOffice Online connects to external APIs for document collaboration and storage integration, such as cloud APIs. However, it remains functional as a standalone software, allowing users to use it without external API dependencies. The project provides documentation on integration optional APIs while allowing users to use alternative backends or completely forgo them, keeping in GPL-Compliant. Like I also mentioned about the weather maps, OpenWeatherMap API for some weather applications, falls under the GPL license. They often distribute the application with a dummy key or prompt users to obtain their own API keys. This setup is accepted because the core application functions without a specific API and only enhances features if a user chooses to add an API key.

Based on these examples, TOHE is justified in withholding its API key as long as it:
Provides a dummy key and ensures that all core functionality remains accessible without the actual API.
Makes it clear that users can obtain and use their own API key if they wish, with simple instructions on how to do so.
Ensures the API is optional and enhances rather than restricts core functionality.

As long as TOHE adheres to these guidelines, it aligns and is in full compliance of GPL requirements, similar to other projects that offer optional API integration without compromising the open-source freedoms granted under the GPL.

Best,
Matthew J
Legal Representation of The Enhanced Network

[discus-sions]

Dear Matthew,

Thank you for your opinion on TOHE’s compliance with the GPL. Please let me respond to it point by point:

Precendents in the open-source community (GitLab and GitHub API Usage)

We’re not copyright holders in these hypothetical projects, so we can’t file a complaint on these projects, even if we’d consider them in violation of the GPL.

We do consider TOHE’s binary distributions without sharing the complete source to be a violation of the GPL, and as we are copyright holder of code that is included in TOHE, we are complaining to TOHE that the license on our GPL 3.0 licensed source code is being violated.

My legal interpretation by the Free Software Foundation

If an API key is not included when building TOHE, certain features are missing and other anti-features appear. As this API key cannot just be downloaded from the same location as the binary, we consider the source code to be incomplete.
The GPL also does not include wording that allows violating parts of the license for optional or non-essential parts of a program without permission of the copyright holders.

GNU GPL-Compatible projects with optional APIs

LibreOffice Online is licensed under the MPL 2.0. Therefore they do not need to comply with the requirements of the GPL 3.0.

Based on these examples, TOHE is justified in withholding its API key as long as it can follow the points below.

We believe the TOHE team can stop violating the GPL license on our code if they change their procedures to either:

• Stop doing binary distributions of my source code
• Stop including parts like API keys that are not in the public source code.

Thanks,
Discussions

[MattTheOnlyOG]

Dear Discussions,

Thank you for your detailed response. We appreciate your engagement in clarifying the GPL compliance requirements for TOHE and respect your position as a contributor to the project. In response, we’d like to address each of your points and outline our approach to ensuring that TOHE remains fully compliant with the GPL 3.0.

Precedents in the Open-Source Community

We acknowledge that while we referenced examples of other projects in the open-source community, these were intended to illustrate common interpretations of GPL compliance in similar scenarios where API functionality is optional. We understand that these examples do not influence the legal interpretation of TOHE’s GPL compliance directly but instead offer context for how similar projects have managed optional APIs without infringing on GPL freedoms.

API Key Requirement for Full Functionality

TOHE’s core functionality remains accessible to users without an API key, with all essential features fully operational. We provided a dummy API key to ensure that the software can be built and run by users independently, consistent with GPL’s requirements to enable freedom in using, modifying, and distributing the software. However, we acknowledge your concern that additional features rely on an API key, and that users cannot obtain this key directly with the source. To address this, we are prepared to provide clear instructions on how users can configure the software with their own API key, if desired, without affecting core functionality.

GPL’s Treatment of Optional Features

We understand your interpretation of the GPL as not allowing any part of the license to be waived for optional features. Our position, based on the FSF’s guidance, is that when a feature is truly optional and does not affect the primary functionality or usability of the software, a dummy or placeholder API key can satisfy GPL requirements. However, we are committed to ensuring TOHE remains in full compliance and have made certain implementations in the most recent update to further support our position in this.

Moving forward, I highly recommend that you consult with a professional who specializes in open-source licensing for a more accurate interpretation of the GPL 3.0 and relevant precedents. This will help clarify the distinction between TOHE’s current approach, which uses a dummy API key for optional features, and what would constitute a true violation of the GPL. A professional assessment can provide a more comprehensive understanding of the policy and its application, ensuring all parties have a clear and fair perspective on compliance requirements in this context.

Please feel free to use the secondary point of contact I’ve opened for more direct communication. While The Enhanced Network is my client, I’m happy to make time to discuss this further in a real-time setting. I have experience mediating open-source licensing disputes and have previously submitted formal interpretations on the language and precedents established in the community. I’m open to clarifying any concerns or questions you may have regarding this matter.

Best,
Matthew J
Legal Representation of The Enhanced Network