Dear all,
With this thread we would like to open the discussion for a few possible improvements of the REUSE specification (currently v3.0, see repository [^1]). While we did not experience any large failures, there might be spots where some tweaking will make it easier for developers and other compliance efforts to adopt REUSE.
I will write a separate email per suggestion and would like to ask you to reply to them individually if you want to provide input to one or multiple suggestions directly. For your convenience, here's an overview:
* Support / repurpose central LICENSE file * Introduce folder.license file * Handle copyright and licensing of snippets * Default handling of submodules
If you have additional suggestions, please open a separate thread on this mailing list.
Please note that all of these are *suggestions* which might be modified or even completely dropped if they are not convincing enough for stakeholders and/or the REUSE team.
Your input will be highly appreciated and help us draft an incremental update of the specification. Thank you!
Best regards, Max
[^1]: https://github.com/fsfe/reuse-docs
There has been the wish to officially support "traditional" LICENSE files in the root of a repository, so a license text of the license being used in the project. This is supposed to lower the threshold for REUSE adopters and license compliance projects.
REUSE currently requires to have a license texts stored inside the LICENSES/ directory named after their SPDX License Identifiers. We see two main reasons for this:
* If there is more than one license being used in a project, it automatically would require two LICENSE files. That is why REUSE chose the LICENSES/ directory. * Identifying the license of the LICENSE file requires heuristic license scanners. With the REUSE solution, it is possible to identify the covered license by its file name, so e.g. "LICENSES/AGPL-3.0-or-later.txt". There is still no warranty that no one wrongly names the license text file, but we primarily assume good faith.
Using a LICENSE file is not denied by the REUSE specification, however it would require that a copy of the file is stored under the LICENSES/ directory under its respective name.
We recognise that this new paradigm might increase the threshold of adopters and for instance clash with GitHub's repository creation wizard that can automatically create the traditional license file. That is why I would like to propose *two options* for a compromise.
## Option 1: LICENSE file valid for one-license repositories
The LICENSE file alone (so not LICENSES/ directory) is a valid option in case the repository only contains files with one SPDX license identifier. REUSE would then assume that the found identifier matches the actual license in LICENSE.
Pros: - Projects using only one license would not have to think about moving the license text file or create a potential duplicate license text. Adoption would be easier therefore. - License scanners could rely on the existence of the LICENSE file in case of one-license repos.
Cons: - If projects introduce a second license (e.g. because of adding an external component, or dual-licensing), REUSE have to mandate introducing the LICENSES/ directory because only that offers the transparency it seeks. So REUSE would carry another threshold down the road if projects evolve license-wise. Currently, as soon as a project is REUSE compliant, keeping the status is rather trivial. - If a second license is introduced, how to deal with the "old" LICENSE file then? - License scanners supporting REUSE would have to be prepared for two scenarios: LICENSE file existent, only the LICENSES/ directory, and both being existent. - In case of a change of license, the user would perhaps only update the license identifiers but not the LICENSE file. With the current REUSE way, the linter would complain about a missing license text, and a superflous one. - Additionally, it is harder for REUSE to assume good faith that the LICENSE file's license matched the found SPDX license identifier.
## Option 2: Repurpose LICENSE file to explain general licensing situation
In combination with debates how to declare the preferred inbound and outbound license (a.k.a. "default license" or "main license"), there is the suggestion to repurpose the LICENSE file to explain the general licensing information of the repository. It would be an optional file though to not introduce breaking changes for already REUSE compliant repos.
So a REUSE-compliant LICENSE file could contain the following text:
``` This repository follows the REUSE best practices for clear copyright and licensing information.
The license texts for all used licenses can be found in the LICENSES/ directory under the root of this repository.
Preferred inbound license: Apache-2.0
Preferred outbound license: Apache-2.0 ```
Pros: - The LICENSE file would still be the main point for people to learn about the licensing of a project. It would also be obvious where to look for the actual license texts. - Even in a project containg multiple licenses, it would be possible to define the preferred inbound and outbound licenses in a more or less standardised way (so not in the README or so). - If there was a wish for a more standardised layout of the file, one could think of SPDX tags to declare the preferred inbound/outbound license. - The whole handling of licenses would not change in the REUSE way. Adding or removing licenses would work as before, and it would not matter how many licenses the project uses. All the spec and tool may have to check is whether the inbound/outbound license does exist as license text in LICENSES/.
Cons: - There would be another purpose for the LICENSE file apart from the usual one. However, since there is no common way how to deal with multiple license texts, people already merge multiple license texts into this file or add custom text and introductions anyway. - This should be supported by source forges and other license compliance tools. - It's "yet another standard" for how to declare this additional information.
Alternative: - Do not use the LICENSE file for that but the README file. However, since most people care about keeping the LICENSE file, and since README is a more fluctuating file, this does not come with many benefits against the current state.
## Summary
As you can see, I consider the pro/con to balance in favour of the repurposed LICENSE file, although it may lead to some more coordination effort with source forges and other license compliance projects. But hey, that's why we are here, right? And there are also people who would rather be in favour of not changing REUSE's handling of LICENSE files at all.
Please share your opinion on these two options (and the third: do not change) in reply to this mail. Thank you!
Best, Max
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
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@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@lists.fsfe.org im Auftrag von Carmen Bianca Bakker carmenbianca@fsfe.org Gesendet: Donnerstag, 5. März 2020 16:37:43 An: reuse@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@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
Hi all,
My 2 cents, and a proposition.
I would rather disfavor option 1, simply because it does not solve the problems :) - no indication of {in|out}bound licenses - no clear SPDX identification of the license
I would intuitively favor option 2, because: - today's LICENSE file contains a license text, and not an SPDX identifier. That's an inconsistency compared to other license identification in the REUSE specs. - It addresses the {in|out}bound licenses problem nicely - We can still support old-style LICENSE full text -> we don't have to fix people's minds.
Now, to circumvent the problem of re-purposing the LICENSE file, why not introduce a new file, like "LICENSE.reuse" ? - we can still store the license text in the LICENSE file - it is close enough to LICENSE so that it attracts people who are looking for compliance info - it would ease the adoption of this standard by GitHub & co - this new file could be generated automatically by the REUSE tools. - it would take precedence over the LICENSE file (I suppose)
I would just modify the content of the file: - to insert a link to REUSE specs - make it more easily parsable (maybe see with the SPDX team to create new tags like SPDX-License-Identifier)
I would not want to mess with the README.md file, that is not made to be parsable, unless adding the SPDX stanza to identify the outbound license. - not sure that updating README.md be will easier than a LICENSE.reuse - one can add a pointer/link to the LICENSE file in the README. - REUSE tools could also automatically insert relevant lines in the README like it does in source code files.
Nico
On 06/03/2020 16:55, Geyer-Blaumeiser Lars (IOC/PDL4) wrote:
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@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@lists.fsfe.org im Auftrag von Carmen Bianca Bakker carmenbianca@fsfe.org *Gesendet:* Donnerstag, 5. März 2020 16:37:43 *An:* reuse@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:
GitHub (and/or other tools) don't recognise the LICENSES/ directory.
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@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@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
Hi Nico,
Thanks for the feedback (in general @all for the lively and constructive exchange!)
~ nicolas1.toussaint@orange.com [2020-03-12 17:55 +0100]:
Now, to circumvent the problem of re-purposing the LICENSE file, why not introduce a new file, like "LICENSE.reuse" ?
- we can still store the license text in the LICENSE file
- it is close enough to LICENSE so that it attracts people who
are looking for compliance info
- it would ease the adoption of this standard by GitHub & co
- this new file could be generated automatically by the REUSE tools.
- it would take precedence over the LICENSE file (I suppose)
Wouldn't we run into a few issues here?
* LICENSE would still exist, but what should it contain if the project has more than 1 license? Option 1 suggests that a LICENSE file would only be valid if there was only 1 license used. If there are more, REUSE would require the LICENSES directory * Could a meta data file like LICENSE.reuse take precedence over a LICENSE file which contains a full license text?
I would just modify the content of the file:
- to insert a link to REUSE specs
- make it more easily parsable (maybe see with the SPDX team to create
new tags like SPDX-License-Identifier)
Good ideas. The first point if definitely useful, the second one would require new tags probably as I didn't find any for preferred inbound/outbound, and obviously none for REUSE status/version or LICENSES.
Best, Max
Late to the party, but adding my thoughts in short.
As others have stated, neither proposal is optimal, and in any case with so much crowd muscle memory, we’re damned if we change the status quo, and remain damned if we don’t.
The lazy way out would be to keep it as it is and just let the `LICENSE` file be outside of REUSE’s scope – if there is one, so be it, but there needs to be a `LICENSES/` folder.
If we want to be more avantgarde, it is a great opportunity to improve the situation. The question remains if the gains outweighs the losses (kudos for framing it that way already at the start!).
## Option 1: LICENSE file valid for one-license repositories
This was already in REUSE spec before, and went out for a reason. The cons simply outweigh the pros. And if anyone really wants to continue to have a `LICENSE` file, they still can, and their REUSE compliance is just a simple: `cp LICENSE LICENSES/${spdx_id}.txt` away.
## Option 2: Repurpose LICENSE file to explain general licensing situation
The problem I see with this is that it would add an additional burden on the maintainers, while giving very limited benefit.
TBH, if I saw something written in a `LICENSE` file, I would still take a quick glance at the filenames in `LICENSES/`. Well, actually, I would still run `reuse` or FOSSology over it anyway, as I don’t trust that whenever someone introduced a new license somewhere into the code base, they actually bothered to update the `LICENSE` file (and I’d only rely on the content of `LICENSES/` folder, if the project was REUSE compliant).
So I see no benefit in Option 2.
I think a suggestion (not a hard rule of the spec) that they should summarise the software’s licensing situation in README (or LICENSE) should be enough IMHO.
Also, while the `LICENSE` file in the root folder is common, there are many other common ways out there – `docs/licenses`, `lib/oss_licenses`, `COPYING`, `COPYING.GPL`, `COPYRIGHT`, `COPYLEFT`, …
If we really wanted to have something useful, we could ask for an SPDX file in the root of the folder, but even then we would need to trust that the maintainer actually regenerates the SPDX file regularly enough. In previous versions of the REUSE, that was actually part of the spec but it was removed, because it was deemed that we cannot burned the maintainers with also maintaining a SPDX file, especially when the `reuse` tool can very easily create an SPDX file out of a compliant codebase anyway.
cheers, Matija
With the current specification it's possible to create an extra file containing the copyright and licensing information for binary files or those not supporting comment headers. So for instance, for the file `cat.jpg`, you can create the text file `cat.jpg.license` which contains the SPDX-License-Identifier and SPDX-FileCopyrightText (or the traditional Copyright ©) lines.
That works well for single files, but how to deal with a directory containing hundreds of such files, e.g. icons or JSON files? Currently, you would either have to create a .license file for each of them, or bulk-license this in the REUSE dep5 file [^1].
This is a bit clunky. Therefore we suggest to introduce the same mechanism for folders that we already have for binary files: folder.license
Example: the directory `img/` contains a lot of non-editable files. To add copyright and licensing information for every single of these files, one could create the text file `img.license` on the same level as the directory itself. This file would then contain the required information.
Pros: - Easier way to bulk-license directories - Information is closer to the actual files and not far away in .reuse/dep5. - It's feels intuitive to support the same mechanism for directories as for files.
Cons: - Could be abused by lazy people who then would only create one .license file for a complex hierarchy, e.g. by doing that for the `src/` folder. This would conflict with REUSE's goal to have the information as close to the files as possible (ideally as comment header). - Potential "option overload", since this would be the fourth option to declary copyright and licensing information next to comment header, file.license, and dep5 file.
Options: - Soft-deprecate the dep5 file over time if we introduced the folder.license scheme if we consider dep5 to be used mainly for bulk-licensing directories. However, dep5 also supports wildcards like `*.png`. - Like the dep5 soft-deprecation above, but combined with the introduction of a better format. DEP5 has its limitations, has a different syntax in some places, and REUSE also overrides some parts of the DEP5 spec. So something like JSON or YAML could be more appropriate.
Please share your opinion on this suggestion in reply to this mail. Thank you!
Best, Max
[^1]: https://reuse.software/faq/#bulk-license
Some thoughts here
You propse to have the file right beside the folder. I understand this due to the similarity to the mechanism for files, but I would rather prefer to have the file inside the folder. Why, because it makes the connection to the folder clearer, if the file is beside the folder it might be difficult to see the association because, e.g., dependending on the browser the files might be shown separately from the folders and the association for a human looking at the parent folder is difficult.
If it is entered into the folder, it might be favorable to use a naming scheme that make the folder license easily detectable, like choosing a name that typically ends up first in the list, e.g., using '_' as first character.
Will the license file allow to reflect multiple licenses, it could be that the copyright holder and even the licenses differ for the different files referenced? Or which mechanism would allow to make as few license references as possible but allowing the possibility of different information for different sets of files?
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@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@lists.fsfe.org im Auftrag von Max Mehl max.mehl@fsfe.org Gesendet: Donnerstag, 5. März 2020 12:35:08 An: reuse@lists.fsfe.org Betreff: [REUSE] Introduce folder.license file
With the current specification it's possible to create an extra file containing the copyright and licensing information for binary files or those not supporting comment headers. So for instance, for the file `cat.jpg`, you can create the text file `cat.jpg.license` which contains the SPDX-License-Identifier and SPDX-FileCopyrightText (or the traditional Copyright ©) lines.
That works well for single files, but how to deal with a directory containing hundreds of such files, e.g. icons or JSON files? Currently, you would either have to create a .license file for each of them, or bulk-license this in the REUSE dep5 file [^1].
This is a bit clunky. Therefore we suggest to introduce the same mechanism for folders that we already have for binary files: folder.license
Example: the directory `img/` contains a lot of non-editable files. To add copyright and licensing information for every single of these files, one could create the text file `img.license` on the same level as the directory itself. This file would then contain the required information.
Pros: - Easier way to bulk-license directories - Information is closer to the actual files and not far away in .reuse/dep5. - It's feels intuitive to support the same mechanism for directories as for files.
Cons: - Could be abused by lazy people who then would only create one .license file for a complex hierarchy, e.g. by doing that for the `src/` folder. This would conflict with REUSE's goal to have the information as close to the files as possible (ideally as comment header). - Potential "option overload", since this would be the fourth option to declary copyright and licensing information next to comment header, file.license, and dep5 file.
Options: - Soft-deprecate the dep5 file over time if we introduced the folder.license scheme if we consider dep5 to be used mainly for bulk-licensing directories. However, dep5 also supports wildcards like `*.png`. - Like the dep5 soft-deprecation above, but combined with the introduction of a better format. DEP5 has its limitations, has a different syntax in some places, and REUSE also overrides some parts of the DEP5 spec. So something like JSON or YAML could be more appropriate.
Please share your opinion on this suggestion in reply to this mail. Thank you!
Best, Max
[^1]: https://reuse.software/faq/#bulk-license
-- Max Mehl - Programme Manager - Free Software Foundation Europe Contact and information: https://fsfe.org/about/mehl | @mxmehl Become a supporter of software freedom: https://fsfe.org/join _______________________________________________ REUSE mailing list REUSE@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
Hi Lars, all,
Je ven, 2020-03-06 je 15:41 +0000, Geyer-Blaumeiser Lars (IOC/PDL4) skribis:
Some thoughts here
You propse to have the file right beside the folder. I understand this due to the similarity to the mechanism for files, but I would rather prefer to have the file inside the folder. Why, because it makes the connection to the folder clearer, if the file is beside the folder it might be difficult to see the association because, e.g., dependending on the browser the files might be shown separately from the folders and the association for a human looking at the parent folder is difficult.
This makes sense as an accessibility/discoverability feature. It also, however, removes the most attractive feature of `folder.license`, which is that it would be equivalent to `file.license`.
Will the license file allow to reflect multiple licenses, it could be that the copyright holder and even the licenses differ for the different files referenced? Or which mechanism would allow to make as few license references as possible but allowing the possibility of different information for different sets of files?
As written, it wouldn't. The file would contain a simple REUSE header that indiscriminately applies to all files in the directory.
---
I'm more inclined to slowly deprecate DEP5 and replace it with a format that was built for purpose. We're currently kind of co-opting DEP5, which has a lot of features that we don't need, a syntax which is difficult to parse, and some instructions in its specification that contradict the REUSE Specification. Also, generally, the DEP5 specification is a bit of a drag to read.
On the tooling end, replacing DEP5 with something else would get rid of a dependency on `python-debian`. It would also enable people to write REUSE tooling in languages that do not have library support for DEP5.
There's an interesting choice that could be made here, though. Instead of having the configuration be *global*, what if we mixed the best of both worlds? So instead of having the configuration in `.reuse/dep5- replacement.json`, what if we put it in the directories?
This would have one very clear benefit: The closer that the file is to the source, the more detectable it is.
The disadvantage is that scattered configuration can be a pain in the behind.
There are some more design things that need to be figured out:
- The format should probably be able to handle globs ("*", "*.png", etc.) - Should the format be able to handle individual files? ("README.rst", ".gitkeep") - Should the format allow licensing of files that are deeper in the directory tree? ("**/*.png", "resources/vid/*.mp4") - Should the format allow "overriding" of existing notices? (e.g., it contains ".gitignore" even though ".gitignore" already contains a REUSE header. Currently with DEP5, the licensing information is simply combined)
... Probably some more things that I'm forgetting. Maybe another time :)
Yours with kindness, Carmen
My 2c from the peanut gallery...
Having the license file IN the folder is consistent with the repo and package scenarios where the license file(s) are at/near the root of the content being licensed. Also helps ensure the license info stays near the files it targets in copy/paste scenarios.
I would try to find some symmetry from the top down rather than bottom up.
Jeff
On Mon, Mar 9, 2020 at 10:47 AM Carmen Bianca Bakker carmenbianca@fsfe.org wrote:
Hi Lars, all,
Je ven, 2020-03-06 je 15:41 +0000, Geyer-Blaumeiser Lars (IOC/PDL4) skribis:
Some thoughts here
You propse to have the file right beside the folder. I understand this
due to the similarity to the mechanism for files, but I would rather prefer to have the file inside the folder. Why, because it makes the connection to the folder clearer, if the file is beside the folder it might be difficult to see the association because, e.g., dependending on the browser the files might be shown separately from the folders and the association for a human looking at the parent folder is difficult.
This makes sense as an accessibility/discoverability feature. It also, however, removes the most attractive feature of `folder.license`, which is that it would be equivalent to `file.license`.
Will the license file allow to reflect multiple licenses, it could be
that the copyright holder and even the licenses differ for the different files referenced? Or which mechanism would allow to make as few license references as possible but allowing the possibility of different information for different sets of files?
As written, it wouldn't. The file would contain a simple REUSE header that indiscriminately applies to all files in the directory.
I'm more inclined to slowly deprecate DEP5 and replace it with a format that was built for purpose. We're currently kind of co-opting DEP5, which has a lot of features that we don't need, a syntax which is difficult to parse, and some instructions in its specification that contradict the REUSE Specification. Also, generally, the DEP5 specification is a bit of a drag to read.
On the tooling end, replacing DEP5 with something else would get rid of a dependency on `python-debian`. It would also enable people to write REUSE tooling in languages that do not have library support for DEP5.
There's an interesting choice that could be made here, though. Instead of having the configuration be *global*, what if we mixed the best of both worlds? So instead of having the configuration in `.reuse/dep5- replacement.json`, what if we put it in the directories?
This would have one very clear benefit: The closer that the file is to the source, the more detectable it is.
The disadvantage is that scattered configuration can be a pain in the behind.
There are some more design things that need to be figured out:
- The format should probably be able to handle globs ("*", "*.png",
etc.)
- Should the format be able to handle individual files? ("README.rst",
".gitkeep")
- Should the format allow licensing of files that are deeper in the
directory tree? ("**/*.png", "resources/vid/*.mp4")
- Should the format allow "overriding" of existing notices? (e.g., it
contains ".gitignore" even though ".gitignore" already contains a REUSE header. Currently with DEP5, the licensing information is simply combined)
... Probably some more things that I'm forgetting. Maybe another time :)
Yours with kindness, Carmen
REUSE mailing list REUSE@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
Hi Carmen, all,
concerning your point if the equal mechanism between file.license and folder.license. As I understand it, the preferred solution is that the license information is IN the file, not at the side of the file in another file, right. This is only the compromise for not being able to add the license information into the file. But wouldn't it be closer to the original idea to add this folder license information IN the folder instead of at the side of the folder.
In addition to Jeffs remark, also zipping a subfolder is much easier, if the folder contains all necessary information.
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@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: Carmen Bianca Bakker carmenbianca@fsfe.org Gesendet: Montag, 9. März 2020 18:47:04 An: Geyer-Blaumeiser Lars (IOC/PDL4); reuse@lists.fsfe.org Betreff: Re: [REUSE] Introduce folder.license file
Hi Lars, all,
Je ven, 2020-03-06 je 15:41 +0000, Geyer-Blaumeiser Lars (IOC/PDL4) skribis:
Some thoughts here
You propse to have the file right beside the folder. I understand this due to the similarity to the mechanism for files, but I would rather prefer to have the file inside the folder. Why, because it makes the connection to the folder clearer, if the file is beside the folder it might be difficult to see the association because, e.g., dependending on the browser the files might be shown separately from the folders and the association for a human looking at the parent folder is difficult.
This makes sense as an accessibility/discoverability feature. It also, however, removes the most attractive feature of `folder.license`, which is that it would be equivalent to `file.license`.
Will the license file allow to reflect multiple licenses, it could be that the copyright holder and even the licenses differ for the different files referenced? Or which mechanism would allow to make as few license references as possible but allowing the possibility of different information for different sets of files?
As written, it wouldn't. The file would contain a simple REUSE header that indiscriminately applies to all files in the directory.
---
I'm more inclined to slowly deprecate DEP5 and replace it with a format that was built for purpose. We're currently kind of co-opting DEP5, which has a lot of features that we don't need, a syntax which is difficult to parse, and some instructions in its specification that contradict the REUSE Specification. Also, generally, the DEP5 specification is a bit of a drag to read.
On the tooling end, replacing DEP5 with something else would get rid of a dependency on `python-debian`. It would also enable people to write REUSE tooling in languages that do not have library support for DEP5.
There's an interesting choice that could be made here, though. Instead of having the configuration be *global*, what if we mixed the best of both worlds? So instead of having the configuration in `.reuse/dep5- replacement.json`, what if we put it in the directories?
This would have one very clear benefit: The closer that the file is to the source, the more detectable it is.
The disadvantage is that scattered configuration can be a pain in the behind.
There are some more design things that need to be figured out:
- The format should probably be able to handle globs ("*", "*.png", etc.) - Should the format be able to handle individual files? ("README.rst", ".gitkeep") - Should the format allow licensing of files that are deeper in the directory tree? ("**/*.png", "resources/vid/*.mp4") - Should the format allow "overriding" of existing notices? (e.g., it contains ".gitignore" even though ".gitignore" already contains a REUSE header. Currently with DEP5, the licensing information is simply combined)
... Probably some more things that I'm forgetting. Maybe another time :)
Yours with kindness, Carmen
Je mar, 2020-03-10 je 07:14 +0000, Geyer-Blaumeiser Lars (IOC/PDL4) skribis:
Hi Carmen, all,
concerning your point if the equal mechanism between file.license and folder.license. As I understand it, the preferred solution is that the license information is IN the file, not at the side of the file in another file, right. This is only the compromise for not being able to add the license information into the file. But wouldn't it be closer to the original idea to add this folder license information IN the folder instead of at the side of the folder.
In addition to Jeffs remark, also zipping a subfolder is much easier, if the folder contains all necessary information.
Hi Lars,
Yes, sorry, my message hadn't made it clear. That is my fault. If we go this route, I would be in favour of putting this file *inside* of the folder, knowing that it wouldn't mesh elegantly with the existing `file.license` method.
And you're also right: `file.license` is a fallback mechanism if you can't put the information inside of the file. Technically so is the file that is proposed in this thread.
Yours with kindness, Carmen
Hi all,
+1 to slowly deprecate dep5, for all reasons given before +1 to store folder specific licensing info *inside* the folders (I guess we all agree in fact)
While it is true that information will be scattered, it will also be easily collected by any tool (to build an SPDX file for ex.)
Another point to make clear, is the precedence between the identification mechanisms: For ex.: dep5 < Folder licensing < cat.jpg.license style < in-file header style
The formalism discussed in the other 'repurpose central LICENSE file' thread could be also applied at every folder level, so that we have a very nice recursive way of licensing files down the tree.
Nico
On 10/03/2020 10:32, Carmen Bianca Bakker wrote:
Je mar, 2020-03-10 je 07:14 +0000, Geyer-Blaumeiser Lars (IOC/PDL4) skribis:
Hi Carmen, all,
concerning your point if the equal mechanism between file.license and folder.license. As I understand it, the preferred solution is that the license information is IN the file, not at the side of the file in another file, right. This is only the compromise for not being able to add the license information into the file. But wouldn't it be closer to the original idea to add this folder license information IN the folder instead of at the side of the folder.
In addition to Jeffs remark, also zipping a subfolder is much easier, if the folder contains all necessary information.
Hi Lars,
Yes, sorry, my message hadn't made it clear. That is my fault. If we go this route, I would be in favour of putting this file *inside* of the folder, knowing that it wouldn't mesh elegantly with the existing `file.license` method.
And you're also right: `file.license` is a fallback mechanism if you can't put the information inside of the file. Technically so is the file that is proposed in this thread.
Yours with kindness, Carmen
REUSE mailing list REUSE@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
Die 13. 03. 20 et hora 09:20 nicolas1.toussaint@orange.com scripsit:
+1 to slowly deprecate dep5, for all reasons given before +1 to store folder specific licensing info *inside* the folders (I guess we all agree in fact)
I agree.
One option would be to call that file simply `.license` analogous to the `.desktop` file that we all know and love. Obviously this would be a hidden file on *nix systems, which has its pluses and minuses.
e.g.:
. ├── .license ├── ant_gatherer.blend ├── castle.blend ├── envmaps │ └── radiomap.jpg
Another option would be to actually just call it literally `folder.license`
. ├── folder.license ├── ant_gatherer.blend ├── castle.blend ├── envmaps │ └── radiomap.jpg
cheers, Matija
~ Matija Šuklje [2020-05-19 19:55 +0200]:
Die 13. 03. 20 et hora 09:20 nicolas1.toussaint@orange.com scripsit:
+1 to slowly deprecate dep5, for all reasons given before +1 to store folder specific licensing info *inside* the folders (I guess we all agree in fact)
I agree.
I agree with both points as well.
One option would be to call that file simply `.license` analogous to the `.desktop` file that we all know and love. Obviously this would be a hidden file on *nix systems, which has its pluses and minuses.
[...]
Another option would be to actually just call it literally `folder.license`
That's a tricky one. Obviously, giving this file the same name as the folder is error-prone, so not an option. So the analogy to file.license is gone more or less.
"folder.license" makes sense name-wise, but as Lars pointed out, choosing a file name starting with a special character avoids that the file is somewhere in between "normal" files.
".license" could work, as dotfiles are quite common for meta information, e.g. .gitignore or .reuse/. However, it would be yet another naming scheme next to "dep5" and "file.license".
But since I do not have a better idea as well, ".license" could work as a text file containing Copyright/Licensing information in the standardised REUSE/SPDX format on a directory level. However, if there are any suggestions, please raise your voice!
Best, Max
On Freitag, 5. Juni 2020 16:02:42 CEST Max Mehl wrote: [...]
"folder.license" makes sense name-wise, but as Lars pointed out, choosing a file name starting with a special character avoids that the file is somewhere in between "normal" files.
".license" could work, as dotfiles are quite common for meta information, e.g. .gitignore or .reuse/. However, it would be yet another naming scheme next to "dep5" and "file.license".
Hi, I think that the visibility of such a ".license" file could be a problem in practise though. When looking at a typical KDE project, we sometimes have inexperienced contributors doing their first commits in open source. With having licensing information inside source code files everything is nice, because they always see the license of the files they are modifying or are getting hit by commit hooks if they try to commit files and were not aware that license statements are required.
Yet, for folders, if you do not enable the display of hidden files, you might be completely unaware of the license that you assign to a file unless you run the reuse tool (which you have to know, too).
Thus, I would prefer something that is not a file that is hidden by default on most systems.
Cheers, Andreas
Die 5. 06. 20 et hora 16:02 Max Mehl scripsit:
But since I do not have a better idea as well, ".license" could work as a text file containing Copyright/Licensing information in the standardised REUSE/SPDX format on a directory level. However, if there are any suggestions, please raise your voice!
I don’t know if it is a better idea, but we could also combine the previous ideas into:
`.{$filename}.license` for individual files (or even for folders)
`.folder.license` for the whole folder in which it resides
cheers, Matija
There is the open question how to deal with snippets inside of a REUSE compliant file that are under a different license and copyright holder. Example: a developer copies a snippet from StackOverflow to their file which is licensed under Apache-2.0. According to the ToS, this snippet would then be licensed under CC-BY-SA-4.0 [^1], and therefore also need to declare the original copyright holder.
In an older issue [^2], Matija suggested something like the following:
``` SPDX-FileCopyrightText: Jane Doe SPDX-License-Identifier: Apache-2.0
quasicode("by Jane Doe");
# REUSE-Snippet-Begin # SPDX-FileCopyrightText: Foo Bar # SPDX-License-Identifier: CC-BY-SA-4.0
print("great code by Foo Bar");
# REUSE-Snippet-End
return(42); ```
It should be noted that SPDX already has some fields to deal with snippets [^3], and since we do not intend to introduce duplicated standards, we might be inclined to make use of it. So we could use instead:
* SPDX-SnippetCopyrightText: Foo Bar * SPDX-SnippetLicenseConcluded: CC-BY-SA-4.0
Pros: - An official way to handle snippets and their copyright and licensing information.
Cons: - Would require a failsafe way how to mark the begin and end of a snippet all comment styles. - The tool would have to crawl more than the first 4 kilobytes of a file to catch all potential snippets. - SPDX-License-Identifier and SPDX-SnippetLicenseConcluded are quite different from each other, so one more pattern of tags to learn for adopters.
So no clearly defined suggestion but rather a start of a discussion. Please share your opinion in reply to this mail. Thank you!
Best, Max
[^1]: https://stackoverflow.com/help/licensing
[^2]: https://github.com/fsfe/reuse-docs/issues/34
[^3]: https://github.com/spdx/spdx-spec/blob/development/v2.2/chapters/5-snippet-i...
Hi Max,
I favor the SPDX approach. I do agree with all the cons as well 😉, adding one more: marking every single snippet of copied code is a tedious task for developers, especially for an existing project that's out there for quite some time and now wants to become REUSE compliant. In terms of adoption, tedious tasks are never a good selling point. But ideally, I agree, snippets should be marked as such.
Best Stefan
P.S. Slightly unrelated to the how-to-mark-snippets-topic: in the example you chose, one could argue that copying a snippet of code under CC-BY-SA-4.0 into an Apache-2.0 licensed file/project could make that whole file/project a "Adapted Material" in the spirit and letter of CC-BY-SA-4.0, and hence the whole file/project would need to be licensed under CC-BY-SA-4.0 (Section 3.b) or a BY-SA Compatible License - so no need bothering marking the snippet anymore 😉
-----Original Message----- From: REUSE reuse-bounces@lists.fsfe.org On Behalf Of Max Mehl Sent: Donnerstag, 5. März 2020 12:36 To: reuse@lists.fsfe.org Subject: [REUSE] Handle copyright and licensing of snippets
There is the open question how to deal with snippets inside of a REUSE compliant file that are under a different license and copyright holder. Example: a developer copies a snippet from StackOverflow to their file which is licensed under Apache-2.0. According to the ToS, this snippet would then be licensed under CC-BY-SA-4.0 [^1], and therefore also need to declare the original copyright holder.
In an older issue [^2], Matija suggested something like the following:
``` SPDX-FileCopyrightText: Jane Doe SPDX-License-Identifier: Apache-2.0
quasicode("by Jane Doe");
# REUSE-Snippet-Begin # SPDX-FileCopyrightText: Foo Bar # SPDX-License-Identifier: CC-BY-SA-4.0
print("great code by Foo Bar");
# REUSE-Snippet-End
return(42); ```
It should be noted that SPDX already has some fields to deal with snippets [^3], and since we do not intend to introduce duplicated standards, we might be inclined to make use of it. So we could use instead:
* SPDX-SnippetCopyrightText: Foo Bar * SPDX-SnippetLicenseConcluded: CC-BY-SA-4.0
Pros: - An official way to handle snippets and their copyright and licensing information.
Cons: - Would require a failsafe way how to mark the begin and end of a snippet all comment styles. - The tool would have to crawl more than the first 4 kilobytes of a file to catch all potential snippets. - SPDX-License-Identifier and SPDX-SnippetLicenseConcluded are quite different from each other, so one more pattern of tags to learn for adopters.
So no clearly defined suggestion but rather a start of a discussion. Please share your opinion in reply to this mail. Thank you!
Best, Max
[^1]: https://stackoverflow.com/help/licensing
[^2]: https://github.com/fsfe/reuse-docs/issues/34
[^3]: https://github.com/spdx/spdx-spec/blob/development/v2.2/chapters/5-snippet-i...
On četrtek, 05. marec 2020 13:46:01 CET, Gustafsson, Stefan wrote:
P.S. Slightly unrelated to the how-to-mark-snippets-topic: in the example you chose, one could argue that copying a snippet of code under CC-BY-SA-4.0 into an Apache-2.0 licensed file/project could make that whole file/project a "Adapted Material" in the spirit and letter of CC-BY-SA-4.0, and hence the whole file/project would need to be licensed under CC-BY-SA-4.0 (Section 3.b) or a BY-SA Compatible License - so no need bothering marking the snippet anymore 😉
Sure, but that is just one example (not uncommon, as AFAIR StackOverflow uses CC-BY-SA¹), and there are other – perhaps even incompatible – sets of licenses one could take as an example. Do you have a better suggestion?
In any case, since we are talking about source code, the fact that a snippet is differently licensed from the majority of the code still somewhat similar to including a differently licensed library or copy a file into the codebase. So, one can still fix the potential incompatibility (or avoid certain obligations) by removing that portion of the code and replacing it with one that is compatible, without major harm. As long as all files and snippets have their licensing info clearly attached to them, you can fix anything that needs fixing.
Following your example, CC-BY-SA-4.0 might apply to the whole file, but what happens if someone later removes that snippet. If the person before them simply changed the license of the whole file to CC-BY-SA-4.0, then one would assume the file would continue to be under that license (instead of Apache-2.0, which would be more logical).
In addition, I would argue that the rest of the file remains under Apache-2.0 even if a CC-BY-SA-4.0 snippet was embedded into it. That is the licensing situation of the code. It is only in the next step when we look into the specific obligations each license (and piece of code) demands. Only then we decide that CC-BY-SA-4.0 is the common denominator² of both CC-BY-SA-4.0 and Apache-2.0, and that it is that license which applies to the new work as a whole (while parts of the work are still licensed as they are).
Now, if this was binary-only, things might have been different³.
cheers, Matija — 1 https://stackoverflow.com/legal/terms-of-service#licensing
2 Although another common denominator could be GPL-3.0-only.
3 C.f. adplumbatio vs ferruminatio https://de.wikisource.org/wiki/RE:Adplumbatio https://muse.jhu.edu/chapter/318772
Hello,
This is definitely a needed feature (mostly for StackOverflow copy & pastes ASAIAC)
My PoV on raised points above:
REUSE-Snippet-* vs SPDX-Snippet*
Definitely in favor of aligning with SPDX standard, for standardization reasons, but also to facilitate automatic detection. BUT, they are useless without corresponding END tags -> should we see with SPDX team to add them ?
The tool would have to crawl more than the first 4 kilobytes of a file to catch all potential snippets.
This means more time & computing power, but searching for a fixed string 'SPDX-Snippet' is still much less effort than searching for plenty of keywords, regexps, or similarities with license texts for ex.
SPDX-License-Identifier and SPDX-SnippetLicenseConcluded are quite
different from each other,
so one more pattern of tags to learn for adopters.
We can still search for "SPDX-License-Identifier" in the first 4kb, then 'SPDX-Snippet*' in the rest of the files.
marking every single snippet of copied code is a tedious task for
developers, It sure is... and will likely only be used under constraint :) Source code editors could also help here with automatic text insertion. When we have an open source snippet detection solution, it could also help inserting those tags.
And an open question: should we add the possbility to also specify a source URL along license and copyright information to easily trace back the snippet to the source ?
Nico
On 06/03/2020 08:07, Matija Šuklje wrote:
On četrtek, 05. marec 2020 13:46:01 CET, Gustafsson, Stefan wrote:
P.S. Slightly unrelated to the how-to-mark-snippets-topic: in the example you chose, one could argue that copying a snippet of code under CC-BY-SA-4.0 into an Apache-2.0 licensed file/project could make that whole file/project a "Adapted Material" in the spirit and letter of CC-BY-SA-4.0, and hence the whole file/project would need to be licensed under CC-BY-SA-4.0 (Section 3.b) or a BY-SA Compatible License - so no need bothering marking the snippet anymore 😉
Sure, but that is just one example (not uncommon, as AFAIR StackOverflow uses CC-BY-SA¹), and there are other – perhaps even incompatible – sets of licenses one could take as an example. Do you have a better suggestion?
In any case, since we are talking about source code, the fact that a snippet is differently licensed from the majority of the code still somewhat similar to including a differently licensed library or copy a file into the codebase. So, one can still fix the potential incompatibility (or avoid certain obligations) by removing that portion of the code and replacing it with one that is compatible, without major harm. As long as all files and snippets have their licensing info clearly attached to them, you can fix anything that needs fixing.
Following your example, CC-BY-SA-4.0 might apply to the whole file, but what happens if someone later removes that snippet. If the person before them simply changed the license of the whole file to CC-BY-SA-4.0, then one would assume the file would continue to be under that license (instead of Apache-2.0, which would be more logical).
In addition, I would argue that the rest of the file remains under Apache-2.0 even if a CC-BY-SA-4.0 snippet was embedded into it. That is the licensing situation of the code. It is only in the next step when we look into the specific obligations each license (and piece of code) demands. Only then we decide that CC-BY-SA-4.0 is the common denominator² of both CC-BY-SA-4.0 and Apache-2.0, and that it is that license which applies to the new work as a whole (while parts of the work are still licensed as they are).
Now, if this was binary-only, things might have been different³.
cheers, Matija — 1 https://stackoverflow.com/legal/terms-of-service#licensing
2 Although another common denominator could be GPL-3.0-only.
3 C.f. adplumbatio vs ferruminatio https://de.wikisource.org/wiki/RE:Adplumbatio https://muse.jhu.edu/chapter/318772
~ nicolas1.toussaint@orange.com [2020-03-13 09:50 +0100]:
REUSE-Snippet-* vs SPDX-Snippet*
Definitely in favor of aligning with SPDX standard, for standardization reasons, but also to facilitate automatic detection. BUT, they are useless without corresponding END tags -> should we see with SPDX team to add them ?
Yes, that would be another set of questions/improvements (in addition to potential tags for a repurposed LICENSE or a LICENSE.reuse file) to discuss with them.
SPDX-License-Identifier and SPDX-SnippetLicenseConcluded are quite different from each other, so one more pattern of tags to learn for adopters.
We can still search for "SPDX-License-Identifier" in the first 4kb, then 'SPDX-Snippet*' in the rest of the files.
I was rather thinking about the human problem. Right now, the amount of tags necessary to edit files the REUSE way is limited (SPDX-License-Identifier, SPDX-FileCopyrightText and/or Copyright). With the differently worded SPDX-Snippet* tags we would increase the likelihood of mistakes and confusion.
And an open question: should we add the possbility to also specify a source URL along license and copyright information to easily trace back the snippet to the source ?
SPDX theoretically allows for comments on snippets [^1], perhaps that could be used for your purpose. For REUSE, this most likely would not become a requirement as it is not directly relevant for the reusability of a file in terms of licensing and copyright.
Best, Max
[^1]: https://github.com/spdx/spdx-spec/blob/development/v2.2/chapters/5-snippet-i...
~ Max Mehl [2020-03-13 10:22 +0100]:
~ nicolas1.toussaint@orange.com [2020-03-13 09:50 +0100]:
REUSE-Snippet-* vs SPDX-Snippet*
Definitely in favor of aligning with SPDX standard, for standardization reasons, but also to facilitate automatic detection. BUT, they are useless without corresponding END tags -> should we see with SPDX team to add them ?
Yes, that would be another set of questions/improvements (in addition to potential tags for a repurposed LICENSE or a LICENSE.reuse file) to discuss with them.
I've started a thread on spdx-legal@ in which I propose a (IMHO feasible) compromise in my latest email. As Nico already stated, we are all in for collaboration with SPDX to not create two differing standards, so let's hope we will come to a decision which makes handling of snippets easy for developers and tools!
Feel free to chime in here: https://lists.spdx.org/g/Spdx-legal/message/2851
Best, Max
Currently, the REUSE specification does not clearly communicate whether a project's Git submodules have to be REUSE compliant as well. This has been an open issue for a while [^1].
The REUSE helper tool does ignore Git submodules by default:
* If one wants to reuse components of a submodule, they would probably reuse from the submodules main repository directly and not from the project including the submodule. * The REUSE adopter should not carry the burden of making the submodules also REUSE compliant in order to enjoy having a REUSE compliant project.
However, the tool also allows to include submodules into the lint (and other subcommands) using the `--include-submodules` argument.
Taking aside the tool situation, how shall the REUSE specification handle submodules by default? Like the tool, so allowing the adopter to ignore them, or the other way round? Or shall REUSE continue to not touch this issue at all?
So no clearly defined suggestion but rather a continuation of a discussion. Please share your opinion on this in reply to this mail. Thank you!
Best, Max
[^1]: https://github.com/fsfe/reuse-docs/issues/36
From a complexity perspective: It is much easier to ignore submodules.
Consider the following scenario:
Project Foo is licensed under Apache-2.0. Project Bar is a submodule of Project Foo, licensed under MIT. Both projects use a `.reuse/dep5` file to license some files.
If a tool wants to verify the compliance of Project Foo *including* the submodule, it has to:
- Detect that Bar is a submodule. - Separately (and recursively!) lint Bar. - Combine the results of that lint into the results of the lint of Foo.
Even more interesting scenario:
Project Foo has a .reuse/dep5 file that contains a glob that licenses everything in submodule Bar as being licensed under 0BSD. This used to be true, but Bar changed its licensing to MIT.
- Should the .reuse/dep5 implication be valid, even though everything in Bar is licensed under MIT these days? - If yes, should there be a LICENSES/0BSD.txt file in Bar? - Should there be a LICENSES/0BSD.txt file in Foo?
---
It's not impossible to handle submodules, but it does entail complexity that is unnecessary: You can simply independently lint the projects. For that reason, I'd rather that submodules are ignored for REUSE compliance.
The Specification could mention this to clarify.
Yours with kindness, Carmen
~ Carmen Bianca Bakker [2020-03-06 12:39 +0100]:
It's not impossible to handle submodules, but it does entail complexity that is unnecessary: You can simply independently lint the projects. For that reason, I'd rather that submodules are ignored for REUSE compliance.
Thank you, I feel the same.
As I did not hear anything else, I've added this to the corresponding Git issue: https://github.com/fsfe/reuse-docs/issues/36#issuecomment-661078834
Best, Max