Navigation path

Asset Description Metadata Schema for Software

3.37/5 | 19 votes
Editor's choice

Public comments on ADMS.F/OSS v0.3

Editor's Choice
13 message(s)
Former User
Public comments on ADMS.F/OSS v0.3
Posted by Former User on May 02, 2012 at 12:04.
( - , Europe )
5/5 | 1 votes

On May 2, the Asset Description Metadata Schema for Free and Open Source Software (ADMS.F/OSS) v0.3 Specification was released for public comments. Members of the public are invited to download the specification from the releases section and share their public review by posting comments to this forum topic (registration required). ADMS.F/OSS v0.3 is open for public comment till June 2 2012.

All comments are registered in an issue list that will be discussed by the Working Group on 5 June  2012. Resolutions of those issues will be shared on Joinup, and will lead to a final version of the specification that will be submitted to the European Commission for endorsement by the EU member states.

A good way to review the usability of the specification is by describing a software project, asset, and distribution using the spreadsheet template created for this purpose.


Patrice-Emmanuel Schmitz
Re: Public comments on ADMS.F/OSS v0.3
Posted by Patrice-Emmanuel Schmitz on May 03, 2012 at 14:34
(Joinup - legal expert, Belgium) - 17/01/2012

Hi Phil, I have some comments related to section 5.7 (Licence Type vocabulary):

  1. I suggest that the exact meaning of each category (or label) should be explained in a missing “description” field. i.e. what “Attribution” or “Known patent encumbrance” means (this may not be clear for everyone). Maybe it is the role of the “id” field containing a link (but I checked these links and it causes an error)...
  2. The proposed categories classify the “known legal regime” of the asset rather than the licence: if the asset is “public domain” (meaning works whose intellectual property rights have expired, been forfeited, or are inapplicable) or if it is “unknown IPR”, then – by assumption - no formal licence exists or is known.
  3. Some of the proposed categories may be convenient for describing the legal or licensing conditions of ADMS, but are clearly outside the F/OSS definition (which is indeed more specific to software than semantics). For example, the categories “Non-commercial use only” and “No derivative work” are in formal contradiction with the Open Source Definition (OSD). What is confusing is that the title of the project “ADMS.F/OSS” seems to inform recipients that all relevant ADMS are F/OSS compliant.
  4. I assume that a licence may be classified by “n” categories or attributes in this vocabulary: for example, a licence X can be “Attribution” and “Jurisdiction within the EU” and “Non-Commercial use only” etc. Right?
  5. The wording “Viral effect” is often perceived very negatively. The correct wording (popularised for software by the Free Software Foundation) could be “Copyleft”. But if you want a neutral wording, more convenient for semantic assets, I would suggest “Share alike” or “Share alike / copyleft”, meaning that the same licence must be used in the case or re-distribution. The wording “Viral effect” was coined by opponents to the GPL and is controversial because few legal certainties (case law) exist about it. If simple linking / interfacing at object code level ( = static linking) produces derivatives, then linking with a GPLed source could indeed produce a “viral” effect, but this is controversial (the opinion may be shared by a majority of F/OSS lawyers, but strongly contradicted by others and we are still missing case law to clarify such “virality” in the European legal context).
  6. I suggest that this “Share alike / copyleft” category should be at least divided in two parts:
  • Share alike / copyleft - not compatible/interoperable with other copyleft licences; (This is the case for the GPL or AGPL)
  • Share alike / copyleft with compatibility exceptions for larger work and interoperability (This is the case for the EUPL v1.1, MPL v2 and some other. It means that a larger derivative work can be licensed under another licence, if the exception conditions implemented for interoperability reasons are met).


Szabolcs Szekacs
Re: Public comments on ADMS.F/OSS v0.3
Posted by Szabolcs Szekacs on May 07, 2012 at 14:38
(European Commission, Europe) - 10/01/2012

Hi Phil,

I agree with Patrice (nr. 3), that there is a contradiction between the name of the ADMS specification and that some software may be not OSS.

I think however that it is important to be able to label a software as "non-OSS", as there are some repositories, which contain also non-oss projects (but which are nonetheless re-usable by public administrations within one member state). Joinup already federates such a repository and will hopefully federate even more in the future.  The ability then to filter out non-OSS software is very important for a future federated repository.





Stijn Goedertier
Re: Public comments on ADMS.F/OSS v0.3
Posted by Stijn Goedertier on May 07, 2012 at 23:32
(PwC, Belgium) - 10/05/2016

Thanks Patrice and Szabi for your comments on Licence Type. The following issue was raised for it:

It will be discussed in the WG Meeting of June 5.

Olivier Berger
Re: Public comments on ADMS.F/OSS v0.3
Posted by Olivier Berger on May 10, 2012 at 14:53
(Institut Mines-Telecom, France) - 11/01/2012

Here are my comments on the draft of specifications (0.3). Although I've already participated in earlier versions elaboration, I still have some remarks ;-)

I'll start by the most important ones, on the contents of ADMS.F/OSS, and will follow with a detailed log of some mistakes or suggestions of less importance I have on the document itself.

1. Important issues

There's a general problem with the naming of the 3 main entities describing software in ADMS.F/OSS, IMHO. Wording is quite important, even if the specs are meant for machines more than for humans. But we should seek to be less ambiguous as possible in the vocabulary for implementers to understand it the right way.

  • "Software Project" should be named "Software Product".

    A "project" is more an endeavour, a community, and that's not what is described here, AFAICT : we're most concerned with finding software than finding contributing communities.

    Apache is a "project" (and a foundation too), and 'httpd' is one of the products it develops.

    If the goal is not to differ too much of the wording of DOAP, in this respect (DOAP is generally more used for describing products than projects, I think), then this should be clarified explicitely in teh specs.

  • Software Asset : this should be named "Software release" or "Software version" or something like that, to clarify : "Asset" is very vague for forge implementors, and I'm not sure it will foster adoption to abstract too much the notions.

    Even if it inherits from ADMS:Asset, there's no need to keep Asset in the class name, IMHO.

  • Renaming to "Software Package" intead of Software Distribution would be better IMHO, as distributions (Linux distributions) refer to a large group of softwate distributed together, and I fear ambiguity here, again…

Also, the specs lack of examples, for instance as RDF in Turtle notation, which would help clarify these notions (see my proposed Open cemetary examples posted to the WG lists as a starting point).

Regarding the reuse of existing vocabularies / ontologies an the constraints they bring in, and the specific novelties of ADMS.F/OSS, the specs document lacks of a mean of traceability of the reuse of DOAP, RADion, etc. or of correspondance with these in case of renaming for equivalent notions.

In tables describing properties and relashionships in 4. Conceptual model :

  • the mandatory attributes should come first, so that conformance to the specs is easier to check.

  • the properties and relationships inherited from other schemas should be explicited, to distinguish what's really novel in ADMS.F/OSS.

  • the target schema of the classes for relationships should be explicted : "adms:Agent" instead of "Agent", etc. to avoid ambiguity between DOAP, FOAD, ADMS, RADion, etc.

About the qname of the vocabulary : I'd prefer to switch from 'admsf' to 'admssw' : "f" can stand for other stuff… and F/OSS seems to have slightly vanished now : "sw" is probably unique for software.

2. Less important details

2.1. Document metadata

  • Title of the document : slight inconsistency betw. the acronym and the title, which no longer mentions Free and Open Source software : this should be clarified in the introduction.

  • links to license and draft spec could be http:// instead of https://

2.2. 1. Introduction

  • ADMS.F/OSS is a metadata schema designed…

  • The intention is not to create an entirely new

2.3. 2. Conformance statement

  • v0.2 -> v0.3

2.4. 2.2 Data consuming conformance

  • one of three ways ? : don't understand

  • RDF conformance : add link to chap. "6. The rdf schema"

2.5. 3.1 Explore and search for software

  • The table (table 1) and discussion above may be moved to a later part of the specs, which "validates" the schema by analysing coverage of the use case needs, but only once the schema has been presented in details.

  • table 1 : some lines are greyed : what's the special meaning ?

2.6. 4. Conceptual model

  • "1. Date types" -> "1. Data types"

  • together with its properties -> their properties

2.7. 4.1 Data types

  • in the table : code : "value from a code list" ??? unclear : need explanation and reference to "5. Controlled vocabularies" ? An example of the use of ids, codes and URIs could be interesting, to explain the general principles with these adopted in the specs (best practices, etc.).

  • in the table : "Complex type (based on UN/CEFACT Identifier. Type ) consisting of:" -> "Complex type (based on UN/CEFACT Identifier). Type consisting of:

  • an optional identifier for the

  • identifier needs a few examples to understand that definition, IMHO

2.8. 4.2.1 Concept: Software Project

  • time-delimited : ??? why ? don't understand

  • id : URI for the project : if not a URL, which reference is supposed to be used ? as it is mandatory, what's exactly that URI ? Implementation dependant ? Example would help.

  • port of : what's the exact meaning of "port" in the context of ADMS.F/OSS : vague notion. Really needed ?

  • metrics : target is a Metrics Data Set and not an Agent AFAIU

2.9. 4.2.2 Concept: Software Asset

  • It refers to RADion Asset, but at the moment, there's no documentation of the RADion specs (but a diagram) which doesn't help verifying conformity. Again, making the prefix explicit in the tables would help figuring out what comes from RADion or what's novel here.

  • homepage : wouldn't "release notes" be better suited ? what's the difference between Project/Product:homepage and SWAsset:homepage

  • included asset : need to clarify the description : libraries / sub modules ?

  • included item : difference betw asset and item is unclear

  • metadata language : uh… what's that ?

  • spacial coverage : unused ? : let's not keep it ?

2.10. 4.2.3 Concept: Software Distribution

  • "a source code distribution and a binary distribution" -> "a source code package and installable package" would better represent the situation of scripting languages which don't require compilation (no "binaries"), but still need some sort of packaging for installation systems used by end users.

2.11. 4.3 Supporting concepts

  • "an number" -> "a number"

2.12. 4.3.1 Concept: Agent

  • type : reference error problem

  • looks like an agent needs a name, etc. … must be present in classes inherited from, so needs some mark of TBD later ?

2.13. 4.3.5 Concept: Licence

  • software licenses are different from other metadata / semantic / documents assets… should that be explicited there ?

2.14. 4.4 Trove classification concepts

  • IANAL, but I think there's no need to keep the "(© SourceForge 2012 CC by)" in the text, even if it should be explicited in the docs if sections are copyrighted by third parties and thus not necessarily subject to the license of that document. How is this different from other schemas like DOAP and FOAF in this respect ? This should be harmonized IMHO.

  • all the code, id, label triples for all the trove attributes look weird : how are code and ID related : shouldn't there be a sort of "factorization" here ?

2.15. 4.5.1 Concept: File Format

  • “targ.gz” -> “tar.gz”

2.16. 4.5.4 Concept: Theme

  • skos is not refered to in the bibliography

2.17. 5.11 Theme vocabulary

  • how's this different from topic : very generic terms like theme, topic and likes should if possible be more specific to be distinguished

2.18. 6. The rdf schema

  • introduction of that paragraph should be reworked / removed ?

  • needs a "TBD" marker or pointer to the document on joinup (published in between)

2.19. 7.1 ADMS.F/OSS Working group

  • Olivier Berger : remove the "TELECOM & Management SudParis campus,

for the " and add " (Institut Mines Telecom)" after TELECOM SudParis, please (the institute got renamed on April 1st 2012 ;).

  • Alain Peyrat : FusionForge -> FusionForge contributor

2.20. 8. References

  • DBpedia doesn't have proper [DBpedia] callouts as far as I coud see

  • DOAP is missing

  • DCAT is missing

  • SIOC : couldn't spot references to it in the specs

Roger Meier
Re: Public comments on ADMS.F/OSS v0.3
Posted by Roger Meier on May 23, 2012 at 23:53
(Siemens, Switzerland)

I really like the combination of existing industry standards such as DOAP, TROVE and SPDX. It is a great vision to integrate them into a common standard!

I have two questions at the moment:

  • Lot of F/OSS does depend on commercial software. Why do you completely ignore commercial software?
  • What about the ISO/IEC 19770 series did you had a look on this?

All the best!



Olivier Berger
Re: Public comments on ADMS.F/OSS v0.3
Posted by Olivier Berger on May 24, 2012 at 23:21
(Institut Mines-Telecom, France) - 11/01/2012

"F/OSS depending on commercial software" ? ... hmmm you probably mean "proprietary" instead of commercial, or "non free software", as free software can be commercialized ;-). Also, I'm not sure one can consider some software Free Software if it depends on non-free software, at least in the sense of the FSF's Free Software Definition or the Debian Free Software Guidelines. But that's not a big deal

Anyway, these details let aside, ADMS.F/OSS, even though initially envisioned to help describe Free and Open Source software, is largely applicable to any software, whatever its licensing conditions be. Unless I've overlooked some details.

As for ISO/IEC 19770, I don't think it has been mentioned yet in the working group. It would be interesting to have some more insights on its applicability in this context, IMHO. Any details on its IP status, i.e. the constraints imposed on implementing it on a practical point of view ?

Stijn Goedertier
Re: Public comments on ADMS.F/OSS v0.3
Posted by Stijn Goedertier on May 25, 2012 at 8:30
(PwC, Belgium) - 10/05/2016


Thanks for your comments, Roger and Olivier. The comment that ADMS.F/OSS could also be used to describe non-free software was also raised by Peter Brown from OASIS. I have listed the following two issues. Let's continue the disucssion there.

David Bicket
Re: Public comments on ADMS.F/OSS v0.3
Posted by David Bicket on May 31, 2012 at 15:48
(ISO/IEC JTC1 SC7 WG21 Software Asset Management, United Kingdom) - 22/06/2012

We need some more communication between these different standards development efforts. The ISO/IEC 19770 standards are probably quite relevant to what ADMS.F/OSS is trying to do, and there appears to be limited understanding about them in these other efforts. The standard for Software Identification ('SWID') Tags (ISO/IEC 19770-2) was published in 2009, and is starting to get significant market uptake. Major publishers such as Adobe and Symantec have a number of products using such tags, and Microsoft recently announced support. A number of installer products now support these tags (e.g. InstallShield, Advanced Installer, WiX, InstallAnywhere), as do an increasing number of software discovery and management tools. The US Government is working closely with because of the security uses of the SWID tag. (E.g. the Chief Security Officer of MITRE has stated: "MITRE sees the ISO/IEC 19770-2 Software Identification (SWID) Tag standard as a key enabler of highly reliable and automatable software inventory and assessment processes, and believes that widespread adoption of SWID tagging by software publishers will go a long way towards helping the nation protect its vital computing assets and infrastructures”.

To continue the conversation, I'd like to respond to a comment from Stijn that "The swid:software_id element is not URI-based". Here are some extracts from ISO/IEC 19770-2:

6.1.5 Unique identifiers

For the purpose of uniqueness, there are two elements that, combined, shall create a globally unique ID called the software_id. These elements are

a) tag_creator_regid

b) unique_id that may be either a GUID, or any reference unique for the tag_creator_regid. The unique_id shall follow the restrictions for URI character use as specified in IETF RFC 3986, section 2, Characters.

6.1.3 Unique registration ID (regid)

Software identification tags may be created by multiple different organizations and do not strictly require a centralized registration authority. Additionally, this part of ISO/IEC 19770 allows entities to create software identification tags for software configuration items they did not create (such as an organization creating software identification tags for their internal software discovery processes). To accommodate these requirements, this part of ISO/IEC 19770 will use a regid. The regid is based off of the iSCSI Qualified Name as defined in the IETF RFC 3720 – section and the IETF RFC 3721 section 1.1 and provides a unique naming authority reference.

A regid can be created by any individual or organization that owns or has owned the registration for a domain name (as specified in IETF RFC 1034, section 3.5 and IETF RFC 1123, section 2.1). The domain name does not need to be active, nor does it need to resolve to an address. Domain names by themselves do not constitute a unique identifier since domains because they can expire and/or be acquired by other entities this means a regid must also include a date that the domain registration was owned by the entity. Finally, for entities that wish to further sub-divide unique naming sub-entities, an optional suffix is provided for the regid that may be used, for example, to provide large software publishers means to allow each of their business units to manage their own software identification tags independently.

Examples of regids:,AccountingSystems,WordProcessing


Stijn Goedertier
Re: Public comments on ADMS.F/OSS v0.3
Posted by Stijn Goedertier on May 31, 2012 at 16:48
(PwC, Belgium) - 10/05/2016

Thanks a lot for your comment, David. Next week, we will propose the WG to include ISO/IEC 19770-2 identifiers in the specification, in particular to identify what is called "software distributions" (software packages) in v0.3 of the specification. One of the design principles of Linked Data, is to have de-referenceable URIs (http-based URIs). Based on a regid, would I know where to obtain the SWID tag? We already have raised the following issues:


Norbert Bollow
Re: Public comments on ADMS.F/OSS v0.3
Posted by Norbert Bollow on June 02, 2012 at 20:50
(, Switzerland) - 22/06/2012

The following comments refer to ADMS_FOSS_Specification_v0.3.pdf

page 9, metadata category "applicability", metadata property
"spatial coverage" and page 28, section 4.5.2:
-> The description "geographic region in which software can be used"
would in the FOSS context IMO require an additional explanation at
least, since it's part of the definition of FOSS that the software can
be used anywhere.

page 9, metadata category "provenance", metadata property "created"
and page 17, property "date of creation":
-> The description "date of creation" is very unclear to me,
since most software is not created in a single day. Do you want an
ISO 8601 date range describing the project which created the initially
published version of the software? But that also does not seem to make
a lot of sense practically: Even for software which was created as
part of a formal project (in the sense of having well-defined start
and end dates), that information is not likely to be readily available
to anyone except to the project manager of that project. And even if
that is what is meant, you need to provide guidance on how to handle
the case of software that is based on one or more software packages
from another publisher.

page 9, metadata category "People":
-> The category name "People" is capitalized. Is this intentional?

page 10, metadata category "format", metadata property "topic":
-> For this metadata property, the description "type of software"
is given. I find this confusing. In my understanding, "type of
software" is something entirely different from its topic. For
example, for a given program, I might answer a question about the
"type of software" as "an application program that is locally
installed on this PC", while I would answer a question about the
topic of this software as "text editing".

page 10, metadata category "accessibility":
-> The term "accessibility" is normally understood in the sense of
"accessibility to people with disabilities". I propose that the
"access URL", documentation and homepage metadata properties should
be moved to the "availability" metadata category, and that experts
on the field of accessibility to people with disabilities should be
consulted to obtain guidance on what metadata properties are in the
area of accessibility.

page 10, metadata category "interoperability credentials":
-> "related asset" is not a good name for a metadata property to
express "the specification implemented by the software". I propose
to use "interop spec" as name for the metadata property.
-> Change "the specification implemented by the software" to "a
specification implemented by the software", since complex software
assets implement multiple interop specs.

pages 11, 14, 15, 18; sections 3.2, 4.2.1, 4.2.2:
-> There are numerous references to "projects developing software".
Indeed, in the FOSS community, initiatives that develop software
are very often called "projects" even though that usage of the word
"project" clashes with the generally accepted and standardized IT
management terminology. For example, the standard ISO/IEC 15288:2008
(IEEE Std 15288-2008) titled "Systems and software engineering -
System life cycle processes" defines "project" as "endeavor with
defined start and finish dates undertaken to create a product or
service in accordance with specified resources and requirements".
In fact also the definition of "software project" on page 14 of the
ADMS.F/OSS specification correctly defines the term as a time-limited
undertaking. However the example that is given following the
definition is not such a time-limited undertaking. I propose that
the ADMS.F/OSS specification should use the phrase "project or
initiative" in most places where it currently says "project". This
would avoid being incorrect, while still being understandable by
people who expect long-term initiatives that develop FOSS software
to be (arguably incorrectly) referred to as "projects".

page 11, new section 3.3
-> Add at least brief information about the relevance in the context
of software asset management processes, as described and standardized
in ISO/IEC 19770-1. I am willing to provide proposed text upon

page 12, second paragraph, first line:
-> The term "purpose built platform" is unclear: It could be
understood mean to mean either "something programmed specifically
for the purposes of a particular repository initiative" or "an
installation of a software system developed for the purpose of
serving as a repository".

page 14, "code" data type
-> It should be clarified whether it is permissible to create new
code values if none of the values in the published code list is
appropriate, whether there is a registration authority for such new
code values, etc.

page 14, "dateTime" data type
-> The set of syntactic formats specified in ISO8601 is very rich. It
would be better to specify a subset such as the dateTime format of
XML Schema, see - in fact,
something called "dateTime" data type should probably defined by
reference to this specification of the XML Schema data type and not
by a reference to the much broader set of syntactic formats of ISO8601.
Alternatively, the ADMS.F/OSS specification could simply use dates in
ISO8601 YYYY-MM-DD format without going into the issues of times and

page 14, "URI" and "URL" data types
-> The use of internationalized domain names should be allowed, as
defined in RFC5890.

page 16, section 4.2.2, first paragraph, first line
-> The term "intellectual content of the software" is unclear.
-> It should be clarified that software assets are not necessarily
executable software. ISO/IEC 19770-1 appropriately clarifies: "For the
purpose of this part of ISO/IEC 19770, it is typically important to
include both executable and non-executable software, such as fonts,
graphics, audio and video recordings, templates, dictionaries, and
documents." I propose to include a similar note in the ADMS.F/OSS

pages 16-19, section 4.2.2
-> The way in which conformance to interoperability specs can be
asserted should be defined in detail. I am willing to provide proposed
text upon request.

page 17, property "keyword":
-> There is a typo here, "word of phrase" should read "word or

page 18-19, section 4.2.2
-> Should be aligned with ISO/IEC 19770-2 so that
(1) it is made clear how to translate information from an ISO/IEC 19770-2
software identification tag to the data model of the ADMS.F/OSS
specification and vice versa, and
(2) it is made clear how to search repositories for software assets that
are related to a software asset for which a ISO/IEC 19770-2 software
identification tag is available.
I propose that this should be discussed in detail with the ISO/IEC
working group which is responsible for the maintenance of that
standard (ISO/IEC JTC1 SC7 WG21).

page 23, measure "average time to close support tickets"
-> the description should be changed to clarify that for purposes of
this metric, support tickets should not be considered "closed" until
an adequate response has been provided, regardless of whether e.g. the
ticket might have been marked as "closed" in the bug-tracking system
-> millisecond precision makes no sense here.

page 24, dimension "time"
-> no "Period of Time" datatype has been

page 42, section 8
-> include ISO/IEC 19770-1 and ISO/IEC 19770-2 among the references.

David Bicket
Re: Public comments on ADMS.F/OSS v0.3
Posted by David Bicket on June 02, 2012 at 23:01
(ISO/IEC JTC1 SC7 WG21 Software Asset Management, United Kingdom) - 22/06/2012

This is feedback to the public release of ADMS.F/OSS v0.3, on behalf of ISO/IEC JTC1 SC7 WG21 which is the working group responsible for international (ISO/IEC) software asset management (SAM) standards.  There are three SAM standards of particular relevance: ISO/IEC 19770-2:2009 Software Identification Tag (also know as 'SWID' tag); ISO/IEC 19770-3 Software Entitlement Tag (in development); and ISO/IEC 19770-7 Tag Management (in development).  Because of the response deadline of 2 June, this can only be limited feedback.  Those working on a daily basis with the SAM tagging standards will ultimately be able to contribute more.



The use cases for ADMS.F/OSS and the ISO/IEC 19770 tagging standards are different but within a common context where many of the properties (or elements) required are common, and where implementation requirements may overlap significantly.  At a minimum, it would be desirable to have normalization of common properties/elements.  More beneficial yet would be common implementation approaches, which could facilitate the practical market uptake of ADMS.F/OSS recommendations.  The Software Identification Tag in particular is already being implemented by major publishers, installation packagers, and software management tools, and ADMS.F/OSS could leverage from this.

In simple terms the principle use cases or purposes could be summarized as follows (unofficial versions):

  • ADMS.F/OSS: to be able to discover from publicly available catalogues whether there is (F/OSS) software available meeting specified criteria.
  • ISO/IEC 19770-2 Software Identification Tag: to identify software authoritatively (both in distribution and as installed), and with it to provide the metadata needed for managing that software.  (This tag is focused on software released for use, and not while under development)
  • ISO/IEC 19770-3 Software Entitlement Tag: to encapsulate the licensing rights and limitations and optional licensing metrics for using specified software.
  • ISO/IEC 19770-7 Tag Management: to provide guidance about how to use and manage tags.



There are many elements which appear to be common between ADMS.F/OSS and the ISO/IEC 19770 tagging standards.  It has not been possible to do a mapping for the purposes of this response.  However, to give a flavour of the areas of apparent commonality, a list is included here of top-level elements from ISO/IEC 19770-2:2009.  There are many more elements one level down which I am not listing but which are also likely to be common (e.g. installation_locale):


Mandatory elements

  • Product title (‘product_title’)
  • Product version (‘product_version’)
  • Software creator identity (‘software_creator')
  • Software licensor identity (‘software_licensor')
  • Software unique identifier (‘software_id’)
  • Tag creator identity (‘tag_creator')

Optional elements

  • Abstract (‘abstract’)
  • Component association (‘component_of’)
  • Components list (‘complex_of’)
  • Data source (‘data_source’)
  • Dependency (‘dependency’)
  • Element owner list (‘elements_owner')
  • Installation details (‘installation_details’)
  • Keywords (‘keywords')
  • License and channel information (‘license_linkage’)
  • Package footprint (‘package_footprint’)
  • Packager (‘packager’)
  • Product category (‘product_category’)
  • Product family (‘product_family’)
  • Product identifier (‘product_id’)
  • Release date (‘release_date’)
  • Release identifier (‘release_id’)
  • Release package (‘release_package’)
  • Release rollout (‘release_rollout’)
  • Release verification (‘release_verification’)
  • Serial number (‘serial_number’)
  • SKU (‘sku’)
  • Software creator alias (‘software_creator_alias')
  • Software licensor alias (‘software_licensor_alias')
  • Supported languages (‘supported_languages’)
  • Tag creator alias (‘tag_creator_alias')
  • Tag creator copyright (‘tag_creator_copyright')
  • Tag version (‘tag_version’)
  • Upgrade for (‘upgrade_for’)
  • Usage identifier (‘usage_identifier’)
  • Validation (‘validation’)

Extended elements

  • Extended information (‘extended_information’)


Note that both ISO/IEC 19770-2 and ISO/IEC 19770-3 are designed to allow extended elements, i.e. anyone can create tags with additional information appropriate to their own purposes, and this capability could easily be used to add ADMS.F/OSS elements.



It is not clear the extent to which ADMS.F/OSS is intended to be directly implementable.  However, the following observations are offered concerning its possible implementation, which also reflect on common implementation possibilities with ISO/IEC 19770-2 Software Identification Tags and ISO/IEC 19770-3 Software Entitlement Tags:

Static Data vs Variable Data.  ADMS.F/OSS appears to contain both static data and variable data, and these intrinsically do not co-exist well in a single data structure.  For example, most data about a particular software distribution will be static, but data relating to 'used by' and 'next version' (described as 'newer version of the Asset') could be variable.   The static data associated with 'assets' or 'distributions' is probably all possible to implement in ISO/IEC 19770 tags.

Whether F/OSS needs Software Identification Tags.  It seems obvious that F/OSS needs to be identifiable in an authoritative way just as any non-F/OSS software needs to be identifiable in an authoritative way, regardless of whether or not there is a publicly available catalogue of such software.  Consequently, it seems logical to have ISO/IEC 19770-2 Software Identification Tags for all F/OSS.  A consequence of this is that much of the necessary information for the implementation of F/OSS would be – or could be, by using Extended Elements – readily available throughout the software ecosystem, collected by standard software discovery and management tools, without the need for a duplicate and overlapping software management capability just for F/OSS.

Ability of Extended Elements to Link to Publicly Available Catalogues and Other Resources.  It is possible to include elements in the Software Identification Tag and Software Entitlement Tag to link to external resources such as publicly available catalogues, documentation, and sources of guidance.  A separate type or types of information structure could be defined for use on these external resources, e.g. to hold variable information such as 'used by' or 'next version', and to define or provide links to projects.  (A similar approach is being developed for linking the Software Identification Tag to security vulnerability databases (e.g. for the US Government), so as to automate much security control functionality which is currently largely manual.)

Segregation of Software Identification and Software Entitlement Information.  ADMS.F/OSS appears to combine information about software itself, and software licenses.  This was the original approach taken by WG21 in developing its tags.  However, it was determined that in most cases, at least for non-F/OSS software, software and licenses are distributed via different channels, and consequently it was necessary to create separate types of tags to reflect this market reality.  Obviously, it is still possible to distribute the two types of tags together, such as for retail software, and this could also be done for much F/OSS.  However, if you want an approach which will co-exist easily with the software management requirements of non-F/OSS software, you may wish to clearly separate the two types of information as WG21 has done.  Based on the fact that some distributions can be available under different licenses, the WG21 approach may be more appropriate in any case for F/OSS.

Publicly Available Repositories.  It has been proposed to have publicly available repositories of Software Identification Tags, in particular through, and such a development could integrate with some of the use case objectives of ADMS.F/OSS, in particular if Software Identification Tags for F/OSS include the necessary elements and URI/URL links to enable that functionality.



Different Understandings of Terms 'Asset' and 'Software Asset'.  ADMS.F/OSS appears to use the term 'software asset' in a way which is consistent with the ADMS definition for 'asset', but in a way which appears to be inconsistent with most industry in general, and with most of the IT industry (not just the software industry).  In particular, the ADMS.F/OSS approach is that an asset is abstract or conceptual, independent of any physical embodiment.  This usage will probably cause confusion between F/OSS and non-F/OSS communities.  The term 'Software Asset' as used in ADMS.F/OSS is probably most clearly translated for non-F/OSS communities as 'product', with the corresponding element being product_id.

Opportunity for Including ADMS.F/OSS Requirements in Future ISO/IEC Tagging Standard Amendments.  It would probably be possible to include ADMS.F/OSS-specific requirements in future editions of the ISO/IEC tagging standards.

Methods of Working Together.  We can find ways of working together if we wish, but have to deal with the fact that ISO standards, once published, cannot be distributed for free.  We can share standards under development but need to do this in accordance with ISO directives.  The easiest way to do this would probably be to establish a formal liaison relationship between the entity responsible for ADMS.F/OSS, and ISO/IEC JTC1 SC7 WG21.  It is also possible for individuals working on ADMS.F/OSS to join one of the development groups under WG21, but this would provide access only for them and not for a broader community.


David Bicket
Convener ISO/IEC JTC1 SC7 WG21






Stijn Goedertier
Re: Public comments on ADMS.F/OSS v0.3
Posted by Stijn Goedertier on June 03, 2012 at 23:01
(PwC, Belgium) - 10/05/2016

Thank you very much for your detailed review and comments, Norbert and David. The following issues have been raised and we will get back to you in the coming days to further discuss alignment with ISO/IEC 19770.


Subscribe to newsletter

You will receive news and links to the most interesting developments...