maturity, purchase cost, license

Jon Ison recently requested four types of updates and new classes within SWO. Some parts of his requests are already in SWO, but all could do with a little look at again, to make sure we’ve got what he needs. Below the changes for 3/4 updates are discussed.


Specifically, Jon is looking for the terms alpha, beta and production. We already have the development status hierarchy, which contains a number of terms including alpha and beta, and some which may be suitable for production. After asking Jon how the current hierarchy fits with what he wants, he has said that by Production he means “software that has been designated as suitable for production environments by the developer / publisher”.  He thinks as well that Production is a synonym of Live (as currently defined) and recommends that it becomes a parent of First release and Latest release.

Changes to the ontology

  • Alpha
    • Expand the definition to: Alpha is a development status which is applied to software by the developer/publisher during initial development and testing. Software designated alpha is commonly unstable and prone to crashing. It may or may not be released publicly.
  • Beta
    • Expand the definition to: Beta is a development status which is generally applied to software by the developer/publisher once the majority of features have been implemented, but when the software may still contain bugs or cause crashes or data loss. Software designated beta is often released publicly, either on a general release or to a specific subset of users called beta testers. (Modified from, accessed 11 June 2013.)
    • Add creator and definition source
  • Live
    • Expand the definition to: Live is a development status which is applied to software that has been designated as suitable for production environments by the developer/publisher. If a non-free product, software at this stage is available for purchase (if it is a non-free product).
    • Add creator and definition source (Allyson Lister, Jon Ison, & Modified from, accessed 11 June 2013.
    • Add synonym Production
    • Put First release and Latest release as children of this class
  • Comments
    • Something can be both Maintained and Live, but may also be Live but not Maintained (specifically, these should not be – and are not – disjoint classes). In this context, Production remains best suited as a synonym for Live, as Production status does not require any level of maintenance, just that software described as such is formally released.

Purchase Cost

For modelling purchase cost, there has been a long long discussion on the SWORD mailing list (see “Cost of software” emails from May) and the final decision is to associate the cost with the license. Robert suggests using either a GCI or a defined class for each of FeeBasedSoftware and FreeSoftware, and to have these classes be defined as those which have licenses containing clauses which mark them as either free, free with caveats (e.g. for academics, or for a base version such as with IntelliJ), or non free.

Changes to the ontology

  • New classes within license clause
    • Purchase cost clause
      • Free
      • Not free
  • Comments
    • The “free” used within the purchase cost hierarchy refers only to the cost of the software, not to the definition of “free software” as provided by GNU and which is commonly used to describe “software that respects users’ freedom and community. Roughly, the users have the freedom to run, copy, distribute, study, change and improve the software.” (
    • In some ways, purchase cost does seem similar to the already-extant usage clause hierarchy, which includes restricted and unrestricted usage. However, a usage limitation is not necessarily due to whether or not something costs money: even if the usage is academic only, it could still be either free or non-free. A license could have multiple usage clauses, e.g. academic only when free, and unrestricted if a fee is paid. Instead, a new clause type which is specifically associated with cost (Purchase cost clause) has been created which can, together with a usage clause, define both limitations and cost. Then statements could be made such as the following:
      • GNU GPL v3 has clause Usage unrestricted
        GNU GPL v3 has clause Free
    • A license could have multiple clauses dealing with different aspects of cost and usage. For instance, how do I model a license that, for academics, is free while for all users generally, there is a fee. We don’t need a “free with caveats” option (except as a defined class) within the purchase cost, as this can instead be modelled by combining usage and cost. However, I’m not sure the following axioms would describe accurately the example I’ve just given
      • LicenseX has clause Usage academic only and has clause Free
        LicenseX has clause Usage unrestricted and has clause Not Free
    • Modelling in this way means we don’t have to create a load of defined classes to represent all of the different classifications of software. We can instead use GCIs to categorize our classes without cluttering the hierarchy or creating complex naming schemes (see For now, I haven’t added any GCIs but it is certainly something which could be used in future.


License already has a number of child classes. Jon suggests tidying up this section by using the short form of the license name (e.g. GNU GPL) as the primary name, and all other versions as synonyms. Also, we need to add more flavours of each of the licenses, e.g. all the versions of GNU GPL and of Creative Commons. was a valuable resource for the changes itemized below.

Changes to the ontology

  • New object property: is compatible license of: this will allow links between licenses which do not contain conflicts, e.g. that the Apache License version 2 is compatible with GNU GPL version 3.
  • As many people are familiar with a “free” license as defined by the GNU Project, a defined class GNU Project Free Software License has been created which can identify such cases (see
  • GNU Copyleft Software License is a child of GNU Project Free Software License, and software which is copyleft must 1) be free software according to the GNU project, and 2) requires that all modified and extended versions of the program be free as well.
  • A new license clause has been added: Copyleft (a child of derivative code same license as it not only requires the same license, but limits the type of license used to one which will provide a certain number of freedoms to the users of the code). This allows us to build the defined class GNU Copyleft Software License
  • All currently existing licenses have been updated in the context of all of these changes, resulting in many new axioms. A few new licenses have been added, but these are not exhaustive. New classes are: CC0, CC BY 2.0, CC BY-SA 2.0, GNU GPL v2, GNU GPL v3, MPL v1.1, MPL v2.0
This entry was posted in modeling. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s