Cloudron no longer AGPL?
ryangorley last edited by ryangorley
Dear Cloudron Team,
One of the things that really attracted me to Cloudron was that it was open source with an AGPL license. That was awesome and it meant a few things:
- It aligned with my values.
- It would be an inviting place for community contributions.
- It wouldn't disappear if the company was acquired or the founders got bored, hired away, or abducted by aliens.
These are important. I have regularly promoted the service in public and private for these reasons, and because it is just a fantastic tool that I gladly pay for. However I recently stumbled upon a comparison table on a website indicating that Cloudron was not open source. That seemed wrong, so I started looking.
What I found was a blog post (https://cloudron.io/blog/2016-08-29-opensource.html) dated 29 August 2016 announcing that Cloudron was being distributed with an AGPL license. At the top was a notice added 28 March 2018 indicating that Cloudron was no longer advertising open source, but was still being developed in the open. It did not indicate any license change. Then I found that the license had in fact changed in GitLab on 26 February 2019.
As far as I can tell, this wasn't announced via social media, email, a blog post, or anywhere. This change is disappointing and I am embarrassed for having promoted it falsely. The manner in which it appears to have been changed, without any notice to those who would be impacted, leaves me unsettled.
I know my single subscription makes little difference in your business, but I doubt I'm the only one who chose Cloudron because of all the benefits of the AGPL. I suspect it matters to those who contributed patches believing this was AGPL software. Were they made aware that their contributions were now proprietary code? I wish you all the success in the world and hate to make a fuss, but I would really appreciate if this was addressed and explained openly.
@ryangorley Sure. The technical reason is that the code base has subscription, appstore and sign up logic. It's unclear what the license should be if it requires the cloudron.io service to work. The non-technical reason is that we were spending too much time explaining why we call ourselves opensource and charge for it. To put an end to such conversations (many of them very hurtful), we just stopped calling ourselves opensource as as early as 2017. I don't know of an easy solution to this.
That said, a major part of Cloudron is the packages. This is what our customers pay us for. They want app packages updated and maintained. If cloudron dies, the box code itself is not very useful since the main thing needed is app packages. All that packaging work, over 100 apps is completely MIT licensed with selenium tests (https://git.cloudron.io/cloudron/). We even released our buildbot as opensource last week which will easily help build the apps without our build service.
ryangorley last edited by
Thank you @girish!
I'm sorry to hear there were hurtful conversations about selling a service built on open source software. It takes a lot of courage to release the code at the core of one's business with a permissive license. It should always be applauded. If someone doesn't want to pay, then they should exercise the rights granted by the license and do their own work implementing the code, or stop whining and just pay the fee for someone else to do it. I see those attitudes changing, but not fast enough.
I think you've built something incredible. You and @nebulon have always been incredibly generous and responsive. I know you've explored many ways to monetize this, from hosted accounts to premium apps. I want you to succeed. I hope the door isn't shut forever to opening up some of these other bits again.
@girish there are lots of open source projects that offer paid/proprietary services out there. You can point to Ubuntu or Android as very popular ones.
As someone who has contributed (albeit only a few small patches) I'm quite surprised to see an attempt to change the license. I'm also not sure that the license change is legal. I am not a lawyer, but my understanding of AGPL would be that since there was no CLA (or was there? I don't remember singing one for Cloudron) signed by contributors, each contributor owns the rights to their patches. To change the license, you would need approval by each contributor. If those patches are still AGPL, then any additional changes to the code base since then must also still covered by AGPL in order to be in compliance.
@iamthefij We have a CLA in place - https://cla.cloudron.io/ . If we didn't get yours, it's probably an oversight. What you are saying seems correct though. I will reach out to the 4-5 people who contributed to Cloudron and inform them personally and act accordingly. FWIW, Johannes and I wrote practically all of cloudron code and most of the apps, thus we didn't carefully consider those contributions.
gabrielcossette last edited by
I'm very sad to hear that Cloudron core code has become proprietary software. Like @ryangorley, I've always been promoting Cloudron as a great well-supported open source self-hosting option.
I too want you guys to succeed but I fail to see a valid reason to turn Cloudron into proprietary software if it is still being developed in the open.
My thoughts on the reasons you gave:
The technical reason is that the code base has subscription, appstore and sign up logic. It's unclear what the license should be if it requires the cloudron.io service to work.
I-am-not-a-lawyer but I'm pretty sure that you can still be under an open source license. I mean, the situation is not "ideal" as an user can't easily self-host without relying on the cloudron.io external service, but anyone is free to create a fork and reimplement these functions. Also, I don't know if it's the case anymore but we used to be able to install cloudron Docker packages built manually without cloudron.io. So in a way, Cloudron was self-hostable, just without the user friendly App Store.
The non-technical reason is that we were spending too much time explaining why we call ourselves opensource and charge for it.
It should be pretty simple for customers to understand, they are paying for a service of maintenance and support (indirectly funding the development of the core product). That is no different than let's say a WordPress maintenance service to have plugins/themes kept up-to-date by a company.
Worse case, if you really want to give proprietary software to some customers, why not dual-license? Contributions would be made under both AGPL and your proprietary license. This way, it's still open source and potential contributors would be a lot more inclined to become involved.
Anyway, I wish that a compromise can be found where Cloudron still remain a great open source self-hosting option!