A Guide for Creators of
DevWheels-Licensed Packages

This is a guide to your benefits and obligations when either you use or allow others to use a work of yours that's subject to a DevWheels Licence, used either remotely or after distributing copies. You put a work under a DevWheels Licence either by choice or because your work is derived from one or more DevWheels-licensed works. See the licence text for the precise rules.

The idea of the DevWheels Licence is, like open licences, to eliminate both friction and lock-in by removing the normal legal impediments that make it hard for people to create, trial, and share works that draw from one or more existing works, while at the same time, unlike open licences, making it feasible for all creators to earn income when their works are put to good use.

It does this by requiring that certain users pay a fee each time they use a work in their intended (deployed) application. The owners of the work being used must in turn pay use-fees to each of the works from which their work was directly derived, so their work will normally be priced greater than the sum of these, hopefully reflecting some sort of added value, or even just better marketing. These owners then must pay the owners of their source works, and so on. Such fees are also owed for DevWheels-licensed dependent works that need to be present for the central work to be either used in that way or be built to be used in that way, whether or not that central work itself has a DevWheels Licence.

You need such a mechanism to reward everyone who contributed to creating each bit of that work when you want to allow unlimited tweaking and re-mixing — like open software — but at the same time make it feasible for creators to earn income. The same tension exists in the video space: Compilation and commentary videos are often worthwhile, but they often either appropriate their source material or can't easily access good source material because of either automated copyright takedowns or burdensome negotiations.

All the below seems complicated, but that's just because this use-licensing process is open, making possible competing and interacting licensing assistant services that have consistent rules and transferable users, as well as a manual fallback. But it will normally be just like an app store, with end-users making payments, and developers registering their apps and bank details. The only extra complications are that developers have to identify any other DevWheels-licensed apps from which their own app has directly drawn, and make sure that both what a single licence covers and how their pricing varies for different categories of users are compatible with the same for these source works.

The source tree of a DevWheels-licensed package

Each version of a DevWheels-licensed package must include a "source tree", which is either a file named sources.txt or a "Sources" Section (for non-file-based packages). A source tree is a list of blocks of text that each specify the licensing a of work, referred to as a version of a package, each indented to reflect the (graph-derived) tree-like structure of how one package version was used to derive another, with the package version for which this source tree has been compiled' at root of the structure and the top of the list.

A source tree gives enough information for end-users to license use by paying the owner of the top-listed package, for that owner to in turn pay the owners of the package versions from which they directly derived their package (indented one level), and so on down each chain of derivation until all contributors are compensated according to their price. Each package version owner keeps the difference between what they've been paid and must pay, so price increments hopefully reflect whatever added value each package version provides, although promotion work can lead to much larger premiums.

Minimising package proliferation

If you've developed improvements to a DevWheels-licensed package version, instead of releasing your own derivative package you can first use the "Licensing Contact" field of the spec of that package version at the top of its source tree to see whether the managers of that package version are willing to integrate your changes into their package. This may include an agreement to forward a certain percentage of their licence revenue from uses of their package that contain your work. For your safety, make a permanent authenticated record such agreements, however a licensing service/app store may support fee distributions arising from such agreements.

These revenue share agreements reduce the proliferation of packages, while still rewarding all added value.

When should my work have a DevWheels Licence?

If you create a version of a package that is directly derived from one or more package versions that are subject to a version of a DevWheels Licence, including when your package version doesn't make any changes but just takes ownership of an existing package version, then unless you either own or get the owners' permission for all DevWheels-licensed package versions from which your package version has been sourced through some chain of DevWheels derivation, or if your package version just bundles one or more essentially-unchanged DevWheels-licensed package versions with unchanged ownership, your package version must also be subject to a DevWheels Licence before you make that package version available to be used in a chargeable production context, either privately (including by yourself) or after a public release. You must use a version of the DevWheels Licence that is at least as high as that used by one of the package versions owned by others from which your package version package version has been directly or indirectly derived.

DevWheels is viral in this way to ensure that the owners of derivative works get paid when their work is indirectly put to good use, allowing such works to be freely made and distributed, but compensated in a fair way.

Of course, you can always voluntarily add a DevWheels Licence to a new or an existing work, as long as it doesn't conflict with another of the work's licences. Choosing DevWheels as your package's licence is a way to give users peace of mind that they can both freely trial the work and are not dependent on you to make improvements, while still compensating you for your work, even if your work is only mainly used as the basis for more popular works. You can still charge for additional support. Don't choose DevWheels if you think you can convince sufficient customers to be locked-in to you as the only vendor and maintainer. That's how big companies are made.

Note that the DevWheels Licence regards copying an unfair number of the names and call signatures of an API as creating a derivative work. This is a view on the main issue raised (but not resolved) by the Google vs. Oracle US court cases over the Java API. You can contradict this by adding an exception to your package's licence that reverses Term A(ii) of the DevWheels Licence.

What must I do when I just distribute DevWheels-licensed works, perhaps in my own package?

Under a non-conflicting licence, you can distribute or allow remote use of your own package that contains DevWheels-licensed works, as long as for all such works where you're not changing the ownership to make your own DevWheels package you make sure that users and potential users are clear about when and how they must license their use of each work. Do this by preserving any in-work licensing, pointing out the circumstances when each work is used, and providing a copy of each work's licence and source tree.

If you're just re-distributing separate copies of single package versions, this usually means you don't have to do anything extra.

What must I do when I release my DevWheels-licensed work to the public?

You don't have to publicly release a DevWheels-licensed work. However, any derivation sources of that work must still be paid if you let anyone (including yourself) use it privately, whether or not you got paid.

If you do make a version of your package available for some or all of the public to use — used as either a local copy or a remote service — you are required at the same time to keep publicly available via the location link of that package version, at no more than a small premium on your cost of delivery, the means and an accessible way to create derivative works of the whole work as released, that are able to be used in all the free ways (evaluation and development).

For software this means making available both its source and an understandable and accessible way to build the package from that source. You can choose whether to strip out the work's production licensing code, leave that code but remove your specific licensing data, or leave both so that your licensing is seen by those who build from source unless they disable it.

How much should I charge?

Before you can make one of your package versions available for use, by you or others, in a chargeable production context, you must prepare a source tree for this package version. By preparing its derivation tree you can see what fees you must forward to the package versions from which your package version has been directly derived (indented one level, but not marked as a duplicate). These are your package version's direct sources.

The "Licensing Conditions" field of each spec of a package version in your package version's derivation tree will both define its chargable unit-of-use (including the time a licence lasts), and describe which types of users pay what use-fees for each of those units-of-use.

To create the licensing conditions for your package version you must first choose a unit-of-use (including a period of use) that is compatible with the units-of-use of all DevWheels-licensed package versions from which your your package version has been derived through some chain of derivation, so that one use of your package version becomes a fixed number of uses (the upstream ratio between units-of-use and licence-quantity doesn't have to be one) of each package version that is in the derivation tree. You will have to negotiate with the managers of any package whose unit-of-use for that version is incompatible with the way you want to charge.

Next you have the option of dividing your potential licensees into numbered "use-cases" that differ in their attributes (e.g. student, government, non-profit) and/or their intended use (e.g. components used, deployment size). At the end of each use-case you state the use-fee for one-unit of use, in one or more currencies. Your package version is free to deploy for those not covered by any use-case, although you can make one explicit by describing a use-case and its zero use-fee.

Like the units-of-use, your use-cases must be compatible with your whole derivation tree, with each of your non-free use-cases mapping to either a free use-case of a directly-upstream package version, or to a (proper or not) subset of a non-free use-case, progressively down each line of derivation. A mapping of this subset type ensures that each of your use-cases maps to no more than one use-case in each source package version, otherwise it would be hard to set a uniform fee for each. Your direct sources (indented one level in the source tree) will have done this when preparing their own source trees, so once you're compatible with them, you're often right with the rest. Again, incompatibilities have to be resolved with agreements with your sources, because your choices affect what money you forward them. You should strive to make your use-cases similar to those of your upstream sources so that they do not have to expand in number and complexity.

Other agreements are possible: You could want to make an agreed reduction in a source's prices when either your package version only partially draws from that package version, or if, because of a change in that package's unique name, it has a substantial overlap with another source package version that is missed by the procedure to remove duplicate sources from a derivation tree.

When you come to an agreement, you should alter the licensing conditions for those package versions, as written in your package version's derivation tree, noting the changes with " (AS AGREED) ", so the reason for the deviation from a package version's normal conditions and fees is clear. For each use-case for which an agreement alters its fees, you have to propagate the effect of that change on the net pricing for use-cases downstream from that in the source tree (except your top package), using the procedure below for adjusting for duplicate versions of a package.

Once you have your final derivation tree and know when and how much you need to pay others for each use of a use-case of your package version, you can set your own prices at least as high, with a premium that hopefully reflects the added-value you've brought through improvements in functionality, packaging, ease-of-use, or discoverability (marketing).

You have three options if you either want to or have to charge in a different currency to the payments you have to make to the owners of packages from which your package version has been directly derived: You could offer end-users a fixed price by performing currency conversions at this time of compilation of your source tree. The disadvantage being that currency movements could eat into your margin, which cannot be fixed until you release a new version and withdraw the old. Second, you can write prices as an unresolved addition and subtraction of various currencies. Although this would mean that currency movements no longer affect your earnings, it makes it harder for end-users to compare prices, unless a licensing service can automatically calculate and show the current amount in their desired currency. Finally, you can negotiate with your source packages to instead pay them in the currency of your choice, again noting any such agreement.

Put your final prices and conditions in the Licensing Conditions field of the specification of your package version in its source tree. Once you start distributing this source tree to potential users you cannot make any changes to that source tree other than adding a line withdrawing that version to the reference source tree available through the package version's location link. This ensures that the licensing conditions are common no matter the distribution. Changing a source tree requires withdrawing that version and issuing a package with a new version-ID.

There is no requirement to agree to a request from a upstream package to withdraw and re-issue a version of your package so that fields of their spec can be changed. However you should generously consider infrequent requests for adjustments to use-case fees due to either inflation or currency movements, or adjustments to payment fees imposed by third-parties. But you are entitled to resist a price increase from an upstream package because they underpriced their work, and think you are capturing more than your fair share of value. They need to develop their own improvements that you may want to later integrate for an appropriate derivation share.

If your package version and its downstream package versions are exclusively available through the same licensing service, they may hold regular re-pricing negotiating rounds, after which all source trees can be simultaneously updated and new (possibly dated) version-IDs issued. Otherwise, after you withdraw a version it's good practise to contact any downstream package versions, either those which you know about or those from which you have received forwarded fees, both to ask them to move to the new version and to remind them that any new derivative versions they issue must move to a non-withdrawn version of your package.

How are upgrades charged?

You can write into the licensing conditions of your package version your own way of charging users who want to change one of their uses of your package to one with a higher version-ID. This will apply to both manual licensing and app store licensing that supports that upgrade method.

However the DevWheels default is to charge the difference in price between the two versions, hopefully reflecting any enhancements to the product. Upgrades are free when there's been no price increases or use-case changes, which can be easily be seen if the "Licensing Conditions Last Change Version" field of the source tree specification of this package version is the same or lower than the version-ID of the currently-licensed version. This default doesn't allow ongoing maintenance payments unless licences are made non-perpetual.

Just like full licence payments, upgrade payments must be forwarded upstream the source tree, in the form of upgrades to those source package versions according to their versions in the old and new versions of the derivation tree of the package that the end-user has upgraded. So if you're using a custom upgrade calculation method, you'll be out of pocket unless all these are sufficiently similar.

If a end-user's use-case changes to one with a higher fee, they are required to pay the difference to continue to use the same version, with the fee difference again propagated upstream.

You must fulfil any request to change a use to a version with the same or lower pricing, upgrade or downgrade.

How do I make sure users pay?

A publicly-released DevWheels-licensed package must also make public all material needed for the whole work to be built, used, and re-distributed, modified or not. This openness does make it impossible to enforce a required payment, even if your licensing "calls home", because it's easier to work out how to disable a licensing mechanism. As an incentive against this, you can give licensees better support or perks, such as pre-release access to new releases, as long as an unlicensed release of your work can still be fully-used for development, evaluation, and re-release.

It's still worthwhile to embed a licensing incentive in your most-easily-deployed distributions, because it makes bypassing licensing a conscious and inconvenient act of either obtaining the raw release and disabling its licensing, or getting a copy of such. This could be unlicensed nag messages, requiring entry of a licensing unlock code, regular verification with your licensing servers, or ways to discourage downstream packages that don't forward the required use-fees.

There is a risk that DevWheels is a half-way house that would give you the worst of the permissive and proprietary worlds: Those used to normal open-source may resent your audacity to charge, while feeling that bypassing a licensing requirement is easy, just, clever, and undetectable; while those used to proprietary software may not appreciate the lack of lock-in, being more appreciative of the well-funded support that normally comes from such walled gardens. But it will be exactly what some customers want — peace of mind while establishing a supportive vendor relationship beyond charity. And from the developer perspective, lack of income has been holding back open-source by developers who aren't subsidised by a well-paying job, often those in developing countries. And it may also suit you as an easy way to get both virality and income, reducing your marketing burden.

Can I refuse to license a use?

If you have ethical issues with a use, you are allowed to refuse to accept payment and license that use. That user can however legitimately get around this. You will have to either accept your forwarded fee or have that fee absorbed by the downstream package owner.

Do I have to pay to use my own work?

You don't have to license your own DevWheels-licensed work while you are developing it by making changes or integrating it with other works, nor when you are internally testing your work in preparation for deployment or release. However, before you deploy this work of yours for your intended use, either by testers or some of your intended users, both for the first time and after each version upgrade, you must ensure that your work has a DevWheels Licence, which sometimes makes you liable on deployment to pay the creators of any work from which your work has been directly derived.

So when deploying your own package, follow the procedure given here for paying the owners of any package versions from which your package has been directly derived, as if you had just paid yourself as an end-user.

Licences can be transferred to new uses or licensees

DevWheels allows a user to transfer a use-licence to different deployment or a different user, including selling it. You are obliged to perform a requested transfer if you can be satisfied that the original licensee will no longer or can no longer make their current use of your package version. You can however either refuse to perform a transfer to a licensee with a use-case that is different from the original licensee, or assign such licences a value.

To make licences fully portable, once you have received payment from a licensee for a use of your package, they can request that you issue them with a text version of that licence in the following form:

      Package: <unique-package-name>
      Package Version: <licensed-version-ID>
      Use ID: <unique-ID-for-this-use>
      Licence Quantity: <number-of-licences>
      Licence Issued: <YYYY-MM-DD>
      Licence Expires: <YYYY-MM-DD or "never">
      Licensor's Signature: <digital-signature-of-licensor>

"Use ID" is an identifier chosen by the owner of the package version licensed by the end-user to be unique over all uses of that package. But because you're allowed, but not required, to issue licences for package versions upstream from this, make this use-ID fully unique by prefixing it with the unique name of the package for which this licence relates, followed by a "." character.

The "Licensor's Signature" field is a digital signature you choose so that you can verify the authenticity of a licence text with near-perfect accuracy.

You must make a transfer on presentation of a licence document by that document's owner.

If you have been paid for a use by a downstream derived package rather than by an end-user, you do not have to allow the end-user to directly use your package version, to issue then a licence document, or comply with a transfer request, although you can offer some of these services. If you do offer these services you would need to be informed of the use-ID chosen by the package version that has been licensed by the end-user, allowing transfers for this use to be synchronised. Also record the end-users' use-case associated with each use-ID so you know how to handle requested transfers.

From what material can I draw to create a DevWheels-licensed work?

Without having to get permission from the owners, you can freely integrate material that's either in the public domain or under either a DevWheels or a permissive licence (MIT, BSD, Apache, CC-BY, etc.), though when placing the integrated package under a DevWheels licence you should abide by any conditions in the source licences (such as retaining copyright notices), making it clear what extra conditions apply to which parts.

In order to put public-domain material under licence, you must either creatively transform or significantly extend the work.

You cannot however freely integrate any material under a whole-work copyleft licence (GPL, CC-SA, etc.), because such licences are incompatible with a DevWheels licence. (DevWheels is a copyleft licence, but not a free-use one.) You can integrate work licensed under the Mozilla Public Licence (MPL), though the integrated portions themselves also remain under the permissive MPL.

You can always try to obtain a special licence from the copyright holders to integrate any material. But if you want to distribute your package, that special licence must also apply to your downstream users and developers.

What do I need to include in my DevWheels-licensed package?

As well as the text of the version of the DevWheels Licence to which your package version is subject, you should include the package version's source tree.

A source tree starts with a specification of the package version itself, followed by similar specifications for the DevWheels-licensed package versions from which your package version was derived through some chain of influence, if any.

The source tree: The specification block of this package version

At the top of a source tree is a specification of the version of the package to which the source tree belongs, without any indenting:

DEVWHEELS-PACKAGE <unique-package-name>
Name: <descriptive-package-name>
Version: <version-ID>
Location: <link-to-package-version>
Licensing Conditions: <licensing-use-cases-and-associated-licensing-fees>
Licensing Conditions Last Change Version: <version-ID>
Payment Information: <payment-information>
Licensing Contact: <licensing-contact-information>          

For example:

DEVWHEELS-PACKAGE jsjbridge.advancedcontrols.com.au
Name: JavaScript-Java Bridge
Version: 1.2
Location: https://github.com/mrj/jsjbridge
Licensing Conditions: $20 Australian Dollars per browser
Licensing Conditions Last Change Version: 1.0
Payment Information: Paypal jsjbridge@advancedcontrols.com.au
Licensing Contact: mrj@advancedcontrols.com.au

The unique package name should not contain a white-space character, and be unlikely to be used by another package. The preferred way to achieve this is to follow a name that's unique over all your packages with a dot character and an internet domain that you control.

There are no restrictions on the descriptive package name, including being the same name as packages by others. But be careful of violating trademarks.

The version number or version ID should imply a standard ordering from earlier to later versions. See Wikipedia's Software versioning article for some ideas.

The presence of line below this package version field that states "VERSION WITHDRAWN YYYY/MM/DD" indicates both that it is not possible to license use of this version of this package after the given date and that package versions whose release or first non-evaluation use is made after the given date are not permitted to derive from this withdrawn package version and put it in its source tree, unless there is no non-withdrawn version of this package that provides nearly all the functionality of this withdrawn version, in which case derivation and unlicensed non-evaluation use is permitted. Fresh versions deriving from fresh source trees aims to encourage the propagation of any pricing updates, with a protection against being locked-out.

The "Location" field is a link through which a copy of this version of this package can be obtained, and optionally used. The most recent version of the source tree of this package version must be accessible through this link, which can only differ from other versions of this source tree by the presence or absence of the above version withdrawal line. A direct link to this source tree is one way to provide the required source trees to managers to whom fees are forwarded. Both the location and source tree links should be chosen for maximum longevity.

The "Licensing Conditions" field tells prospective licensees who must pay what for what use. If you have a licensing website that helps prospective licensees, you can put a link to this first. But a full description of the licensing conditions must follow, both in case the site is down, and for creators of derived packages to be able to work out their own compatible licensing conditions, mindful of their added value.

One thing you should make clear here is the package's sole and only unit-of-use — the extent (including period) of use that one licence encompasses. It could be one per user, per hardware component, per software component, per amount of usage, etc., each perpetual or lasting a month, a quarter, or a year. In the example above it is perpetual use on one browser (a software component).

If you're creating a version of a package that has been derived from one or more DevWheels-licensed packages, you must use the same unit-of-use (other than a quantity variation) so that each use of the package results in a fixed indirect use of each of the packages from which it has been derived, and hence a predicable payment chain. Agreements can be reached to change the unit-of-use of a source package version as stated later in the source tree to make it compatible.

The licensing conditions can either apply to all prospective licensees or can describe one or more use-cases, which can vary according to the attributes of the prospective licensee and the intended use of that package version by that prospective licensee. If there is more than one use-case, they must be numbered.

A licence fee (which can be zero) should be appended to the description of each use-case, or simply stated for a sole unrestricted use-case. A licence fee can either be specified in a single currency, in multiple currencies, or as a sum and difference of amounts in more than one currency, protecting you from the effect of exchange rates on forwarded fees. In this case, use of licensing software prevents users having to do the calculation and conversion to their payment currency themselves. Use not covered by any use-case has a zero licence fee.

The most simple licensing condition is therefore a single fee for a given perpetual unit-of-use. Each licensing fee you specify must include all charges required to obtain a licence for that use, with the exception of payment surcharges and discounts that are independent of use-case, which are specified in the "Payment Information" field below.

Leave the Licensing Conditions field of this package version blank for now until you see how any package versions from which your package has been derived constrain your unit-of-use, use-cases, and prices.

The "Licensing Conditions Last Change Version" field specifies the version ID of this package version sequence for which a licensing condition last changed, allowing users to quickly assess their need to pay an upgrade fee, and for package creators deriving from this new version to know when they do and don't need to update their own licensing conditions in order to maintain compatibility and margin.

A "Payment Information" field follows. This instructs both prospective end-users and package managers that must forward payments to packages from which their package has been derived how to pay their required licence fees, and may be just a link to a payment processor. The text must describe any surcharges or discounts for the use of particular payment methods and currencies by particular payers. It may be hard to withdraw a version from the market if you link directly to a payment processor.

The package specification is completed by a contact information field that allows both package licensees and managers of derived packages to notify you of their licensing payments and initiate negotiations on altered licence conditions and fees. This field also allows potential contributors to initiate negotiations on integrating work into your package, perhaps in return for a share of your licensing revenue.

Package specifications can be written in a language other than English. However the English names of the specification fields must still be present at the start of lines, with comma-separated translations appended in brackets: For example, "Location (Standort, Indawo): ..."

The Source Tree: The Derivation Tree

A blank line should follow the specification block for the package version for which this source tree is being constructed, followed by a four-space-indented and blank-line-separated concatenation of the source trees of each of the DevWheels-licensed versions of other packages from which this package version has been directly derived, in the form each tree existed when material from each source was last drawn, as altered by any agreement. Do not regard an earlier version of your package as one of these direct sources, though your package may appear in the trees of one or more of these sources (all of which will be zero-priced as duplicates).

When creating the derivation tree for either a new package or a new version of a package you must check that none of the package versions in the tree have been withdrawn, unless there's no non-withdrawn substitute version, in which case you can draw from a withdrawn package version. To do this check, visit the "Location" link of each and see whether there's a "VERSION WITHDRAWN" line in their reference source tree.

By giving specifications for all package versions in the derivation tree of the package version in question, as altered by any agreements, the source tree of a package version becomes the master reference for determining how each is compensated for each use of this package as payments are forwarded upstream, not any of the reference source trees of the package versions in that tree.

The version of the source tree that you interpolate from a DevWheels directly-upstream package version must be no earlier than the one that existed when all the material you integrated also identically existed. So if you're being selective about what you take, you can sometimes reduce licensing costs by drawing-from/synchronising-with an earlier version of the package than the current one.

A source tree can contain package specifications with prefixes other than "DEVWHEELS-" that relate to source works not subject to a DevWheels Licence. These specifications are ignored for the purposes of DevWheels licensing.

Because the derivation tree of a package version may actually be a graph due to more than one package version being derived from the same package version, the source tree that results from the above source tree concatenation procedure could contain duplicate package version specifications. We want to remove these duplicates so that each package version is credited only once. Moreover, we want to only credit a package from a given set of authors/managers/releasers once, even if the package for which this source tree is being compiled was derived from a number of versions of a given package through different derivation chains. We only want to include the specification of a given package with the highest version, which should be the one with both the most to offer and the highest price, excluding the fee influences of the others.

To do the duplicate removal, first find any unique package names prefixed with "DEVWHEELS-PACKAGE" that are listed more than once, ignoring any specifications already prefixed with "DEVWHEELS-DUP-PACKAGE". A UNIX shell command to help you find these is:

grep 'DEVWHEELS-PACKAGE' sources.txt | sed 's/^[[:space:]]*//' | sort | uniq -cd

Then for each of these, pick one that has the highest version ID that will be kept as a non-duplicate. This also applies to lower versions of the top package for which this source tree is being compiled. This top package will alone have the highest version of that package, and will be chosen as the non-duplicate.

The specifications of the package versions not so picked must be changed to replace "DEVWHEELS-PACKAGE" with "DEVWHEELS-DUP-PACKAGE".

Following that, each package version marked as a duplicate must be revisited to remove its contribution to the prices of the package versions above it in its derivation chain (indented less), ignoring both specifications that are already duplicates and the top specification itself. So for each non-free use case of a package version marked as a duplicate, then for each such package on the chain, change the fees in their "Licensing Conditions" field of all use-cases that are either the same as or a subset of that duplicate use-case to first replace the fee with"<original-fee> (NET <original-fee>)" if the bracketed net pricing is not present, then subtracting from the net fee the net fee for the duplicate use-case, or the original fee if there's no net pricing. If two currencies differ, do not use the current exchange rate, but rather write the net fee as a subtraction that can be resolved at a time of your choosing, including letting a licensing service resolve this at the time of each licence purchase.

Be wary when concatenating source trees that you may have introduced hidden duplicate packages because a package has been (deliberately?) released under multiple names. If left undetected and uncorrected, the licence fees you must forward will be higher than they should be.

Once all duplicates have been removed, and you've similarly adjusted for any agreements, and can see what fees you need to forward to your directly-upstream package versions you can confidently set the fees of your own package version.

Whenever you prepare to make a new release, make sure you retain a copy of the source tree of the old release at its original permalink accessible from that old release's "Location" permalink, so that both you and upstream forwarders can still refer to it if an end-user either licenses that version or upgrades from that version.

Integrating updates from a DevWheels-Licensed upstream package

If you integrate new material from one of your existing directly-upstream package versions, you must obtain a new copy of that package's source tree, as it existed when all of the sourced material first identically existed, or a later version. Integrate this source tree into the source tree of your package in place of the (once-indented) old version, and redo the procedure given in the last answer to ensure that there's only one non-duplicate/non-excluded of each package spec, and that this has the highest version among all specs of that package, and set your new net pricing.

You again have to check that no source in the tree has been withdrawn. If it has, you may be able to use a later version, or, if its work has been integrated into another package, you can substitute the source tree of that package. Otherwise, the spec of this package version needs to be removed.

Look at the "Licensing Conditions Last Change Version" field of an upgraded upstream package to see whether its licensing conditions have changed since the version from which you once sourced. This may reassure you that your own licensing condition don't need to change, or prompt you to either change your own conditions or to enter a negotiation about putting changed conditions in your package version's source tree.

Negotiation may also be indicated when you are plucking a subset of changes that do not reflect the full work involved in the update of the direct source.

Do the same with any new DevWheels-licensed directly-upstream package, but this time add their source tree to the bottom of yours, separated from the package above by a blank line, and indented four spaces.

Removing derivation from an upstream package

If you have written or integrated material that means that your package version is no longer derived from a particular package version in your source tree, remove it from the source tree and adjust your licensing conditions. If the removed package version is further than directly upstream, you will first have to get approval from the package versions in-between to forward lower fees because one of their sources is no longer your source. Remember, the source tree of the package version directly-licensed by the end-user is the master list of forwarding responsibilities, not the home source trees of each package version on this tree.

If your package is no longer derived from any DevWheels-licensed package, you can optionally no longer use DevWheels as your package's licence.

Make sure that all newly-integrated material that triggered the source removal was created with clean-room design, meaning that the dependency on a package was removed by independent creation or reverse engineering, without a derivation that violates its DevWheels Licence.

After receiving a licence payment from an end-user or downstream package

The source tree of a package version that's directly-licensed by the end-user not only describes in its top spec what use-fee this end-user must pay, the derivation tree of this source tree also specifies how portions of this payment must be forwarded down each chain of derivation.

If this source tree of the end-user-licensed package version says that your package version has been directly derived from one or more other Devwheels-licensed packages that are not marked in this source tree as duplicates, then when you receive a fee subsequent to the end-user making a chargeable production use, you have to in turn forward some of that payment the owners of each of those direct-source package versions. This payment may come from an end-user, which you mimic if either you or someone you've authorised is the end-user, whether or not your package is public, or you may have been forwarded a payment from a package version one-level downstream in the derivation tree.

You don't make any payment when your package version has been derived from an earlier version of the same package (it either won't appear in the source tree, or will be listed as a duplicate), and you only do so for versions of other packages that you own if that version has in turn been derived from a package version owned by others. That is, for the manual forwarding method, each package version in the derivation tree only pays package versions that are adjacent (one level) upstream, and you simulate payments to yourself for packages you own so as not to miss anyone else. Licensing services will do this as a single fee distribution for all package versions it covers, contacting other services to complete the rest.

Here is the full manual procedure:

First you need to know whether an upstream payment you must make is a full payment for the version or an upgrade from a lower version. The upstream payment will only be an upgrade if both (a), the licence payment you have received is an upgrade payment for a change in this use of your package to a version of your package with a higher version-ID, and (b), a version of that direct-source package is also a direct-source of your package in the source tree of the package version that was previously-licensed by the licensee. This upgrade will be from the version of that direct-source package in the source tree of the package version that was previously-licensed by the licensee to the version of that direct-source package in the source tree of the package version that has been newly-licensed by the licensee.

If an upgrade payment is due, unless a different method for calculating version change fees has been specified in the licensing conditions of that direct-source in the source tree of the package version that has been newly-licensed by the licensee, the fee owed is the difference between the net fees as stated for the licensee's use-case in the licensing conditions of that direct-source in the source trees of the newly-licensed and previously-licensed versions of the package that has been licensed by the licensee for this use, in one of the listed currencies, with no fee owed if this difference is not positive.

If a full payment is due, the licensing fee you owe to that direct-source is the net fee as listed for the licensee's use-case in the licensing conditions of that direct-source in the source tree of the package version that has been newly-licensed by the licensee, in one of the listed currencies. When only a change in use-case has been purchased, the forwarded fee will instead be the difference in fees for the two use-cases of the upstream package version, if positive.

If during this forwarding of payments up the derivation tree you owe a fee to yourself as owner of a package, you act as though you received that fee, subsequently paying fees to any upstream package version. This ensures that all other owners in the tree are reached.

You need to let the receiver of your payment know, either as part of the payment flow or via the "Licensing Contact" information, the unique name of the package owed this payment, the use-case number of the end-user licensee, the licence period (if not perpetual), both for the licensee and for this forwarding, either a copy of or a link to the source tree of the package that has been newly-licensed by the end-user, and, for upgrades, the source tree of the package version from which the licensee has upgraded. If source trees are provided through an earlier communication, the associated package names and versions must be provided at time of payment.

Unless there's an agreed other schedule, you have 40 days from receipt of a payment to forward the appropriate shares to your directly-upstream sources, making it possible to process licensing payments once each calendar month.

If an attempt to pay a source is unsuccessful, you will make regular attempts to both pay what is owning and to contact the source to inform them of your payment failure. If after 60 days you are still unable to pay a source, instead attempt to pay each of this source's direct sources their required net licence payments as specified in the source tree of the package version licensed by the end-user. You can either keep any remaining unclaimed portion fee, or refund the end-user. Again, follow the procedure given in this answer to make your payments, moving deeper into the source tree if unsuccessful until either all branches of the source tree have been paid, or the packages you are unable to pay have no upstream sources.

If you want to guard against downstream developers not promptly forwarding your licence shares, without threatening to shame or sue them for breach of contract, you can add a condition to your package licence that mandates downstream use of a particular licensing service/app store, to which you link in your "Licensing Conditions", so that end-user payments pass through a trusted processor. You can also convince, with or without public pressure, a licensing-service/app-store/hosting-service to remove a package version which you know to have a false source tree. For software, you can mandate downstream retention of an internal licensing mechanism.

Any licence fee that remains after paying your direct sources should be divided according to any revenue-share arrangement that has been made.