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 https://github.com/ucum-org/ucum/issues/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.

[tdunning]

@dr-shorthair thanks for the comment

I am about to push a version of the readme with instructions about whether to use "UCUM" describe a subset or extension.

My guess is that my guess about how to handle those will be off base. I am putting something down, though, since that makes it easier to critique into a better form.

The basic idea that I am heading to is

1) subsets are OK, but should not claim to comply with UCUM standard. Instead, they might be described as "implementing a subset of UCUM" and whatever subset they implement should be precise in the sense that they should not implement units not in the UCUM standard.

2) there are several cases of extensions:

2.a) Extensions which fit into other frameworks but which parse UCUM completely. These are, I think, non-controversial to describe as "UCUM compatible". An example would be a parser which parses UCUM to produce units as part of the Julia Unitful library. The Julia Unitful library supports arithmetic on units, user defined units and parsers for other notations for units, so it isn't just a UCUM implementation.

2.b) Extensions which use UCUM syntax to describe non-unit oriented information required in some domain. For instance, in sustainability, there is often a need to annotate values with a chemical compound and a mass unit. Examples might be 3kg of methane or 5 gigatons of carbon dioxide. When these are converted using relative impact, they need to be stated as something like 2 megagrams of CO2 equivalent. I believe that using annotations enclosed in `{}` would be a reasonable choice here, possibly with an application specific prefix. Thus, 3 "kg {chem: CH4}" or 2 "Mg {equiv: C}". Such an implementation could be called "UCUM compatible".

2.c) Extensions which use proposed units which have not yet been accepted as part of the standard, but which are undergoing the adoption process (and which may fail to be adopted). I know of no examples of this and I don't know how this should be handled.

Comments welcome either here or on the https://github.com/tdunning/ucum-units repository.

[gschadow]

So we just keep ignoring the issues?

I would say that this https://github.com/tdunning/ucum-units is in violation of the UCUM license, it's not even referencing it. Notice how much it talks about the Apache license and gives not a single concern about infringing the UCUM license.

A particular goal of this repository is to allow redistribution of core UCUM artifacts under a license that corporate legal teams will recognize and approve.

this seems to mean "I created this repository because I want to re-distribute UCUM under the license that I think is the center of the world".

"corporate legal teams recognize and approve" the Microsoft license, the Oracle license, and whatever else End user License for whatever else the corporate offices are using. This isn't an argument. It just side-steps the issue.

I think this needs to be dealt with not just let go like that.

So far in this discussion I still see no response or responsiveness to the real legal needs that UCUM, LOINC, SNOMED, ISO, IEEE, and every other standard organization is grappling with.

What now?

[tdunning]

I don't think that this is ignoring the issues at all. This is an attempt to meet the needs you have expressed about keeping the UCUM license in place for the standard itself but establishing a more liberal license for a machine readable version of the standard so that others can use it in ways that you yourself have said that you do (i.e. for creating a JSON version of the units files).

The repository that I created is a vehicle for discussion. As you point out, it violates the the current UCUM license because it is me who hosts it rather than UCUM. That is why I suggest this repository or something very much like it be hosted by the ucum-org GitHub entity. From your comment, I clearly should put a comment at the top of the README saying that this repository should not be used, but is only a vehicle for concrete discussion.

To repeat and emphasize, I have no intent to distribute these unit files under any license. I created this repository for discussion purposes.

I agree that there are many licenses in the world and even many standard open source licenses. Proprietary licenses such as Microsoft's various EULAs are in appropriate for release an open source artifact. Within the class of open source licenses, there are only a few that are widely accepted as easy to consume. The most prominent of these are the Apache license, the MIT license, and various versions of the BSD license. The MIT and Apache licenses are predominant on Github and I don't think that there are any important differences for this repository.

To a degree, the purpose of releasing these artifacts under a widely recognized open source license is precisely to sidestep the issue of trying to craft modifications to the UCUM license itself. For one thing, such modifications are painstaking and difficult to do well. For another, making changes to a bespoke license doesn't help the problem that the license is a one-off and thus requires full legal review.

But I think that you mistake my motivation or the effects of this sidestep.

I hear very clearly from you that the standard itself needs to be protected very differently than how open source software is normally handled. I also hear that the integrity of the text of the standard is the key goal of that protection.

This makes a lot of sense. I get it that UCUM and many other standards organizations have similar needs.

On my side, I would like to do as you say you do to generate alternative forms of the units files for use in my software. Further, I want to do this in a way that my company's lawyers will approve and I want to enable others to do this as well. The best way to do that is to have a clearly marked open source component that the standards organization in question distributes.

So splitting the repository into two parts (both under the control of ucum-org), one with the text of the standard licensed under the current license and one with just the machine readable files that assist in the implementation of UCUM-compatible software licensed as open source seems to break the deadlock.

So, could you look back through the repository that I created with a more generous eye keeping in mind my actual intent? Imagine a future state where this proposed repository is hosted by ucum-org, not by me.

[tdunning]

I have added the warning to the README to make clear that the repo I created should absolutely not be used unless it is rehosted under the ucum-org organization. I also cleaned up some broken / unclear text.

If there needs to be an explicit pointer to the core UCUM repository for the standard or to the UCUM website, please send a pull request suggesting where and how that reference should be made.

[tdunning]

@gschadow wrote

A particular goal of this repository is to allow redistribution of core UCUM artifacts under a license that corporate legal teams will recognize and approve.

this seems to mean "I created this repository because I want to re-distribute UCUM under the license that I think is the center of the world".

This is close. Distinctly different from what I want.

More correctly, "I created this repository because I want the UCUM community to distribute two tiny pieces of UCUM under some open source license that I think is widely recognized"

[gschadow]

Thanks for this, now we are communicating.

I still think that a separate distribution is not needed nor helpful. That in fact the best electronic distribution is the ucum-source.xml itself. (I create JSON from that source) that ucum-essence.xml and the old .units files are just other minor transformations.

I think we should fix the UCUM license, to permit the things that people need to do and still prohibit what we don't want to be done (e.g. steal it, bastardize it, "embrace and extend" it)

[tdunning]

If the xml source is more basic, then distributing that is fine. I would suggest providing a transformer or three into alternative forms to help potential users. Pre-transformed convenience files in various formats (YAML and JSON come to mind) could be helpful. Exactly which files are provided is not the core issue, however.

I think we should fix the UCUM license, to permit the things that people need to do and still prohibit what we don't want to be done (e.g. steal it, bastardize it, "embrace and extend" it)

I hear you.

But given the exigencies of corporate approval, having a modified UCUM license won't actually help adoption by people like me. I sit in our open source program board and have a ring-side seat on this issue.

As you have said, the core standard needs a tight license, but it is your thought that these machine readable files could be used much more liberally. My strong opinion based on three decades of experience in open source on both the providing side of hundreds of projects and the consuming side of thousands is that anything but a standard license is a real problem. I have also worked with hundreds of enterprise customers and they really don't like non-standard licenses in dependencies.

Further, I really don't think that any standard license meets the needs that you have expressed.

This is a serious contradiction between the needs of serious people.

I am proposing this split as a Solomonic splitting of the licenses to recognize both needs.

[gschadow]

Remember the point of the "Solomonic split" is that it never occurred!

It is not possible to split the two because the license on the simple data file would have to inherit the restriction on the source or else it simply invalidates the restriction on the source.

We do not want to allow that people redistribute an embrace-and-extend approach.

Along the discussion you have given examples with the curly braces annotations. Those curly brace annotations are not an extension of UCUM. So people can create as many as they want, and they can also share lists of them. You could imagine people adopting a certain convention how to write curly brace annotations and then use that to carry computer interpreted notions that go beyond the scope of UCUM. For example, they may actually use curly brace annotation to distinguish a mole of glucose, hydrogen, or photons respectively.

What we absolutely don't want is some group of foobar engineers deciding that they want their elmer-unit to be represented by the simple symbol E and so they distribute a UCUM++ that also has the E as the elmer unit.

Another thing we need to protect from -- and this is a real threat approaching UCUM -- is a big bully like SNOMED to come and suck all of UCUM in along with "tablets" and "old pair-of-shoes" all declared units (hostile, or at least inconsiderate, embrace and extend.)

If we say all these things, and then spit out something under a permissive open source license like Apache, we just negate everything we said in the main license. Otherwise any Apache license would have to receive an additional limitation of use clause and then you would not like that.

I think the only reason dual licensing approaches work is then the open source license is GPL, because the GPL presents an impediment to those who want to embrace and extend and control. They now pay a price in having to release their source as GPL or go with whatever commercial license is being offered. Since our intention is not revenue but control, this GPL approach isn't going to be useful, and I bet you wouldn't like it either.

Frankly, I think the bottom line is, it doesn't matter what people think. Our content is independently valuable. I really don't think open source license FUD is justified and ultimately serious players see that the benefits outweigh the risk.

Or did you also complain with ISO and IEEE about their copyright?

https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100206.pdf https://www.iso.org/terms-conditions-licence-agreement.html#Copyright

[gschadow]

Moving ahead on a principled approach, I would say that redistributing derivative work should simply be prohibited in any form.

And here is how you technically work around that. And this technical workaround is exactly what we want.

We make the content available online, easy a pie, no paywall, no catch and no CAPTCHA. If you have a system that wants UCUM in a certain internal data format, you are of course free to use that, but you aren't supposed to redistribute that. Instead, what you can easily do is at runtime or installation time, you pull from the source and generate whatever you internal format may be. You can pull it into a data base table and have all your code depend on that database table in your entire enterprise. Of course we cannot control what you do in your enterprise.

But you must not redistribute that content to others. You never have to. If you are a software vendor, you can always pull from the source and you never have to distribute your own derivative on your company site. There is a difference between your code, downloadable installation packages you put up on your site, maybe free and open. But you can't take the file and say "hey, people found this useful because it has UCUM and a bunch of additions which we have added over the years, go and take it if you want". You see? Internally you could even do your own codes, but those would be done by your software. If you wanted to now have a public API where you want to promote using those codes with other parties, then you are not allowed to publish those together with UCUM.

But nobody prevents you from publishing a list of esoteric unit-like symbols to use with the acupuncture API community. That's freedom of speech. And you can say "we recommend that you use our codes together with UCUM, and here is a link to the UCUM sources. And by the way, if you use our software, we pull everything together for you so when using our software you don't have to worry about any of this and your an enter in this user field the letter "E" to mean the elmer unit of median acupuncture energy flux.

[tdunning]

OK. I give up.

I can see that you don't feel it necessary to meet our needs. We need to be able to automatically transform the spec into a parser at build time (not installation or runtime) and that constitutes creation of a derivative which you reject.

Since you are adamant on that point, there is no solution.

I will wait for another week or so and delete my proposed repository.

We will find an alternative path without UCUM. I don't see any way that our sustainability project at HPE can use UCUM.

[tdunning]

Closing due to impasse.

No fix available

[dr-shorthair]

Sorry to see this.

I thought the work proposed here was a useful, pragmatic approach that would allow the very good work done in UCUM to be used more widely, and relieve other communities from having to re-invent this wheel. While I fully understand that UCUM may not feel that it owes anything to communities outside LOINC, in the spirit of open science (and engineering) it is a real shame for UCUM to be locked away behind unnecessarily impenetrable procedures. The LOINC community has gained much from other science disciplines ...

[gschadow]

While I fully understand that UCUM may not feel that it owes anything to communities outside LOINC, That is not what I said.

I appreciate there is frustration on both sides.

Certainly this idea of "UCUM doesn't care about "communities" outside LOINC is a mischaracterization. We care about anyone who comes forward with a solid argument and a solution and then works on some compromise. When I mention LOINC in connection with the license issue it is because Regenstrief Institute is the Copyright owner of both of them. So anything that we say as advisors will have to still get past the Regenstrief lawyers. Since LOINC is a lot bigger and has gone passed that step already, if we can find that straight-forwardly adapting the LOINC license is viable, then the last step past the Regenstrief lawyers will be much easier than if we do something else altogether.

The problem is that in all of these license discussions there is no viable approach forthcoming.

Give me a rational argument how one can have a license that protects from "embrace and extend" attempts and then throw it out by publishing the main content under a totally permissive license anyway?

That rational explanation has not been forthcoming.

Neither has there been any attempt to take the challenge about the apparent inconsistency. Are you going to ISO and IEEE and demand they change their license terms or else you will not use them? Or else your nameless "open source community" will not use them?

All these reference to this "community" or that "community" are ways to avoid dealing with the substance of the arguments.

Just tell me: is there a "standard license" that we should adopt which considered the nature of the licensed material? The only real proposal made (CC-ND) I picked up, but it wasn't viable. Is GPL viable? No. A dual license GPL + UCUM restricted? I bet no, even though it has plenty of precedence in that "open source community".

So why not collaborate in the creation of license terms which work for everybody? I have never seen such collaboration actually occur. And it has been so many years. Hence I started with "oh not again".

260 is there to come to terms with that (pun intended).

[dr-shorthair]

So that this thread does not end on a pessimistic note:

There is plenty of precedent for artefacts related to standards being made easily available, as uncovered by @tdunning and described here https://github.com/ucum-org/ucum/issues/260#issuecomment-1345931856

[tdunning]

@gschadow, you keep saying that ISO and IEEE don't release artifacts to help implementors under standard open source terms. That isn't true. You should stop repeating it.

Referring to communities is not trying to sidestep any issues. It is a standard term of art in the open source world that reflects a group of people who have common interests and work to further those interests by collaborating. A common saying in the open source world is that community is more important than code. The idea there is that building methods for collaborating productively and bringing in more contributors who are willing to work together is a far more important and productive step than any code artifact. This is because a productive and vibrant community can replicate code very easily, but code by itself is essentially dead.

Building community is done by welcoming new ideas and new contributors and considering their view points. The result of building a software community well can be dramatic. Most web systems are based, for instance, on Apache servers. And all of the Fortune 500 companies have adopted open source software for key business processes. Github is another example. By making community building easier, they have inspired an explosion of projects. There are now over 200 million projects hosted on Github. One of my own personal projects which implements a statistical method for sketching probability distributions now has over 1 million downloads per month because I welcomed outsiders who wanted to change how my software worked and to include it in their systems. Community building works.

But the way that you build community is not by ignoring people who offer small improvements for weeks and it isn't by insulting their motives or their qualifications. If you are an ass, people will go elsewhere. If they need a solution for a problem you are solving, they will come up with their own solution rather than collaborate with you. This process of diversion of effort, or forking, has a profoundly negative impact on the success of projects. Split a community in half and one half will likely die and it is quite possible that both will do so.

One of the most important results of a strong community is not only widespread use of the artifacts that community builds, it is also consensus.

You profess you want to control UCUM and prevent "embrace and extend" attacks. In fact, the best way to get people to use UCUM as a standard would be to build consensus rather than just to fight change.

Based on your previous responses, I don't expect that you will understand or even take the time to read what I am saying, but I wanted to try one last time to convey what I was trying to help build here.

[chgessner]

As said elsewhere: HL7 FHIR decided on CC0 (https://creativecommons.org/publicdomain/zero/1.0/) for the specification, accompanied by strong statements on trademark protection. Would CC0 work for software vendors here?

[grahamegrieve]

CC0 would work for software vendors and would be appropriate for the collateral - ucum-essense.xml, principally. But it would not achieve what @gschadow is trying to achieve, which is to use the license to stop the kind of derivatives that he does not wish to exist. I think that the conversation shows that the license is too blunt a tool to achieve this, because some derivatives are good, and necessary to use the standard, and others are not desired, but the license can't differentiate between them.

the FHIR license takes a very different approach: any kind of derivatives are allowed under the license; instead, HL7 relies on the trademark to enforce discipline on the community. That's not possible for UCUM now, because it requires trademark enforcement from the beginning, and it's not possible to retrofit that onto existing UCUM usage.

I personally think this is unnecessary; UCUM usage in practice is mandated by standards bodies and communities who have nil interest in variations of UCUM, and then it is implemented by oh-so-average software that is depressingly useless at conformance, and so I think that the license gets in the way of solving the actual problem that exists, which is that all sorts of crap units are called UCUM units when they aren't. It's a software problem, so we should not get in the way of anything that fixes that

[gschadow]

@gschadow, you keep saying that ISO and IEEE don't release artifacts to help implementors under standard open source terms. That isn't true. You should stop repeating it.

That is true and you have not shown anything to the contrary. You have not shown a license on ISO and IEEE standards, let alone an Apache license. You have shown that the content is being made available free of charge, something UCUM does for over 10 years.

Go to them and force them to put their standards under Apache license. When they do it, we probably will too.

Will they listen to you? Will they be so "welcoming"? Try it.

I have always considered the needs for the derivative works. You saying I don't or we don't is simply not true. The problem is you do not want to even entertain the questions. You just want Apache license and accept nothing else.

[tdunning]

That is true and you have not shown anything to the contrary. You have not shown a license on ISO and IEEE standards, let alone an Apache license. You have shown that the content is being made available free of charge, something UCUM does for over 10 years.

I actually have shown something more important. These groups make important machine readable artifacts available on different terms than the license. The SI Brochure is a fine example. You can use it any way that you like as long as you reference it. This isn't the same as open sourcing the standard.

This model of open sourcing an artifact that enables easy implementation of the standard is exactly what I proposed. You (@gschadow) aren't listening well enough to discern the difference.

Releasing an open source reference artifact that could be used to build UCUM implementations would help the propagation of UCUM, not hurt it. As @grahamegrieve points out, UCUM usage is mandated by standards bodies. The best way to protect that status is make it easy to build an implementation and make it easy to test that the implementation is compliant. And then protect the trademark by saying that only implementations that pass the test can be called UCUM compliant.

You just want Apache license and accept nothing else.

Nope.

I have said just the opposite.

All open source implementations need is an artifact that allows useful derivatives, no viral provisions and which is widely used. As I have stated many times, there are many licenses which would work (BSD, MIT, X, Apache, CC0 and so on) and many which will not (GPL, CC-ND, bespoke licenses).

[tdunning]

It bears repeating, my current position is that it is impossible to cleanly build on UCUM.

I will be building my own encoding for units.

That's a really unpleasant and stupid position to be in, but it is forced by @gschadow's intransigence on allowing the units file to be used according to standard open source practice in the same fashion that IEEE and ISO currently foster.

Again, it is not necessary to open source the entire standard. All that is needed is an open source artifact to make it easy to implement the standard. Adding a compatibility tester would be a great addition, but is not necessary. As that option is unsatisfactory to @gschadow and since he refuses to even carefully read what I have written and continues in misstate reality in borderline abusive ways, there really isn't much any way forward.

[timbrisc]

We are closing this issue here on GitHub as we have transitioned the topic to internal review within the UCUM committee and Regenstrief Institute. Our sincere thanks to all interested as we continue deliberations. If you would like to provide further commentary, please it to ucum-support@ucum.org.