Hi all,
Apache-2.0 stipulates that if a project contains a NOTICE file, then any derivative work must include a readable copy.
Let’s assume I integrate a piece of Apache-2.0 licensed software into a codebase. The REUSE Spec v3 is pretty clear in how to attribute copyright and where to put the license file. I didn’t quite get though, how you handle the NOTICE file.
Of course one could just merge all applicable notices from different NOTICE files into the project’s NOTICE file (if it is also Apache-2.0 licensed) as suggested by the license, but considering maintainability it would be easier to keep them separate, I think. In that case, should a NOTICE file also be put in the licenses folder and be associated with the the code it applies to via some naming convention? Or should it be added to a dep5-file? Or is this still to be specified…?
Thanks for any pointers,
Chris
Mit freundlichen Grüßen / Best regards
Dr. Christian Hoeppler
CR Open Source Officer (CR/ADX1.1 CR-OSO)
Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | www.bosch.com
Tel. +49 711 811-43624 | Mobile +49 1525 8813463 | Christian.Hoeppler(a)de.bosch.com
Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 14000;
Chairman of the Supervisory Board: Prof. Dr. Stefan Asenkerschbaumer; Managing Directors: Dr. Stefan Hartung,
Dr. Christian Fischer, Dr. Markus Forschner, Stefan Grosch, Dr. Markus Heyn, Dr. Tanja Rückert
Hello all,
I agree with Carmen on option 2. The reason to think about the LICENSE file is because it is common. Changing the smeantics on the file will not improve the situation, because people do not like the LICENSE file in root because it is such a nice thing, but because they are used to it and in the end the content of the file matters, so changing the content should not be an option.
When it comes to option 1 it is simply a convenience and it makes specifications much more likeable if they make themselves as convenient as possible. Perhaps it is a simple bugfix for GitHub but for the bugfix in the brains of users this is not as easy 😊. What makes the LICENSE file in the root folder convenient is the simple asosciation with the file is in the root so it applies to everything in that root folder. If it is in a sub folder, this is an additional mental step to associate the file with the brother and sister folders of its parent, so it "feels" better. I understand that more complext situations are better handled in its own box aka. folder, but for easy cases it helps to grasp the situation faster.
In the end the place only matters for human readers, because tools can easily adapt and from the way, license and copyright scanners work, they simply detect the license texts, whereever they are hidden in the folder structure, again it is then the human being who has to assess the information retrieved by the scanner who has to make the associations.
Mit freundlichen Grüßen / Best regards
Dr. Lars Geyer-Blaumeiser
Project Delivery - Open Source Services (IOC/PDL4)
Bosch.IO GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch.io
Mobil +49 172 4815079 | lars.geyer-blaumeiser(a)bosch.io
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling
________________________________
Von: REUSE <reuse-bounces(a)lists.fsfe.org> im Auftrag von Carmen Bianca Bakker <carmenbianca(a)fsfe.org>
Gesendet: Donnerstag, 5. März 2020 16:37:43
An: reuse(a)lists.fsfe.org
Betreff: Re: [REUSE] Support / repurpose central LICENSE file
Hi all,
In general I disfavour option 2 (using LICENSE to summarise the
licensing situation). This should already happen in the README of a
project, so it is a duplicated effort. Moreover, keeping the summary
up-to-date can be challenging. At least if it's in the README, you
encounter the summary every now and then, and can file a bug report if
it's out-of-date. The chances that you would randomly read LICENSE are
nil.
It has a few more issues:
- The reason that a lot of people want to keep the LICENSE file is
because GitHub auto-detects the file. A summary cannot be auto-
detected.
+ Last I heard, this is still a known issue at GitHub. GitHub wants
to support the detection of multi-licensed projects at some point.
- A lot of tools (and humans) might assume that the license text is in
LICENSE, and neglect to verify. That is obviously not what we want.
- REUSE is really cool because it introduces a machine-readable way of
doing copyright and licensing. I cannot envision an easy way in which
to make this suggested LICENSE summary machine-readable.
---
I feel more ambivalent about option 1. I'm erring towards no because it
would complicate the specification for no good reason. Having a
directory covers all cases. Having a LICENSE file adds a ton of
complications as listed in the cons.
I know two reasons to do it anyway, but I don't find them very
convincing:
1. GitHub (and/or other tools) don't recognise the LICENSES/ directory.
2. Having a single LICENSE file is easier/nicer/whatever.
Point 1 requires a simple bugfix.
Point 2 is tabs-vs-spaces. I am devoutly convinced that there is a
correct answer to the tabs-vs-spaces debate (hint: it's spaces), but
the rational part of my brain says that it just doesn't matter.
The spec is stronger when it suggests one---and only one---obvious way
to do it.
---
So I wouldn't change anything in this department. Of course, if we
don't change anything, it'll never really be a closed debate.
Ah well. 🙆
Yours with kindness,
Carmen
_______________________________________________
REUSE mailing list
REUSE(a)lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/reuse
This mailing list is covered by the FSFE's Code of Conduct. All
participants are kindly asked to be excellent to each other:
https://fsfe.org/about/codeofconduct
Hello all,
I agree with Carmen on option 2. The reason to think about the LICENSE file is
because it is common. Changing the smeantics on the file will not improve the
situation, because people do not like the LICENSE file in root because it is
such a nice thing, but because they are used to it and in the end the content
of the file matters, so changing the content should not be an option.
When it comes to option 1 it is simply a convenience and it makes
specifications much more likeable if they make themselves as convenient as
possible. Perhaps it is a simple bugfix for GitHub but for the bugfix in the
brains of users this is not as easy 😊. What makes the LICENSE file in the root
folder convenient is the simple asosciation with the file is in the root so it
applies to everything in that root folder. If it is in a sub folder, this is an
additional mental step to associate the file with the brother and sister
folders of its parent, so it "feels" better. I understand that more complext
situations are better handled in its own box aka. folder, but for easy cases it
helps to grasp the situation faster.
In the end the place only matters for human readers, because tools can easily
adapt and from the way, license and copyright scanners work, they simply detect
the license texts, whereever they are hidden in the folder structure, again it
is then the human being who has to assess the information retrieved by the
scanner who has to make the associations.
Mit freundlichen Grüßen / Best regards
Dr. Lars Geyer-Blaumeiser
Project Delivery - Open Source Services (IOC/PDL4)
Bosch.IO GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY |
www.bosch.io
Mobil +49 172 4815079 | lars.geyer-blaumeiser(a)bosch.io
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Von: REUSE <reuse-bounces(a)lists.fsfe.org> im Auftrag von Carmen Bianca Bakker
<carmenbianca(a)fsfe.org>
Gesendet: Donnerstag, 5. März 2020 16:37:43
An: reuse(a)lists.fsfe.org
Betreff: Re: [REUSE] Support / repurpose central LICENSE file
Hi all,
In general I disfavour option 2 (using LICENSE to summarise the
licensing situation). This should already happen in the README of a
project, so it is a duplicated effort. Moreover, keeping the summary
up-to-date can be challenging. At least if it's in the README, you
encounter the summary every now and then, and can file a bug report if
it's out-of-date. The chances that you would randomly read LICENSE are
nil.
It has a few more issues:
- The reason that a lot of people want to keep the LICENSE file is
because GitHub auto-detects the file. A summary cannot be auto-
detected.
+ Last I heard, this is still a known issue at GitHub. GitHub wants
to support the detection of multi-licensed projects at some point.
- A lot of tools (and humans) might assume that the license text is in
LICENSE, and neglect to verify. That is obviously not what we want.
- REUSE is really cool because it introduces a machine-readable way of
doing copyright and licensing. I cannot envision an easy way in which
to make this suggested LICENSE summary machine-readable.
---
I feel more ambivalent about option 1. I'm erring towards no because it
would complicate the specification for no good reason. Having a
directory covers all cases. Having a LICENSE file adds a ton of
complications as listed in the cons.
I know two reasons to do it anyway, but I don't find them very
convincing:
1. GitHub (and/or other tools) don't recognise the LICENSES/ directory.
2. Having a single LICENSE file is easier/nicer/whatever.
Point 1 requires a simple bugfix.
Point 2 is tabs-vs-spaces. I am devoutly convinced that there is a
correct answer to the tabs-vs-spaces debate (hint: it's spaces), but
the rational part of my brain says that it just doesn't matter.
The spec is stronger when it suggests one---and only one---obvious way
to do it.
---
So I wouldn't change anything in this department. Of course, if we
don't change anything, it'll never really be a closed debate.
Ah well. 🙆
Yours with kindness,
Carmen
_______________________________________________
REUSE mailing list
REUSE(a)lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/reuse
This mailing list is covered by the FSFE's Code of Conduct. All
participants are kindly asked to be excellent to each other:
https://fsfe.org/about/codeofconduct
_______________________________________________
REUSE mailing list
REUSE(a)lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/reuse
This mailing list is covered by the FSFE's Code of Conduct. All
participants are kindly asked to be excellent to each other:
https://fsfe.org/about/codeofconduct
--
Matthias Kirschner - President - Free Software Foundation Europe
Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290
Registered at Amtsgericht Hamburg, VR 17030 |(fsfe.org/support)
Contact (fsfe.org/about/kirschner) Weblog k7r.eu/blog.html
Ada & Zangemann - A Tale of Software, Skateboards, and Raspberry
Ice cream - For everyone from 6 - 106 years - ada.fsfe.org