The High Integrity C++ Coding Standard (HICPP) by Perforce has recently been moved behind a registration wall. The original documentation links now redirect to an application form requiring email submission.
Please see: High Integrity C++ Coding Rules
If the standard is no longer publicly accessible, we need to ensure that our continued hosting of these descriptions and checks doesn’t violate their copyright. Will it be a serious problem?
The downloaded PDF, which requires a business email account to get (therefore limiting contributions to only people with a business account), has this:
© 2013 Programming Research Ltd
IANAL, but if the document is copyrighted my understanding is we do not have permission to copy it, fully or partially. The same problem happens with e.g. AUTOSAR and CUDA guidelines, which are publicly accessible, and we do not have checks for these rules for this reason.
Regarding what to do about the existing checks, keep them or remove them, I don’t know. Maybe @tstellar can give some advice?
EDIT: I found this at the end of the document:
Conditions of Use
You are free to share (copy, distribute and transmit) this complete work, or parts of this work, subject to attributing to PRQA as follows, “HIC++ Coding Standard as created by PRQA” (and you must not in any way suggest that PRQA endorses you or your use of this work).
So I guess that’s better from a legal point of view?
Considering that:
I would vote for actually removing the hicpp module altogether, and move/refactor the existing checks into misc/bugprone.
It unfortunate that one needs to go through business account and sales team to get coding standarts.
For us this means that individual contributors and maintainers won’t be able to verify bug reports/correctness of given hicpp checks.
I’m +1 on this, at least do the refactoring and later decide about removal.
IIRC tstellal on a 1-2 months break right now, we may ask about legal side a little later.
Kind of, but it’s worse for us because it has an attribution requirement which we need to honor when we deploy clang-tidy. Because of that requirement, I think we should remove the hicpp checks entirely.
CC @beanz for licensing concerns
Agreed, I don’t think it’s generally possible (or desirable) for the community to maintain support for standards that are not accessible.
I’m inclined to agree with the removal, but remind me, how different is this from ISO C++? Technically only the “draft” is freely available, it’s just our collective belief and faith that the draft matches the final ISO document that allows people to freely access the standard.
Do you think we could reasonably satisfy the attribution requirement by including that specific string somewhere in help text for these checks? Anyone vending LLVM would need to intentionally remove the checks and/or the string in order to drop the attribution.
There are moving parts here, so this is not a complete explanation. However, since ~1997, all of the papers which propose features to C++ (or C) are made publicly available as are the voting records to know which papers were adopted. So we do have access to the documents we need for any of our maintainers to do their due diligence. If this were to change, it would be an existential crisis for open source communities like ours. There are a more limited number of people who have access to the final draft text of the standard or participate on the standards committees who help ensure we meet the final wording as opposed to in–progress wording, but thankfully the number of differences between the final wording and former drafts tends to be mostly manageable.
I think we’d need a lawyer to answer that but is there enough community support and user pressure for HIC++ to be worth deviating from our usual practices even if we find a way around the attribution requirement? There are 155 coding rules in the document and our clang-tidy module exposes ~30 checks. Looking at the history for the module, it looks like the last new check was added in 2023 and the one before that seems to be 2018. Are we even sure the current checks reflect the current state of the rules they’re supposed to cover?
Aside: we’ve historically struggled to find maintainers for clang-tidy and so we don’t have any module-level maintainers. Despite that, I wonder if we should consider requiring a maintainer for modules covering external coding standards (core C++ guidelines, CERT, HIC++, etc), particularly if we add new ones.