Release machine readable unit list as open source

[tdunning]

There is a significant problem currently with the way that UCUM artifacts are released.

That is that the current UCUM license is not a recognized open source license and will not be. There are several issues:

• field of use limitations (section 3.a.i, primarily)
• no derivative works (3.a.iv and 3.a.v)
• no changes allowed (3.a.iii and 3.a.iv)

Another major impediment is that the UCUM license is not a standard license at all and thus requires a major legal review before adoption.

These issues would prevent the use of any components from the UCUM web site, for instance, in any project of the Apache Software Foundation and would probably prevent similar use by my current day job (but I am not speaking for them).

Obviously, this doesn't restrict the creation of applications that merely comply with the UCUM standard, but given recent court cases, I would expect significant hesitancy about such an implementation because it would be hard to do a clean implementation without direct and extensive reference to source materials from the UCUM repository which are subject to this license.

I can see that the current license is a reasonable one for a traditional standard. But I would also contend that the goal of UCUM would be substantial enhanced if there were some assets available under a standard, permissive open source license such as Apache License 2.0, BSD or MIT.

To that end, I would suggest that there be an additional repository under https://github.com/ucum-org/ that contains the following files:

• README.md, a file describing the files and the purpose of the repo
• LICENSE, a verbatim copy of the Apache License 2.0
• ucum-ci.units
• ucum-cs.units
• ucum-essence.xml

Over time, it might be useful if reference implementations of basic UCUM functionality could be hosted in this repo as well, all under the same open source license. I would expect that this functionality would include a UCUM parser, a generator and a compatibility checker that integrate with whatever unit computing framework is dominant in the language of the reference implementation. One example of such a framework is Julia Unitful.

I can create a prototype of such a repository if desired.

The expected short-term result of this repository would be the direct adoption of UCUM in the current day job project I am working on as well as in a number of open source projects. We could probably also turn the creation of this repository into a bit of a social media event which would raise the profile of UCUM in communities where it is not yet well known.

@ucum-org/advisors
@dr-shorthair @timbrisc

[dr-shorthair]

Related to #159

[tdunning]

This issue is definitely related to #159 but should be much more easily accomplished because it doesn't open up the issue of changing the license on the standard itself.

[dr-shorthair]

Indeed.

[gschadow]

Oh not again.

It doesn't have to be "standard", UCUM is not software, so a software license does not apply.

UCUM is free and open to use.

It is CRITICAL and VITAL that the license must prohibit re-publication with changes ("Here is a better UCUM with my favorite unit added and the one I hate banned" -- Cannot allow that.)

This is TOTALLY different from open source software where it is intended that software may be copied and tweaked and improved. But software is software and language is language.

Different things. If there are people who do not appreciate it when first looking at it, so be it. Over time they will understand or simply not care any more because they can do what they need without worrying.

[dr-shorthair]

Developers don't consider things 'over time'. If it is not a license they have seen before, they will just go elsewhere, and re-invent our wheel. Is that what you want?

The current bespoke terms give the impression that any systematic use of UCUM codes in software risks violating some license because it is a 'derivative work'. We know that is not the intention, but that is the impression that has been taken many times, including by some sophisticated people.

Could we please have a clarifying statement up front that developers are encouraged to use UCUM codes in their software. At the moment they can't tell.

[tdunning]

 Oh not again.

No need to be so dismissive. This is not my first rodeo. I was VP for Incubation at Apache and also on the board of directors. I have seen and evaluated more licenses than you are likely to see in your lifetime. I have dealt with many corporations, large and small, on license issues. This is a problem.

It doesn't have to be "standard", UCUM is not software, so a software license does not apply.

First of all, adoption is often critically gated by whether or not a license is standard. In corporate settings, non-standard licenses require a major legal review cycle. If there are two alternatives, both alike in many respects, the one with well understood terms will be accepted and the other strongly deprecated.

And second, it doesn't matter if UCUM is software or not. There is a part of the standard (the units files) which are machine readable and very useful for a software implementation that interoperates with UCUM. Unfortunately, those files cannot be used by software because they have a restrictive, non-standard license. Even worse, they can't even be adapted into a roughly equivalent file in, say, Python because the current license says "no derivative works". The only thing safe in that respect is a clean room implementation, but that isn't possible either because clean room makes no sense with a standard that we want to refer to in creating software.

As such, you have two goals here that lead to conflicting positions. The first is the one you expressed relative to maintenance of the standard in a stable and controlled form. That's fine and laudable. The second goal is the one I have, which involves the use of the standard in machine readable form.

SO ...

This is why I offered to create an alternative repository which contains the machine readable bits of the standard that are suitable for use in software and even to create one or more reference implementations. This alternative repository would be licensed under a standard software license because it would clearly be software. The standard itself could continue to be released under whatever home-brew license you like to use. Both the standard-must-not-be-tainted and the software creation goals would be met.

And relative to @dr-shorthair 's suggestion that there is a clarifying statement, that really doesn't help. There is still the license sitting there in all of its determinative glory. The only way to bindingly change the license for parts of the overall standard without changing the license is to extract the bits you want people to re-use and license those in a way that encourages re-use. You can clarify until you are blue in the face, but corporate legal counsel won't budge. Been there. Done that. Failed for good reason.

How about it? Mind if I create a micro-repo with the files in question, an Apache license and a README? It seems to solve for both goals.

[colin-e-hscic]

I have to agree. I flagged the UCUM license terms as a potential red flag for our use of UCUM in the UK, with the prohibitions on either super- or sub-setting the unit set as the major concern.

One lesser issue, but one I haven't seen mentioned much is the question of localisation. Once upon a time there was mention in the UCUM documentation about localisation to "languages other than English", which raises some interesting questions as we speak English here, just not the same English that the folk at Regenstrief do...

[gschadow]

When I said "oh not again" I meant endlessly meandering ruminations without substance or direction.

[...]

Now that all said, I see that specific issues were raised, and I will address them, fully counting on the good faith effort of all participants to engage the issues and not just come back to the FUD "it's unusual to people so we are scared" argument. OK?

I acknowledge your believe and intent to make specific actionable changes, and I quite welcome that.

This issue is definitely related to #159 but should be much more easily accomplished because it doesn't open up the issue of changing the license on the standard itself.

So let's go in that spirit and dive into detail not endless ruminations.

• field of use limitations (section 3.a.i, primarily)
• no derivative works (3.a.iv and 3.a.v)
• no changes allowed (3.a.iii and 3.a.iv)

Let's dive in. To quote the license of Section 3 you mention (BTW, the text at https://ucum.org/license has a problem with item b. that should be roman numeral i.)

Section 3. License Conditions.
Your exercise of the License Grant is expressly made subject to the following conditions.

a. You may not:
i. use the Work for the purpose of developing or promulgating a different standard for identifying units of measure;
ii. use the Work in any way which may dilute the Work’s purpose of providing a definitive standard for identifying precisely defined, unambiguous units of measure in electronic documents and messages;
iii. use the Work in any way that expressly or implicitly change its meaning;
iv. add, delete, or modify the Work’s content including field names, field contents, descriptions, and comments; or
v. use the Work to create Derivative Works.

Now your issues

• field of use limitations (section 3.a.i, primarily)

The characterization of this as a "field of use limitation" is perhaps true in a metaphorical sense, perhaps jurisprudence has set a precedence on this understanding, I defer to your expertise. But this is extremely important for any standard out there. SNOMED, UMLS, and any ISO standard deal with this issue. Nobody says (in healthcare sector for example) "we won't use SNOMED because it's not open source and we don't like the license", they begrudgingly do it, just like people shell out the money to buy ISO or IEEE standard documents to implement them.

For all these standards some clause on non-promulgation of derivative work is critical for the content that is being distributed, and any discussion on this issue must acknowledge an understanding of the criticality of this issue. I don't care what developers think. But I do care what lawyers think. Clearly no self respecting standard organization can allow for its specifications to be just copied and redistributed if they want to make money on them (as ISO and IEEE apparently do want to make money). UCUM and LOINC does not, so UCUM and LOINC are way more open than ISO, IEEEE, SNOMED. But we do not appreciate to be bashed around for that while nobody claims "we're not going to implement the USB or BlueTooth standard because we have to pay for the document and abide by a non-standard license". (This sort of attitude leads me to "not again" response.)

UCUM and LOINC are way more open than ISO, IEEE and whoever issues the USB and BlueTooth standards. Give us some credit for that. But also, realize that no standard organization can allow redistribution of modified content claiming "hey, we are USB++" while the other company issues the "USB# standard". We will not allow UCUM++ or UCUM-- to be redistributed. Period.

This is the subject of item ii. to which -- I note -- you did not object. Great, I think we can resolve this then.

• no derivative works (3.a.iv and 3.a.v)

I agree that "no derivative works" clause is too restrictive. I agree. And vow to work on fixing that. Clearly it is OK for anyone to create their own UCUM "table", and distribute them with their software for example. I, for example, take the UCUM source and transform it into a JSON syntax which I then load and instrument with javascript classes to add the UCUM semantics, functional, computable, etc. Clearly such a thing must be allowed. And clearly such a thing would be considered "derivative works" under case law, and it is clearly not our intention to prohibit such use.

• no changes allowed (3.a.iii and 3.a.iv)

This one we probably can hold on to, if we qualify of what "change" means. Which is critical, because any derivative work that puts the content into a different form is also a "change" of something.

We do not intend to prohibit any creation of subsets for any specific use of UCUM.

We do not intend to prohibit removal of some annotations or adding others to the UCUM concepts, nor creation of relationships to other concepts. For example, if someone has a kind-of-quantity terminology (like LOINC is one) then making links to UCUM and thereby incorporating a subset of UCUM into LOINC, would not be a prohibited act.

The only thing that is FUNDAMENTALLY different from the animus of open source licenses on which we have to insist, is that open source's purpose is to create modifications, improvements, even drastic changes totally uninhibited. (Does it really, always? Was the MIT X11 license permissive of complete changes of the interfaces? Maybe. But I don't remember that now.) For us and for SNOMED and for IEEE and for ISO it is inconceivable that someone comes and says "hey, here is a derived variant of the IEEE 488 standard which we say is IEEE 488-turbo-plus."

Let us acknowledge this issue and try to hammer out a better text of the license, without using overly broad prohibitions on "derivative works" and defining "changes" so as to continue prohibit unacceptable changes and green-light prima facie "changes" that are not the kind of change which we intend to prohibit.

I accept that the license can and shall be improved. Working with these specific issues.

If there is some "widely accepted" license out there that accomplishes our intention, then by all means we should be inclined to use it. But if our intentions and needs are being negated as irrelevant, then we continue to push back.

[tdunning]

Related to the license readability, I previously submitted pull request #252 to fix the markdown implementation of the license text

[tdunning]

Regarding the comments about licensing, I don't think that anybody has tried to claim that the intentions and needs of the UCUM community are irrelevant. The claim is that the current license inhibits adoption. This is simply an observed fact for me, not an opinion. This observation does not imply anything about the intentions and needs of the UCUM community just as the intentions and needs of the UCUM community do not negate my direct experience.

One standard approach taken in the open source world to manage similar concerns is to allow unfettered modification and derivation of machine usable artifacts but to restrict naming. In this vein, the UCUM community could have a tightly bound and controlled text of the standard, a loosely bound software artifact and a name that is controlled through trademark so that somebody who uses a mangled version of UCUM would not be allowed to called it UCUM nor use the UCUM name.

This approach separates out components so that where perceived needs of the UCUM community might conflict with perceived needs of a user such as myself, those conflicts can be resolved by having different licensing constraints on different components and the overall need of the UCUM community relative to the good name of the UCUM standard can be controlled by non-license mechanisms.

To make progress toward that goal, I have created a candidate repository that uses the Apache license to control just the machine readable units files. This addresses the strong requirement from people like me for using a standard license and using these artifacts to produce software artifacts.

Based on this discussion, I will also add additional placeholders for trademark policy to this repository (along with disclaimers that my repo is not official, but is a concept car for evaluation).

You can find my work in progress at https://github.com/tdunning/ucum-units

I would appreciate constructive comments.

[chgessner]

This approach of separating components is apparently also used for the HL7 FHIR product in a similar way: while the copyright for the specifications is Creative Commons CC0, there is a strong notion of trademark protection (and reference to FHIR governance):

https://www.hl7.org/fhir/license.html

I'm not an expert on such issues, so just take this as a remark, without a position on either side of this discussion.

[tdunning]

As a meta-comment that I regret making, it would seriously help keep this discussion if it could be based on what is happening here and not any defensiveness related to other discussions with other people in other places.

To be specific, here is an abridged version of a recent comment eliminating all but some of the loaded phrases:

... endlessly meandering ruminations without substance or direction.

... not just come back to the FUD "it's unusual to people so we are scared" argument. 

... let's go in that spirit and dive into detail not endless ruminations.

... we do not appreciate to be bashed around for that while nobody claims "we're not going to implement the USB or BlueTooth standard because we have to pay for the document and abide by a non-standard license". 

... Give us some credit for that

... if our intentions and needs are being negated as irrelevant, then we continue to push back.

To be crystal clear, I have no time for endless ruminations. I would like to use UCUM in our software systems, have problems doing so in our organization, and I would like contribute to the system to overcome those issues. I haven't been bashing anybody around. I have been giving the UCUM community credit for being as open as they are and I haven't negated anybody's intentions or needs. I fully acknowledge the value of the system as it is and that standards are not software.

So please stop injecting these into this conversation. There may have been other people who were been abusive or obnoxious or even just long-winded. That's not me. We don't need the echoes of any of that in this discussion. We also don't need for anybody to apologize for anything, either. Let's just stick to the simple issue described in this suggestion and get some stuff done.

[tdunning]

What you said about derivative works is encouraging.

I agree that "no derivative works" clause is too restrictive. I agree. And vow to work on fixing that. Clearly it is OK for anyone to create their own UCUM "table", and distribute them with their software for example. I, for example, take the UCUM source and transform it into a JSON syntax which I then load and instrument with javascript classes to add the UCUM semantics, functional, computable, etc. Clearly such a thing must be allowed. And clearly such a thing would be considered "derivative works" under case law, and it is clearly not our intention to prohibit such use.

no changes allowed (3.a.iii and 3.a.iv)
This one we probably can hold on to, if we qualify of what "change" means. Which is critical, because any derivative work that puts the content into a different form is also a "change" of something.

We do not intend to prohibit any creation of subsets for any specific use of UCUM.

We do not intend to prohibit removal of some annotations or adding others to the UCUM concepts, nor creation of relationships to other concepts. For example, if someone has a kind-of-quantity terminology (like LOINC is one) then making links to UCUM and thereby incorporating a subset of UCUM into LOINC, would not be a prohibited act.

But I would like to point out that none of this is clear to an outsider like me. And changing the current license isn't going to help that much because the license is still a special-purpose license bespoke to the interests and needs of a standard. Moreover, I don't even think that derived works are a great idea to allow willy-nilly for most of the content in the standard.

As such, it really does seem to me that the separate repository approach is much simpler. The standard stays relatively tightly restricted while the separate repository that holds only the machine readable assets that are intended to be used for derived works is very clearly not restricted.

Can you look at and comment on my first draft of such a directory? The key content here is the README, really. Does it say what you intend?

https://github.com/tdunning/ucum-units

[dr-shorthair]

Thanks a lot @tdunning - this is a great start.
I think you have probably hit the nail on the head.

Currently there is a single, bespoke, license which appears to apply to all UCUM artefacts.
The machine-readable artefacts need to be freed up, at least to a point.

Having those in a separate repo with a different, standard, license would achieve what I was chasing in #159.