On 19. 06. 24 23:32, Miroslav Suchý wrote:
Dne 19. 06. 24 v 5:58 odp. Miro Hrončok napsal(a):
How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND
MIT" or similar?
Converting "GPLv2" (which could mean any number of "weaker" licenses are
hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" (which
means all the code is exactly GPL 2.0 only) cannot be done automatically.
I don't know. But it seems like the best option.
Not to me.
When we decided to do the SPDX thing, we also decided to do the "no effective
license analysis" and "list all the licenses". I don't have an opinion whether
that decision is good or bad, but it is that way. We cannot automatically
convert GPLv2 to GPL-2.0-only (or similarly with other variants and versions).
If we do this, we are effectively saying "OK, we agreed on a set of rules, but
we decided to ignore them for a sake of..." what exactly? Completeness?
Closure? That does not make sense to me.
More below.
What are the options:
1) Wait for all the maintainers to do the conversion themselves. Based on the
data I send every two weeks, we can do it in a year. But that target date is 20
days away every two weeks.
Even if this "never" happens (i.e. we will still have packages using the old
License notation in 10 years), it is the right thing to do. We decided that new
packages MUST follow the new rules (and use the SPDX notation), and the old
thing will eventually die out, very very slowly. And that's OK.
It's better to have 25 % packages notconverted than having 25 % packages
converted incorrectly.
Moreover, when we see "GPLv2" we know what it means -- it has not been
converted yet and might hide additional licenses. If you convert everything to
"GPL-2.0-only" we can no longer distinguish between "effective GPL" and "GPL
and no other license".
(Note that I do not live in a fantasy world and I am well aware many packages
were already converted from GPLv2 to GPL-2.0-only or similar by their
maintainers without checking all the licenses. But that is their choise. We
should, not encourage it and do it in bulk.)
2) Do nothing at all.
That's the same as 1).
3) Automatically convert where there's a good chance it's correct.
Good chance of correct is not good enough correct.
If it is, let's change the rules to explicitly allow this kind of "effective
license analysis" again and bulk convert everything. (If we do that, a lot of
work was wasted, but let's not sue that as an argument not to do that, if it
turns out to be the best solution.)
In our group we made a list of what can be automatically converted. For RH
folks this link
https://docs.google.com/spreadsheets/d/1thDTCawJTewqMCgC1dDuKu4Hq9DCA57q0VDstFXTHvg/edit?usp=sharing
for others this copy
https://k00.fr/tnbu0zrs
What I posted is what made sense to us. But there are licenses where it doesn't
make sense to us. For example.
wxWindows
which will probably be rewritten to
LGPL-2.0-or-later WITH WxWindows-exception-3.1
but the exception may be slightly different and needs to be checked.
I disagree with the conclusions from that list wrt the GPL license family.
I would be very happy if the migration was done manually. Every time I did a
manual analysis, I discovered some files under other licenses.
That is exactly the reason we cannot do it automatically.
But manually checking everything under the current state of the tools is not
realistic.
That is the reality we need to accept. But it does not mean we can dodge the
bullet by doing the proposed conversion.
But there are a lot of people working in the background to have better tools.
For example, I would like to publicly thank Robert-André Mauchin, who has spent
a lot of time wrapping scancode=toolkit and its dependencies. This is an
excellent tool for file analysis. We are just a small step away from completing
all the reviews. When this is done, I'd like to create a tool to alert
maintainers to new licenses that are used in a file but not in tarball.
+1
For me, migrating these particular licenses is not a perfectly executed step.
But it is a step forward. And any imperfections can be fixed in the future.
The conversion can be done in the future as well.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
