<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font size="-1"><tt>Hi all,<br>
<br>
My 2 cents, and a proposition.<br>
<br>
I would rather disfavor option 1, simply because it does not
solve the problems :)<br>
- no indication of </tt></font><font size="-1"><tt><font
size="-1"><tt>{in|out}bound licenses</tt></font><br>
- no clear SPDX identification of the license<br>
<br>
I would intuitively favor option 2, because:<br>
- today's LICENSE file contains a license text, and not an SPDX
identifier.<br>
That's an inconsistency compared to other license
identification in the REUSE specs.<br>
- It addresses the {in|out}bound licenses problem nicely<br>
- We can still support old-style LICENSE full text -> we
don't have to fix people's minds.<br>
<br>
Now, to circumvent the problem of re-purposing the LICENSE file,<br>
why not introduce a new file, like "LICENSE.reuse" ?<br>
- we can still store the license text in the LICENSE file<br>
- it is close enough to LICENSE so that it attracts people who<br>
are looking for compliance info<br>
- it would ease the adoption of this standard by GitHub & co<br>
- this new file could be generated automatically by the REUSE
tools.<br>
- it would take precedence over the LICENSE file (I suppose)<br>
</tt></font><font size="-1"><tt><br>
I would just modify the content of the file:<br>
- to insert a link to REUSE specs<br>
- make it more easily parsable (maybe see with the SPDX team to
create<br>
new tags like SPDX-License-Identifier)<br>
</tt></font><br>
<font size="-1"><tt><font size="-1"><tt>I would not want to mess
with the README.md file, that is not made to be parsable,<br>
unless adding the SPDX stanza to identify the outbound
license.<br>
- not sure that updating README.md be will easier than a
LICENSE.reuse<br>
- one can add a pointer/link to the LICENSE file in the
README.<br>
- REUSE tools could also automatically insert relevant lines
in the README<br>
like it does in source code files.<br>
</tt></font><br>
Nico<br>
<br>
</tt></font><br>
<div class="moz-cite-prefix">On 06/03/2020 16:55, Geyer-Blaumeiser
Lars (IOC/PDL4) wrote:<br>
</div>
<blockquote type="cite"
cite="mid:609049b7dbb04a7dbb0db2a7ea56fcb0@bosch.io">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr"
style="font-size:12pt; color:#000000;
font-family:Calibri,Helvetica,sans-serif">
<p>Hello all,</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>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
<span>😊</span>. 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.</p>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr"
style="font-size:12pt; color:rgb(0,0,0);
font-family:Calibri,Arial,Helvetica,sans-serif,"EmojiFont","Apple
Color Emoji","Segoe UI
Emoji",NotoColorEmoji,"Segoe UI
Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper"
style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:; margin:0">
<div><span style="font-size:10pt">Mit freundlichen
Grüßen / Best regards </span><br>
<br>
<b><span style="font-size:10pt">Dr. Lars
Geyer-Blaumeiser</span></b><br>
<br>
<span style="font-size:10pt">Project Delivery - Open
Source Services (IOC/PDL4) </span>
<br>
<span style="font-size:10pt">Bosch.IO GmbH |
Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY
|
</span><span style="font-size:10pt"></span><span
style="font-size:10pt"><a class="moz-txt-link-abbreviated" href="http://www.bosch.io">www.bosch.io</a>
</span><br>
<span style="font-size:10pt">Mobil +49 172 4815079 |
<a class="moz-txt-link-abbreviated" href="mailto:lars.geyer-blaumeiser@bosch.io">lars.geyer-blaumeiser@bosch.io</a>
</span><br>
<br>
<span style="font-size:8pt">Sitz: Berlin,
Registergericht: Amtsgericht Charlottenburg; HRB
148411 B</span><br>
<span style="font-size:8pt">Aufsichtsratsvorsitzender:
Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne
Reckling</span><br>
<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>Von:</b> REUSE
<a class="moz-txt-link-rfc2396E" href="mailto:reuse-bounces@lists.fsfe.org"><reuse-bounces@lists.fsfe.org></a> im Auftrag von Carmen
Bianca Bakker <a class="moz-txt-link-rfc2396E" href="mailto:carmenbianca@fsfe.org"><carmenbianca@fsfe.org></a><br>
<b>Gesendet:</b> Donnerstag, 5. März 2020 16:37:43<br>
<b>An:</b> <a class="moz-txt-link-abbreviated" href="mailto:reuse@lists.fsfe.org">reuse@lists.fsfe.org</a><br>
<b>Betreff:</b> Re: [REUSE] Support / repurpose central
LICENSE file</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi all,<br>
<br>
In general I disfavour option 2 (using LICENSE to summarise
the<br>
licensing situation). This should already happen in the
README of a<br>
project, so it is a duplicated effort. Moreover, keeping the
summary<br>
up-to-date can be challenging. At least if it's in the
README, you<br>
encounter the summary every now and then, and can file a bug
report if<br>
it's out-of-date. The chances that you would randomly read
LICENSE are<br>
nil.<br>
<br>
It has a few more issues:<br>
<br>
- The reason that a lot of people want to keep the LICENSE
file is<br>
because GitHub auto-detects the file. A summary cannot be
auto-<br>
detected.<br>
<br>
+ Last I heard, this is still a known issue at GitHub.
GitHub wants<br>
to support the detection of multi-licensed projects at some
point.<br>
<br>
- A lot of tools (and humans) might assume that the license
text is in<br>
LICENSE, and neglect to verify. That is obviously not what
we want.<br>
<br>
- REUSE is really cool because it introduces a
machine-readable way of<br>
doing copyright and licensing. I cannot envision an easy way
in which<br>
to make this suggested LICENSE summary machine-readable.<br>
<br>
---<br>
<br>
I feel more ambivalent about option 1. I'm erring towards no
because it<br>
would complicate the specification for no good reason.
Having a<br>
directory covers all cases. Having a LICENSE file adds a ton
of<br>
complications as listed in the cons.<br>
<br>
I know two reasons to do it anyway, but I don't find them
very<br>
convincing:<br>
<br>
1. GitHub (and/or other tools) don't recognise the LICENSES/
directory.<br>
<br>
2. Having a single LICENSE file is easier/nicer/whatever.<br>
<br>
Point 1 requires a simple bugfix.<br>
<br>
Point 2 is tabs-vs-spaces. I am devoutly convinced that
there is a<br>
correct answer to the tabs-vs-spaces debate (hint: it's
spaces), but<br>
the rational part of my brain says that it just doesn't
matter.<br>
<br>
The spec is stronger when it suggests one---and only
one---obvious way<br>
to do it.<br>
<br>
---<br>
<br>
So I wouldn't change anything in this department. Of course,
if we<br>
don't change anything, it'll never really be a closed
debate.<br>
<br>
Ah well. 🙆<br>
<br>
Yours with kindness,<br>
Carmen<br>
<br>
<br>
_______________________________________________<br>
REUSE mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:REUSE@lists.fsfe.org">REUSE@lists.fsfe.org</a><br>
<a href="https://lists.fsfe.org/mailman/listinfo/reuse"
moz-do-not-send="true">https://lists.fsfe.org/mailman/listinfo/reuse</a><br>
<br>
This mailing list is covered by the FSFE's Code of Conduct.
All<br>
participants are kindly asked to be excellent to each other:<br>
<a href="https://fsfe.org/about/codeofconduct"
moz-do-not-send="true">https://fsfe.org/about/codeofconduct</a><br>
</div>
</span></font>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
REUSE mailing list
<a class="moz-txt-link-abbreviated" href="mailto:REUSE@lists.fsfe.org">REUSE@lists.fsfe.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fsfe.org/mailman/listinfo/reuse">https://lists.fsfe.org/mailman/listinfo/reuse</a>
This mailing list is covered by the FSFE's Code of Conduct. All
participants are kindly asked to be excellent to each other:
<a class="moz-txt-link-freetext" href="https://fsfe.org/about/codeofconduct">https://fsfe.org/about/codeofconduct</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Nicolas Toussaint
OBS - Orange Business Services - Lyon, France
Tel: +33 608 763 559</pre>
</body>
</html>