Skip to main content

How licensing works

MooseFS comes in two editions. Each edition sets its own terms for running the software. Community Edition is free software. MooseFS PRO is commercial. A PRO cluster runs under a license that limits how much data the cluster may hold. CE and PRO: feature matrix covers which capabilities each edition includes. Editions: Community and PRO covers what an edition is. This model balances open-source flexibility and enterprise-level scalability. This model lets organizations choose the edition that best fits their needs.

Community Edition is distributed under the GPLv2​

Community Edition is licensed under version 2 of the GNU General Public License. The license text ships with the source. Under that license, you may run the software for any purpose, personal or commercial. You may read the source and adapt it to your needs. You may also pass it on, modified or not, as long as it stays under the same license. This licensing model encourages transparency, collaboration, and innovation. The full text is in the GNU General Public License, version 2.

A Community Edition cluster runs without a license file and reports itself as licensed under the GPLv2. Nothing in that cluster caps the amount of data you store, the time you run the cluster, or the number of Chunkservers you attach. The hardware that you give the cluster sets the ceiling instead. The limits that the product sets for every installation, listed in Limits, apply as well.

A PRO license is perpetual and caps raw space​

A PRO license PRO (PRO Edition only) is perpetual and non-transferable: you buy it once and keep it. You do not rent the software for a period, as you would with a subscription.

The license caps used raw space. Used raw space is the space your data occupies on Chunkserver disks once redundancy is counted in. That space is more than the size the same data has for a user. The license limits the space in use, not the disks you attach. For example, a cluster with 1 PiB of disks and 15 TiB of data on them stays inside a 20 TiB license. Buying more disks does not change that. The licensed figure is in binary units, the larger of the two conventions. Limits explains the difference.

The price depends on the same figure. The raw size of the cluster that the license covers sets the price. The rate per TiB is lower for a larger size, so a larger cluster costs less per unit than a smaller cluster. This page does not publish the rates or the thresholds between them. Rates and thresholds are part of an offer, not of the software.

The license leaves the rest of the cluster unlimited. The license sets no ceiling on:

  • the number of Master Servers, or the memory each of them has.
  • the number of Chunkservers.
  • the number of stored objects, files and directories alike.
  • the number of connected clients, that is, of mounts.
  • bandwidth, or the total volume of data transferred.

Those are limited by the hardware and by the product's own limits. A Community Edition cluster works under the same limits.

A PRO installation always has a license, because every Master Server has one built in. PRO Personal covers what a cluster runs under until you install a license of your own.

Support is a separate purchase from the edition​

Support does not come with a license and is not part of one. Support is sold for a fixed term of at least a year, but a PRO license is perpetual. The two purchases therefore end at different times. A cluster whose support term has ended keeps running under the license it holds.

The edition you run does not determine what support you have. Support is offered for Community Edition and for PRO Personal as well as for PRO Enterprise, so support can cover a cluster that runs under GPLv2. The level of the contract determines the terms. There are two levels, Basic and Premium. The contract, rather than this documentation, defines what each level covers in response times and in contact channels. You agree on the terms with MooseFS.

The license file reaches every Master Server​

A PRO license PRO (PRO Edition only) reaches the cluster as a file, mfslicence.bin. Each Master Server reads the file from its own disk and re-reads the file on every process reload. LICENSE_FILENAME in mfsmaster.cfg holds the path to the file. The page install a license covers putting the file in place and checking that every Master Server runs under the same file.

That option always holds a value. When the configuration sets none, the option holds /etc/mfs/mfslicense.bin, so a Master Server always has a path to try. What happens next depends on whether the Master Server can open the file at that path. When the file does not open, because it is missing or because its permissions do not allow access, the Master Server stays on its built-in license. The cluster then runs under PRO Personal terms. A file that opens is loaded. The load has two outcomes. Either the Master Server runs under the license that the file includes, or the load fails and the Master Server stops with an error. The load fails when the file is not a license, is damaged, has expired, or was issued for another installation. Once a file has been opened, the Master Server never falls back quietly to the built-in license.

The file includes the terms themselves: the used raw space that the license allows, and the highest product version that the license covers (for example, a Master Server up to 5.2.x). When the license was granted for a period rather than bought outright, the file also has an expiry date. An evaluation license is granted that way. Alongside the terms, the file names who issued the license and who it was issued to. mfslicinfo prints the license that your Master Servers run under. For a perpetual license, the expiry date reads never. mfslicinfo queries each Master Server and does not read any file. A built-in license is therefore printed the same way as a license that came from disk. Confirming that the version limit covers the release you are moving to is part of pre-upgrade checks.

A license binds to an installation, not to a machine​

Nothing in a PRO license PRO (PRO Edition only) names a machine: not an address, not a hardware identifier, not a count of Master Servers. The same file goes on every Master Server of the group. To move a Master Server to different hardware, copy the file across with everything else the Master Server needs.

A license can name the installation. The license identifies that installation by metadata ID: the number that the cluster's metadata includes and by which the cluster is recognized. Every Master Server of a group shares the ID, because those Master Servers share the metadata. Two clusters have two different IDs. A license issued commercially usually names the installation. When a license names the installation, a Master Server loads only metadata whose ID matches. When the license leaves the ID open, the Master Server does not compare IDs at all.

The refusal is explicit. A Master Server whose license names a different installation does not start: the metadata does not load. The log shows wrong meta id - can't load metadata. A degraded mode is not one of the outcomes. Every component runs fully licensed or not at all.

The ID belongs to the metadata, so every operation that keeps the metadata keeps the license working. Such operations include replacing the machine that a Master Server runs on, adding a Follower, and restoring a copy of the metadata onto other hardware. Metadata that starts from nothing belongs to a different installation and gets a new ID. A license bound to the old installation does not start that new installation.

Terms beyond the fixed ones are shown in the same place as the fixed terms. mfslicinfo prints each of those terms as a row of its own, named by the term, between the client the license was issued to and the type of the license.

Past the limit, the cluster takes no data​

The bounds that a PRO license PRO (PRO Edition only) includes are enforced while the cluster runs. Each bound has a visible consequence.

When used raw space reaches the licensed figure, no new data can be written. Data that is already stored stays readable. The cluster keeps serving that data. However, the routines that keep data at its Redundancy Level have no space left to work in, so resiliency degrades as well. Warnings appear before that point. Alerts lists the messages and what each of them means. To get back under the limit, do one of the following: raise the licensed size, delete data you no longer need (snapshots included), lower the Redundancy Level, or empty the trash.

A time-limited license ends differently. Once the license expires, the cluster shuts down. A perpetual license does not expire, so the shutdown concerns evaluation licenses and any other license granted for a period. To keep such a cluster running, put a new license file in place before the expiry date. The expiry date is one of the terms written into the file, so a longer period means a new file rather than a change to the file you have.

A Master Server whose version is newer than the highest version the license covers does not start under that license. The Master Server reports that you are no longer entitled to use this version. To resolve this, get a license that covers the version, or run the version that the license was written for.

Moving the instance to Community Edition resolves each of these cases, but the instance loses the capabilities that PRO adds. CE and PRO covers that move.