On Thu, Mar 3, 2022 at 5:08 PM Jilayne Lovejoy <jlovejoy(a)redhat.com> wrote:
On 3/3/22 2:51 PM, Kevin Fenzi wrote:
> On Thu, Mar 03, 2022 at 12:03:15PM -0700, Jilayne Lovejoy wrote:
>>
>> Given that "good" and "bad" are historical for the Fedora
licensing
>> documentation - what are your thoughts on this?
> I like the idea of moving to 'approved' vs 'not approved' in
general. I
> think most people looking at that list will be looking in the context of
> packaging for Fedora and will just want to know if it's approved or not.
>
> That said, I think Neil makes a good point about people choosing
> licenses. Would it make sense to have 'approved' and 'not approved'
and
> 'reccomended' ? :) Of course then recommended would be subjective, but
> perhaps thats ok. This would just be a smaller subset of licenses that
> are not only approved, but encouraged by the project.
>
That's an interesting idea - are you thinking this would be in the
context of: "If you are creating or considering a license for a package
that you want included in Fedora, here is a list of recommended licenses
to use" ? (which I suppose implicitly says, use an approved/good one,
but don't just pick any old approved/good one, please)
Historically I think Fedora had some informal standards around
Fedora-specific projects (not Fedora packages, but projects that are
in some sense part of the larger Fedora project) but I am not sure
this has ever really been documented. Most Fedora projects seem to use
GPLv2, the MIT license, LGPLv2.1, perhaps GPLv3 to some degree. I
don't see a compelling need for Fedora to start making recommendations
for *Fedora* projects since this has seemed to work pretty well as an
informal thing. As for whether Fedora should make broader
recommendations ... I am not sure at this point Fedora doing so will
have much impact on upstream licensing choices so I don't know if it
would really be worthwhile.
Internally at Red Hat, we have had a fairly lengthy list of
default-approved licenses for new projects for some time now. We've
thought about making this a much smaller list. I wouldn't immediately
see a need for this list to be harmonized with a hypothetical Fedora
recommended list since it serves rather different purposes, in
contrast to our goal of harmonizing Fedora "good" and "bad" license
lists more generally with internal Red Hat counterparts.
Richard