-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a standard license for UCUM #159
Comments
2021-01-15 03:56:15: simon.cox@csiro.au changed component from help to support material |
2021-01-15 03:56:33: simon.cox@csiro.au edited the issue description |
2021-01-15 23:13:21: mitchbre@regenstrief.org changed status from new to assigned |
2021-01-15 23:13:21: mitchbre@regenstrief.org set owner to Governance/Process |
2021-02-16 22:43:22: simon.cox@csiro.au commented
|
2021-02-17 19:05:07: gschadow@pragmaticdata.com commented
|
2021-02-22 05:03:44: simon.cox@csiro.au commented
|
2021-02-22 13:45:14: simon.cox@csiro.au commented
|
2021-06-04 21:24:11: dvreeman@gmail.com commented
|
2021-06-07 00:03:19: simon.cox@csiro.au commented
|
2021-06-07 00:03:19: simon.cox@csiro.au |
1 similar comment
2021-06-07 00:03:19: simon.cox@csiro.au |
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. |
I can create a scaffold of the repository I am suggesting if it would help. |
@tdunning I put significant effort into this issue. |
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 Hopefully, one of the maintainers will pop in for comments. |
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. |
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.
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:
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:
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
There is clarification of what this remixing and transforming excludes:
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:
|
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. |
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
<#159 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB5E6XZN3GQUSG6XU5NC33WMVCHHANCNFSM6AAAAAAR6RC6FY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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. |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: