[REUSE] Support / repurpose central LICENSE file

Thu Mar 12 16:55:58 UTC 2020

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 at 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 at lists.fsfe.org> im Auftrag von Carmen 
> Bianca Bakker <carmenbianca at fsfe.org>
> *Gesendet:* Donnerstag, 5. März 2020 16:37:43
> *An:* reuse at 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 at 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 at 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

-- 

Nicolas Toussaint
OBS - Orange Business Services - Lyon, France
Tel: +33 608 763 559

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fsfe.org/pipermail/reuse/attachments/20200312/07245714/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5478 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fsfe.org/pipermail/reuse/attachments/20200312/07245714/attachment-0001.bin>