Re: Package Licensing - Open Data Commons Open Database License (ODbL) License
by Justin Zobel
Ahh OK. Well, it would make sense to have a combined list. Hopefully,
someone on the Fedora side can give me the all OK to include the package
based on RHEL's inclusion policy.
And I just realised I hit reply instead of reply-all on the email again.
On Wed, Feb 16, 2022 at 8:55 AM Richard Fontana <rfontana(a)redhat.com> wrote:
> In theory, the Fedora list is the RHEL list, but some time ago Red Hat
> started supplementing it internally with another "list" (or compiled
> information) resulting from review of results of certain scanning
> tools on RHEL package source code. That "list" is not currently public
> information. Our current plan is to essentially merge the two license
> approval efforts so that there is one single public list of approved
> and unapproved licenses. But it will take some time to undertake the
> various steps for getting there.
>
> Richard
>
> On Tue, Feb 15, 2022 at 5:14 PM Justin Zobel <justin.zobel(a)gmail.com>
> wrote:
> >
> > Thank you Richard. Is there an "Accepted Licenses" page for RHEL?
> >
> > On Wed, Feb 16, 2022 at 4:40 AM Richard Fontana <rfontana(a)redhat.com>
> wrote:
> >>
> >> On Mon, Feb 14, 2022 at 9:52 PM Justin Zobel <justin.zobel(a)gmail.com>
> wrote:
> >> >
> >> > Thank you for these insights. Are you able to provide a link to the
> RHEL review of ODbL for the Fedora license team to refer to in their review
> process?
> >>
> >> Unfortunately in this case there really isn't anything to link to
> >> apart from a snarky comment by me about how lengthy the license is :-)
> >>
> >> Richard
> >>
> >>
> >>
> >> >
> >> > On Tue, Feb 15, 2022 at 11:52 AM Richard Fontana <rfontana(a)redhat.com>
> wrote:
> >> >>
> >> >> On Mon, Feb 14, 2022 at 6:49 PM Justin Zobel <justin.zobel(a)gmail.com>
> wrote:
> >> >> >
> >> >> > Hi Team,
> >> >> >
> >> >> > I've just begun packaging for Fedora and of course, I happen to
> choose one with a license that needs querying.
> >> >> >
> >> >> > The Open Data Commons Open Database License (ODbL) is for database
> usage in the kpublictransport KDE library. It is used for access to
> OpenStreetMap via the KTrip application designed to aid users in navigating
> via public transport.
> >> >> >
> >> >> > From the OpenStreetMap Copyright page on their website:
> >> >> > OpenStreetMap® is open data, licensed under the Open Data Commons
> Open Database License (ODbL) by the OpenStreetMap Foundation (OSMF).
> >> >> >
> >> >> > Open Database License: https://opendatacommons.org/licenses/odbl/
> >> >> > Open Street Map: https://www.openstreetmap.org/copyright
> >> >> > KDE Source Repository:
> https://invent.kde.org/libraries/kpublictransport/
> >> >> > Fedora Source Repository:
> https://src.fedoraproject.org/rpms/kpublictransport/
> >> >> >
> >> >> > I would like to know if this license is acceptable to Fedora.
> >> >>
> >> >> This is somewhat interesting as it is the first case I can think of
> >> >> where a license that Red Hat has specifically reviewed internally for
> >> >> inclusion in Red Hat Enterprise Linux has at a later time come up for
> >> >> a decision in Fedora.
> >> >>
> >> >> We actually approved ODBL for RHEL last year, and I think if we had
> >> >> our contemplated merging of RHEL license review and Fedora license
> >> >> review in place, it would just end up on the "good" list, but given
> >> >> that the new process is not yet established it would probably be a
> >> >> good idea to do another review now that it has come up for Fedora.
> >> >>
> >> >> Richard
> >> >>
> >>
>
>
> --
>
>
2 months, 2 weeks
Fedora's shortname -> SPDX
by Miroslav Suchý
I wrote a script which converts Fedora's shortname to SPDX
https://pagure.io/copr/license-validate/blob/main/f/license-fedora2spdx.py
It is not packaged yet. You need to have `license-validate` and `rpminspect-data-fedora` packages installed. Plus the
script above. In fact you need
https://github.com/rpminspect/rpminspect-data-fedora/blob/c06dee22da8db10...
because the file fedora.json in master and in Fedora's `rpminspect-data-fedora` is not JSON valid.
If you go over these obstacles you can try it:
$ ./license-fedora2spdx.pyGPLv2
GPL-2.0
$ ./license-fedora2spdx.py'MIT or (GPLv1 and Glide)'
Warning: more options how to interpret MIT. Possible options: ['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND',
'no-spdx-yet (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ', 'MI
T-enna', 'MIT-feh', 'mpich2']
mpich2 or ( GPL-1.0 and Glide )
I.e. it will honor operators and parenthesis, and if the conversion is straight script will give you the result. If
there is some confusion, e.g., Fedora's MIT shortname can be converted to more than one SPDX identifier, it will print a
warning. And you should investigate what is the right SPDX identifier.
I welcome your comments. I will resolve any issues you will find and then add it to `license-validate` package.
I hope this will ease the migration to SPDX when the time comes.
Miroslav
2 months, 2 weeks
Waydroid LineageOS licensing
by Alessandro Astone
Hi,
I'm working on packaging Waydroid for fedora. This is a wrapper around
lxc that natively runs a patched LineageOS android image. While the lxc
wrapper itself is GPL3, the big elephant in the room is the LineageOS image.
On the first use the user is supposed to run `waydroid init` which
downloads the LineageOS image precompiled by the Waydroid team, from
their servers. It also supports OTA updates from them. The user could
instead provide its own images (to a specified location in /usr) and
waydroid will skip the download and use those.
My first question is: Would waydroid be allowed to download it's own
precompiled images? Does it fall in the 'firmware for emulators'
category, for which the policy is as follows?
> * Emulators must not point to any third-party sites which provide
> firmware or ROM files that are distributed without the clear and
> explicit permission of their copyright holders.
>
If yes: who is the copyright holder? AOSP is a collection of projects,
most of them being Apache licensed with owner "The Android Open Source
Project", but also includes many external projects from various authors
with various licenses. Of course there's also some Apache licensed "The
LineageOS Team" code and some Apache licensed "The Waydroid Project"
code. Ultimately the code is compiled by the Waydroid team.
Some included third party projects are already problematic for fedora,
for instance ffmpeg and chromium (which includes ffmpeg).
If no: Can we source build LineageOS in koji? I would need help
identifying the problematic packages in the huge list of packages that
make up android. Here's my specfile for it:
https://github.com/aleasto/waydroid-lineageos-devel/blob/main/waydroid-li...,
it has 786 tarballs. If you prefer an xml listing of the projects you
should look at default.xml and snippets/lineage.xml from
https://github.com/LineageOS/android/tree/lineage-17.1
Problems should only arise from external/* projects, since everything
else _should_ be Apache.
I've already removed chromium (in the form of a prebuilt webview apk in
aosp or lineageos) and ffmpeg from the specfile (maybe forever, maybe
until later given the progress at src.fedoraproject.org/rpms/ffmpeg).
Thank you!
Alessandro
2 months, 3 weeks
Draft attempt to define Fedora license categories
by Richard Fontana
Greetings,
As part of some ongoing efforts to improve information relating to
Fedora licensing and licensing policy, we want to provide better
documentation around the various license approval categories for
Fedora, as currently set forth here:
https://fedoraproject.org/wiki/Licensing:Main
but which probably will live in the future on docs.fedoraproject.org.
Here's a rough draft which I wanted to publish here for review.
Feedback/criticisms/suggestions welcome.
Side note: This preserves Tom Callaway's historical usage of "good" to
mean "Fedora-approved", but I have mixed feelings about this
terminology.
1. Licenses for Code
“Code” means software code, any other functional material whose
principal purpose is to control or facilitate the building of
packages, such as an RPM spec file, and other kinds of material that
the Fedora Council has classified as "code" rather than "content", but
does not include font files.
[Comment: This annoyingly and confusingly does not line up with
definitions in the FPCA, but Fedora should get rid of the FPCA anyway]
A license for code is “good” if the Fedora Project determines that the
license is a free/libre//open source license.
[Not sure if it's helpful to add the following:]
In making this determination, Fedora historically relied primarily on
the Free Software Definition as maintained and interpreted by the Free
Software Foundation, but out of necessity Fedora passed judgment on
many licenses never addressed by the FSF and, in the process, built up
an informal body of interpretation and policymaking (admittedly,
mostly undocumented) that went far beyond what the FSF had done.
Fedora has also sometimes considered the decisions of other community
Linux distributions and other important efforts to define and apply
FLOSS norms, most notably the OSI’s Open Source Definition. In a small
number of cases, Fedora has disagreed with decisions of the FSF and
OSI regarding whether particular licenses are FLOSS.
2. Licenses for Documentation
Any license that is good for code is also good for documentation.
In addition, Fedora may designate a license as good for documentation
if (a) the license meets the standards for good licenses for code, (b)
the license is designed primarily for technical documentation or
otherwise has a history of substantial use in free software
communities for documentation, and (c) the license is not commonly or
normally used for code.
[Comment: this feels unsatisfactory to me, for multiple reasons, but I
think it does accurately represent the historical Fedora policy.]
3. Licenses for Content
“Content” means any material that is not code, documentation, fonts or
binary firmware.
Any license that is good for code is also good for content.
In addition, Fedora may designate a license as good for content if it
restricts or prohibits modification but otherwise meets the standards
for good licenses for code.
4. Licenses for Fonts
Any license that is good for code is also good for fonts.
In addition, Fedora may designate a license as good for fonts if it
contains a nominal prohibition on resale or distribution in isolation
but otherwise meets the standards for good licenses for code.
5. Licenses for Binary Firmware
Some applications, drivers, and hardware require binary-only firmware
to boot Fedora or function properly. Fedora permits inclusion of these
files if they meet certain requirements [currently set forth at:
https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware but the
non-license part of this needs to move somewhere else ].
Any license that is good for code is also good for binary firmware.
In addition, Fedora may designate a particular firmware license as
good for firmware if the terms in the license that would not be
acceptable in a good code license are limited to the following:
* Requirements that the firmware be redistributed only as incorporated
in the redistributor's product (or as a maintenance update for
existing end users of the redistributor's product), possibly limited
further to those products of the redistributor that support or contain
the hardware associated with the licensed firmware
* Requirements that the redistributor to pass on or impose conditions
on users that are no more restrictive than those authorized by Fedora
itself with respect to firmware licenses
* Prohibitions on modification, reverse engineering, disassembly or
decompilation
* Requirements that use be in conjunction with the hardware associated
with the firmware license
Richard
3 months, 1 week
concerning who can change code licence
by Germano Massullo
Italian identity card middleware for Linux cannot be packaged for Fedora
because a developer assigned an "all rights reserved" licence to his code.
In the ticket [1] where I raised this problem, some developers of the
project said that they will investigate to find out if the lines of code
of the "wrong" license maybe erased.
My personal opinion is that only THE author must be the one allowed to
change the licence of his own code, not another person.
Is that correct?
Best regards
[1]: https://github.com/italia/cie-middleware-linux/issues/16
3 months, 2 weeks
font licenses from Fedora submitted to SPDX License List
by J Lovejoy
Hi all,
I’m posting this to both SPDX-legal and Fedora-legal.
I have just finished doing a compare of all the “good” font licenses for Fedora with the SPDX License List. As a result, I have submitted 4 new license to SPDX. See https://github.com/spdx/license-list-XML/issues <https://github.com/spdx/license-list-XML/issues> (specifically, Issues 1404, 1405, 1406, and 1407)
There are still two more “good” font licenses that may need to be added, but need a bit of research (e.g., looking for the license text in the actual source files of the packages) first. If anyone wants to help with that, let me know!
SPDX-legal - note that the criteria for font licenses to be considered “good” for Fedora is slightly more relaxed than the license for software. I still believe they will all fall squarely within the SPDX license inclusion guidelines.
Fedora-legal - once these issue show as “Accepted” SPDX will need some help creating the PR with the actual files. If anyone out there wants to help there, that would be great!
Cheers,
Jilayne
3 months, 2 weeks
