<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small">On Tue, Jan 7, 2020 at 6:33 AM Andreas Cord-Landwehr <<a href="mailto:cordlandwehr@kde.org">cordlandwehr@kde.org</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Montag, 6. Januar 2020 23:43:29 CET Cornelius Schumacher wrote:<br>
[...]<br>
> In general I think the proposal makes a lot of sense. It definitely is going<br>
> into the right direction.<br>
> <br>
> Regarding the LicenseRef-KDE-Accepted-(L)GPL texts:<br>
> <br>
> * What's the exact reasons for changing them compared to our current license<br>
> statements? I tend to think it's better to keep them as they are and leave<br>
> the versions in. Otherwise they are missing the reference to what "later"<br>
> is relative to.<br>
> * The texts are not meant to be used as license headers in source files but<br>
> as stand-alone files, so the refeence in a SPDX identifier such as<br>
> "LGPL-2.1-only OR LGPL-3.0-only OR LicenseRef-KDE-Accepted-LGPL" can be<br>
> resolved. Maybe that could be made more explicit in the policy. Maybe by<br>
> moving them to the end as an appendix with an explanation how these are to<br>
> be stored as files according to SPDX and REUSE conventions. Then the<br>
> LicenseRef* identifiers in the bullet points in the policy could maybe also<br>
> turned into hyperlinks pointing to these sections in the appendix.<br>
> <br>
> It would also be nice to have examples for license headers which don't use<br>
> the full text of the headers but only the SPDX identifiers as specified by<br>
> REUSE. This is the more concise version and I think the one we would like<br>
> to settle on longer term. So it would be good to have explicit examples<br>
> which show how this will look like. That could be a later step, though.<br>
<br>
Hi Cornelius, thanks for your comments!<br>
<br>
Regarding the license statements for the "accecpted by KDE" clause: My main <br>
motivation was to introduce a workaround with some licensing mixups we have in <br>
our repositories. For example (there are many more, these are only the first in <br>
my list):<br>
- LGPL-2.0-only OR LGPL 3.0-only OR LicenseRef-KDE-Accepted-LGPL:<br>
  <a href="https://github.com/KDE/kio/blob/master/autotests/kfilecopytomenutest.cpp" rel="noreferrer" target="_blank">https://github.com/KDE/kio/blob/master/autotests/kfilecopytomenutest.cpp</a><br>
-  LGPL-2.1-only OR LGPL 3.0-only OR LicenseRef-KDE-Accepted-LGPL:<br>
  <a href="https://github.com/KDE/attica/blob/master/src/projectparser.cpp" rel="noreferrer" target="_blank">https://github.com/KDE/attica/blob/master/src/projectparser.cpp</a><br>
So, there are two LGPL based licenses with the same accepted-by-KDE clause, <br>
which relies on the LGPL-3 clause for defining a proxy. Yet, they state <br>
different LGPL-2.* versions, once LGPL-2.0-only and once LGPL-2.1-only. The KDE <br>
clause -- in my opinion -- does not need this distinction, as it only relates <br>
to the LGPL-3 version for defining is meaning.<br>
So another option would be to define that later versions of the LGPL-3.0 are <br>
meant. This should not change any meaning of the current license statements. <br>
What do you think?<br>
<br>
Regarding the second point: I fully agree and will do this. And I want to do <br>
this together with examples how to state the licenses correctly. However, I <br>
think, stating the examples for REUSE compatible license usage should best be <br>
put on a separate wiki page for better readability.<br>
<br>
Cheers,<br>
Andreas<br><br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">Thanks to start this. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">So, as part of my current work at BMW i've been part last year of OSS Compliance tooling group ( Mirko been there as well most of the times ) and we are working on full compliance pipeline, including automatic scanning, SPDX generation till last step of have curated license metadata.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">Would be long to explain detailed projects in general, but if people are interested, here the core softwares we're looking toward the pipeline:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">* For the scanning part ( simplified, they do a lot more )</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">- The QuarterMaster Project: <a href="https://qmstr.org/">https://qmstr.org/</a> </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">- OSS Resource Toolkit - <a href="https://github.com/heremaps/oss-review-toolkit">https://github.com/heremaps/oss-review-toolkit</a> </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">* For archiving ( and scanning, again simplified )</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">- Fossology - <a href="https://www.fossology.org/">https://www.fossology.org/</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">- SW360 / Antenna - <a href="https://projects.eclipse.org/proposals/sw360">https://projects.eclipse.org/proposals/sw360</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">* Curating</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">- <a href="https://clearlydefined.io/about">https://clearlydefined.io/about</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">Everything is open source as the motto of the tooling group.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">On my side, if we are going to this path, i was looking a part were i could effectively contribute back to KDE, and now i want to propose to define a pipeline to us, and do the technical process with the automation of this, and then complement Andreas work, since i do have already knowledge on this area.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large">Best regards</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:large"><br></div></div></div>