Clarification of the use of the AGPL along with the "ee" package #1415
Replies: 2 comments 1 reply
-
|
@ssddanbrown thanks for the great write up. The details of our licensing are still evoling, the philosophy behind doesn't:
@Mythie making the build possible without EE is a good idea |
Beta Was this translation helpful? Give feedback.
-
|
@ssddanbrown happy to keep discussing this, as it's something I think a lot about |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello 👋 ,
To be up-front, I'm interested in licensing scenarios & techniques within the open source world.
I saw the project was under the AGPLv3 license, but I also saw the ee folder and license, so assumed an open-core & dual-license setup.
Looking further though, It looks like a lot of the open source code relies on the ee package, or at least has direct references to it unless there are other mechanisms at play, which from my own (non-legal-expert) experience of the AGPL I know does not mix too well.
So my questions are:
packages/eefolder be removed completely without causing build/run problems)If I've misunderstood, and you actually have some open mocks/versions of that
eepackage, it would be great to know how that's done, so I can use that as a good example of mixed-license setups to show others.Edit: Following the self-hosted guidance, a clone,
npm installand anpm run build:webworks fine by default, but attempting to runnpm run build:webafter removing thepackages/eefolder seems to break the build with manyModule not found: Can't resolve '@documenso/ee/server-only/limits/provider/client'kind of errors.Beta Was this translation helpful? Give feedback.
All reactions