This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Add AUTOSAR module
AbandonedPublic

Authored by carlosgalvezp on Oct 28 2021, 9:08 AM.

Details

Summary

To allow checking the AUTOSAR C++14 Coding Guidelines.

Also an easy check, alias of the C++ Core Guidelines one.

Test and documentation included.

Diff Detail

Event Timeline

carlosgalvezp created this revision.Oct 28 2021, 9:08 AM
carlosgalvezp requested review of this revision.Oct 28 2021, 9:08 AM

Specify C++14 in the module description.

Fix ordering in check list.

Update release notes.

"C++14 Guidelines"? So it's always and definitely C++14 specific? What is the licencing approach of this guideline? Looking up with searchers seems to turn up a few PDFs which say --- AUTOSAR CONFIDENTIAL ---, yet they are up and out on the official-looking website.

clang-tools-extra/clang-tidy/autosar/CMakeLists.txt
27

I'm not sure this is needed here, for this module, as of now.

carlosgalvezp added a comment.EditedOct 29 2021, 1:21 AM

"C++14 Guidelines"? So it's always and definitely C++14 specific?

To my knowledge, AUTOSAR handed over the work to MISRA and the current direction is that MISRA will merge AUTOSAR C++14 and older MISRA revisions into a brand-new MISRA release, coming up 202x (The "x" is very unclear here, it could take years to get it in place). So I would be surprised if AUTOSAR released a new version after this. The way they are written they are targeting the use of C++14.

I suppose we can change the description in the future + add configuration to select whether to choose C++14 or something else if that ever comes up, but I think it's a bit premature at this point. Would you agree?

What is the licencing approach of this guideline? Looking up with searchers seems to turn up a few PDFs which say --- AUTOSAR CONFIDENTIAL ---, yet they are up and out on the official-looking website.

Yes, that's strange. The disclaimer says the following:

The material contained in this work is protected by copyright and other types of
intellectual property rights. The commercial exploitation of the material contained in
this work requires a license to such intellectual property rights.
This work may be utilized or reproduced without any modification, in any form or by
any means, for informational purposes only. For any other purpose, no part of the
work may be utilized or reproduced, in any form or by any means, without permission
in writing from the publisher.

I'm not a lawyer but I think we can be sure that this is not a commercial use case? I guess if we were a company selling an AUTOSAR C++14-compliant static analyzer then we would need a license.

Removed unnecessary dependency in CMakeLists.txt

carlosgalvezp marked an inline comment as done.Oct 29 2021, 1:55 AM

Also, I've sent a mail to AUTOSAR directly asking for consent, so there's no doubt.

aaron.ballman added a subscriber: tonic.

Also, I've sent a mail to AUTOSAR directly asking for consent, so there's no doubt.

Thank you for reaching out to them. I am also not a lawyer, but that license worries me because people DO incorporate clang-tidy into their own commercial offerings (downstream), so we could be creating a legal hassle for them. We may need to reach out to the LLVM Foundation for guidance depending on what the AUTOSAR folks come back with (adding @tonic here for awareness as llvm foundation president).

carlosgalvezp added a comment.EditedOct 29 2021, 4:56 AM

people DO incorporate clang-tidy into their own commercial offerings

Gna, that can be a problem. I wonder if in that case it would be possible to add a few lines into the LLVM Exceptions part of the license. If it's too much of a hassle I guess I'll need to drop it and continue on a local fork unfortunately.

It's interesting however that this fork has implemented quite a few AUTOSAR checks keeping the existing LLVM license:
https://github.com/Bareflank/llvm-project

tstellar requested changes to this revision.Oct 29 2021, 10:05 AM

@carlosgalvezp Did you write this patch or did you get it from someone else?

This revision now requires changes to proceed.Oct 29 2021, 10:05 AM
carlosgalvezp added a comment.EditedOct 29 2021, 10:10 AM

@carlosgalvezp Did you write this patch or did you get it from someone else?

@tstellar I wrote it myself (following the existing pattern for the other modules in the llvm-project repo).

Just to clarify, I mentioned the above repo to point out about the license, but I don't plan to take code from there.

@carlosgalvezp The LLVM Foundation Board will conduct a legal reivew of this patch. Would you be able to share any information you have about the license or usage restrictions for the AUTOSAR specification?

carlosgalvezp added a comment.EditedNov 9 2021, 4:01 AM

@carlosgalvezp The LLVM Foundation Board will conduct a legal reivew of this patch. Would you be able to share any information you have about the license or usage restrictions for the AUTOSAR specification?

@tstellar Thanks for taking the time to review this, very much appreciated. Absolutely, here's what I know:

  • All pages of the pdf contain the footer "AUTOSAR CONFIDENTIAL". I don't understand what that means legally, given that the document is public.
  • The second page of the pdf contains a legal disclaimer, that claims the document shall be used "for information purposes only". For commercial usage, written permission from AUTOSAR must be obtained. I think it would be best if you look at the written statements directly, I might have missed important bits here.
  • There exists a llvm-project fork that has implemented some of the checks: https://github.com/Bareflank/llvm-project/tree/bsl-tidy/clang-tools-extra/clang-tidy/bsl. They don't explicitly name Autosar anywhere in the code, but it's clear that they implement Autosar checks. In fact some commits refer to the rule number. The license of this fork is kept as the existing Apache 2.0 with LLVM Exceptions. I don't know if this was agreed with Autosar or simply the author didn't take enough consideration about the licensing aspects. I just want to mention that open-source Autosar checks already exist today under that license, whether it's a mistake or not.
  • I have sent an email to AUTOSAR requesting their consent to implement open-source checks. Would you like me to CC you and other members of the Board into that mail? Who should I add?
  • More restrictive guidelines (the pdf document/license must be purchased), like MISRA, do allow open-source checkers, as long as only the rule number (not the rule text) is displayed.

I believe that's all I know, I hope it helps in reviewing this issue. Let me know if there are more questions or anything is unclear!

@tstellar @tonic I have finally received an answer from AUTOSAR. Let me know if you'd like me to CC you the mail chain to see the exact discussion.

The AUTOSAR confidential statement states that these documents are considered under the license of AUTOSAR, thus a commercial usage without being a partner is not allowed.

As you stated correctly, the C++14 guidelines have been handed over to MISRA and will be released there in spring 2022 according to my knowledge.

Since we had other similar requests already, I can state that this usage of the guidelines is uncritical from AUTOSAR’s perspective.

@tstellar @tonic I have finally received an answer from AUTOSAR. Let me know if you'd like me to CC you the mail chain to see the exact discussion.

Can you cc board@llvm.org on the mail chain.

@tstellar I totally missed your fast reply, sorry about that! I have just forwarded the mail chain to the indicated address. Let me know if there's anything else I can do to help.

@tstellar Do you have any updates on the topic? What approximate time frame should I expect? Thanks!

Unfortunately our legal counsel has advised that this patch should not be included into LLVM because the exact patent burden is not disclosed. Therefore, we can not accept this patch into LLVM. I am very sorry to have to report this disappointing news.

Thanks a lot @tonic for your update and for the work done in the last months ! It's indeed very sad to hear the news. It's a pity that the work will probably be duplicated in many local forks with sub-optimal solutions instead of a centralized, high-quality, peer-reviewed open-source solution.

I'm not very familiar with the terms so I'm not sure I fully understand the reasons why we are advised not to proceed. Could you clarify/elaborate on what it means "the exact patent burden is not disclosed"? I was hoping that the written consent we got from AUTOSAR would be a strong basis to move forward.

Thanks a lot @tonic for your update and for the work done in the last months ! It's indeed very sad to hear the news. It's a pity that the work will probably be duplicated in many local forks with sub-optimal solutions instead of a centralized, high-quality, peer-reviewed open-source solution.

I'm not very familiar with the terms so I'm not sure I fully understand the reasons why we are advised not to proceed. Could you clarify/elaborate on what it means "the exact patent burden is not disclosed"? I was hoping that the written consent we got from AUTOSAR would be a strong basis to move forward.

In general it would also be good to know if there was any other impediment to move forward. This information would be extremely valuable to try and do better in the future - I'm thinking on the upcoming MISRA release.

Chris Tapp (chair of MISRA) has been involved in similar discussions in the cfe-dev mailing list, so I think it would be beneficial for him to get this feedback and hopefully make the upcoming MISRA release easy to work with from this standpoint (if MISRA is interested in an open-source checker implementation, of course).

Looking forward to your thoughts :)

Hi all, I'm commenting on this based on my personal opinion, I don't speak for the LLVM board or anyone else. I am also not a lawyer :)

This isn’t a clear cut case (as is typical!). LLVM's approach on patents protection revolves primarily around the terms in the Apache 2 license, which is based on the owner of patents contributing code. Beyond that, we can’t/don't proactively do all the research of potential patent infringement of contributed code.

That said, we have historically NOT taken code that is known to infringe on high risk patents. The one that comes to mind is the (now expired) patents on Steensgaard’s unification-based pointer analysis work. We rejected taking related work until those patents expire.

In this case, AUTOSAR/Parasoft looks like a little company, their spec is clearly saying they have IP rights associated with it, and the risks seem very high to me. I think we should ask for a legal statement signed by a director of the company (not an informal email) saying we can use this in LLVM. The risk is just otherwise too high for the vast community of people who use LLVM.

-Chris

lattner requested changes to this revision.Feb 18 2022, 9:34 AM
carlosgalvezp abandoned this revision.Feb 18 2022, 10:54 AM

Understood, thanks a lot for the clarification and for the time taken!

I will then abandon this patch given the high risk involved. I will forward this feedback to MISRA in case there is a possibility to publish the upcoming revision in open-source-friendly terms.

Thank you so much Carlos, I hope they can come to see the value of having first class support for this in LLVM/Clang. I really appreciate you pushing for this,

-Chris