LicenseRef-OASIS-IPR is considered non-free

[bgermann]

The OASIS PKCS#11 header files that you have included are non-free.
Please consider replacing them with the drop-in replacements from the NSS library or pkcs11.h from OpenSC.

[t-j-h]

They are "free" in the sense that they are open and available with a commitment that you can use them from the OASIS TC members with clear IP rights. This is an implementation using PKCS#11 v3.0.

There is only one source of the official specification and the official header files and the specification explicitly states "This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works."

The TC operates on an RF RAND terms and there are no statements or declarations from any party asserting any claim against the specification. What this does is cover you for any "hidden" claims a TC participant may have as they are required to declare such claims and are required to offer a license under the noted terms.

[simo5]

@bgermann please identify who stated that the headers are non-free and with which justification.

[bgermann]

The IPR Policy does not allow distribution of modified copies. You may only distribute derivative works "that comment on or otherwise explain it or assist in its implementation", as already mentioned by @t-j-h. Line 11 of the Policy explicitly states that "this document itself may not be modified in any way".

You can see one example of a comment that suggests the same at tpm2-software/tpm2-pkcs11#338 (comment).

So the headers are "free" as defined by @t-j-h, which is not the kind of free that is the common understanding of free software (FSF) or Open Source software (OSI).

[t-j-h]

"In whole or in part" precisely allows for the issue that you are saying cannot be done.
What is done is that you cannot produce something that conflicts and claims to be the standard.

There is clear definition of the document itself and implementation.

Get a lawyer to actually review what is permissible if you don't understand how the license and copyright actually works.

Many people have taken the original PKCS11 header files and tried to make derivatives to avoid the original RSA license terms in dubious fashions over the years. The OASIS Open license actually makes it very clear what can be done. If you have doubts over the rights you can consult a lawyer or you can ask OASIS what it actually means.

Conflating the obligations of contributing members with respect to any IP they might try to add to the specification with the rights of users of the specification is where casual readers get themselves into interpretation challenges.

If a contributing member tries to sneak in IP and subsequently make claims against implementations (a universal problem around which there is a whole range of litigation) then the OASIS IPR terms kick in. You have to declare if you have any claims as a contributing member (which none have) and if you do have such claims then you are obligated to license those specific IPR claims under the stated terms.

That gives you a lot more confidence and places you in a better position than the standards produced in most standards bodies.

[bgermann]

Making many words does not solve the problem. Many free software projects have replaced the OASIS headers with the other ones because of this. I have seen the PKCS#11 working group had discussing the license on their agenda for years and always postponed it.

[t-j-h]

You cannot change the license terms of an OASIS technical committee. It requires shutting it down and starting a new one and getting explicit permission from every single contributer.

Each time someone asks about this we go through the details to see what the problem is with the license and it turns out there isn't an actual problem in every instance other than people who feel they would like the TC to operate under different terms and for the header files to have a different license - neither of which is possible.

Look at all the projects that use it as is and their licenses and you can see there is no actual issue. Just a few left overs from previous mistaken approaches related to RSA's original license terms where people mistakenly thought they could just strip out the comments from the header file and then be able to remove copyright and attribution requirements.

Most free software uses the header files as is from RSA or OASIS and if you want modern usage from OASIS.

And for reference, I am a member of the OASIS technical committee and was responsible for PKCS#11 back when I worked for RSA long ago which was prior to RSA contributing PKCS#11 as the starting point for the OASIS Open PKCS11 technical committee.

[simo5]

@t-j-h just to be clear the OASIS license is very less than ideal, it is ambiguous and confusing, compared to well established FOSS licenses.
I highly encourage OASIS to consider changing the headers files license to something standard like ISC/MIT like licenses.

@bgermann I consulted internally and there is indeed some consensus that the license on these files is probably not free bcause it restrict modification. OTOH most of the useful data (excluding comments) in the files is probably not copyrightable anyway.

I will now close this issue pending some thinking about whether I want to go through the trouble of finding perfectly equivalent files elsewhere and import those. At the moment I do not think the license is an impediment to the use and distribution of the software except for very nitpicky downstreams. I will reconsider the matter of these headers later on.

[bluca]

@simo5 I submitted pkcs11-provider for upload to Debian/Ubuntu, and it has been rejected because of these header files, given their license is incompatible with the DFSG (https://www.debian.org/social_contract#guidelines) as it forbids modifications. Would it be possible to address this and use the equivalent headers from p11kit? It looks like that's what other projects like softhsm have done: softhsm/SoftHSMv2#412

[bgermann]

@bluca Submitting to Debian is what I was about to do when I filed the issue but did not consider it because of the header license.

[t-j-h]

@simo5 I submitted pkcs11-provider for upload to Debian/Ubuntu, and it has been rejected because of these header files, given their license is incompatible with the DFSG (https://www.debian.org/social_contract#guidelines) as it forbids modifications. Would it be possible to address this and use the equivalent headers from p11kit? It looks like that's what other projects like softhsm have done: opendnssec/SoftHSMv2#412

Details as to where this was done and who made the decision in debian would be useful so we can deal with this mistaken understanding.

[bgermann]

The decision is done by the FTP Master group: https://ftp-master.debian.org/ (contact details at the bottom).

[bluca]

@simo5 I submitted pkcs11-provider for upload to Debian/Ubuntu, and it has been rejected because of these header files, given their license is incompatible with the DFSG (https://www.debian.org/social_contract#guidelines) as it forbids modifications. Would it be possible to address this and use the equivalent headers from p11kit? It looks like that's what other projects like softhsm have done: opendnssec/SoftHSMv2#412

Details as to where this was done and who made the decision in debian would be useful so we can deal with this mistaken understanding.

The FTP team, which is in charge of deciding what is approved and what is not. What is the misunderstanding precisely? The license clearly forbids distributing modifications so it seems pretty straightforward and clear

[simo5]

@bluca I need to check if those files are actually equivalent and not an older revision.

This BS with licenses is very annoying, Debian almost certainly does not even believe that headers are copyrightable at all ... then act as is they are...

I'll take another look, but this stuff is really annoying as heck.

[simo5]

@t-j-h you said a couple of time that this is a misunderstanding, can you point to where the OASIS terms unequivocally say these headers can be modified (with whatever caveat about misrepresentations)

[simo5]

@bluca do you think debian will accept the solution in #306 ?

[bluca]

@simo5 yes, that would be great, thank you. If you are the author, I would though recommend to avoid public domain - the reason is that public domain is actually legislation dependent, and what it means changes country by country, so when possible it's best avoided. There are SPDX-approved licenses that are equivalent, but well defined and still short, for example in systemd we use MIT-0:

https://spdx.org/licenses/MIT-0.html

But it's not a blocker, we can use it either way, just a suggestion.

[simo5]

I know that Public Domain has some issue, but it is a deliberate decision, thanks.

(should it cause actual acceptance issues somewhere I may re-license the original code into an MIT-like license and update it here, but I will keep it as Public Domain as long as possible).

[simo5]

@bluca do you need a new release?
Or can you just pull from a main git id once I merge it?

[bluca]

I can upload from a git snapshot, thanks

[bluca]

FYI it's now been accepted in Debian and it will then also be in Ubuntu in a little while