(In reply to Carl George 🤠 from comment #0)
> EPEL as a compilation is currently advertised as GPLv2 licensed.  This is
> done in two places:
> 
> - the License tag of the epel-release package [0]
> - the GPL file included in the epel-release package [1]
> 
> That GPL file also has a notice at the top that elaborates on the concept of
> the compilation.  That notice also incorrectly refers to the compilation as
> Red Hat Linux.  I verified those same properties were in place in the
> initial commit of the epel-release package for EPEL 4 [2], and appear to
> have just been carried forward over time to newer releases of EPEL.  The
> initial announcement for EPEL [3] makes no mention of a compilation license.

I just looked at the fedora-release package from Fedora 7 and it has the same RHL-derived GPLv2 file with the notice on top. So we can reasonably assume that the initial creators of epel-release deliberately copied that GPL file (indeed I would assume that epel-release was based on fedora-release) without necessarily thinking more deeply about it. (As another random curiosity, the fedora-release spec file has GFDL as the license tag!) 

I don't think we have any evidence suggesting that anyone thought something like "EPEL ought to have its own compilation license, which should be GPL". It's certainly no more nonsensical for EPEL to have a compilation license than it is for Fedora to have one, and is maybe even slightly less nonsensical given that the theory behind the compilation license is that there is some thin copyright interest in the selection and arrangement of packages. However, this bug necessitates a general comment on these compilation licenses, so I'll give my view, which is that they are basically pointless and arguably more bad than good. The only value that the present-day MIT compilation for Fedora has is the symbolism of renouncing the earlier questionable but deeply-rooted practice of using the GPL as a compilation license. But the value of that symbolism diminishes with each release. Probably the best argument for not just getting rid of the Fedora MIT compilation license is that it might lead to confusion and alarm. 

Also, it is worth noting that EPEL is designed to be used with other distributions, the known examples of which have their own "open source compilation license" practice. This further suggests to me that having a distinct compilation license for EPEL serves no purpose other than potentially creating additional confusion and friction.

> 1. The EPEL compilation is derived from the Fedora compilation.  Are we even
> allowed to change it from MIT to GPLv2?  To me that seems to be what
> effectively happened with EPEL 8, which was set up after the Fedora MIT
> switch but carried forward the GPLv2 files from EPEL 7.

It's a good question. It has implications for the various Fedora derivatives that have persisted in the tradition of having some sort of GPLv2 compilation license even after Fedora's change. I think the answer is yes, this is allowed, given that in a normal context you can have a GPLv2-licensed derivative work of an MIT-licensed work, and also given the theory here that the copyrightable thing is the selection and arrangement of packages. 

> 2. Should we start EPEL 10 as an MIT compilation to align with Fedora?  I
> have a proposal for what I think that would look like in epel-release [9],
> using LICENSE and Fedora-Legal-README.txt.in files derived from the
> equivalent files in fedora-release.
> 
> 3. If we make the switch to MIT, should we leave existing EPEL releases on
> GPLv2 and just use MIT for EPEL 10 going foward?  Or is it worth switching
> everything to MIT?  Are we even allowed to change from GPLv2 to MIT after
> starting these EPEL releases as the former, and maintainers contributing
> under those terms?

Here's what I would suggest: We should assume that no one actually thought they were putting EPEL under a GPLv2 compilation license, and we should assume it is unnecessary to have an explicit compilation license for EPEL.

Nevertheless, epel-release can't have a blank License: field and that should reflect the license of the contents of epel-release. And also anything copyrightable in epel-release itself has to be under a Fedora-allowed license. Looking at the contents of epel-release, it is mostly what I would consider non-copyrightable except perhaps for the `crb` script. So I would assume that script is under GPLv2 (or let's say GPLv2-or-later) and therefore the license tag should be GPL-2.0-or-later. Unless the author(s) of the `crb` script (Troy Dawson?) have some other preference.

(In reply to Richard Fontana from comment #1)
 
> Here's what I would suggest: We should assume that no one actually thought
> they were putting EPEL under a GPLv2 compilation license, and we should
> assume it is unnecessary to have an explicit compilation license for EPEL.
> 
> Nevertheless, epel-release can't have a blank License: field and that should
> reflect the license of the contents of epel-release. And also anything
> copyrightable in epel-release itself has to be under a Fedora-allowed
> license. Looking at the contents of epel-release, it is mostly what I would
> consider non-copyrightable except perhaps for the `crb` script. So I would
> assume that script is under GPLv2 (or let's say GPLv2-or-later) and
> therefore the license tag should be GPL-2.0-or-later. Unless the author(s)
> of the `crb` script (Troy Dawson?) have some other preference.

Oh further note: if Troy Dawson or the author(s) of the crb script wish to use GPLv2 as the license, the GPLv2 license file in epel-release should be replaced with a vanilla GPLv2 license file that doesn't have the old RHL notice on top.

The license on *-release dates back to around Red Hat Linux 5.0 but may have been RHL6. It was decided to move to a GPL for the 'distribution' as a whole to make it clear that 'resellers' *cough* had to also include the src.rpms for all of the packages that were in the binaries. I believe there was one reseller who only distributed the GPL src.rpms on request.  

Whether that legal logic makes sense or not I don't know. It was made 25+ years ago with a completely different legal guessing on what distributions, licenses and requirements for redistribution were. The epel packages came from the earlier Extras and Fedora LTS project which were trying to duplicate RHL in spirit as well as words. However I expect even by the time EPEL-5 came out the memories of the original decisions were weak.

Hope this helps some

(In reply to Stephen John Smoogen from comment #3)
> The license on *-release dates back to around Red Hat Linux 5.0 but may have
> been RHL6. It was decided to move to a GPL for the 'distribution' as a whole
> to make it clear that 'resellers' *cough* had to also include the src.rpms
> for all of the packages that were in the binaries. I believe there was one
> reseller who only distributed the GPL src.rpms on request.  
> 
> Whether that legal logic makes sense or not I don't know. It was made 25+
> years ago with a completely different legal guessing on what distributions,
> licenses and requirements for redistribution were. The epel packages came
> from the earlier Extras and Fedora LTS project which were trying to
> duplicate RHL in spirit as well as words. However I expect even by the time
> EPEL-5 came out the memories of the original decisions were weak.
> 
> Hope this helps some

That is useful to know. I don't think this made that much sense back in the 1990s (when the landscape and culture around open source licensing was quite different) and in any case it's inconsistent with language that has always been in what's now the RHEL EULA (a variant of which Fedora used for a number of releases before ~2009), which also grants a GPLv2 compilation license of sorts but otherwise seems to suggest the opposite of what the RHL notice was trying to do.

> Also, it is worth noting that EPEL is designed to be used with other distributions, the known examples of which have their own "open source compilation license" practice. This further suggests to me that having a distinct compilation license for EPEL serves no purpose other than potentially creating additional confusion and friction.

That sounds fine by me.  I don't have strong feelings around whether or not EPEL has a compilation license.  Mainly I just just want to ensure we're doing the right (or least bad) thing, in the opinion of Fedora Legal.

> Nevertheless, epel-release can't have a blank License: field and that should reflect the license of the contents of epel-release. And also anything copyrightable in epel-release itself has to be under a Fedora-allowed license. Looking at the contents of epel-release, it is mostly what I would consider non-copyrightable except perhaps for the `crb` script. So I would assume that script is under GPLv2 (or let's say GPLv2-or-later) and therefore the license tag should be GPL-2.0-or-later. Unless the author(s) of the `crb` script (Troy Dawson?) have some other preference.

The License tag was my primary concern.  In the initial implementation PR for epel10, I intentionally left out the crb script so that we can make an independent decision on what the License tag should be based solely on the repo configs and gpg key.  If those are considered non-copyrightable, then what value makes sense for the License tag?  Whatever that answer is, then perhaps the eventual License tag should be:

License: <that license> AND <license of the crb script>

We also have to answer the same question for epel-rpm-macros, which doesn't have any scripts we can defer to for a License tag.

https://src.fedoraproject.org/rpms/epel-rpm-macros/tree/epel9

(In reply to Carl George 🤠 from comment #5)
  
> The License tag was my primary concern.  In the initial implementation PR
> for epel10, I intentionally left out the crb script so that we can make an
> independent decision on what the License tag should be based solely on the
> repo configs and gpg key.  If those are considered non-copyrightable, then
> what value makes sense for the License tag?  Whatever that answer is, then
> perhaps the eventual License tag should be:
> 
> License: <that license> AND <license of the crb script>

I don't think this is really currently documented in the Fedora legal docs, but: There is a custom identifier, `LicenseRef-Not-Copyrightable`, which would be appropriate for cases where otherwise a license tag would be empty because the contents of the package are most likely not copyrightable. However, if there is anything in the package that would be covered by a (real) license, as in the case of the crb script, then LicenseRef-Not-Copyrightable would not be included in the license tag. Essentially I think it should only be used in a license tag if *everything* in the binary RPM is not copyrightable. Otherwise it probably shouldn't be used, since all packages will have non-copyrightable elements. So for example if the crb script were licensed under (in SPDX) `GPL-2.0-or-later`, then epel-release could be 
License: GPL-2.0-or-later
but if the crb script were not present, it would be
License: LicenseRef-Not-Copyrightable

Thanks for the clear guidance.  I'll start epel-release with LicenseRef-Not-Copyrightable.  Later Troy can add the crb script, state explicitly which license he is placing it under, and switch the License tag to that.

Would you agree that the contents of epel-rpm-macros are similarly non-copyrightable, and should also use LicenseRef-Not-Copyrightable?

Apologies in advanced for fracturing the licensing discussion about epel-rpm-macros, but see my previous comment in https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/79#comment-212823.

(In reply to Carl George 🤠 from comment #8)
> Would you agree that the contents of epel-rpm-macros are similarly
> non-copyrightable, and should also use LicenseRef-Not-Copyrightable?

Yes. I see that there is a GPLv2 file in there (without the RHL-vintage header) and I can't bring myself to say that it's justifiable. So I would suggest removing the GPL file and using LicenseRef-Not-Copyrightable in the license tag.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-7c4c1ca326