On 09/01/17 22:17, paul.kon...@dell.com wrote: > >> On Jan 9, 2017, at 4:08 PM, David Brown <da...@westcontrol.com> >> wrote: ... I found a reference to this in MISRA's forums: >> >> <https://www.misra.org.uk/forum/viewtopic.php?f=56&t=1189> >> >> The post and reply are from 4 years ago, but I expect the situation >> is the same now as then. Basically, MISRA are quite happy for any >> tools to support checking of the rules, no matter what the license >> of the tools, and there is no certification or checking for >> conformance. However, if you are going to include the rule texts, >> you need that part of the checker to be under a "commercial license >> agreement that contain[s] the expected restrictions on reverse >> engineering or extracting of information from the software". The >> say it's fine for a pure open source checker to refer to the checks >> by MISRA rule number, but not by rule text. It looks like no >> license is needed from MISRA to do this. > > I'd say that messages of the form "you violated rule number 42" are > unacceptable, since they have no intellegible meaning.
Such messages /are/ useful and meaningful for people who are interested in MISRA compliance checking, and who have a copy of the MISRA standards for reference. In many cases, the MISRA rule would be triggered along with a normal gcc warning. If you write "if (x = 1) ...", gcc (with -Wparenthesis) will warn about suggesting parenthesis around the expression, while MISRA checking will trigger rule 13.4. And for MISRA rules that are never going to be of interest outside MISRA checking, such as a ban on types like "int" (yes, really - advisory directive 4.6), you can easily look them up in the MISRA documents. I would hope that a checker is allowed so say "you violated MISRA directive 4.6", using the MISRA name, but even without that the checks are useful. And on the other hand, no level of detail in warning messages is going to make MISRA directives like 4.6 make sense to people unfamiliar with MISRA - you are not going to be able to give a message that convinces "normal" gcc users that using "int" is a bad idea. You have to remember that an option (or plugin) for MISRA checking is /only/ of interest to people who need to check MISRA compliance, and already have the MISRA documents on hand. This is why I have been arguing for a plugin, not putting MISRA checking into the main gcc. > And the MISRA > reply you pointed to says specifically that GCC couldn't get a > license to use the messages because it's under GPL. There is no need to "get a licence" here for any purpose, except for a copy of the copyrighted MISRA documents. The reply I referenced said that you cannot use copyrighted MISRA materials (such as the rule texts) in a form where this text is easily extractable, without /your/ code having a licence or contract that forbids such extraction. That does mean that a MISRA checker that includes rule texts cannot be under an open source licence (at least, not the part that generates the rule texts). > (The "additional > module" exception mentioned afterwards seems to be based on a > misunderstanding of the GPL "derived work" machinery.) Perhaps, but not necessarily. There are ways to combine GPL'd programs with non-GPL'ed code. For example, as far as I understand it the GCC Python plugin is under the GPL, but the Python code it runs does not have to be under the GPL. And while you may not /distribute/ code that directly mixes GPL'ed code and incompatible code, there is nothing that hinders people from /using/ such a mixture. One possible solution could be to write a set of scripts for the GCC Python plugin that do the MISRA checking and generate warnings or reports with just the rule numbers. That can all be under the GPL. This can be distributed along with another GPL'ed Python script that will read a copy of the MISRA C:2012 pdf document and extract the rule texts and the licensing watermark, and generate an additional script for the Python plugin that expands the checks. /This/ script would not be under the GPL - it would have a licence specifically disallowing copying, "reverse engineering", etc., and be personalised to the name on the MISRA pdf. When you run the Python MISRA checker plugin with this additional script, you would get the full rule texts, but all MISRA's requirements to protect their copyrighted work are in place. Yes, this would be jumping through a few hoops - but compared to the effort of actually writing the MISRA checking code, it's a drop in the ocean. > > It looks like MISRA should adjust its rules if it wants to support > open source. It strikes me that in comparison to most "industry standard" bodies, they have gone far out of their way to support open source and have specifically said that pure open source checkers can be made as long as the rule text is not included. MISRA put a lot of effort into making their documents, and want to protect their copyright in the way they see fit - that is their right, and should be respected just as the gcc developers want to protect /their/ copyrights in the way /they/ see best. MISRA's copyright requirements are a lot easier for many people to handle than the GPL's requirements - it is the /GPL/ that hinders the use of copyrighted text in this case. > > paul >
