On Thu, Mar 3, 2022 at 5:08 PM Jilayne Lovejoy jlovejoy@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