First let me say up front, I have no problem whatsoever with an enterprise version of cosmos SDK.
I can understand the need for it and support Cosmos Labs desire to have an enterprise version.
BUT i think the placement and wording of the Enterprise licenses within the broader apache2 cosmos sdk repo is problematic for a lot of reasons.
Two that jump out:
-
The license in the enterprise level say "By using or accessing the repository(ies)"
IANAL but i have never considered a sub-directory of a repo, a "repository" of its own and its that kind of language lawyers love to argue about.
And then it goes on to say all the restrictions we now have to "repositories".
At its best, its super confusing unclear license language, at worst its a future nightmare.
-
If i want to make a clean version of cosmos SDK WITHOUT the enterprise directories, I cant. The licenses say specifically says:
"remove or alter any proprietary notices contained in the Repos;"
Removing the enterprise directory would in fact remove the licenses, so again its highly confusing restrictive language to live inside an otherwise Apache2 repo.
This create a genuine knock on effect in the age of AI. Agents are 100% going to be training on this code (may already have) because theres no clear way for any agent training process to know to exclude it. We have already seen agents happily regurgitating their training set. This creates ample opportunity when working on cosmos to inadvertently incorporate this code into a new work. Also, a local agent with access to this repo 100% will scan this code and there's no real way to prevent it polluting its context or getting re-emitted anyway.
Is there a real need for the enterprise modules to be within the main apache2 cosmos-sdk repo?
This is not an idle query, I am being told by my IP team i can no longer carry a fork of cosmos because of the risk of contamination. The best we have so far is a hoop jumping process where we clone the repo clean, remove the enterprise directory and then apply that as a single flat update to our fork. But then that would remove the license, which we cant apparently do. So we haven't done this yet, its just the best way we have come up with to have a clean fork where we wont inadvertently use the enterprise code.
First let me say up front, I have no problem whatsoever with an enterprise version of cosmos SDK.
I can understand the need for it and support Cosmos Labs desire to have an enterprise version.
BUT i think the placement and wording of the Enterprise licenses within the broader apache2 cosmos sdk repo is problematic for a lot of reasons.
Two that jump out:
The license in the enterprise level say "By using or accessing the repository(ies)"
IANAL but i have never considered a sub-directory of a repo, a "repository" of its own and its that kind of language lawyers love to argue about.
And then it goes on to say all the restrictions we now have to "repositories".
At its best, its super confusing unclear license language, at worst its a future nightmare.
If i want to make a clean version of cosmos SDK WITHOUT the enterprise directories, I cant. The licenses say specifically says:
"remove or alter any proprietary notices contained in the Repos;"
Removing the enterprise directory would in fact remove the licenses, so again its highly confusing restrictive language to live inside an otherwise Apache2 repo.
This create a genuine knock on effect in the age of AI. Agents are 100% going to be training on this code (may already have) because theres no clear way for any agent training process to know to exclude it. We have already seen agents happily regurgitating their training set. This creates ample opportunity when working on cosmos to inadvertently incorporate this code into a new work. Also, a local agent with access to this repo 100% will scan this code and there's no real way to prevent it polluting its context or getting re-emitted anyway.
Is there a real need for the enterprise modules to be within the main apache2 cosmos-sdk repo?
This is not an idle query, I am being told by my IP team i can no longer carry a fork of cosmos because of the risk of contamination. The best we have so far is a hoop jumping process where we clone the repo clean, remove the enterprise directory and then apply that as a single flat update to our fork. But then that would remove the license, which we cant apparently do. So we haven't done this yet, its just the best way we have come up with to have a clean fork where we wont inadvertently use the enterprise code.