Once upon a time, Gary Buhrmaster said:
> The follow up suggested that the license
> field be differently formatted.
>
> I disagree with such explanatory
> prefixes, as it requires yet more apps
> to parse/support various prefixes.
No, my suggestion of using "License: SPDX:" would not require
On Wed, May 25, 2022 at 12:47 AM Maxwell G wrote:
> I don't follow. What "rpm spec file support" are you referring to?
I interpreted the proposal as adding a
new stanza SPDX: in addition to License:
which requires changing the definition.
The follow up suggested that the license
field be
On Tuesday, May 24, 2022 7:08:13 PM CDT Gary Buhrmaster wrote:
> I don't think that is going to work unless the rpm spec
> file support would be backported to previous releases
> (without another macro that tries to do some magic).
I don't follow. What "rpm spec file support" are you referring
Once upon a time, Gary Buhrmaster said:
> On Tue, May 24, 2022 at 11:29 PM Chris Adams wrote:
> > Would it make sense to make ALL the new tags be SPDX:, at least for
> > an interim period (of years most likely) where both old and new tags are
> > allowed?
>
> I don't think that is going to work
On Tue, May 24, 2022 at 11:29 PM Chris Adams wrote:
> Would it make sense to make ALL the new tags be SPDX:, at least for
> an interim period (of years most likely) where both old and new tags are
> allowed?
I don't think that is going to work unless the rpm spec
file support would be
Once upon a time, Maxwell G via devel said:
> I already brought this up previously, but how will we handle license
> identifiers such as MIT that are valid in both SPDX and Fedora but have
> different meanings? We won't know whether it's specifically referring to the
> MIT/Expat License (SPDX)
On Tuesday, May 24, 2022 3:11:39 PM CDT Miroslav Suchý wrote:
> We see no reason why not to do that. It should not cause any harm. If
**you** know of any reason we should not propose
> this, please tell us now.
I already brought this up previously, but how will we handle license
identifiers
