https://joinup.ec.europa.eu/asset/adms_foss/topic/public-comments-admsf/oss-v03#comment-12267

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.

CONTEXT

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.

COMMON PROPERTIES/ELEMENTS

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.

With ADMS.F/OSS we do not want to reinvent the wheel and try to maximally reuse existing vocabularies. See for instance this news item on the reuse in the v0.3 release. The ADMS.F/OSS v0.3 vocabualry is represented in RDF Schema, meaning that it is inherently open and extensible. 

If ADMS.F/OSS was implemented using the extension mechanism provided in ISO/IEC 19770-2:2009  XML schema, I believe this would require the specification to be implemented as an XML-schema only (option 1). In my view, several other alignment options exist:

• Option 1 - Drop the ADMS.F/OSS RDF vocabulary and implement ADMS.F/OSS as an extension to the  ISO/IEC 19770-2:2009  XML schema. 
• Option 2 - Provide a mapping to the ISO/IEC 19770-2:2009  XML schema. This option would at least ensure that software description metadata in a SWID tag can be converted into ADMS.F/OSS format and vice versa.  
• Option 3 - Add a regid-based software identifier: The ADMS.F/OSS specification provides a means to include an identifier based on the SoftwareIdComplexType for a software distribution.
• Option 4 - Link to the SWID tag: ​This option would require a SWID tag to have an access URL where it can be obtained. 
• Option 5 - Embed the SWID tag: This option would involve embedding the entire SWID tag as an XMLLiteral inside the RDF code. This option requires tool support to parse the XMLLiteral, which will be opaque for most RDF parsers.

Regarding alignment with ISO/IEC 19770, I wouldn't mind anyone trying to make sure there's some interoperability between ADMS.F/OSS and it, but I'm concerned about the licensing conditions on that "standard"'s specs.

IMHO, we should make sure to promote open standards, here, in particular as the tools like FusionForge used by many forges are FLOSS tools.

Still, in David Bicket's comment (https://joinup.ec.europa.eu/asset/adms_foss/topic/public-comments-admsf/oss-v03#comment-12267), in "Methods of Working Together", I read : "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."

That would be a show stopper for most FLOSS contributors, I'm afraid (this assumption is only mine and not my employer's obviously).

I'm afraid this is potentially a very classic troll, but nevertheless a practical matter regarding the potential for dissemination to every FLOSS developer, Public Administration, etc. potentially wishing to contribute to FLOSS meta-data standardization.

Maybe the ADMS.F/OSS particular focus on F/OSS metadata description is finally indeed justified, even though the specs are fairly generic ;-)

I hear Olivier's concerns about wanting only 'free' standards, and if that is what the ADMS.F/OSS group wants, then so be it.  But I feel that there is a major risk of throwing out the baby with the bathwater over the issue of 'free' standards vs 'open' standards.  I did not become involved in ISO because I took a decision to go over to the dark side.  I did it because I saw it as the most effective way to get the market to adopt good software asset management practices, which would help all end-users deal with this incredibly complex area.  That is happening, and ADMS.F/OSS can leverage off of it, or can re-invent its own approach if it wishes.  There is no requirement for everyone who will benefit from the ISO tagging standards to buy copies of them, any more than it is necessary for people who benefit from ISO security standards (ISO/IEC 27001 et al) to buy a copy of them.  The question I believe is simply how to leverage.  But a limited number of people will probably need to buy copies of the ISO standards if they want to make it work.

The issue of open standards is an emotive one as is readily apparent from doing a web search on the term.  Some people like Olivier explicitly or implicitly appear to equate 'open' with 'free'.  Wikipedia doesn't take this line, rather giving a less restrictive definition while recognizing that differences of opinion exist.  ("An open standard is a standard that is publicly available and has various rights to use associated with it, and may also have various properties of how it was designed (e.g. open process). There is no single definition and interpretations vary with usage."  It goes on to define "publicly available" as "easily available for implementation and use, at a reasonable price".)    The issues about what is 'open' are not limited to just cost.  For example, I read the following in one discussion thread on the topic: "Time and again in the last year, the definition of "open standards" is being raised as a "problem". For whom? It is difficult to pin down: by one definition, none of the de jure bodies would qualify (because they sell standards); by another, organisations like W3C wouldn't qualify (because it is not incorporated as a not-for-profit); by yet another IETF would not qualify (as it isn't a structured, governed organisation). If you define an open standard in such a way as to exclude anything with any IP claim, you would exclude MPEG, JPEG, Bluetooth, WiFi, ODF'.'