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:
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.
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:
sources.txtfiles. GitHub have told me that the unrestricted-forkability of DevWheels-licensed software makes such packages eligible to be placed on their free accounts, despite the DevWheels Licence not meeting all the criteria for an "open source" licence.
sources.txtfile. The same enforced simplification would be done with licensing periods, being perpetual and/or quarterly.
In 2008 I launched the (currently-down) railswheels.com 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 devwheels.com.
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