Motivation for the DevWheels Licence

Because the source and build systems are both exposed, it's much easier for users of Free and Open-Source Software (FOSS) to both customise their installations and fix any problems, either themselves or with the help of the community of users who can see exactly what the software is doing. Source is the ultimate documentation. For this reason, source-available software is often better-supported than closed software, especially for less-wealthy users.

The other great advantages of FOSS are its unhindered cooperative development model, made possible by unrestricted redistribution of both copies and derived works, and the trialling of full versions without payment.

Not having to pay to subsequently use the software in any way is a bigger draw for some users than others.

From a developer's perspective, it's easy to see why almost all open software is released under a FOSS licence, when charging for open software has some large downsides:

  1. Paying users have dramatically-raised expectations of quality and support, including warranty, no matter how small the fee.
  2. Promotion is more likely to be regarded as spam, because its self-serving nature is more obvious than with software funded by either donations, support, proprietary products and services, selling users (ads), or glory (and its associated employment prospects) — there ain't no such thing as a free beer. Often companies will provide free development and distribution infrastructure only to FOSS projects.
  3. Some will be offended by the audacity of charging, encouraging individuals or businesses to become heroes of the community by creating a free clone. This is more likely for smaller open packages that provide a popular component service. The ability to inspect how a solution works makes one forget the difficulty of an unrecognised problem, a good solution, and a blank editor.
  4. Openness makes avoiding payment even easier and more likely. One must rely on a combination of reasonable licence fees, moral pressure on individual users, and safety, reputational, and support pressure on business users.
  5. Arranging payment for deployments that use a large number of charged components has the potential to be burdensome, and some users will have trouble affording a large aggregate expense.

Against these, one must weigh the advantage of making it much easier for independent developers to earn a living from their open software itself, rather than through non-market and indirect means, by closing all or part of their work, or through a licence that restricts competition (can't sell, can't fork or sell, can't serve, can't use in certain ways, we can integrate your mods for free). Free-software licences, with their focus on user freedoms, practically removes the freedom of developers to exploit their work.

Most FOSS is created either by companies who sell either closed products or their users' data, by developers who want to advertise their skills to such companies, or by companies who sell support to the few who can afford it. The remaining software done as a hobby or for donations (often unacknowledged, and with a freeloader problem) has issues with quality and support. For most users, the best form of support is a polished release with good documentation. Polish can save a significant part of deployment costs.

The DevWheels Licence has been designed to make it feasible for software to be both commercial and fully-open. Software (and other material) placed under this licence can be freely copied, and modified versions released. The software can also be used without charge for evaluation, testing, and development. Developers can however require that certain classes of users pay to run their software in a production context. These payments go not only to the developers of the deployed package, but to the developers of packages from which that package has been derived, right down the fork trees, according to their value-add as set by the packages' pricing increments above what their directly-upstream packages have charged. This value-add doesn't have to come from improvements in code or documentation, but someone with marketing nous can make money by charging more for distributing an under-priced package, which may encourage the original developer to charge more for later versions, helping software find its market price.

This need not create a proliferation of packages. In lieu of releasing their own version, developers are encouraged to instead try to have their improvements integrated back into the original package, perhaps in exchange for a revenue share.

This ability of contributors to be paid for their work is in contrast to so-called open-core software, which uses Contributor Licence Agreements to socialise the work but privatise the profits.

The DevWheels Licence describes a sources.txt file that keeps track of licence conditions and fees down fork/source trees/graphs, allowing end-users to work out how much they need to pay to buy a licence, and developers to work out how much they must charge to be able to pay their immediate sources, without too much trouble as upstream packages change.

However, as mentioned in Point 5 above, this does have the potential to be a logistical and financial burden when a deployment brings together a large collection of software, each with different licence conditions, and with complex graphs of developers and source packages. So although the sources.txt file is sufficient, can be used if no software help is available, and makes sure that no software has a monopoly, the licensing and payment burdens could be greatly eased with a website that:

In 2008 I launched the (currently-down) website that did precisely this for Ruby on Rails plugins that had been licensed under an earlier version of the DevWheels Licence (the RailsWheels Licence). I hope to soon re-launch this on

RailsWheels also addressed Point 4 by providing a means to prevent software from running in a production context unless the user explicitly recorded that they had bought a licence. While this was easily bypassed, it did make piracy a conscious act, giving some users, especially business users, pause. Unfortunately, unlike Ruby on Rails software, it is often not straightforward to determine whether a package is running in a chargeable production rather than a development/evaluation context.

The "Dev" part of the licence name comes from "development" or "developer". The "Wheels" part comes from the philosophy of not reinventing the wheel, which is much easier when there are no restrictions on evaluation or customisation.

Mark R. James
January 6, 2019