process for review of licenses
by Jilayne Lovejoy
Hi all,
As you all know, we have a larger project of moving Fedora license data
to a data format and repository, updating and improving Fedora-legal
documentation related to licensing, and adoption of SPDX ids. In light
of that, it is also relevant to look at the process for review of a new
license for potential inclusion in Fedora.
I'd describe the past/current process as:
- send email to this list, some discussion may ensue on list (with
community members and Red Hat legal), decision made and then license is
added to the applicable wiki table (good or bad) at
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing
- Of course, up until somewhat recently, this entire workflow was
shepherded by Tom Callaway
Now that we have the license data in a repository, it seems like we can
use Issues and Merge Requests for the process flow, instead of relying
on email. As such, I'd like to propose something along the following lines:
*
**How to request review of a new license*
If you find a license for a package you want to include in Fedora and
that license is not listed in the Fedora License Data, you can submit it
for review as follows:
Note: you must be a Fedora contributer and become part of the Fedora
Gitlab group. See LINK for more on how to become a Fedora contributor.
1) Create a new issue in the Fedora License Data repo with the following
information: license name, link to text of license, package name and
link, why you want to include it in Fedora, whether it is on the SPDX
License List, and the SPDX expression as applicable (see below for hints
on determining if a license text matches a license on the SPDX License List)
2) All discussion related to the license review based on the license
criteria will be on the Issue thread and a decision will be noted there.
` If the license is not on the SPDX License List, then submit the
license to the to the SPDX-legal team at
https://tools.spdx.org/app/submit_new_license/. In addition to the
required information, include a note that it is under review for Fedora
and a link to the related Fedora License Data Gitlab issue.
The ultimate decision for licenses allowed or not-allowed for Fedora
based upon the license criteria rests with Red Hat legal.
3) Once a decision has been made, the person who submitted the license
for review creates a Merge Request for the license using the TOML file
format.
4) Merge Requests will be reviewed and merged by the Fedora License Data
repo maintainers.
Happy to hear your thoughts, feedback, and suggestions!
Thanks,
Jilayne
1 week, 5 days
LGPL-ish license in Package Review for sfexp
by Ian McInerney
When verifying the license for sfsexp (
https://bugzilla.redhat.com/show_bug.cgi?id=2095717) in my review, I
noticed it appears to have a modification to the LGPLv2+ license on it. The
full license text provided by the package is:
Copyright (2003-2006). The Regents of the University of California. This
material was produced under U.S. Government contract W-7405-ENG-36 for Los
Alamos National Laboratory, which is operated by the University of
California for the U.S. Department of Energy. The U.S. Government has rights
to use, reproduce, and distribute this software. NEITHER THE GOVERNMENT NOR
THE UNIVERSITY MAKES ANY WARRANTY, EXPRESS OR IMPLIED, OR ASSUMES ANY
LIABILITY FOR THE USE OF THIS SOFTWARE. If software is modified to produce
derivative works, such modified software should be clearly marked, so as not
to confuse it with the version available from LANL.
Additionally, this library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation; either version 2.1 of the
License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License
for more details.
You should have received a copy of the GNU Lesser General Public License
along with this library; if not, write to the Free Software Foundation,
Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, U SA
LA-CC-04-094
(taken from https://github.com/mjsottile/sfsexp/blob/master/COPYING).
This to me reads as a modification to the normal LGPL (since it puts
requirements that derivative works be clearly marked as distinct). Is this
modification acceptable for inclusion in Fedora?
-Ian
3 weeks
Publishing containers based on Fedora
by Andreas Hartmann
Hello everyone,
I recently started to host my own container registry via GitLab. I use it to
build container images for my own use (bundling mostly CLI tools at the moment)
and would like to publish them, too, so others may use them as well.
Now since I use Fedora Linux on all of my systems, I would also like to use it as
a base for the containers where necessary (I.e. where alpine Linux doesn't work).
Now I'm wondering if there are any restrictions that I should be aware of with
regard to the publishing of these images. That is mostly because I have hardly
ever seen any container on e.g. the docker Hub that's based on Fedora.
I do not use the Fedora trademark, I don't advertise that the containers are
built on top of a Fedora base container, I never mention the word Fedora in any
of the docs associated with the containers. The only relation between these
containers and the Fedora project is the line `FROM
registry.fedoraproject.org/fedora:36` at the beginning of my Containerfiles.
Is this acceptable, or does that already mean that I mustn't publish these
images?
In case I am allowed to publish such container images: Are there any packages
that need to be removed from the containers? I know that Fedora Remixes mustn't
use the official Fedora logo RPMs but supply their own instead. Are these part of
the containers and hence need I remove them?
Finally, again in case I am allowed to publish such container images in the first
place, which applications am I allowed to bundle with the containers? I am aware
that Fedora has adopted e.g. the "3rd-party repositories" in Gnome Software,
which give filtered access to flathub applications, due to legal reasons. I would
*assume* that it's okay to publish e.g. GPL-licensed software along with a Fedora
container. What about other licenses such as MIT?
Sorry for the lengthy mail, but I haven't been involved much with legal matters
regarding software in my life before. I just want to make sure I'm legally
allowed to do what I want to, *before* I get into trouble for infringing
trademarks/licenses or anything. I have already searched the web and the archives
of this mailing list, but that didn't produce any results.
Thank you in advance!
Kind regards
Andreas Hartmann
3 weeks, 1 day
Re: [Fedora-packaging] Re: license of the binary policy
by Richard Fontana
On Wed, May 25, 2022 at 2:12 AM Otto Urpelainen <oturpe(a)iki.fi> wrote:
>
> As a maintainer of modest amount of packages and occassional new package
> reviewer,
> the issues I have with the current licensing policy as linked above are:
>
> 1. The "effective license" thing that is already discussed in another
> thread does not appear in the policy at all, and it does not appear in
> Fedora Licensing page, either. The only places that mention it that I
> have discovered are Licensing:FAQ [1] and random discussions at mailing
> lists and so on. This makes it quite difficult to understand if
> "effective licensing" is actually part of the policy or not. It would be
> easier to understand its status if it was covered in the policy itself.
> The policy itself should be unambiguous and possible to interpret
> without reference to any FAQ. A FAQ should not introduce new
> requirements and exceptions.
That part of the FAQ will have to be revisited, if the approach I
suggested today is adopted (a good example of why it isn't exactly
maintaining the existing policy). Basically, the "simple enumeration"
approach would mean that there is no such thing as "effective
licensing".
If people think that "effective licensing" is something that is so
valuable that it is worth the resulting unavoidable complexity of
analysis and inconsistency across packages, that view should be
voiced. I *can* imagine providing some more detailed rules about what
"effective licensing" means (and at an earlier stage I was actually
thinking of working on something like this). I basically gave up
because it's clear no one agrees on what effective licensing means,
which means it's not effective. :)
> 2. In general, it is confusing that the policy is split between
> Packaging Guidelines, Fedora Licensing main page and, apparently, also
> the FAQ. How can I determine if any given docs or wiki page is
> authorative? Would it be possible to consolidate everything that is
> authorative to a single page and declare it such?
Good idea.
> 3. Specifically related to the effective licensing question, MIT and BSD
> basically *only* ask to include the license text when shipping binaries.
> The effective licensing thing then erases those licenses, if there is
> GPL somewhere in the mix. The cognitive dissonance between wanting to
> honor upstream licenses and not shipping them due to effective licensing
> is serious. Since MIT and BSD are very common licenses, and code under
> them is also very commonly found embedded in otherwise GPL projects, I
> would like the licensing policy explicitly cover this situation and
> explain why it is allowed to not ship the MIT/BSD license in this case.
> (Perhaps, it would be good to revisit the part of the policy that
> discussed shipping license texts and consider, why is that required: It
> is in order to honor upstream licenses, or for some other reason, like
> end user convenience?)
All the licenses are shipped in that they are found in the SRPM.
Implicitly, Fedora's position is that this is compliant with those
permissive licenses. I think the issue you're raising is Fedora's
policy on what license texts to install in /usr/share/licenses. I
don't think that issue is directly tied to how the License: field is
populated. I couldn't immediately find any documentation on the
/usr/share/licenses policy, but my intuition from looking at lots of
Fedora and RHEL packages is that this contains any license text that
seems to be "global" in some way, and in cases where there is no
obvious such license, some appropriate license is selected from the
source files for this purpose. We might want to separately revisit the
/usr/share/licenses policy at some point if there is interest.
Richard
>
> [1]: https://fedoraproject.org/wiki/Licensing:FAQ
> _______________________________________________
> packaging mailing list -- packaging(a)lists.fedoraproject.org
> To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproje...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
4 weeks
license of the binary policy
by Jilayne Lovejoy
Hi Fedora legal and packaging,
I'm cross-posting this, as I think it's relevant to both groups.
The current policy for filling out the license field of the spec file
(as described at
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidel...
) states, "The License: field refers to the licenses of the contents of
the binary rpm. When in doubt, ask."
As we consider how to improve documentation related to Fedora licensing,
it would be helpful to hear people's thoughts on the following:
1) how do you (package maintainers) interpret this policy in practice?
2) what further information/documentation about this policy would be
helpful?
3) should this policy be different, and if so, how?
4) any other related thoughts or observations
Thanks!
Jilayne
4 weeks
SPX Change proposal
by Miroslav Suchý
I took the initiative and drafted
https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1
I did **not** set it as ready for wrangler yet. I welcome comments. And feel free to edit it directly. Especially these
who I put there as proposal owners.
I would love to track all remaining work in the Scope section, so we know what needs to be done and who is responsible.
I am sure I missed something there. Feel free to add it.
Miroslav
1 month
