search

ucum-org / ucum

https://ucum.org
Other
58 stars 10 forks source link

Use a standard license for UCUM #159

Closed timbrisc closed 1 year ago

timbrisc commented 3 years ago

Issue migrated from trac ticket # 5778

component: support material | priority: critical | keywords: license

2021-01-14 20:44:52: simon.cox@csiro.au created the issue

Use of UCUM codes in various systems* is being inhibited by confusion about the UCUM license. The current Terms of Use are perceived as very 'fierce'. This is partly because the Terms of Use are (understandably) tuned primarily to the 'whole system'. The license to merely mention UCUM codes should be more clear. But there is a major barrier because it is a bespoke license, and people these days are looking for the standard licenses (e.g. Creative Commons, Apache, etc) and resist others because they would have to do some lawyering which they can't afford.

-W3C RDF, QUDT

timbrisc commented 3 years ago

2021-01-15 03:56:15: simon.cox@csiro.au changed component from help to support material

timbrisc commented 3 years ago

2021-01-15 03:56:33: simon.cox@csiro.au edited the issue description

timbrisc commented 3 years ago

2021-01-15 23:13:21: mitchbre@regenstrief.org changed status from new to assigned

timbrisc commented 3 years ago

2021-01-15 23:13:21: mitchbre@regenstrief.org set owner to Governance/Process

timbrisc commented 3 years ago

2021-02-16 22:43:22: simon.cox@csiro.au commented

This issue keeps coming up, almost every time I mention UCUM in various forums (which is frequently!). The problem is that it is perceived that the current Terms of Use prohibit the explicit mention of UCUM codes in other systems. This perception may be incorrect, but it is persistent, so needs to be dealt with.

A related concern is that these days any use of a non-standard license is more or less automatic grounds for rejection by many potential users.

I understand the concern to protect the integrity of the UCUM system, particularly for clinical applications where errors have serious immediate consequences. But there is also a benefit in promulgating the use of UCUM codes as widely as possible, to avoid the proliferation of other systems with incompatibilities.

If replacing the current Terms of Use with a more standard license is out of the question, then I strongly suggest that the Terms of Use be supplemented with a very clear statement that the use of UCUM codes in other systems is encouraged and will not trigger any IP actions.

timbrisc commented 3 years ago

2021-02-17 19:05:07: gschadow@pragmaticdata.com commented

I would welcome Simon if you want to make a specific change proposal.

  • If you like to replace the license entirely: do say so.
  • If you like to use a different base license + some changes?
  • If you like to modify the text of the current license? Do propose!
  • You mention to add a sentence on top. Go ahead! I can imagine that a re-wording can help. There are different styles how to write licenses. Some are more legalese and some are speaking as "you" to the person telling them what they can do.

I am very open and I think we all understand what our requirement is as far as barring the hijacking of the specification and redistributing a modified version. That's really all.

timbrisc commented 3 years ago

2021-02-22 05:03:44: simon.cox@csiro.au commented

There is a model and associated ontology for expressing detailed rights statements - https://www.w3.org/TR/odrl-model/. This allows for detailed descriptions of permissions, prohibitions, and obligations. However, it is likely that a standard Creative Commons license would do the trick in this case.

The CC BY-ND by attribution, no derivatives license is probably suitable. This might be accompanied by the following explicit clarifications:

  • use of UCUM codes to denote units of measurement in the context of any digital representation of quantitative information is encouraged. Attribution to UCUM should be made in system documentation, but is not expected on every individual instance of usage

  • the UCUM specification document is the normative definition of UCUM and contains the official numerical values of constants and conversion factors. No derivatives of this document are permitted, except by explicit arrangement with UCUM

timbrisc commented 3 years ago

2021-02-22 13:45:14: simon.cox@csiro.au commented

Note that the actual legal-code for the license is https://creativecommons.org/licenses/by-nd/4.0/legalcode

timbrisc commented 3 years ago

2021-06-04 21:24:11: dvreeman@gmail.com commented

This is a really important discussion, and in general I am supportive of the notion of a standard/general open license.

But, my view is that a suitable one does not exist today (given the principles I've heard SDOs express). I've reviewed and summarized a number of issues with the Creative Commons licenses as they relate to biomedical terminologies (esp derivatives) here: https://danielvreeman.com/creative-commons-licensing-biomedical-terminologies/

IMHO, the community would greatly benefit from working together to make a model license.

timbrisc commented 3 years ago

2021-06-07 00:03:19: simon.cox@csiro.au commented

Thanks Dan - Indeed, solving this together is important.

However, I am concerned that any significant delay will undermine adoption of UCUM outside the LOINC community. Potential users are confused in relation to use of UCUM codes in software and services, so are turning away from UCUM. The current license prohibits derived works and there is nothing to tell developers that merely using UCUM codes in software and services is OK. I believe that it is now urgent to clarify that point.

Can we add a statement somewhere near the top of the ToU stating clearly that "developers are encouraged to use UCUM codes in software and services, providing that when a code is used it denotes a units-of-measure as defined by the UCUM specification".

In particular, there is opportunity to get UCUM embedded in W3C and in OBO ontologies now, but we could lose these people if the clarification is not made.

timbrisc commented 3 years ago

2021-06-07 00:03:19: simon.cox@csiro.au

timbrisc commented 3 years ago

2021-06-07 00:03:19: simon.cox@csiro.au

tdunning commented 2 years ago

I am facing exactly this issue right now.

Somebody in our organization recommended the use of UCUM units for our sustainability effort. IN order to do so, I wanted to build some software to validate our data. I cannot use an external service for this purpose since our package needs to run even disconnected from the internet.

My first response was to look at the unit definition files. Unfortunately, the ucum-ci.units has a GPL license which means I cannot include it in any of our software and the overall license is a) a non-standard license and b) has a "no derivatives" clause. Since the software I would create that includes a table from UCUM would plausibly be a derivative work, this license stops all progress in using UCUM in my setting.

What would specifically help here would be to have a special purpose repository that includes only machine readable files defining the standard units and which is entirely licensed using a BSD, MIT or Apache license.

What would help even more would be a repository with Python, Go, Java, Julia, R and Javascript packages that include tables of standard units and parsers in the respective languages for UCUM syntax and license this software using any of BSD, MIT or Apache license. If you just create the framework for this, I am sure that people from the respective language communities would be thrilled to contribute implementations. Having a standard package with standard licensing in whatever language is in use would make the establishment of UCUM as a standard practically a fait accompli.

The current situation is just hte opposite. There are various partially functional libraries out there, but they all have dubious license provenance because they use some part of the UCUM standard (and thus may not be able to offer the license they claim) or because they depend on external services.

tdunning commented 2 years ago

I can create a scaffold of the repository I am suggesting if it would help.

dr-shorthair commented 2 years ago

@tdunning I put significant effort into this issue. The issue seems to be that UCUM already serves its target community, and is fully adopted there. The UCUM custodians have little motivation or interest in users outside of their base community (clinical, health). So they don't perceive that there is a problem to be solved, or at least: not by them.

tdunning commented 2 years ago

Ah ... that's really unfortunate.

I have spent considerable additional effort looking around and it really does appear that there is essentially zero penetration of UCUM outside of the health sphere.

It would seem that there is considerable potential, however, if the license were opened a bit on the basic unit specification. I could see the Unitful package in Julia supporting a UCUM syntax for units which would allow a user to write ucum"mm[Hg]" or ucum"N/m2" as appropriate. Python could support something similar if not quite so congenial. Having a solid standard for interchange would really be nice.

Hopefully, one of the maintainers will pop in for comments.

tdunning commented 2 years ago

Note that issue issue #253 is related, but not a duplicate.

THIS issue is about relicensing the entire standard. The other issue about creating an artifact with more standard open source licensing on which implementations can be based. I feel like creating a second repository with usable licensing is MUCH simpler than opening the pandora's box of relicensing the entire standard.

gschadow commented 1 year ago

The issue #253 got closed. I appreciate the frustration that lead to this.

In that discussion it did become clear that something needs to be changed about the prohibition of derivative works. Apache license was proposed and a certain dual licensing approach where the bare bones content (like ucum-essence.xml and the ucum-cs.units files) would be promulgated under Apache license while UCUM source and text and all would remain under custom license. However, the dual licensing approach would defeat the purpose of the UCUM license where we intend to prohibit attempts to "embrace and extend".

Normal open source code licenses may not apply, but it has been proposed specifically to use the Creative Commons Attribution No-Derivatives version could be used. While the "No Derviatives" sounds like a non-starter if the issue is derivatives, it actually might still work.

The CC BY-ND by attribution, no derivatives license is probably suitable. This might be accompanied by the following explicit clarifications:

  • ...
  • the UCUM specification document is the normative definition of UCUM and contains the official numerical values of constants and conversion factors. No derivatives of this document are permitted, except by explicit arrangement with UCUM

If the goal is to use a standard license then no clarification or additional clause should be necessary or else it runs again into the same wall of people unwilling to read and abide by licenses.

For the record: I believe that we do not need to adopt any standard license because we aren't begging for attention. Especially not from software vendors. However, since a proposal has been put forward and some detail has been discussed, why not give this specific proposal a try.

So here is how CC summarizes the essence:

  1. The Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
  2. NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material.
  3. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.

The question is if the non-distribution provision doesn't also go too far and defeat the purpose. Remember that the no derivative works provision is the biggest stumbling block now. So when CC-ND says:

If you remix, transform, or build upon the material, you may not distribute the modified material.

the question is if the specific definition of remix, transform, or build upon excludes creating computer files and packaging them for use in software without distributing them in some other way outside the software. This is especially tricky for

The text of the license calls this a prohibition of sharing "Adapted Material", where

Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.

There is clarification of what this remixing and transforming excludes:

CC licenses grant permission to use the licensed material in any media or format regardless of the format in which it has been made available. This is true even if you have applied a NoDerivatives license to your work. Once a CC license is applied to a work in one format or medium, a licensee may use the same work in any other format or medium without violating the licensor’s copyright.

That is a bit tricky, because "format" in the sense of music or literary text are such things as MP3, OGG, WAV files or PDF, HTML, PostScript, etc. But it is not so clear if an information database artefact in XML transformed to JSON or some RDF constitutes a mere change of "format". You could introduce significant amount of (re-)interpretation if you did that.

I do not have the answers. But I propose the following:

  1. Interested parties should provide comments if they feel this particular CC ND license would solve their problem.
  2. Interested parties should propose specific alternative licenses which they consider "standard" and fit for their prupose.
  3. If CC-ND is found not to be suitable by proponents of this issue, and if no specific alternative is being proposed, this issue (desire for "standard" license) should be closed. If so, another issue will be opened to modify the UCUM license to permit the kind of derivative works use which we want to allow and prohibit that which we want to prohibit. This would then be a custom license, not a "standard" license, so the present issue would remain closed.
  4. If CC-ND or alternative is found suitable by the proponents, we would have to further analyze if this license would be suitable for UCUM (and LOINC?) needs, and specifically
  5. Regenstrief lawyers should make a determination if they find it suitable, and after whatever negotiating finally moved to adoption.
chgessner commented 1 year ago

I am worried that this approach would block even the most basic requirements of terminology management and distribution of UCUM-derived value sets in machine readable form or through APIs of terminology services. However, I am not an expert on legal issues...

gschadow commented 1 year ago

I am worried that this approach would block even the most basic requirements of terminology management and distribution of UCUM-derived value sets in machine readable form or through APIs of terminology services. However, I am not an expert on legal issues...

Christof, the label "expert" means very little today. Matters of law are always based on common sense and rational argument. So, now the question is: which approach are you worried about? And what alternative do you see?

It was your talking about FHIR and their use of some CC license that perked my ears, made me look at CC, then come back here to see that Simon had already proposed that a long time ago.

Clearly, if we do nothing, we have a blanket no derivative works prohibition in the current license, which means whatever problem CC-ND would entail, we probably already have now if we do nothing.

In order to make progress somehow, I am sharpening this debate to resolve it. The "standard license" camp needs to give a yea or nay answer on the CC-ND, or provide an alternative. If none is forthcoming, this "standard license" horse is dead. And then we can edit the current license, look back at the previous one, and hash out statements of requirements for the new custom license we wish to adopt.

tdunning commented 1 year ago

CC-ND is not usable for any artifact that gets incorporated into a software distribution.

Even GPL prevents incorporation into any non-GPL licensed software. Currently, projects on github are roughly 80% non-GPL.

Creative Commons licenses are not generally suitable for software use in any case. They were specifically created for text, audio, video and similar media artifacts and don't address some issues inherent in the use of software components.

The core problem with CC-ND particularly is that a UCUM artifact that many build pipelines require that the transformation into a special-purpose machine readable form for packaging into a deliverable artifact. This machine readable form is a derivative work and that is clearly not allowed under CC-ND.

I previously proposed in #253 that limited machine readable items be shared under an Apache license. Any Apache compatible software license (BSD, MIT, X, Apache) would be usable in that context. Further, I created an example repository to demonstrate how that could be done.

Unfortunately, even though I specifically described that repository as being for discussion purposes and labelled it as such in the README, I was accused of copyright violation. I closed #253 based on this and other abusive behavior in the discussion.

The behavior involved in that discussion is actually as important as the license chosen for any limited distribution. My own assessment to my company is that the UCUM community is not a suitable provider for any component of software we might choose to deliver due to legal threats being made.

I wish the UCUM well in figuring out how to work with open source software communities, but I don't think that I will be able to contribute further to help this happen.

On Sat, Dec 10, 2022 at 7:22 PM Gunther Schadow @.***> wrote:

I am worried that this approach would block even the most basic requirements of terminology management and distribution of UCUM-derived value sets in machine readable form or through APIs of terminology services. However, I am not an expert on legal issues...

Christof, the label "expert" means very little. Matters of law are always based on common sense and rational argument. So, now the question is: which approach are you worried about? And what alternative do you see?

It was your talking about FHIR and their use of some CC license that perked my ears, made me look at CC, then come back here to see that Simon had already proposed that a long time ago.

Clearly, if we do nothing, we have a blanket no derivative works prohibition in the current license, which means whatever problem CC-ND would entail, we probably already have now if we do nothing.

In order to make progress somehow, I am sharpening this debate to resolve it. The "standard license" camp needs to give a yea or nay answer on the CC-ND, or provide an alternative. If none is forthcoming, this "standard license" horse is dead. And then we can edit the current license, look back at the previous one, and hash out statements of requirements for the new custom license we wish to adopt.

— Reply to this email directly, view it on GitHub https://github.com/ucum-org/ucum/issues/159#issuecomment-1345445773, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB5E6XZN3GQUSG6XU5NC33WMVCHHANCNFSM6AAAAAAR6RC6FY . You are receiving this because you were mentioned.Message ID: @.***>

gschadow commented 1 year ago

So, it looks like CC-ND is out.

Apache / BSD / MIT will not work because it negates the controls which UCUM or any self-respecting terminology standard needs.

This subject is complicated and can only be solved if people are engaging in finding a solution and actually working with the issues.

If your product is a curated list, database, and you want to hold a copyright to give you control while at the same time share it freely, you are screwed. It's like you're reaching out a hand and unless the other side can't pull you all the way over the table (leaving only your shoes behind) you are being blamed. No good deed goes unpunished as they say.

Are you recommending to your company not to use ISO, IEEE, SNOMED, BlueTooth, USB, MedDRA, etc. release all their standards with a suitable "standard license"? Once they do, then we can adopt that too. Meanwhile people can recommend "not using" the ISO country codes because of a "non standard" license.

Clearly, we need to do something about the no derivative works prohibition. We need to open it up.

I am going to open another ticket.

Any further specific bid for a suitable "standard license" that strikes some sort of compromise or can make a case that releasing some files under a unrestricted license does not have the effect of defeating the main license, can still go in here.

dr-shorthair commented 1 year ago

@td wrote

The behavior involved in that discussion is actually as important as the license chosen for any limited distribution. My own assessment to my company is that the UCUM community is not a suitable provider for any component of software we might choose to deliver due to legal threats being made.

I wish the UCUM well in figuring out how to work with open source software communities, but I don't think that I will be able to contribute further to help this happen.

Oh dear. That is a real shame. I believe you were making a good-faith attempt to broaden the stakeholder community for UCUM, which has also been my goal over a number of years.

timbrisc commented 1 year ago

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.