#3302 Issue open: [RFE] Distribute rear-release-notes.txt under a more permissive license

Labels: documentation, cleanup, ReaR Project

lzaoral opened issue at 2024-08-22 08:10:

Fedora is undergoing a major check of licenses of its packages. @pcahyna has noticed that doc/rear-release-notes.txt file is distributed under the CC BY-ND 3.0 license which is not allowed for documentation in Fedora, RHEL, Debian and possibly other distros.

Please, relicense this file under a more permissive license.

At the moment, we have created a custom release archive in Fedora and RHEL with this file omitted but it would be nice to switch back to the official upstream release archives.

jsmeix commented at 2024-08-22 09:17:

According to what

# git log -p --follow doc/rear-release-notes.txt

shows this special license for this particular file
was already there when this file was introduced via
https://github.com/rear/rear/commit/b91baf682fd9f4e1b72884f574a8a726a86300fd

But this commit also shows that rear-release-notes.txt
was based on the former Rear-release-notes.txt file
which contained

:Author: Gratien D'haese
:Date: 17 November 2011

Accordingly I assign this issue to @gdha

jsmeix commented at 2024-08-22 09:19:

What git shows as authors of rear-release-notes.txt

# git log -p --follow doc/rear-release-notes.txt | grep '^Author: ' | sort -u
Author: Dag Wieers <dag@wieers.com>
Author: Dag Wieërs <dag@wieers.com>
Author: Damani <damani@rubrik.com>
Author: Gratien D'haese <gratien.dhaese@gmail.com>
Author: Johannes Meixner <jsmeix@suse.com>
Author: Johannes Röhl <Johannes.Roehl@novastor.com>
Author: Peter Oliver <git@mavit.org.uk>
Author: Schlomo Schapiro <schlomo@schapiro.org>
Author: gdha <gratien.dhaese@gmail.com>
Author: rowens275 <rowens@fdrinnovation.com>

jsmeix commented at 2024-08-22 09:23:

Because in general ReaR is under GPL v3 license
I suggest to also have rear-release-notes.txt under GPL v3.

Hereby I (as one of the by git listed authors) I agree and
permit to change the license of rear-release-notes.txt
from its current license to GPL v3.

jsmeix commented at 2024-08-22 09:36:

@lzaoral
did Fedora's major check of licenses perhaps find
also other files in ReaR that are not under GPL v3
but have a different license explicitly specified?
If yes, could you please report them as a separated issue.
Ideally I would prefer to have all ReaR files under GPL v3
as far as possible legally and with reasonable effort.

pcahyna commented at 2024-08-22 09:46:

@jsmeix My check was not very thorough. I basically looked ad what Debian is doing - they had stopped shipping doc/rear-release-notes.txt already. I also looked at usr/sbin/rear and noted that ReaR is GPL v3 or later (not just GPL v3): https://github.com/rear/rear/blob/1d03f236e1ecb57af75acef34e3acb0891beafdd/usr/sbin/rear#L9 .

gdha commented at 2024-08-22 09:47:

Because in general ReaR is under GPL v3 license I suggest to also have rear-release-notes.txt under GPL v3.

Hereby I (as one of the by git listed authors) I agree and permit to change the license of rear-release-notes.txt from its current license to GPL v3.

@jsmeix I have no problems to convert the license to GPL v3.

jsmeix commented at 2024-09-05 12:09:

I think we should do the license change for ReaR 3.0 if possible.

gdha commented at 2024-09-05 12:20:

@jsmeix okay will do it soon.

pcahyna commented at 2024-09-06 10:19:

My understanding is that you should get agreements from all authors, or delete their contributions (@lzaoral is that right)? git log --author=dag@wieers.com --author=damani@rubrik.com --author=Johannes.Roehl@novastor.com --author=git@mavit.org.uk --author=rowens@fdrinnovation.com master -- doc/rear-release-notes.txt shows the last commit:

commit 8d01a37c8b79a879cea59cb369f7ca8728189b02
Author: Johannes Röhl <Johannes.Roehl@novastor.com>
Date:   Thu Nov 12 12:06:36 2020 +0100

@JohannesRoehlNovaStor , FYI

jsmeix commented at 2024-09-06 10:41:

I am not at all a software lincenses expert.
I also think I vaguely remember that to change a license
one needs to get agreements from all authors
which is my reason behind why I posted
https://github.com/rear/rear/issues/3302#issuecomment-2304184020

I think in practice it could be an impossible task
(i.e. impossible with reasonable effort in reasonable time)
to get agreements from all authors.

A possible way out could be to keep the current
doc/rear-release-notes.txt as is but renamed
e.g. to doc/rear-release-notes-until-2.7.txt
and for ReaR 3.0 start from scratch with a new
doc/rear-release-notes.txt
keeping the unversioned name for the current one
to not break links and references at arbitrary places
that point to doc/rear-release-notes.txt

This way we could ( by-the-way and hooray! ;-)
mecilessly clean up our release notes
from any old and possibly outdated stuff,
cf. https://github.com/rear/rear/issues/3264

pcahyna commented at 2024-09-06 11:02:

A possible way out could be to keep the current
doc/rear-release-notes.txt as is but renamed
e.g. to doc/rear-release-notes-until-2.7.txt

Keeping the current release notes in the repo does not solve the problem of one file having a different license (and above all a non-free one) than the rest of the repo, so it is not a way out at all.

jsmeix commented at 2024-09-06 11:51:

@pcahyna @lzaoral
I (perhaps falsely assumed) you could then
(relatively easily) drop the old and outdated
doc/rear-release-notes-until-2.7.txt
from your RPM (or perhaps replace it with your own
that contains only a reference to our upstream one)
so that you could provide (at least) the current
doc/rear-release-notes.txt
in your RPM.

If this is insufficient for what you need,
please help with getting agreements from all authors.

pcahyna commented at 2024-09-06 12:06:

@jsmeix The main issue for us (at least in my POW) is not the lack of release notes in the package, but the inability to use the upstream source tarball at all and the resulting need of producing a cleaned-up tarball as the package source. Note that it is not just about the RPM, it is also about the SRPM, because the SRPM needs to be provided as well (distributions provide all their sources), and a file with such a license can not be shipped at all. It is also very confusing for anyone using the sources (they see that ReaR is GPL and they thus may assume that all the sources are GPL and then accidentally violate the license terms).

pcahyna commented at 2024-09-06 12:09:

If this is insufficient for what you need,
please help with getting agreements from all authors.

sure, but we need a plan B here in case we don't get it. What about doing what you proposed and then moving doc/rear-release-notes-until-2.7.txt to another repo (perhaps to the web pages)?

gdha commented at 2024-09-06 12:31:

My understanding is that you should get agreements from all authors, or delete their contributions (@lzaoral is that right)? git log --author=dag@wieers.com --author=damani@rubrik.com --author=Johannes.Roehl@novastor.com --author=git@mavit.org.uk --author=rowens@fdrinnovation.com master -- doc/rear-release-notes.txt shows the last commit:

commit 8d01a37c8b79a879cea59cb369f7ca8728189b02
Author: Johannes Röhl <Johannes.Roehl@novastor.com>
Date:   Thu Nov 12 12:06:36 2020 +0100

@JohannesRoehlNovaStor , FYI

@pcahyna @jsmeix Why not reaching out to them to inform the license change and mention explicitly if no reply is given an approval is assumed.

pcahyna commented at 2024-09-06 12:35:

mention explicitly if no reply is given an approval is assumed

IANAL, does not sound very legal to me TBH

jsmeix commented at 2024-09-06 12:45:

@pcahyna
regarding your
https://github.com/rear/rear/issues/3302#issuecomment-2333910077

Ah!
I didn't have the SRPM in mind.

But wouldn't it help to remove that file
in the RPM spec file section '%prep'
because I think I vaguely remember somehow
that the SRMP gets built after the '%prep' section
i.e. using possibly modified original sources
which is why one should normally not modify
the original sources but apply patches instead
but in this case modifying the original sources
is perhaps a valid exception?

gdha commented at 2024-09-06 12:52:

@jsmeix @pcahyna Why not remove the release-notes and documentation from our ReaR master branch and move it to a ReaR documentation source repository? Sources and documentation do not have to share the same tree.
We already have a https://github.com/rear/rear-user-guide available.

jsmeix commented at 2024-09-06 12:59:

What about this simple and straightforward way:

Remove the old one in ReaR 3.0 - i.e.:
For ReaR 3.0 start from scratch with a new
doc/rear-release-notes.txt

Reasons:

The old one is still there in older git branches
and in older source tar balls and so on.

IANAL, but I think we are allowed to remove
all existing content in doc/rear-release-notes.txt
and create its content anew from scratch
where our new content is under a new license.

pcahyna commented at 2024-09-06 13:05:

@jsmeix

@pcahyna regarding your #3302 (comment)

Ah! I didn't have the SRPM in mind.

But wouldn't it help to remove that file in the RPM spec file section '%prep' because I think I vaguely remember somehow that the SRMP gets built after the '%prep' section i.e. using possibly modified original sources which is why one should normally not modify the original sources but apply patches instead but in this case modifying the original sources is perhaps a valid exception?

No, that's not how %prep works. The SRPM contains the original source tarball and patches and %prep unpacks the tarball and applies the patches during the build of binary RPMs. If the original source tarball can't be included in the SRPM, one must build a new "original" that can be included, every time one wants to update the package.

[Export of Github issue for rear/rear.]