Queries regarding licenseing and advertising as open source

[ssddanbrown]

Hello,
Just came across this project via your HN. I posted a response there about not considering this open source, while being advertised as open source, so I thought I'd expand on that here.

While the license is Apache 2.0, a widely accepted open source license, you've added a range of additional terms to this, some of which I believe may go against the commonly regarded open source definition (OSD). My specific queries in regard to the licensing are as follows:

Unless provided with a written agreement or permission, the paid features of Dokploy (as a service) cannot be modified

From the code, how do we know what's a paid of free feature? Can that change without change to the project? Can the project be used without that code? Such code under this term wouldn't generally be considered open source due to the limitation on modification.

Unless provided with a written agreement or permission, no persons are permitted to redistribute another paid version of Dokploy.

This goes against point 1 of the OSD. Being able to re-sell and re-distribute is a pretty fundemental right of both open source and free software.

Unless provided with a written agreement or permission, no persons are permitted to create the same paid version of Dokploy.

What counts as "the same paid version" lacks clarity, and same issues as the previous point.

Prohibition of Resale Without Permission: [...]

This point is confusing, since it's preventing a lot of things the that the Apache 2.0 license specifically allows, while stating "Notwithstanding any provisions in the main body of the Apache License, Version 2.0,".

Commercial Distribution: Any form of distribution of Dokploy, whether for direct profit or indirect financial benefit, through commercial channels is strictly prohibited without a separate commercial agreement negotiated with the copyright holder. [...]

Again, goes against common expected freedoms of open source as mentioned above.

Modification of Paid Features: The paid features of Dokploy (as a service) may not be modified [...]

Again, not clear what these are in regard to the codebase.

Open Source Distribution of Free Features: Any modifications to the free features of Dokploy must be distributed freely and must not be included in any paid or commercial package without complying with the open-source license terms stipulated in this agreement.

Preventing those terms of use is against the OSD. Also, these terms wouldn't really be considered "open-source license terms".

---

Sorry if this comes across pedantic. To be clear though, I totally respect your right to license your efforts as you wish, I just think specifically advertising as open source could be potentially misleading to many while you have these added terms. I've written more about why I think the term "open source" is important here.

[sbuttgereit]

While the license is Apache 2.0, a widely accepted open source license, you've added a range of additional terms to this, some of which I believe may go against the commonly regarded open source definition (OSD).

Actually, the use of the Apache license in this way appears to be more than a violation of the accepted understanding of of "Open Source", but is actually a violation of the Apache Foundation's terms for using the license:

You may re-use our license unchanged, and also modify it.

If you modify it, you are on your own from a legal point of view, and the result is NOT the Apache License, just a new license inspired by ours.

This means that the terms 'Apache License', 'Apache', and any similar references to the ASF cannot appear in your modified license, other than to state that it differs from the original.

Also, you cannot use 'Apache' in the name of the modified license. Names like "Apache License with such-and-such clause", for example, are not acceptable, as they cause confusion.

Creating a new license is a non-trivial task. If you do that we recommend that you get your own legal advice.

Reference: https://www.apache.org/foundation/license-faq.html#mod-license

It's important to understand that Licenses are themselves subject to copyright law and may only be used under their own terms and conditions.

[Siumauricio]

Hi @ssddanbrown, thanks for the explanation and clarification, I have changed the license as it was against the open source rules, now the core is completely open and only 2 specific features of dokploy are restricted and forbidden to sell without consent.

Read the license and let me know what you think.
https://github.com/Dokploy/dokploy/blob/canary/LICENSE.MD

[ssddanbrown]

Hi @Siumauricio,
Thanks for being receptive to make changes to improve clarity!

Read the license and let me know what you think.

Unfortunately it's still not clear in usage. Reading that I'd have questions like:

• What code is related specifically to those features?
• Can the project still work/function if I remove the code related to those?
• If I use your script to deploy the application (assuming it's open source as advertised) am I actually instead subject to those non-open terms by default?

Generally it's better if those non-open elements are kept seperate, or at least clearly functionally specified (eg. These files are under the Apache license apart from the following directories/files:..).
If the application can't be ran without those parts/files, I would generally consider advertising as open source to be misleading though.

IMO, the best open core examples keep the non-open parts at a clear distance. The non-open core will be in a separate repo. The offering will be labelled separately (For example, CE [community edition] and EE [enterprise edition]).
Many others that keep them in a mixed repo, will keep the non-open code to a single folder within the project, under its own license, with that referenced in the top-level readme and/or license (again, while allowing the open offering to work standalone).

[Siumauricio]

@ssddanbrown

1. Basically everything prefixed with Cluster and compose is the code we are restricting in the license, everything else is free and open.

Cluster

Compose

2. Of course, in fact these functionalities are new, that is to say about 4 versions or so ago these were implemented, so the software will work without these functionalities.

3. Correct.

As I mentioned, these features are new so if you uncouple them it should work without problems, but of course you will always have to remove the code because this is a system that is all linked at a very basic level, of course removing the pieces would work the same but you would have to manually modify the code and remove these references

If I would like to keep it in a mixed repository, but as it is something that usually goes all together I still do not handle this at the plugin level to decouple something so easily, probably using a monorepo would help me to decouple these features and make it easier, but in the end the idea that I always want is that people can use all the features and not have to manually implement those features, of course for the specific cases that someone wants to create a business with this if they would have to modify the code to decouple the features that really would be very easy to remove them, but of course as it is a simple application of nextjs there is no way for me to remove them, as I mentioned maybe with a monorepo would be something easier which is a thing that I'm considering

[maribox]

Open Source Alternative to Vercel, Netlify and Heroku.
Why not call it "Source available"? Because the project is not Open Source if only some parts are Open Source.
You could also make a separate repo for the non Open Source part (I also think that would make everything much more transparent), but currently that tagline is just false, no?