Missing licenses from ST

MMarwedel commented 5 years ago

Hello, ST uses two types of licenses, which are currently not detected. The first one has additional requirements to the BSD-style license, and is currently detected as simply BSD. You can find multiple samples of this here on Github, like: https://github.com/akospasztor/stm32-bootloader/blob/master/Middlewares/Third_Party/FatFs/src/diskio.c or https://github.com/aws/amazon-freertos/blob/master/lib/third_party/mcu_vendor/st/stm32l475_discovery/BSP/B-L475E-IOT01/stm32l475e_iot01_tsensor.c

The second one is something "different": https://github.com/micropython/micropython/blob/master/ports/stm32/usbhost/Class/AUDIO/Inc/usbh_audio.h or https://github.com/JoeMerten/Stm32-Tools-Evaluation/blob/master/STM32Cube_FW_F4_V1.9.0/Middlewares/ST/STM32_USB_Host_Library/Core/Src/usbh_core.c The license is already named in #662 but is declared resolved in #900 however, the license text added in #900 is different.

The following rules add a detection, I welcome a better naming of the files/rules and category.

missingLicenses.zip

pombredanne commented 5 years ago

Thanks: this is great The names you picked are actually quite good. The only question is whether the proprietary license is frequent enough to deserve a name of its own, as opposed to be only a few extra detection rules for a proprietary-license... but a quick search https://github.com/search?q=%22MCD-ST+Liberty+SW+License+Agreement+V2%22&type=Code tells me this is worth it.

One small note: we usually prefer using st-mcd-2.0 rather than st-mcd-v2 in the key, but that minor.

pombredanne commented 5 years ago

ping?

MMarwedel commented 5 years ago

Anything else you want me to do in this case? Or should I add the renamed files as pull request?

pombredanne commented 5 years ago

@MMarwedel a pull request would be best if you can manage that. Otherwise it is your call to make two new licenses or one license and some new rules. Thanks!

pombredanne commented 5 years ago

@MMarwedel thank you for your PR: I merged #1559 in the branch you requested and that will eventually be merged in develop once all the test runs are completed. You will note that I added a few changes: I used the full license text for the .LICENSE file... https://github.com/nexB/scancode-toolkit/commit/27a272f610219c6be1a88831926477b8b9d2738aand created a few rules for the notice you add used as the text as a well as a few other common variants: https://github.com/nexB/scancode-toolkit/commit/ec5004ef4493ec38ad7fc54530e4450f0cf6d010

Thank you again for your contributions. For reference any incorrect or missing license detection is treated as a bug, so if you find more of these, please enter a ticket as you did here.

pombredanne commented 5 years ago

@MMarwedel

Actually I did revisit this as I was finding highly suspicious that the commits for #900 and #662 were not correct as the ticket was for the same license URL... And here is the mess: the same URL https://www.st.com/software_license_agreement_liberty_v2 for the so called "MCD-ST Liberty SW License Agreement V2" has pointed to different content over the years. At least these three versions:

From 2011 to 2015, various redirects but all to the same PDF. It carries this note at the bottom: "Software License Agreement (Liberty V2) Nov 16 th , 2011" ... this is therefore the only "true" Software License Agreement (Liberty V2) IMHO.

2015 ... Feb 2018: This is no longer a PDF but a plain text file and a completely different agreement:

http://www.st.com/content/ccc/resource/legal/legal_agreement/license_agreement/de/fc/f7/32/a0/8b/4f/db/ultimate-liberty-v2.txt/files/ultimate-liberty-v2.txt/jcr:content/translations/en.ultimate-liberty-v2.txt https://web.archive.org/web/20180207212429/http://www.st.com/content/ccc/resource/legal/legal_agreement/license_agreement/de/fc/f7/32/a0/8b/4f/db/ultimate-liberty-v2.txt/files/ultimate-liberty-v2.txt/jcr:content/translations/en.ultimate-liberty-v2.txt

I was expecting this to be one added by #900 but while very close they are different.

From Feb 2018 (after #900 was merged) ... we have yet another text which is the current one Feb 2018 ... May 2019: https://www.st.com/content/ccc/resource/legal/legal_agreement/license_agreement/group0/59/57/63/12/cf/a6/47/65/SLA0044/files/SLA0044.txt/jcr:content/translations/en.SLA0044.txt This is the one I used to day as a text. It as has this header "SLA0044 Rev5/February 2018"

I have attached and formatted these three texts for reference: st-mcd-2.0_2011.LICENSE.txt st-mcd-2.0_2015.LICENSE.txt st-mcd-2.0_2018.LICENSE.txt

What do you think we should do for sorting out this mess?

We could reach out to ST https://github.com/STMicroelectronics as there are some folks we could ping there:
- https://github.com/BernardPuel
- https://github.com/CCASTM

we could also update things but then which license is the one for this notice? The license name is for the 2011 version for sure... But on the other the URL points now to the 2018 version. I would err for the first case. Please advise!

* Licensed under MCD-ST Liberty SW License Agreement V2, (the "License");
* You may not use this file except in compliance with the License.
* You may obtain a copy of the License at:
*
*        http://www.st.com/software_license_agreement_liberty_v2
*
* Unless required by applicable law or agreed to in writing, software 
* distributed under the License is distributed on an "AS IS" BASIS, 
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.

MMarwedel commented 5 years ago

Thanks for doing the work for sorting this things out. Maybe contacting ST is the best solution. I dont have a good idea at the moment.

pombredanne commented 5 years ago

@MMarwedel let me ping the them here. I cannot hurt! @BernardPuel @CCASTM I am pinging you because I saw your names associated with @STMicroelectronics and we are trying to sort out some ST software licensing ambiguities. You can see the history above. If you could forward this to someone that could help that would be very gentle of you! Thank you.

0xc0170 commented 3 years ago

I found this issue, it's related to ST so I am reporting here their new license format. I don't know how actually can scancode detect their license properly.

What they do in the recent components, add LICENSE file that lists either full text license, and the files contain only this:

  * Copyright (c) 2020(-2021) STMicroelectronics.
  * All rights reserved.
  *
  * This software is licensed under terms that can be found in the LICENSE file
  * in the root directory of this software component.
  * If no LICENSE file comes with this software, it is provided AS-IS.

It's not easy to find out what is root if the component is distributed as part of bigger software pack. How shall this work? I find this format hard to play with license checking software.

pombredanne commented 2 years ago

@0xc0170 I had missed this when you posted it ....

It's not easy to find out what is root if the component is distributed as part of bigger software pack. How shall this work? I find this format hard to play with license checking software.

Yes, this is a difficult and weird thing to handle as this is ambiguous.

Some thoughts:

@akugarg contributed a new feature that can smartly find and follow the LICENSE file and its license ... See https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/plugin_license.py#L132
I am adding a specific rule that can be detected for this notice and work with the above ST wording and the code of 1.
@JonoYang and @AyanSinhaMahapatra are working on a feature to report a primary license for packages. Which means eventually having a way of finding package roots in a bigger software stack. Some of the tracking issues are #2065 and #2418 The general idea is to use the presence of specific well-known "key files" such as LICENSE, README, etc. to determine if a given dir is a possible package root.

aboutcode-org / scancode-toolkit

Missing licenses from ST #1549