Proposal: Allow REUSE compatible License Statements in License Policy

[Helio Chissini de Castro]

On Tue, Jan 7, 2020 at 6:33 AM Andreas Cord-Landwehr <cordlandwehr at kde.org>
wrote:

> On Montag, 6. Januar 2020 23:43:29 CET Cornelius Schumacher wrote:
> [...]
> > In general I think the proposal makes a lot of sense. It definitely is
> going
> > into the right direction.
> >
> > Regarding the LicenseRef-KDE-Accepted-(L)GPL texts:
> >
> > * What's the exact reasons for changing them compared to our current
> license
> > statements? I tend to think it's better to keep them as they are and
> leave
> > the versions in. Otherwise they are missing the reference to what "later"
> > is relative to.
> > * The texts are not meant to be used as license headers in source files
> but
> > as stand-alone files, so the refeence in a SPDX identifier such as
> > "LGPL-2.1-only OR LGPL-3.0-only OR LicenseRef-KDE-Accepted-LGPL" can be
> > resolved. Maybe that could be made more explicit in the policy. Maybe by
> > moving them to the end as an appendix with an explanation how these are
> to
> > be stored as files according to SPDX and REUSE conventions. Then the
> > LicenseRef* identifiers in the bullet points in the policy could maybe
> also
> > turned into hyperlinks pointing to these sections in the appendix.
> >
> > It would also be nice to have examples for license headers which don't
> use
> > the full text of the headers but only the SPDX identifiers as specified
> by
> > REUSE. This is the more concise version and I think the one we would like
> > to settle on longer term. So it would be good to have explicit examples
> > which show how this will look like. That could be a later step, though.
>
> Hi Cornelius, thanks for your comments!
>
> Regarding the license statements for the "accecpted by KDE" clause: My
> main
> motivation was to introduce a workaround with some licensing mixups we
> have in
> our repositories. For example (there are many more, these are only the
> first in
> my list):
> - LGPL-2.0-only OR LGPL 3.0-only OR LicenseRef-KDE-Accepted-LGPL:
>   https://github.com/KDE/kio/blob/master/autotests/kfilecopytomenutest.cpp
> -  LGPL-2.1-only OR LGPL 3.0-only OR LicenseRef-KDE-Accepted-LGPL:
>   https://github.com/KDE/attica/blob/master/src/projectparser.cpp
> So, there are two LGPL based licenses with the same accepted-by-KDE
> clause,
> which relies on the LGPL-3 clause for defining a proxy. Yet, they state
> different LGPL-2.* versions, once LGPL-2.0-only and once LGPL-2.1-only.
> The KDE
> clause -- in my opinion -- does not need this distinction, as it only
> relates
> to the LGPL-3 version for defining is meaning.
> So another option would be to define that later versions of the LGPL-3.0
> are
> meant. This should not change any meaning of the current license
> statements.
> What do you think?
>
> Regarding the second point: I fully agree and will do this. And I want to
> do
> this together with examples how to state the licenses correctly. However,
> I
> think, stating the examples for REUSE compatible license usage should best
> be
> put on a separate wiki page for better readability.
>
> Cheers,
> Andreas
>
>
Thanks to start this.

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.
Would be long to explain detailed projects in general, but if people are
interested, here the core softwares we're looking toward the pipeline:

* For the scanning part ( simplified, they do a lot more )
- The QuarterMaster Project: https://qmstr.org/
- OSS Resource Toolkit - https://github.com/heremaps/oss-review-toolkit

* For archiving ( and scanning, again simplified )
- Fossology - https://www.fossology.org/
- SW360 / Antenna - https://projects.eclipse.org/proposals/sw360

* Curating
- https://clearlydefined.io/about

Everything is open source as the motto of the tooling group.

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.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20200107/fe25221a/attachment.htm>