Clarification and Justification Requested for OpenGPTs License Terms

[wfjt]

We are seeking detailed clarification on the OpenGPTs License terms, particularly given its contrast with common open-source licenses like Apache 2.0 and MIT. OpenGPTs is promoted as a free alternative to OpenAI's GPT and Assistant APIs, yet its licensing terms present potential contradictions and practical challenges, especially considering LangChain's use of the MIT license for other projects.

Key Issues and Contradictions:

1. Sublicensing Restrictions:

   • The license prohibits sublicensing, limiting the ability to grant a license to third parties.
   • Impact: Restricts distribution and modification possibilities in projects that typically allow sublicensing (e.g., Apache 2.0, MIT).

2. Hosted Services Prohibition:

   • Forbids providing the software as a hosted or managed service.
   • Impact: Limits use in cloud-based or SaaS models, prevalent in modern software ecosystems.

3. License Key Mechanism and Distribution Challenges:

   • The license requires a license key but restricts its distribution and tampering.
   • Impact: Creates a contradiction where users of a derivative project need a license key from OpenGPTs but cannot obtain it through sublicensing.
   • Open Question: How can developers distribute projects using OpenGPTs if each end-user is required to obtain a separate license key directly from OpenGPTs?

4. Compatibility with Other OSS Licenses:

   • Concerns about compatibility with permissive OSS licenses like Apache 2.0 and MIT due to OpenGPTs restrictions.
   • Open Question: Can OpenGPTs be legally used in projects under Apache 2.0, MIT, GPLv2, GPLv3, etc., without violating its terms?

5. Scope of Hosting Restriction:

   • Unclear whether the hosting restriction applies to the entire derivative work or only the parts utilizing OpenGPTs code.
   • Open Question: Does the hosting limitation impact the derivative work as a whole, or is it limited to the OpenGPTs components?

6. Contradiction with OSS Principles:

   • The limitations contradict the openness and freedom associated with OSS.
   • Open Question: How do these restrictions align with OSS philosophy, particularly considering LangChain's use of MIT for other projects?

Request for Clarification:

We request thorough clarification on the above points to better understand the intended use, limitations, and practical implications of integrating OpenGPTs into various projects.

Justification for License Choice:

Additionally, we seek justification for the choice of this specific licensing model for OpenGPTs, especially given its contrast with the more permissive MIT license used in other LangChain projects.

The license seems to be designed to make the project something for building personal tools, never shared with anyone. It grants distribution rights, yet the ambiguities force conservative interpretation, and it doesn't seem to be possible to redistribute any project using OpenGPTs given the licensing restrictions. All this goes against the nature of the open-source software community as a whole. Please explain what is so special about OpenGPts that it cannot use an SPDX OCI license like Apache 2.0 on which much of this world runs on.

[wfjt]

So I take it Harrison won't be answering this? If you can't spare a few minutes after over 3 weeks to explain your rationale and the gaping holes in the proprietary licence which prevents who knows how many from touching this project, then I take the point. Never for builders in the first place. Case closed.

[hwchase17]

Sorry for the delay @wfjt - had completely missed this.

This license chosen was the same as the Airbyte License for largely the same reasons as when they first moved (https://airbyte.com/blog/a-new-license-to-future-proof-the-commoditization-of-data-integration). Namely we do not want huge companies to take this project and start offering it as a hosted service themselves (as has happened to many other OSS projects)

I think the Airbyte License FAQ (https://airbyte.com/company/license-faq) can probably better respond to general questions - I think this part is the most salient

There are only a few high-level limitations. You cannot:

Provide the products to others as a managed service. For example, you cannot sell a cloud service that provides users with direct access to Airbyte. You can sell access to applications built and run using Airbyte.

The intent is for this to not affect anyone except for huge companies trying to offer it directly as a hosted offering.

More than happy to answer specific questions to your use case should you have any more!

[StellaAthena]

I appreciate your worries, and understand where you're coming from. I think the response to try to lock things down is natural, but ultimately the wrong approach.

That said, even conceding the philosophical point I think this is a very bad license for you to choose. Here are some impacts of your license:

1. It is a violation of the license of this library to incorporate it into existing open source libraries. It is a violation of this license to use this code as a reference to write a corresponding class in Hugging Face's transformers library, code to export models trained in GPT-NeoX or Megatron-LM to be compatible with this library, or code to evaluate models in this framework with LM Eval, HELM, and BigBench.
2. The entire clause about keys is logically incoherent. Taken literally, it seems to mean that the software functionally cannot be redistributed at all.
3. Projects that incorporate your code cannot be commercialized.

If you are really adamant about wanting to give companies the middle finger and don't believe in open source philosophical principles, why not do something like the LLaMA2 license or the Stability AI Community License which only limits the commercialization of the software (and in some cases only does so for large corporations?). I still think that those licenses are philosophically non-desirable, and depending on the exact wording may not address #1. But it would certainly make the code less radioactive.

[ErikBjare]

I have no trouble with choosing to use a non-OSI license, but I do find it troublesome to simultaneously name the project "OpenGPT" and describe it as "an open source effort".

It is source-available, not open source.

As someone who was curious about using the code, and am familiar with popular OSS licenses, I feel pretty discouraged by it having a non-standard license with unclear terms. I simply don't know if my use would fall under the restrictions, as they seem fairly broad and vague.

I think @StellaAthena's points are great, and further my concern.

[wfjt]

Thank you for changing the license to MIT, now I can use this great project!