Why not make Cloudron fully open source again?
-
@ruihildt said in Why not make Cloudron fully open source again?:
It never was a requirement for apps to have a specific license to be packaged.
Not to say that all licenses types can be packaged - the license for the app needs to allow free distribution of the software in order for us to package it.
-
@avatar1024 said in Why not make Cloudron fully open source again?:
@jdaviescoates Most but not all I don't think (TeamSpeak isn't, right?).
Confluence and Emby too. Possibly others (I would still really like a filter in the app store for licences and LDAP support)
But, I think the additional Cloudron code in the Cloudron packages for those apps is still MIT even for these non-open-source apps too.
@avatar1024 said in Why not make Cloudron fully open source again?:
At least in my circle, it's difficult to promote cloudron due to its licensing choice and I would need more info to explain / justify such a choice
Same.
@avatar1024 said in Why not make Cloudron fully open source again?:
and everyone of course wants the dev to get reliable income, people just think a free software license would not endanger the business model
Exactly.
Although I'm still open to being convinced otherwise if there is some genuine risk I've not fully considered as a non-developer.
@avatar1024 said in Why not make Cloudron fully open source again?:
I will write more on the topic soon
Thanks
-
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. The access to code has stopped being the bottleneck. The problem is now centralization. We've seen this happen again and again with Redis, Elastic etc.
The question is whether this risk is worth the developer contributions and user adoption that Cloudron is missing out by NOT being open-source.
-
@nilesh The devs seem to imply they donāt want code contributions but will allow them if it allows a new app in the store that couldnāt exist without them.
Thatās the vibe Iāve gotten anyway. Iāve written code contributions to
box
for my VPN Client app and plan to add contributions todashboard
. But Iāll let you guys know what happens. -
@nilesh I signed up way before there were the amount of developer contributions we can see now because what the Cloudron team could offer was already awesome. I've seen the forums get really busy with lots of dev suggestions; I've tried non-Cloudron submitted apps that didn't work out for this or that reason - even though some are still on offer, I'm not sure to what degree the Cloudron team has taken "full" responsibility for these dev-contributed apps, but it has all made me wonder just how much busier these contributions have made the Cloudron team, and to what detriment to existing users or road plans. Obviously the Cloudron team has a better picture of who the paying users are, but I suspect there are many like me. Don't get me wrong, I super appreciate the time outside devs and users have freely given to helping make the overall Cloudron platform broader, but the people I'm looking at getting to sign up and pay for Cloudron are more like me , though they have less awareness or interest in open-source in general, they do like things that work, and they like having ownership and control over their data (meaning we won't ever sign up with an AWS, GC or Azure-branded cloudron). My main concern is that Cloudron remains functioning to be able to offer their service.
-
@scooke That sounds spot on and the best demographic to go after. Since Iām just a dev that finds this stuff fun (not the target market); they still do go out of the way to help me which I think shows how much character both of them have. Which is another reason Iāve backed Cloudron so much.
I did want to ask what you meant by installing apps outside of the official AppStore and what was your experience with that?
-
@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.
-
@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.
-
@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.