drbdmanage license change

martin

Proxmox Staff Member
Staff member
Apr 28, 2005
748
1,626
223
Hi all,

We just want to inform you that Linbit changed the license for their 'drbdmanage' toolkit.

The commit messages says ("Philipp Reisner"):

------------------
... basically we do not want that others (who have not contributed to the
development) act as parasites in our support business ...

------------------

The commit is here:

http://git.drbd.org/drbdmanage.git/commitdiff/441dc6a96b0bc6a08d2469fa5a82d97fc08e8ec1

The new License contains the following clause (3.4b):

------------------
3.4) Without prior written consent of LICENSOR or an authorized partner,
LICENSEE is not allowed to:

b) provide commercial turn-key solutions based on the LICENSED SOFTWARE or
commercial services for the LICENSED SOFTWARE or its modifications to any
third party (e.g. software support or trainings).

------------------

So we are basically forced to remove the package from our repository. We will
also remove the included storage driver to make sure that we and our
customers do not violate that license.

Please contact Linbit if you want to use drbdmanage/DRBD9 in future. They may
provide all necessary packages.

__________________
Best regards,

Martin Maurer
Proxmox VE project leader
 
Looks like Linbit chose the way that Apple has taken once: no other players. Although I was successful with making master+2slaves DRBD cluster in production.
 
Adding a few facts: The DRBD systems contains 3 components that are relevant for most Proxmox users:
The latter allows you to use it, to modify it, to sub-license (=redistribute) it (or a modified version).
It restricts you in offering support services for DRBD Manage itself.
It does not limit you in offering support services for your offering like VMs as a service (which happen to live on a Proxmox system with DRBD in it), or any other offering you realize by using DRBD Manage.

When Proxmox VE 4.4 is out we will create a public repository that contains these 3 packages and the mentioned storage driver.
 
So the "few facts" also are:
a) DRBD Manage is NOT free(dom) software anymore
b) you can NOT trust Linbit about developing free software, the license can become proprietari in a snap
c) is bettere not use DRBD if you use Proxmox, since you can't have support from proxmox and you have to pay 2 for it (Proxmox for the proxmox part, and Libit for the storage part) and you will end in a "ping pong responsability hell", where each party will say that the other "platform" is "unknown, unsupported and for sure the reason of the problem".

This, unfortunately, at least for me puts of course an END in the usage of DRBD, I'm very sad for the big amount of time I've spent learning and testing it waiting for a stable DRBD9 to come (the 2 node storage + 1 for quorum cluster sounded great, if we can't have a 2 node cluster like vmware has).
 
So we are basically forced to remove the package from our repository. We will
also remove the included storage driver to make sure that we and our
customers do not violate that license.
The license effects only DRBD Manage. DRBD Linux kernel driver and DRBD utils are GPLv2 and this can't be changed easily by Linbit.
If you would remove only the storage driver, all the users which use DRDB 9 & LVM as storage, like it was necessary with DRDB 8.x, could still use Proxmox as a simple 2 Node HA cluster.

... is bettere not use DRBD if you use Proxmox, since you can't have support from proxmox and you have to pay 2 for it (Proxmox for the proxmox part, and Libit for the storage part) and you will end in a "ping pong responsability hell", where each party will say that the other "platform" is "unknown, unsupported and for sure the reason of the problem".
As long as you use the DRDB 9 & LVM as storage approach, which doesn't require DRBD Manage, the Proxmox team can and I guess will still support you.

When Proxmox VE 4.4 is out we will create a public repository that contains these 3 packages and the mentioned storage driver.
Will you test it?
Can we, the Proxmox users, 100% rely on this service for a server lifetime?

So we are basically forced to remove the package from our repository.
I would really appreciate, if the Proxmox project leader would rethink his decision and keep the DRBD Linux kernel driver and DRBD utils packages in the repository. In my opinion this is the only possibility to get long term support for DRBD in Proxmox.
 
I would really appreciate, if the Proxmox project leader would rethink his decision and keep the DRBD Linux kernel driver and DRBD utils packages in the repository. In my opinion this is the only possibility to get long term support for DRBD in Proxmox.
+ 1 vote

According to this official website of IBM...
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatbestpractices_pdf.pdf

... In the page 12 says in the title "Best practice: Use block devices for VM storage", and if we use DRBD as LVM block devices, we have the best performance.

Then, PVE can have a VM running in the DRBD primary, and the second DRBD resource as secondary, so when we need to do a online migration, PVE can change the status of these DRBD resources during the migration process. Also do something similar with the HA process.

This can be important when we have a data base or other applications that need high input/output to the disk, and also HA is required.

Best regards
Cesar
 
I'm a little confused.

On their website it looks like they are trying to work with everything virtualization wise. Ultimately virtualization is the only direction that makes sense in their business model and unlike redhat they have no vertical integration.

Gluster/Ceph are both redhat now and those will advance very quickly compared to DRBD and the need for redundant storage outside of virtualization is much lower.

Beyond that, I'm left wondering how this actually affects people who use proxmox, were people actually hyper-converging with DRBD? I've always kept those worlds relatively separate and used NFS or other storage methods atop DRBD, so proxmox has never been aware of DRBD.

I assume ya'll have reached out to linbit and asked for removal of your logo, which I would suspect is protected use, cause yeah they are leveraging your brand to promote their product.
 
Another idea came into my mind.
1) drbdmanage adds functionality to drbdadm. This is not that much, that it wouldn't be possible to write some Perl scripts to do this. This new scripts could be used by a new storage plugin for Proxmox.

2) Proxmox could fork the drdbmanage version before the license change and maintain this. Linbit decided years ago to do an Open Source project and now thy are violating the Open Source spirit. It wouldn't be the first project which was forked, due to bad maintainer decisions.

BR,
Jasmin
 
Another idea came into my mind.
1) drbdmanage adds functionality to drbdadm. This is not that much, that it wouldn't be possible to write some Perl scripts to do this. This new scripts could be used by a new storage plugin for Proxmox.

2) Proxmox could fork the drdbmanage version before the license change and maintain this. Linbit decided years ago to do an Open Source project and now thy are violating the Open Source spirit. It wouldn't be the first project which was forked, due to bad maintainer decisions.

BR,
Jasmin

Yeah,

I see that while the Proxmox team is fantastic it is much easier to talk the talk than walk the walk when it comes to enterprise level support of a forked project that you manage and develop in house. You can really only do a handful of these I'd imagine, and if you are going to take over a project like that then there has to be a high level of motivation to do so.

With the off-the-shelf solutions (ceph/gluster/etc) that can be used without this extensive level of re-writing and maintaining as Linbit releases DRBD updates it really doesn't make sense to continue support unless there is a dire need, which based on other options there isn't.

It's a shame for sure, I like DRBD.
 
Adding a few facts: The DRBD systems contains 3 components that are relevant for most Proxmox users:
The latter allows you to use it, to modify it, to sub-license (=redistribute) it (or a modified version).
It restricts you in offering support services for DRBD Manage itself.
It does not limit you in offering support services for your offering like VMs as a service (which happen to live on a Proxmox system with DRBD in it), or any other offering you realize by using DRBD Manage.

When Proxmox VE 4.4 is out we will create a public repository that contains these 3 packages and the mentioned storage driver.

So, what does this *exactly* mean?
Is Proxmox still allowed to distribute all 3 components from their own repository?
Does Proxmox have to exclude just DRBD Manage itself from their support offerings and refer customers who need DRBD Manage support to Linbit?

Why are you going to create a dedicated repository for the DRBD components for PVE 4.4 then?

Somehow I have the feeling that the two companies Proxmox Server Solutions GmbH and LINBIT HA Solutions GmbH should get their issues with each other sorted in a sensible way that's best for the customers... :(
 
  • Like
Reactions: jasminj

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!