Cuber is released under a source available license

Publish Date: Apr 28 '22

I am happy to announce that Cuber is moving from a custom commercial license to a source available license.

cuber-cloud / cuber-gem

An automation tool that simplify the deployment of your apps on Kubernetes.

CUBER

Deploy your apps on Kubernetes easily.

What is Cuber?

Cuber is an automation tool (written in Ruby) that can package and deploy your apps (written in any language and framework) on Kubernetes.

Unlike other tools that add more options and more complexity to Kubernetes, Cuber is made to simplify and reduce the complexity.

Kubernetes is up to 80% cheaper compared to PaaS like Heroku and you can choose between different cloud providers (no lock-in) It is also reliable and it can scale enterprise applications at any size The only downside is that it's difficult to master Cuber makes Kubernetes simple! In this way you have the simplicity of a PaaS, at the cost of bare infrastructure and without the additional cost of a DevOp team.

Installation

First you need to install the prerequisites: ruby, git, docker, pack, kubectl.

Then install Cuber:

…

View on GitHub

In particular we are adopting the Standard Source Available License (SSAL) and you can use Cuber for free for small / medium apps.

Cuber makes it easy to deploy your apps on Kubernetes: just create a Cuberfile, with ~10 lines of code, and then type cuber deploy to package and deploy your app on any Kubernetes cluster.

Comments 2 total

Jay JeckelApr 28, 2022
That license could use some improvement.
1. It allows people to use and modify the code, but it doesn't allow redistribution of the unmodified code or distribution of modified versions of the code.
2. It makes the same mistake that the MIT License made by requiring the "above" copyright and the "this" list of permissions to be included, but doesn't mention that the below warranty disclaimer must also be included.
3. I understand the desire to make the license short, but you should probably just copy the whole MIT warranty disclaimer instead of only two sentences from it. It can seem like unneeded boilerplate, but in legal matters some boilerplate can be useful and comforting.
Honestly, unless you are going to hire some lawyers or other copyright experts, you'd probably be best served by copying the whole MIT License and just adding your extra condition to the permission list. You would lose nothing while gaining the comfort and security MIT provides and the extra restriction you've deemed necessary.
- Marco ColliApr 28, 2022
  Thanks for your feedback, I really appreciate it!
  
  Yes, redistribution is not listed yet. It could be easily added without damaging the main goal of the license. I'm still wondering what are the pros and cons of "redistribution" for this type of license and the possible use cases: nowadays most libraries can be download as dependencies (e.g. from NPM, RubyGems, etc.), so redistribution outside the official channels seems unnecessary. Why redistribution would be necessary / useful?
  
  Yes, the expression "this permission" is somewhat ambiguous, however the MIT license is widely accepted and has the same sentence, so I think it's ok and the meaning is clear (for historical reasons). Or maybe I could use the expression "this license".
  
  I have compared multiple OSS licenses and extracted the "common" part of the disclaimer. Many parts of the MIT license disclaimer are not present in the BSD for example, so they seem unnecessarily redundant. So I think that what I wrote is enough. I'm not a lawyer, because I graduated in CS, but I studied law in Italy for 2 years.
  
  About using the MIT license directly (that was my first idea) I had a small doubt about the copyright of the license itself: I don't think that there is one, but as a precaution, and in order to create something even more clear, I decided to write everything from scratch.

Add comment

Marco Colli @collimarco