On 8/22/23 15:40, David Cantrell wrote:
On Mon, Aug 21, 2023 at 9:30 AM Daniel P. Berrangé <berrange@xxxxxxxxxx
<mailto:berrange@xxxxxxxxxx>> wrote:
On Mon, Aug 21, 2023 at 01:04:29PM +0200, Florian Weimer wrote:
> I think Richard said that he would start a thread like this, but it
> hasn't happened, so I feel like should get this off my chest now.
>
>
<https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_license_analysis <https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_license_analysis>>
> starts with this:
>
> | No “effective license” analysis
> |
> | The License: field is meant to provide a simple enumeration of the
> | licenses found in the source code that are reflected in the binary
> | package. No further analysis should be done regarding what the
> | "effective" license is, such as analysis based on theories of GPL
> | interpretation or license compatibility or suppositions that
> | “top-level” license files somehow negate different licenses appearing
> | on individual source files.
>
> This is contradictory. I think there are two aspects here:
>
> * Determine possible licenses that end up in the binary package.
>
> * Perform algebraic simplifications on the license list.
>
> Both analyses are forms of effective licensing analysis. Of course, you
> cannot derive an SPDX identifier without doing any analysis. However, I
> strongly believe that the first approach (determining the binary package
> license) is itself a form of effective licensing analysis, and similar
> reasons for package maintainers not doing this applies. The derived
> SPDX identifier will reflect both the package source code and what went
> into the build system.
It could perhaps be worded better, but I don't see this as contradictory,
it is just a matter of what you consider "effective analysis" to refer to.
The last sentance expands on this to say that 'effective' in this context
is refering to the analysis of license compatibility that Fedora previously
recommended.
The 'license compatibility' aspect is what is meant by the process here. Previously Fedora
carried a large license compatibility chart and there were rules (both written and passed
down through oral tradition) about what is and is not compatible with the different GPL
licenses. A common case was a GPL project incorporating BSD licensed code which meant the
entire collective work was GPL licensed _per FSF guidelines_. This is the part that Fedora
Legal wants to do away with. Package maintainers do not need to perform this compatibility
analysis.
So yes, it could probably be worded better.
The analysis maintainers are being asked to do today is not about interpreting
licensing. They "merely" being asked to determine what source files are
containing code that becomes part of the resulting binary RPM. This is more
build system analysis than license analysis, and distinct from what Fedora
would traditionally describe as "effective license analysis".
Correct.
> * Some package maintainers, when translating to SPDX, merely translate
> the existing License: line as best as they can, without looking at the
> actual sources or produced binaries.
This I think is probably the main flaw in the process we asked our
maintainers to follow.
At a high level we portrayed the whole exercise as merely a terminology
change, but it was not.
Given the removal of the effective license analysis requirement, that
was / is an over simplification.
Strictly speaking I think the exercise ought to have been portrayed as
more of a license (re-)audit. In the general case maintainers ought to
be redoing the license audit part of the new package review process,
for all existing packages, not blindly converting existing terminology.
We did portray this as a re-audit and not simply a change in abbreviations. I did many
presentations on just that and we held numerous hack fests where we helped people analyze
packages to determine the correct license expression in SPDX.
There are definitely maintainers who thought it was just a change in abbreviations and I do
not think there is an easy way to stop that. But as we have been going through this
process, the number of maintainers auditing packages has been high and we are seeing more
licenses captured and added to SPDX that were not previously represented.
What I would like to see in the future is a tool connected to Bodhi that can run for each
build of a package and perform a license analysis, build the License tag string, then
compare it to what is in the spec file. If it's different then alert the package maintainer
and say "Hey, I'm a script and I analyzed the licenses in this package and I *think* I found
something different than what you put in the spec file License tag. If I were you, I would
check it out because one of us is probably wrong." Maybe we'll have that at some point.
> In the light of this, I would like to suggest updating the guidelines in
> the following way:
>
> The License: line should be based on the sources only. Using a tool
> such as Fossology to discover relevant licenses and their SPDX tags is
> sufficient. No analysis how licenses from package source code or the
> build environment propagate into binary RPMs should be performed.
> Individual SPDX identifiers that a tool has listed should be separated
> by AND. Package maintainers are encouraged to re-run license analysis
> tooling on the source code as part of major package rebases, and
> update the License: tag accordingly.
>
> To me, that seems to be much more manageable.
What I'm not a fan on with this approach is that it would cause us
to include licenses that are clearly irrelevant for Fedora binary
packages. If we consider the "license" tag to be something for end
users to look at, I think this will be misleading.
For example in one package I reviewed there is kernel code that is
only built on Solaris which is under the CDDL. Including that in
the Fedora binary RPM license feels totally wrong.
In many packages using autotools there are snippets of m4 code that
are under a variety of licenses, again not affecting the output.
Those would "bloat" the license tag for little obvious gain.
I do agree though that doing *perfect* build system analysis to figure
out what source files become part of the binary RPMs is impractical
for any non-trivial packages.
My approach has been to scan the source for licenses, and then look
at source files with any licenses I was surprised to see. Often it
is possible to exclude these unexpected licenses, because they are
obviously part of the build system, or are obviously for a differnt
OS platform.
I agree here. To me, the source archive already includes its licensing information. What
Fedora does is build this source in a curated way for distribution, so the licenses that
apply to our build do not necessarily align with other distributions. This is the licensing
information that I think is relevant for Fedora to understand and convey to users. There
will always be additional licenses in the source archives (given your examples above such as
autotools or optional code that is not enabled at build time), but the source archives
include all of that licensing information. If they didn't, we would not be able to build
anything from that source to include in Fedora.
I would describe this as trying to meet the spirit of the having the
RPM license reflect binary content, while acknowledging the reality
that maintainers won't fully analyse the build system as it is too
time consuming & impractical.
I might suggest adding an extra sentance to make it more explicit
that the binary RPM license is not a perfect representation of
the binary content, as may sometimes include extra licenses from
source files that were not relevant. This would reflect the somewhat
pragmatic approach that I think maintainers already take in practice
One thing I have learned through this whole SPDX project is that being a convergence of
something technical and something not makes it very difficult to arrive at what we think is
an acceptable completion. I think what we have now in Fedora is pretty good compared to
other distributions, but it can always improve. We just keep making improvements and keep
refining the process. Shaving the yak, as it were.
Thanks,
| The License: field is meant to provide a simple enumeration of the
| licenses found in the source code that are reflected in the binary
| package. In may also include additional licenses for files that are
| not part of the binary where it is impractical to filter them out
| during license review. No further analysis should be done regarding
| what the "effective" license is, such as analysis based on theories
| of GPL interpretation or license compatibility or suppositions that
| “top-level” license files somehow negate different licenses appearing
| on individual source files.
With regards,
Daniel
--
|: https://berrange.com <https://berrange.com> -o-
https://www.flickr.com/photos/dberrange <https://www.flickr.com/photos/dberrange> :|
|: https://libvirt.org <https://libvirt.org> -o- https://fstop138.berrange.com
<https://fstop138.berrange.com> :|
|: https://entangle-photo.org <https://entangle-photo.org> -o-
https://www.instagram.com/dberrange <https://www.instagram.com/dberrange> :|
Hello,
Regarding this, I am testing a new tool for license analysis.
I took a random package from an SPDX PR in my Inbox.
https://src.fedoraproject.org/rpms/90-Second-Portraits/pull-request/1
Surprise, surprise, we have non free code, this is just amazing!
Analysis:
OFL-1.1
---
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/data/fonts/neuton.ttf
CC-BY-SA-4.0 AND CC-BY-3.0 AND Zlib
---
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/LICENSE.txt
LicenseRef-proprietary-license
---
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/data/fonts/yb.ttf
After research: https://www.dafont.com/young-beautiful.font
Note of the author:
My fonts are free for PERSONAL use only. For any commercial use (anything you make money
from), you must send a paypal donation.
Please visit my website http://mistifonts.com/ to see my affordable prices.
And on that site we have:
Terms Of Use
This font is free for personal use and non-profit use.
If you make money from using this font, you must purchase a license.
You may not trace or edit my fonts and then resell them as your own creation. For example:
Taking my font, tracing over the letters or editing some of the letters, and then selling
that font.
Please download, install and test the font before purchasing a license to ensure that it
works for your intended use.
You can read license Terms of Use >>here<<
=> NON FREE (AS IN SPEECH, NOT BEER)
MIT
---
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/middleclass/CHANGELOG.md
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/middleclass/middleclass.lua
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/middleclass/MIT-LICENSE.txt
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/middleclass/README.md
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/middleclass/rockspecs/middleclass-3.0-0.rockspec
X11
---
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/slam.lua
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/hump/camera.lua
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/hump/class.lua
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/hump/gamestate.lua
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/hump/README.md
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/hump/signal.lua
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/hump/timer.lua
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/hump/vector-light.lua
90-Second-Portraits-1.01b-16.fc38.src.rpm-extract/90-Second-Portraits-1.01b.zip-extract/hump/vector.lua
So the Licence field should be:
# Zlib: Main package
# CC-BY-SA-4.0: assets by Tangram Games
# CC-BY-3.0: data/music/monkeys.ogg
# OFL-1.1: data/fonts/neuton.ttf
# MIT: middleclass/
# X11: slam.lua and hump/
License: Zlib AND CC-BY-SA-4.0 AND CC-BY-3.0 AND OFL-1.1 AND MIT AND X11
And then we have a non-free font data/fonts/yb.ttf that should be removed/replaced.
_______________________________________________
legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/legal@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
