License is inadequate, some derivative works must be allowed.

[gschadow]

In #159 it was argued that a "standard" license should be used because "the open source community" would not be able to use any non-standard license.

In #253 essentially the same case was made and a push for publishing some computer files (like ucum-essence.xml) under the Apache license.

We cannot have one license that prohibits derivative work and then create derivative work of the essence of UCUM and lift any restriction of derivative work.

The attempt to find a "standard license" that is suitable has failed.

But we did learn in detail in #253 that the present license has way too broad a derivative works prohibition, that it is not suitable at all. The license needs to be fixed. It's a bug really.

I am actually not sure how that current UCUM license even came about?

The current terms are extremely restrictive:

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.

and also it is noteworthy what it grants:

[...] revocable license to reproduce, publicly display, publicly perform, and distribute the Work, and to use the Work for the purposes of developing and commercializing Software Applications that will communicate with and interoperate with the Work.

The previous license (under which the current "official" release of UCUM is actually based is essentially a slight modification of the LOINC license at the time changing LOINC to UCUM and some other minor modifications to make sense. But the principle of limiting derivative works is from there.

Today LOINC has a revised license and it is useful to look closely at that and see how it could be adapted for UCUM in that same semi-mechanical way.

I propose to effectively track the LOINC license.

[colin-e-hscic]

Once upon a time I believe I saw references to allowing localisation of UCUM in the documentation, however it was couched as "localisation to languages other than English" which is a a problem because we (in the UK / Australia / NZ) speak English, but it's not the same as American English and this affects some spelllings.

Is there potential for this to be properly catered for in future? I would suggest localisations of UCUM being contributed back to the main development to maintain the integrity of the distribution.

[gschadow]

Translations are derivative works. The LOINC license under point 12 is very specific about that and in the spirit of tracking the LOINC license, it transfers analogously to UCUM.

The original UCUM site (which I have recovered in order to be able to trace such texts which have been lost in the move) stated an internationalization project. But this isn't related to license consideration.

If you like to propose some specific course of action regarding the need to an alternative English text, you are welcome to do so. Try to give some specific course of action and perhaps example were such alternative English text would be (a) different in ways over than just replacing "-ize" with "-ise" or other such nearly automatable transformations, (b) how such alternative version would actually help people, because I am sure that all British English speakers do understand American English very well.

The rest of this issue should concern itself with the revision of the license itself.

[tdunning]

As a point of reference, @gschadow has vehemently stated that making machine-readable summaries of specifications available under liberal licenses is not what other standards bodies like ISO and IEEE do.

He is simply uninformed on this matter regardless of his professed authority.

Take ISO-4217, currency codes as an example: https://www.six-group.com/en/products-services/financial-information/data-standards.html

The list of currency codes is made available for free and without charge or restriction. This is even more liberal than what I was suggesting with the Apache license + trademark limitations in #253

Take as another example, IEEE Std 1159.3 which is a standard for the interchange of power quality data. The software to read and write data in this format is released under the Apache license. See https://opensource.ieee.org/pqdif/pqdifnet

These are apparently not exceptional. I didn't have to go looking for them. I was looking for currency codes for another purpose. I got curious about the IEEE and found that the IEEE has established an entire system for hosting open source software and is working very hard to reconcile the differing needs. See https://opensource.ieee.org/users/sign_in

The approach that I suggested of providing machine readable files under a standard open source license is not exceptional at all. In fact, I would argue that it is the modern norm.

Standards organizations who have as their priority the fostering of the adoption of the standards that they are creating realize that making it easy to adopt the standards through open source methods and culture of sharing is far more effective at establishing a widespread and authoritative standard than playing dog-in-the-manger.

[dr-shorthair]

The real authority of standards is measured by their usage.

[tdunning]

I just noticed that the SI Brochure itself is licensed as CC with attribution. No constraint on modification or derivatives.

https://www.bipm.org/en/publications/si-brochure

If the SI is open source, what business does a two-bit organization have in saying that UCUM is sooo special that it requires special protection from corrupt influences.

@dr-shorthair is completely correct. The authority and prestige of a standard is measured by its adoption. Preventing adoption is effectively a form of indirect sabotage.

[gschadow]

Blistering heat.

I think I have referenced the ISO copyright statements. https://www.iso.org/privacy-and-copyright.html and https://www.iso.org/publication/PUB100206.html. IEEE https://standards.ieee.org/ipr/stdspermission/#std3.

The funny thing is that nobody seems to care. There are many publicly available tables of ISO country codes for example, and yet the copyright situation is completely unclear, or rather, there is no language anywhere that states that license is granted to make or distribute any derivative work.

Nowadays ISO says "ISO allows free-of-charge use of its country, currency and language codes from ISO 3166, ISO 4217 and ISO 639, respectively." https://www.iso.org/iso-3166-country-codes.html, which is also what UCUM says. There is no prominent copyright notice on that list, but there is on the standards.

The software to read and write data in this format is released under the Apache license. See https://opensource.ieee.org/pqdif/pqdifnet

That is irrelevant. Everybody knows that software is often released under open source licenses.

IEEE has established an entire system for hosting open source software

also completely irrelevant when the question is the copyright on their standards.

It is exactly this sort of unrelated complaining and zero engagement on actually resolving the issue that I started out with "not again".

The situation is as follows:

I created the UCUM while employed at Regenstrief Institute. So Regenstrief Institute is the copyright owner. They decided on the license that is there now. Changed it from the one that I had adapted from the LOINC license at the time. There are specific threats against both LOINC and UCUM where big money organizations are attempting to swallow the content to bootstrap their own promulgation of an alternative standards, for which they charge very high user fees. These are realities.

I have said many times that I am more than willing to help work out a viable license that considers the reasonable interests of all parties. But it is never good enough. And notably, engagement on the issues is rarely forthcoming.

I understand that there is a good amount of animosity in this conversation from both sides, so a little explosion here or there is no big deal, but when all the heat is unloaded the question is still how to reasonably permit derivative works without opening the content up to hostile take-overs.

[grahamegrieve]

the question is still how to reasonably permit derivative works without opening the content up to hostile take-overs.

at heart the problem is that you don't want the license to allow derivative works of the implementation collateral that are not conformant to UCUM itself? Does that really matter? No matter what people do to the ucum-essense.xml, they're still not redefining what UCUM is, because that's defined by ucum.org, so why care about that? Just let people do whatever they want with that?

[tdunning]

Furthermore, if you want to control the brand and the standard, trademark is a better tool. Prevent people from using the name "UCUM" or "UCUM encoding" if they haven't demonstrated conformance to the standard (and define conformance however you like).

[gschadow]

Grahame, the primary issue is SNOMED gobbling up everything. Other large organizations are also suspect at pulling something like that.

The second issue is people promulgating extensions. Which is following the first issue.

The third issue is that there is really no issue. There are plenty of open source projects implementing UCUM on github alone and doing it in a good faith way. Without incessantly complaining about the license and threatening they will walk away if they won't get their way.

Some of these projects are redistributing some content of UCUM, one of them added the UCUM sections into the ucum-essence.xml file (calling them "class"). It is all in good faith and fine.

All I want is to update the license to formally grant license to this sort of thing.

The issue with ISO country codes is a perfect analogy of what is happening. ISO has in recent years massively restricted their copyrights trying to control distribution. Yet they chose to not go after reproductions of some of their content (e.g. on Wikipedia). The HL7 vocabulary committee people were grieving over this ISO country code license issue over a decade ago, and at the time I couldn't even believe it, but it was a massive issue if you actually wanted clarity. To this day the actual situation is completely unclear. Nowadays ISO themselves distributes the data, but never actually came around issuing a license. They might at this point have forfeited their ability to sue, but to my knowledge they never formally conceded and I could not find any evidence that they did grant any permissive license.

UCUM's case is somewhat similar. Regenstrief Institute lawyers like to hold the Copyright and maintain that ownership. Mind you, I would have liked to just take it out of their hands 10 years ago, because it's not exactly easy to work with RI lawyers. But I have not done it because I had no just basis. So this is a baseline fact.

And I say it is not a problem. It is objectively not a problem, see how many implementations there are! See how much use there is! It's constantly growing. So sitting there whining about it and poo-pooing with such grand-standing proclamations that "the real authority of standards is measured by their usage" is all so hyperbolic overblown.

We have offered a thing to the world, the world has accepted it. We have always been extremely liberal with keeping everything free. We just don't want it to be taken out of our hands. That is all, that is not a big deal, that is not inhibiting any reasonable person from implementing, as they all do.

Whether or not trademarking is a better tool or even viable option Grahame seemed to say that it's too late now for that path, I would disagree, but it is a different question.

[grahamegrieve]

I don't mind being wrong about that.

All I want is to update the license to formally grant license to this sort of thing.

That would be great. But the pressure to adopt a formally recognised license - OSI certified - is real and exists for a real reason. And I don't see how using a formal open license for the collateral is going to make any difference to SCT or any other organisation, as long as RI retains authority over the standard and the trademark

[gschadow]

For SCT it is not the trademark. This is a whole different deal with the trademark. At this time there is no registered trademark and you yourself said that it might be too late to go for that. But for SCT it doesn't matter, they are just as happy to suck it in (as they recently did with LOINC) and then sell it under their own mark with the power they have.

I have been checking the OSI to see a huge number of licenses there, and with an idea of submitting ours to them, I read their scope on "open source" which UCUM clearly does not classify under (because the product is not computer program source code.) Then I also noticed that Creative Commons is not on the list of OSI licenses, probably precisely because CC is for content other than software, so open source matters do not apply.

Again, I do not see how this is a real issue in practice. UCUM is being implemented plentifully and there is no real actual practical hurdle here. We simply iron out the issue where derivative works prohibition is too broad and the matter is resolved.

(Just as an aside, Grahame, you said there was an issue with people promulgating garbage units as UCUM. I haven't seen that. But it would be interesting to take a look, not with any intention to sue, but with an intention to understand the problem. BTW, my strong wording about this other github that slapped the Apache license on UCUM things was of course not meant as a real threat (I do not opine or act on behalf of RI) but I felt this issue belongs fairly discussed rather than being pulled over the table.)

[grahamegrieve]

It was a long debate about cc0. I think they should've listed it, but they didn't.

I'm not so sure it's not an issue. I distribute ucum-essence.xml with all my software and so a corporate could say that they can't adopt my software for the reasons @tdunning has enumerated. That would put me in an unhappy place. Would you dual license ucum-essence.xml under the UCUM licence and CC0? Sure, SCT could sell that.... no problems. I bet they can charge an extra $0.05 for distributing something people can get for free...

there was an issue with people promulgating garbage units as UCUM. I haven't seen that

not exactly promulgating.. more just using and distributing out of ignorance, because there's no online validator, and there's been no proper UCUM validator for terminology services. I'm trying to change that, but it's slow going - I don't have time to argue with a national authority that their units are non-conformant and non-sensical, when their paid people will dig in and argue.

[chgessner]

Concerning UCUM validation, I made a move here: https://github.com/ucum-org/ucum/discussions/250

[gschadow]

I'm not so sure it's not an issue. I distribute ucum-essence.xml with all my software and so a corporate could say that they can't adopt my software

The important thing here is "corporate" is one thing and "open source community" is another thing. The UCUM license (would) grant you the right to do exactly what you did. Corporate deals with all sorts of EULAs and has no real issue because there is no issue. If they want to build on your software as open source, then they can try and find something else and they won't and they can whine and cry and ultimately they just use it. Why would they not? It clearly says they can!

BTW, there is also a really easy way to get around it if someone would actually really super-duper care about it. Just don't package ucum-essence.xml or whatever in your code. Simply pull it on the fly and apply whatever transform to it. But why doing that if the license was to say that you can do what you do?

[dr-shorthair]

That is an irrelevant distinction. Many/most corporate products are built on stacks of open-source software, and routinely contribute to it. In practice there are no routine boundaries between corporate and the open-source community. @tdunning has been making exactly that point.

[dr-shorthair]

The most valuable 'standards' are the ones with the greatest uptake. Network effects. Barriers to adoption are almost always counterproductive.

If the concern is dilution of the UCUM brand, then that should be addressed directly. License restrictions are the wrong tool.

[gschadow]

No. License restrictions are not the wrong tool.

UCUM has uptake. There is nothing equal.

The license is currently what it is.

The point here is to qualify the derivative works prohibition to explicitly allow all the good stuff so many people are doing.

[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.

[dr-shorthair]

Is there any more information available on how the licensing issue has been addressed?

[tdunning]

I haven't heard a word.