This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adoption of C subset standards

On 09/01/17 22:17, wrote:
>> On Jan 9, 2017, at 4:08 PM, David Brown <>
>> wrote: ... I found a reference to this in MISRA's forums:
>> <>
>> 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

> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]