MISRA is a standard widely use in automotive field for C/C++ language.
And it’s published edition e.g. 2023(MISRA C++:2023: Guidelines for the use of C++17 in critical systems: Amazon.co.uk: The MISRA Consortium, Tapp, Chris: 9781911700104: Books) need to be paid.
Will it have Intellectual property issues when we start implementing a tool for check misra rule from llvm side?
Hi!
It depends, do you intend to create a private tool in a private repository, or do you intend to make it public and open-source (even further, do you intend to include it in the llvm-project repo?)
For any public usage there’s a lot of restrictions. For example, the MISRA word is trademarked so you can’t use it in the tool without permission. Reproducing the rule texts is forbidden since they are copyrighted. That’s why tools like cppcheck only prints the rule number, and you need to feed it a text file with the rule texts for them to be printed. You can read more about it here:
https://web.archive.org/web/20220703021714/https://forum.misra.org.uk/thread-884.html
If the goal is to contribute to the llvm-project, another blocker is that code-reviewers are not able to review the code without buying a copy of the MISRA document, which goes against the principles of open-source development.
We had a similar issue with AUTOSAR C++14, which is a lot easier than MISRA since the document is publicly available for free. You might want to read these discussions:
Thank you. Yes, i want to introduce misra check tools in directory clang-tools-extra/clang-tidy/ . From your description and former discussion, it seems impossible.
Yep, it’s very unfortunate. Are there are news in this regard @tstellar ?
Seems cppcheck use “misra” cppcheck/addons/misra.py at 70a1e084ff7c2011ea46115ccc81cd0c1bc80735 · danmar/cppcheck · GitHub directly 
Maybe the “misra” copyright a little looser compare to autosar？
Hi all
I’m pleased to offer an “official” MISRA position…
Hope that helps,
Kind regards
Andrew
Chairman of the MISRA C Working Group
All posts in a personal capacity unless otherwise stated.
Thank you Andrew!
FWIW, the licensing requirements may pose an issue for us (and maybe not!). Attribution can sometimes be problematic depending on the situation. This would require a license review by the LLVM Foundation board before we accepted the contribution. CC @beanz
I appreciate @AaronBallman that nothing is simple - and Open Source meeting Copyrighted material can be a challenge…
For example, with another open-source tool, we’ve published appropriate content under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0) licence.
If there is an interest in pursuing this, we can bring it to the LLVM Foundation Board to have the foundation’s lawyers review.
IANAL, but my suspicion is that the “Creative Commons Attribution-NonCommercial-NoDerivatives” is incompatible with LLVM’s permissive license and current distributors of LLVM that distribute for-profit products with Clang-powered components.
If we want to have the Foundation’s lawyers review this request we’ll need to know:
I believe this is what has recently been published:
It would be great if the MISRA C++:2023 headlines were also published 
My understanding is that none of that content would ever be part of the LLVM repository. Like cppcheck, clang-tidy could be configured to receive this file as an input from the user, but this file would not be part of nor distributed along LLVM.
Would this make things easier?
From the IP perspective maybe that’s better, but I wonder about the user perspective.
One complication that the community also needs to think about is how to handle implementation and review logistics. Clang has lots of quotes and citations to language specifications in its implementation which make it much easier for reviewers to understand the intent of the code and that the implementation matches the intent.
With MISRA’s IP constraints as described we cannot do that, we also probably can’t quote the MISRA docs in commit messages, PRs, or Clang’s documentation.
I agree with @beanz that repercussions of such restrictive license make it extremely hard to work on MISRA checks upstream. I’m also worried that even if we agree to work on this upstream with all those restrictions, MISRA can pull the rug from under us at any moment, leaving us with a chunk of code, PRs, comments that will be very hard to make sense of. I think for continuity purposes, we have to be able to host the file with the name of rules ourselves, even if it’s another repository under llvm GitHub organization, and be sure we can keep hosting it even if MISRA changes its mind in the future.
Speaking as a Clang contributor (not in my capacity with the LLVM Foundation):
I believe the “headline” text (which @AndrewBanks said would be available under Creative Commons) is really likely to be a problem from a user perspective.
With that text under any non-commercial license we would not be able to include MISRA support pre-packaged in any official LLVM releases, and many of the LLVM distributions are also unlikely to include the text.
That would produce a significantly degraded user experience because the data would have to come from a side-car file, which would not likely be included in the distributions people are using to get the toolchain today.
It also poses a maintenance challenge because any testing that relied on that data would have its own challenges and contributors may have difficulty keeping those tests passing. The descriptions of the MISRA rules would not be able to be replicated into source or other compiler documentation so we would be relying on patch authors having paid copies of the rules.
It would almost be better to have the headline text and tooling completely separate from the monorepo so that users have an additional install that is under other licensing, and the maintenance is separated from the remainder of the project.
is it possible to decouple the check itself and diag message (aka MISRA headline and content)?
In other checks domain (e.g. bugprone / modernize) we create checks and implement then, it does not need to fulfill all of MISRA check detail and llvm community can review and fix it as normal check. Then we can create new domain named MISRA and only provide the alias from other check and overwritten diag message with guideline number. In MISRA domain, we need some volunteers which have MISRA guideline text to maintain this alias.
I am not an expert on intellectual property, so I am not sure if this violates the relevant provisions of MISRA. But at least this ensures a certain balance between code review and MISRA guideline.
Fully agree, I think this is the main blocker. Ideally the LLVM Foundation could purchase the document and somehow make it available to main contributors/owners, who are in charge of code review. Users implementing new checks can be assumed to have purchased the document themselves.
even if it’s another repository
This sounds like a very interesting idea!
That would produce a significantly degraded user experience
I’m not sure this is such a big problem. As a user, I would not be surprised to have to have a copy of the MISRA rules if I want to get my code checked against it. I must be able to read the full rationale and examples of the rule. I might even have to add NOLINT suppressions for false positives. I can only do that if I have the full rules available.
is it possible to decouple the check itself and diag message
In the general case, no. There are some novel rules in MISRA that don’t exist anywhere else. Also, some rules that seem similar to existing ones have very slight modifications.
and overwritten diag message with guideline number
This is precisely what MISRA is trying to prevent us from doing and why they have these restrictions. MISRA wants the headline text to never be altered, and be presented exactly as they intend it. If we take the diagnostic message from another public check, and link it against a MISRA rule number, then we are presenting incorrect information.
I am wondering if going towards a clang plugin which is distributed as a .so file can help here?
That could be an option, if this clang-tidy plugin were to be developed in a separate repository with a different license. But maintaining a whole separate repo, CI pipelines, delivery pipelines etc is probably quite costly.
Regarding the point “developers/reviewers cannot develop without having purchased the MISRA document” - I wonder how Clang compiler developers do with the ISO C++ Standard? That’s also a document that has to be purchased. Or are the drafts considered a reliable source of truth?
Yes, draft is considered good enough. Individual papers are also useful.
Also, I’m pretty sure most of the C++ features are implemented based on the papers that propose the features rather than the full specification.
Making sure that a compiler conforms to the full C++ specification every couple years would be a nightmare.