Why not make Cloudron fully open source again?
-
@nilesh said in Why not make Cloudron fully open source again?:
IMHO, there are serious problems with AGPL-licensed software that is hosted on servers - namely, it allows Amazon AWS , Google GCP, Microsoft Azure etc to take the code and start charging for it without contributing anything back to upstream.
Two things.
- The scenario you describe is actually exactly what AGPL was designed to protect against, no? See https://www.gnu.org/licenses/agpl-3.0.html and lots of relevant quotes from that and other write-ups in posts above.
Perhaps you're thinking of a different license?
But, also,
- as I said above, I think the risk of someone cloning Clouron is MUCH higher from a small tech agency than the Tech Giants taking the code. The Tech Giants have unfathomable resources. If they wanted to reverse engineer Cloudron it would take an unimaginably tiny fraction of their immense budgets.
-
@jdaviescoates The Fair Code license makes this explicit - I think it might work well here if they choose to go open-source. https://faircode.io/
-
This post is deleted!
-
Just dropping this link here for inspiration while I remember: https://ghost.org/about/
-
Reference the above and thinking out loud; I'm thinking to turn our efforts on the whole Brandlight WP/Woo stack, and probably wider peripheral development & maintenance business, into a Foundation.
Mostly for simplicity and arguments' sake, team, users & contributors become beneficiaries. Better trust for what happens with income & expenses.
I'm sure there's other advantages I need to research too but mostly a deceleration to the world that the work is for the quality of the products and no-one's looking for a quick-flip or windfall, just sustainable satisfaction and protection to keep on evolving.
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@marcusquinn Like a .coop too.
-
The meeting with Cloudron enthusisats we had on Workadventure and reading the following article by ERP Next developers made me remember about this thread.
When this discussion started back in July 2020, nebulon said "we will answer in more details", but since then, we haven't heard from him and girish directly on whether Cloudron could become fully open source again.
@nebulon @girish With the time passed and the discussions, is it a question you feel ready to answer?
-
I can't answer for Cloudron but if it were me, to go FOSS I'd want to split the functionality to a core FOSS package and commercial license for add-ons and support to protect the business IP.
Similar to Freescout & EspoCRM, plus the standard CLA that's now common with FOSS.
With that in mind, I don't know that gains would be quite what people would be hoping for since it's already source-available and any would-be contributor can already get involved with a free install.
I can understand the ideology, but in practice, for me, the experience, enthusiasm and renumeration of the creators is more important to me for security of continuity.
I'm sure the feature requests will eventually plateau, and the community supplement many more apps, at which time I guess that would afford more headspace for this.
In the meantime, it's the coming features and apps that have most value to me, so I guess anything distracting from that is going to be an intermittent long range conversation.
Sorry, I know you addressed the comment directly but I guess there's also other interests here that don't have this at the top of the wishlist still.
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@marcusquinn said in Why not make Cloudron fully open source again?:
I can understand the ideology, but in practice, for me, the experience, enthusiasm and renumeration of the creators is more important to me for security of continuity.
I live and breathe open-source, but this right here is the most important for me in all projects I contribute to (longevity).
-
@nebulon @girish
Just thinking out loud here but have you considered the consequences of MongoDB‘s license (SSPL = Server Side Public License) for apps on a Cloudron yet? I came across it at my work recently and it’s a quite drastic „viral“ copyleft license:- Offering the Program as a Service.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
So I think it does not affect the Cloudron source code but potentially the source code on all apps using MongoDB.
Overview: https://www.percona.com/blog/2020/06/16/why-is-mongodbs-sspl-bad-for-you/
-
@necrevistonnezr said in Why not make Cloudron fully open source again?:
So I think it does not affect the Cloudron source code but potentially the source code on all apps using MongoDB.
That is not the case. The SSPL provision in question only applies when you sell Mongo itself as a service. Key phrase in you citation :
offering a service the value of which entirely or primarily derives from the value of the Program or modified version
The point is to prevent Cloud service providers like AWS & such to sell managed versions of Mongo, with their own modifications & optimizations, without contributing back to the upstream Mongo.
-
@necrevistonnezr Very interesting, thanks for sharing! I like to think I understand things given enough reading, but it does seem to be one minefield of cost and IP claims risk.
-
@mehdi Also interesting, I'm not sure I'd trust Amazon's commentary on anything but I kinda feel Percona's seems well intended.
Given most SaaS are just hosted CRUD apps, it would seem to me legit Mongo could slide into your Inbox with some demands if they chose to?
-
@mehdi
Nope, Sec. 13 of the license does contain „selling“ a service, it speaks of „make the functionality of the Program (…) available to third parties“.
If you provide access to a MongoDB instance - e.g. you host an app that others can interact with - and that uses MongoDB, you’re in.And the definition of „Service Source Code“ - the one you have to publish - is extremely broad.
The same applies to Elastic / Kabana by the way, they switched to SSPL as well (they also use Elastic V2 license but that’s worse).
-
@necrevistonnezr Correct me if I'm misunderstanding this but is this what they are saying?
- If you use MongoDB in your XaaS, you have to make all your code available AGPL or buy a MongoDB licence to keep your code private.
- If you use a MongoDB SaaS you can legit ask that company to give you a copy of all code necessary to run your own instance.
Is that what it says?
To me that sounds good for consumers, and bad for close-source SaaS businesses or open-source ones that are less obligatory than AGPL?
I'm in the "who gives a monkeys about the code, the business is the people who know how to use it" camp - but then I doubt that's compatible with venture capital aspirations to own stuff - but then I've not seen anything VC backed that couldn't have been made cheaper and as successful other ways.
-
@necrevistonnezr said in Why not make Cloudron fully open source again?:
make the functionality of the Program (…) available to third parties
This means directly. When you host an app that uses MongoDB in the back-end, you are making the app itself available, not mongodb, so no, it does not apply.
CF this citation from Mongo's own FAQ about SSPL:
Does section 13 of the SSPL apply if I’m offering MongoDB as a service for internal-only use?
No. We do not consider providing MongoDB as a service internally or to subsidiary companies to be making it available to a third party.
Or also :
What will happen if someone in the community is currently building something on MongoDB Community Server?
There will be no impact to anyone in the community building an application using MongoDB Community Server unless it is a publicly available MongoDB as a service. The copyleft condition of Section 13 of the SSPL does not apply to companies building other applications or a MongoDB as a service offering for internal-only use.
Source https://www.mongodb.com/licensing/server-side-public-license/faq
-
@mehdi
The FAQ is not binding in any way. Only the license text is binding and (purposefully) vague (in order to create uncertainty and thus motivate companies to license).
As a lawyer, I would not recommend to built a business on the mere hope that implementing MongoDB code is conforming to the License Agreement. -
This is very interesting and relevant to this discussion:
https://autonomic.zone/blog/co-op-cloud/
Basically, a UK based worker co-op digital agency who used to use Cloudron no longer do so and have now started yet another project to fulfil very similar goals called Co-op Cloud.
This is primarily because Cloudron is no longer open source.
I really love their project and wish them well and will do all I can to support them, but I can't help also feeling a bit sad that it needs to exist at all.
I reckon if Cloudron had remained open source their energy could been usefully put into helping to improving Cloudron rather than starting another project.
