From mattdm at fedoraproject.org Fri Nov 5 12:04:49 2021 Content-Type: multipart/mixed; boundary="===============4445413137890556127==" MIME-Version: 1.0 From: Matthew Miller To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: website blurb about licensing of iso downloads Date: Fri, 05 Nov 2021 08:04:43 -0400 Message-ID: <20211105120443.GA15453@mattdm.org> In-Reply-To: CAC1cPGwZc-ZBLikvJPV2YMjYtYoLFGs6hciPjTVgrWrNyZsnxQ@mail.gmail.com --===============4445413137890556127== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 04, 2021 at 12:30:16PM -0400, Richard Fontana wrote: > > license -- the MIT license -- but I don't see that much value in > > placing any emphasis on that. But if that is going to be referred to, > > it should be "the license of the Fedora distribution itself", not the > > more ambiguous "the license of the Fedora project itself". > = > Or maybe "the license of the Fedora Linux distribution itself" (if I > recall correctly there's been some effort to refer to the distribution > as "Fedora Linux"). Yes please. I'm not going to fight colloquial usage, because that'd be silly, but for formal use like this, yes. It's the distro that's under the license, not ... all of us. :) -- = Matthew Miller Fedora Project Leader --===============4445413137890556127==-- From zbyszek at in.waw.pl Fri Nov 5 12:59:49 2021 Content-Type: multipart/mixed; boundary="===============0648434467991211971==" MIME-Version: 1.0 From: =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek_=3Czbyszek_at_in=2Ewaw=2Epl=3E?= To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: website blurb about licensing of iso downloads Date: Fri, 05 Nov 2021 12:58:40 +0000 Message-ID: <20211105125840.GE11852@in.waw.pl> In-Reply-To: CAC1cPGxodLmhBtZ08R13Nrh8k46=vEiWAzUyswf7bzUn2aHhrA@mail.gmail.com --===============0648434467991211971== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 04, 2021 at 12:27:56PM -0400, Richard Fontana wrote: > On Thu, Nov 4, 2021 at 12:09 PM Jilayne Lovejoy w= rote: > > > > > > > > On 11/4/21 1:46 AM, Zbigniew J=C4=99drzejewski-Szmek wrote: > > > On Thu, Nov 04, 2021 at 07:44:43AM +0000, Zbigniew J=C4=99drzejewski-= Szmek wrote: > > >> Hi, > > >> > > >> [see https://pagure.io/fedora-web/websites/issue/215 for the origina= l issue] > > >> > > >> I hope that this is the right venue for this question/review request: > > >> https://getfedora.org/ currently says > > >>> Fedora is always free for anyone to use, modify, and distribute. > > >>> It is built and used by people across the globe who work together a= s a community. > > >> There is a pull request open to amend the text to include: > > >> > > >> {% trans trimmed %}It is a compilation of software packages, > > >> each under its own license. Images that can be downloaded here are > > >> available under the combination of licenses of the constituent > > >> software packages and the license of the Fedora project itself. > > >> View License{% endtrans %} > > > This^ is https://pagure.io/fedora-web/websites/pull-request/218#reque= st_diff > > looking at the PR and the website page itself - do I understand > > correctly that this is essentially adding a line to the blurb at the > > last section (before the footer banner) of this page - > > https://getfedora.org/ - next to the gray/white globe graphic? > > > > Just trying to visualize the end result. > = > I think so. Seems to be associated with this issue: > https://pagure.io/fedora-web/websites/issue/215 > = > I'm not sure why it's that important to say this I'll try to provide a broader context to answer why I think it's important. The first aspect is legal and formal: we provide software and assets for do= wnload that are copyrighted by many many different authors, and those people make = those items available under some specific licenses. Those licenses are intended t= o allow free reuse, but they are not free-for-all "public domain" licenses. Thus to= avoid misrepresenting the permissions for our deliverables, we should provide some blurb that unambiguously links to a formal description that this is a colle= ctive work and that individual licenses need to be followed and where they can be= found. The second aspect is (I believe) a big missed marketing opportunity: not everyone who gets to our download page "lives and breathes" open source, and even if something is "free to download", for many people this is not immedi= ately what exactly this means. So I think we should provide a blurb that emphasiz= es freedom, but also allows people to dig deeper. (I think that somebody who stumbles upon getfedora.o should be able to learn at least a bit what open source is and I'd consider this part of the outreach to the wider community.) I think the current text on the website does a decent job, but the missing part is a hyperlink to further documents that would explain this in an accessible way. > but I guess it's > mostly worded okay, except that "the license of the Fedora project > itself" should be reworded since there is no license of the Fedora > project itself (in my view, anyway). There is a collective work > license -- the MIT license -- but I don't see that much value in > placing any emphasis on that. But if that is going to be referred to, > it should be "the license of the Fedora distribution itself", not the > more ambiguous "the license of the Fedora project itself". The text in the PR now is: {% trans trimmed %}It is a compilation of software packages, each under its own license. Images that can be downloaded here are available under the combination of licenses of the constituent software packages and the license of the Fedora Linux distribution itself. View License{% endtrans %} Zbyszek --===============0648434467991211971==-- From bcotton at redhat.com Thu Nov 11 16:46:14 2021 Content-Type: multipart/mixed; boundary="===============8250638708952399924==" MIME-Version: 1.0 From: Ben Cotton To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Thu, 11 Nov 2021 11:45:53 -0500 Message-ID: In-Reply-To: 20211103120845.873.88804@mailman01.iad2.fedoraproject.org --===============8250638708952399924== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Nov 3, 2021 at 8:10 AM Artur Frenszek-Iwicki wrote: > > I'm posting here because I'd like to confirm that the license is OK with = Fedora. > I have added this to the list[1] of Good Font licenses. You can use "MIT" as the identifier, as it's now on the list of MIT variants[2]. [1] https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses_4 [2] https://fedoraproject.org/wiki/Licensing:MIT#ttyp0_variant -- = Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=3DAmerica/Indiana/Indianapolis --===============8250638708952399924==-- From rfontana at redhat.com Thu Nov 11 16:53:32 2021 Content-Type: multipart/mixed; boundary="===============6537713679366238742==" MIME-Version: 1.0 From: Richard Fontana To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Thu, 11 Nov 2021 11:53:10 -0500 Message-ID: In-Reply-To: CA+voJeVpjgdhkMcayFMXrz1dxoBK4Aig1NEWPfBvsox+sTAdgg@mail.gmail.com --===============6537713679366238742== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2021 at 11:48 AM Ben Cotton wrote: > > On Wed, Nov 3, 2021 at 8:10 AM Artur Frenszek-Iwicki > wrote: > > > > I'm posting here because I'd like to confirm that the license is OK wit= h Fedora. > > > I have added this to the list[1] of Good Font licenses. You can use > "MIT" as the identifier, as it's now on the list of MIT variants[2]. > > [1] https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses_4 > [2] https://fedoraproject.org/wiki/Licensing:MIT#ttyp0_variant Sorry, I meant to reply to this earlier. I am not sure if this should be acceptable for Fedora. My concern is that the "UW" naming prohibition is unreasonably restrictive. Does anyone have thoughts on this? Richard --===============6537713679366238742==-- From bcotton at redhat.com Thu Nov 11 16:59:53 2021 Content-Type: multipart/mixed; boundary="===============4000293541463678129==" MIME-Version: 1.0 From: Ben Cotton To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Thu, 11 Nov 2021 11:59:33 -0500 Message-ID: In-Reply-To: CAC1cPGxEEA5yBV3LHdnfL09QcLKQTXjEEk2st-Dapv98s=btXg@mail.gmail.com --===============4000293541463678129== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2021 at 11:53 AM Richard Fontana wr= ote: > > I am not sure if this should be acceptable for Fedora. My concern is > that the "UW" naming prohibition is unreasonably restrictive. Does > anyone have thoughts on this? > I read it as being similar to section 6 of ASL 2.0: > 6. Trademarks. This License does not grant permission to use the trade na= mes, trademarks, service marks, or product names of the Licensor, except as= required for reasonable and customary use in describing the origin of the = Work and reproducing the content of the NOTICE file. -- = Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=3DAmerica/Indiana/Indianapolis --===============4000293541463678129==-- From rfontana at redhat.com Thu Nov 11 17:16:30 2021 Content-Type: multipart/mixed; boundary="===============1893568254792348033==" MIME-Version: 1.0 From: Richard Fontana To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Thu, 11 Nov 2021 12:16:13 -0500 Message-ID: In-Reply-To: CA+voJeV2VHx7z0uR9HRLoG9MTFs0bZBumx+8TzZiiWZOOxvprA@mail.gmail.com --===============1893568254792348033== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2021 at 11:59 AM Ben Cotton wrote: > > On Thu, Nov 11, 2021 at 11:53 AM Richard Fontana = wrote: > > > > I am not sure if this should be acceptable for Fedora. My concern is > > that the "UW" naming prohibition is unreasonably restrictive. Does > > anyone have thoughts on this? > > > I read it as being similar to section 6 of ASL 2.0: > > > 6. Trademarks. This License does not grant permission to use the trade = names, trademarks, service marks, or product names of the Licensor, except = as required for reasonable and customary use in describing the origin of th= e Work and reproducing the content of the NOTICE file. But this would be like the Apache License saying "derivative works can't have the consecutive letters 'AP' in their name". I'm not sure at what point such a restriction becomes problematic from a FLOSS standpoint but for example if it were one letter, like "U", that would obviously not be okay. Two letters doesn't seem too different. The closest parallel I'm aware of might be the PHP license, which Fedora (following the FSF's view) treats as free but GPL-incompatible. The main reason for the GPL incompatibility, I believe, is this naming restriction: "Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from group(a)php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"". Maybe that's the right call, as we've been assuming, but I wonder if a two-letter sequence restriction goes too far. It could be that the traditional view has been that any arbitrarily restrictive renaming provision is okay from a libre standpoint. I'm not sure why that should be correct though. Richard --===============1893568254792348033==-- From bcotton at redhat.com Thu Nov 11 17:48:41 2021 Content-Type: multipart/mixed; boundary="===============3303468505757123736==" MIME-Version: 1.0 From: Ben Cotton To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Thu, 11 Nov 2021 12:48:22 -0500 Message-ID: In-Reply-To: CAC1cPGzYMo3oaZRQy_K5s2Sot1sC-131On-YzukOUuZ=q0rRxg@mail.gmail.com --===============3303468505757123736== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2021 at 12:16 PM Richard Fontana wr= ote: > > But this would be like the Apache License saying "derivative works > can't have the consecutive letters 'AP' in their name". I disagree. First "uw" is how the foundry is identified. The Apache Software Foundation doesn't use "AP" to identify itself, as far as I've seen. Second, the word "word" is meaningful here. If the University of Washington, as an example, used "UWash-ttyp0" as the name, that wouldn't violate the restriction. In other words, it's not that the letters u and w appear consecutively, but they're used as a word. > It could be that the traditional view has been that any arbitrarily > restrictive renaming provision is okay from a libre standpoint. I'm > not sure why that should be correct though. > I'm not sure this is a well-explored area, but I think authors have a fundamental right to disclaim association with derivative works. Just as a license can require attribution, we should be able to require dis-attribution (for lack of a better term). So I'm inclined to accept most "you can make derivatives so long as you don't try to make it sound like it's from or endorsed by me" scenarios. Where I'd draw the line is more arbitrary restrictions. Like if GNOME had a license that restricted calling a derivative work "dwarf" because Merriam-Webster says they're synonyms. But saying "you can't call it 'GNOME-ish'" would be acceptable because it uses the word "GNOME". I'm not entirely sure that one-letter words are automatically out of bounds. I think there's some room for context. Like if I make a font called "c-font" that's part of a larger ecosystem of "c-*" packages, I think it's reasonable to say "you can't use 'c' alone in your derivative work" ("bc" would be fine, but "remade-c" wouldn't). On the other hand, if "c-font" is the only "c-" name package, then I agree that it's arbitrarily restrictive. I hope this makes sense. It's a philosophy I've not hitherto given a lot of explicit thought, so the explanation is probably a bit rough. Maybe it'll be a conference proposal at some point? -- = Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=3DAmerica/Indiana/Indianapolis --===============3303468505757123736==-- From j at tib.bs Thu Nov 11 18:00:24 2021 Content-Type: multipart/mixed; boundary="===============8726727341999188117==" MIME-Version: 1.0 From: Jason L Tibbitts III To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Thu, 11 Nov 2021 12:00:14 -0600 Message-ID: In-Reply-To: CAC1cPGxEEA5yBV3LHdnfL09QcLKQTXjEEk2st-Dapv98s=btXg@mail.gmail.com --===============8726727341999188117== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable >>>>> Richard Fontana writes: > I am not sure if this should be acceptable for Fedora. My concern is > that the "UW" naming prohibition is unreasonably restrictive. Does > anyone have thoughts on this? Naming can be difficult, but I believe we've long accepted clauses forcing renaming. A license saying "don't use our name in your new name" seems reasonable even if your name is just a few letters (like "IBM" or "UW"). It is technically restricting a freedom but not in any way that seems meaningful. Where I think it gets sticky is if a license were to prevent renaming, or maybe to specify the name to be used for modified versions. A more difficult corner case would be something like "must not start with the letter 'a'" or "must sort higher alphabetically". - J< --===============8726727341999188117==-- From rfontana at redhat.com Thu Nov 11 18:51:52 2021 Content-Type: multipart/mixed; boundary="===============0299221597013977914==" MIME-Version: 1.0 From: Richard Fontana To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Thu, 11 Nov 2021 13:51:34 -0500 Message-ID: In-Reply-To: CA+voJeVsG710R_XoD+0VSP0pe=FZ+twuAo-kEDtu2uDYNV=oeQ@mail.gmail.com --===============0299221597013977914== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2021 at 12:48 PM Ben Cotton wrote: > > On Thu, Nov 11, 2021 at 12:16 PM Richard Fontana = wrote: > > > > But this would be like the Apache License saying "derivative works > > can't have the consecutive letters 'AP' in their name". > > I disagree. First "uw" is how the foundry is identified. The Apache > Software Foundation doesn't use "AP" to identify itself, as far as > I've seen. Second, the word "word" is meaningful here. If the > University of Washington, as an example, used "UWash-ttyp0" as the > name, that wouldn't violate the restriction. In other words, it's not > that the letters u and w appear consecutively, but they're used as a > word. But that implies that a word can't contain another word, I think? "UWash" for example I would argue contains a number of words ("ash", "wash", "as", "a", for starters). Unless "word" has a special domain-specific meaning in the world of font foundry names (does it?) it is not clear to me that this developer would agree that "UWash" does not violate the restriction. > > It could be that the traditional view has been that any arbitrarily > > restrictive renaming provision is okay from a libre standpoint. I'm > > not sure why that should be correct though. > > > I'm not sure this is a well-explored area, but I think authors have a > fundamental right to disclaim association with derivative works. Just > as a license can require attribution, we should be able to require > dis-attribution (for lack of a better term). So I'm inclined to accept > most "you can make derivatives so long as you don't try to make it > sound like it's from or endorsed by me" scenarios. Where I'd draw the > line is more arbitrary restrictions. Like if GNOME had a license that > restricted calling a derivative work "dwarf" because Merriam-Webster > says they're synonyms. But saying "you can't call it 'GNOME-ish'" > would be acceptable because it uses the word "GNOME". > I'm not entirely sure that one-letter words are automatically out of > bounds. I think there's some room for context. Like if I make a font > called "c-font" that's part of a larger ecosystem of "c-*" packages, I > think it's reasonable to say "you can't use 'c' alone in your > derivative work" ("bc" would be fine, but "remade-c" wouldn't). On the > other hand, if "c-font" is the only "c-" name package, then I agree > that it's arbitrarily restrictive. So then maybe the question is what does "word" mean in this license? If it has the narrow meaning that you are assuming, then maybe it is okay. I'm not sure. Worth noting also, in FLOSS historically some restrictions have been tolerated in font licenses that weren't considered libre in software licenses. This is probably one of the reasons why Fedora, for example, has a separate category for acceptable font licenses. (Example: SIL OFL vs. SunRPC.) But that's not especially for some sort of admirable reason. It's because the community chose to "look the other way" out of a strong desire to see sort-of-free-ish fonts get released, as Dave Crossland explained to me a long time ago. Richard --===============0299221597013977914==-- From bcotton at redhat.com Thu Nov 11 19:59:07 2021 Content-Type: multipart/mixed; boundary="===============8678319252261758464==" MIME-Version: 1.0 From: Ben Cotton To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Thu, 11 Nov 2021 14:58:48 -0500 Message-ID: In-Reply-To: CAC1cPGzjhXzb50ZZzQpQYAkQZLGbTeT+csARJDzyUNh4=SaZbg@mail.gmail.com --===============8678319252261758464== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2021 at 1:51 PM Richard Fontana wro= te: > > But that implies that a word can't contain another word, I think? > Now we're having fun! > "UWash" for example I would argue contains a number of words ("ash", > "wash", "as", "a", for starters). Unless "word" has a special > domain-specific meaning in the world of font foundry names (does it?) > it is not clear to me that this developer would agree that "UWash" > does not violate the restriction. > The most reasonable interpretation in my view is that the context matters. So a word that is a variation of the form would be the same "word" for the purposes of the licence. For example, "ash" and "ashen". But if it's a string that happens to appear in another, unrelated word, they are separate words. For example, "ash" and "wash". In my original example, the fact that "UWash" is a name the University of Washington uses supports the "it's not the same word" argument. If I were to name a font "uwash-ttyp0", the "they're separate words" case is weaker, but not a slam dunk. I don't think you're arguing against the general concept (e.g. ASL 2.0 section 6), so the question is really "what's the minimum length?" If General Electric released software under ASL 2.0 (replacing "Apache" with "General Electric"), section 6 would preclude using "GE" in the name of a derivative as that is a trademark of General Electric. So I think we have to be okay with two-letter names if we're okay with ASL, don't we? Similarly, calling a derivative work "stoneage", while it contains the consecutive letters "g" and "e", seems obviously acceptable under ASL 2.0 section 6. I understand the philosophical issue with restricting renaming generally. But I think if we go down that road, that represents a significant policy shift from our past practice. -- = Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=3DAmerica/Indiana/Indianapolis --===============8678319252261758464==-- From rfontana at redhat.com Fri Nov 12 05:01:32 2021 Content-Type: multipart/mixed; boundary="===============4972811549912855273==" MIME-Version: 1.0 From: Richard Fontana To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Thu, 11 Nov 2021 23:35:43 -0500 Message-ID: In-Reply-To: CA+voJeXvrca2azxcUTcCmuFOpTNpB0vTpdh8i7JwzfwZvOTD=Q@mail.gmail.com --===============4972811549912855273== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2021 at 2:59 PM Ben Cotton wrote: > > On Thu, Nov 11, 2021 at 1:51 PM Richard Fontana w= rote: > > > > But that implies that a word can't contain another word, I think? > > > Now we're having fun! > > > "UWash" for example I would argue contains a number of words ("ash", > > "wash", "as", "a", for starters). Unless "word" has a special > > domain-specific meaning in the world of font foundry names (does it?) > > it is not clear to me that this developer would agree that "UWash" > > does not violate the restriction. > > > The most reasonable interpretation in my view is that the context > matters. So a word that is a variation of the form would be the same > "word" for the purposes of the licence. For example, "ash" and > "ashen". But if it's a string that happens to appear in another, > unrelated word, they are separate words. For example, "ash" and > "wash". In my original example, the fact that "UWash" is a name the > University of Washington uses supports the "it's not the same word" > argument. If I were to name a font "uwash-ttyp0", the "they're > separate words" case is weaker, but not a slam dunk. > > I don't think you're arguing against the general concept (e.g. ASL 2.0 > section 6), so the question is really "what's the minimum length?" If > General Electric released software under ASL 2.0 (replacing "Apache" > with "General Electric"), section 6 would preclude using "GE" in the > name of a derivative as that is a trademark of General Electric. So I > think we have to be okay with two-letter names if we're okay with ASL, > don't we? Similarly, calling a derivative work "stoneage", while it > contains the consecutive letters "g" and "e", seems obviously > acceptable under ASL 2.0 section 6. > > I understand the philosophical issue with restricting renaming > generally. But I think if we go down that road, that represents a > significant policy shift from our past practice. OK, well I withdraw my objections to treating this as an acceptable Fedora license for fonts. I reserve the right to complain about a similar future non-font-oriented license. :-) Richard --===============4972811549912855273==-- From jlovejoy at redhat.com Fri Nov 12 16:52:45 2021 Content-Type: multipart/mixed; boundary="===============8319989003216688555==" MIME-Version: 1.0 From: Jilayne Lovejoy To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Fri, 12 Nov 2021 09:52:35 -0700 Message-ID: In-Reply-To: CAC1cPGy97-iTxgAvQTb-kshpYr+gcEtU8tZK=mufi1FuchDzEg@mail.gmail.com --===============8319989003216688555== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 11/11/21 9:35 PM, Richard Fontana wrote: > On Thu, Nov 11, 2021 at 2:59 PM Ben Cotton wrote: >> On Thu, Nov 11, 2021 at 1:51 PM Richard Fontana = wrote: >>> But that implies that a word can't contain another word, I think? >>> >> Now we're having fun! >> >>> "UWash" for example I would argue contains a number of words ("ash", >>> "wash", "as", "a", for starters). Unless "word" has a special >>> domain-specific meaning in the world of font foundry names (does it?) >>> it is not clear to me that this developer would agree that "UWash" >>> does not violate the restriction. >>> >> The most reasonable interpretation in my view is that the context >> matters. So a word that is a variation of the form would be the same >> "word" for the purposes of the licence. For example, "ash" and >> "ashen". But if it's a string that happens to appear in another, >> unrelated word, they are separate words. For example, "ash" and >> "wash". In my original example, the fact that "UWash" is a name the >> University of Washington uses supports the "it's not the same word" >> argument. If I were to name a font "uwash-ttyp0", the "they're >> separate words" case is weaker, but not a slam dunk. >> >> I don't think you're arguing against the general concept (e.g. ASL 2.0 >> section 6), so the question is really "what's the minimum length?" If >> General Electric released software under ASL 2.0 (replacing "Apache" >> with "General Electric"), section 6 would preclude using "GE" in the >> name of a derivative as that is a trademark of General Electric. So I >> think we have to be okay with two-letter names if we're okay with ASL, >> don't we? Similarly, calling a derivative work "stoneage", while it >> contains the consecutive letters "g" and "e", seems obviously >> acceptable under ASL 2.0 section 6. >> >> I understand the philosophical issue with restricting renaming >> generally. But I think if we go down that road, that represents a >> significant policy shift from our past practice. > OK, well I withdraw my objections to treating this as an acceptable > Fedora license for fonts. I reserve the right to complain about a > similar future non-font-oriented license. :-) > Since you both are having so much fun... here's my two cents ;) I agree this is ok for Fedora, but I also understand Richard's initial = hesitation re: the naming issue. I think the distinction is that - the clause in Apache 2.0 is explicitly consistent with trademark law. - whereas, this license sort of goes a step further and gives = instructions on how to change the name enough to avoid a "likelihood of = confusion" for the consumer (the standard for trademark infringement) Stating you must rename a modified version (or derivative work) is = pretty common, but generally still considered free/open as it is merely = reflecting the reality of trademark law (at least that's they way I = think of it). Explaining how to rename it - goes a step further, which could be seen = as too far, but in this case, it seems pretty reasonable. I think the line gets crossed (and may be where Richard is reserving his = right to complain) when a license actually requires the use of a = specific name in a specific scenario, so-called "badgeware" licenses. = Pam Chestek did a great talk on this at FOSDEM 2014, if anyone is = interested :) https://archive.fosdem.org/2014/schedule/event/trademark_licenses/ Cheers, Jilayne --===============8319989003216688555==-- From mattdm at fedoraproject.org Sat Nov 13 21:55:52 2021 Content-Type: multipart/mixed; boundary="===============1940113612555702350==" MIME-Version: 1.0 From: Matthew Miller To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Sat, 13 Nov 2021 16:55:45 -0500 Message-ID: <20211113215545.GA28652@mattdm.org> In-Reply-To: CA+voJeVsG710R_XoD+0VSP0pe=FZ+twuAo-kEDtu2uDYNV=oeQ@mail.gmail.com --===============1940113612555702350== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2021 at 12:48:22PM -0500, Ben Cotton wrote: > restricted calling a derivative work "dwarf" because Merriam-Webster > says they're synonyms. But saying "you can't call it 'GNOME-ish'" > would be acceptable because it uses the word "GNOME". Ooh. I was with you right up until this example. To me, "GNOME-ish" means "reminiscent of GNOME but not GNOME", which seems like the kind of thing that _should_ be allowed. GNOME-erific or GNOME-improved or even GNOME-fork, yeah, I see. But I'd hate to see open source licenses getting into "that big foot-race that happens to be in capital of Massachusetts every year" or "I guess we'll just all say Superb Owl" territory. -- = Matthew Miller Fedora Project Leader --===============1940113612555702350==-- From reto.gantenbein at linuxmonk.ch Sun Nov 14 12:08:34 2021 Content-Type: multipart/mixed; boundary="===============0191083596915393353==" MIME-Version: 1.0 From: Reto Gantenbein To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Approval of license exception for new Fedora packages: raft/dqlite Date: Sun, 14 Nov 2021 13:08:25 +0100 Message-ID: <2f8b328a8d89e47cc26a2a59c1c50609e2a4f10d.camel@linuxmonk.ch> --===============0191083596915393353== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi everyone I'm in the course of adding two new packages raft [1] (sources: [2]) and dqlite [3] (sources: [4]) to Fedora. According to the LICENSE files [5][6] I would choose the Fedora license short name "LGPLv3 with exception" for these packages. The exception goes as following: "As a special exception to the GNU Lesser General Public License version 3 ("LGPL3"), the copyright holders of this Library give you permission to convey to a third party a Combined Work that links statically or dynamically to this Library without providing any Minimal Corresponding Source or Minimal Application Code as set out in 4d or providing the installation information set out in section 4e, provided that you comply with the other provisions of LGPL3 and provided that you meet, for the Application the terms and conditions of the license(s) which apply to the Application. Except as stated in this special exception, the provisions of LGPL3 will continue to comply in full to this Library. If you modify this Library, you may apply this exception to your version of this Library, but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version. This exception does not (and cannot) modify any license terms which apply to the Application, with which you must still comply." According to the rules that I found in the documentation [7] I'm asking you for approval of this exception. Kind regards and cheers, Reto = [1]: https://bugzilla.redhat.com/show_bug.cgi?id=3D2017459 [2]: https://github.com/canonical/raft [3]: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D2017476 [4]: https://github.com/canonical/dqlite [5]: https://github.com/canonical/raft/blob/v0.11.2/LICENSE [6]: https://github.com/canonical/dqlite/blob/v1.9.0/LICENSE [7]: https://fedoraproject.org/wiki/Licensing:Main?rd=3DLicensing#Software_Licen= se_List --===============0191083596915393353==-- From rfontana at redhat.com Sun Nov 14 17:00:11 2021 Content-Type: multipart/mixed; boundary="===============6166147711817892868==" MIME-Version: 1.0 From: Richard Fontana To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: ttyp0 font license Date: Sun, 14 Nov 2021 11:59:54 -0500 Message-ID: In-Reply-To: dc5fced9-ffb7-9acf-29c7-c0927886d96b@redhat.com --===============6166147711817892868== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, Nov 12, 2021 at 11:52 AM Jilayne Lovejoy wr= ote: > > > > On 11/11/21 9:35 PM, Richard Fontana wrote: > > On Thu, Nov 11, 2021 at 2:59 PM Ben Cotton wrote: > >> I understand the philosophical issue with restricting renaming > >> generally. But I think if we go down that road, that represents a > >> significant policy shift from our past practice. > > OK, well I withdraw my objections to treating this as an acceptable > > Fedora license for fonts. I reserve the right to complain about a > > similar future non-font-oriented license. :-) > > > Since you both are having so much fun... here's my two cents ;) > > I agree this is ok for Fedora, but I also understand Richard's initial > hesitation re: the naming issue. > > I think the distinction is that > - the clause in Apache 2.0 is explicitly consistent with trademark law. > - whereas, this license sort of goes a step further and gives > instructions on how to change the name enough to avoid a "likelihood of > confusion" for the consumer (the standard for trademark infringement) > > Stating you must rename a modified version (or derivative work) is > pretty common, but generally still considered free/open as it is merely > reflecting the reality of trademark law (at least that's they way I > think of it). As I see it, there are plausibly-FLOSS licenses that attempt to contractualize/non-trademark-intellectual-property-license-ize policy concerns that have been traditionally associated with trademark law. This is not categorically problematic. For example the OSD says "The license may require derived works to carry a different name or version number from the original software" and broadly speaking that seems to be a correct distillation of how the community has looked at this issue. But the question for me is how far or how much further can such a license provision go than what we assume is the background trademark law default for there to be a concern that the license is now too restrictive to be considered free/open source. I don't believe there is *no* such point at which a line is crossed. I think what makes me accept this license with some misgivings is (a) Ben's interpretation which is narrower than the one I initially had, and (b) it's a font license and there's a mostly unacknowledged lower standard applied to font licenses. So if this same provision appeared in a software license I am not sure it should be acceptable. Richard --===============6166147711817892868==-- From dulsi at identicalsoftware.com Thu Nov 18 13:57:33 2021 Content-Type: multipart/mixed; boundary="===============6899581305803998466==" MIME-Version: 1.0 From: Dennis Payne To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Bytepath packaging question Date: Thu, 18 Nov 2021 08:57:26 -0500 Message-ID: <739df56efb686f63269572952ebddb218d44d58f.camel@identicalsoftware.com> --===============6899581305803998466== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Bytepath is a commercial game which has been released open source. I=E2=80= =99ve avoided packaging commercial games since that might decrease sales. However the official release requires love 10.2 and can=E2=80=99t be run directly from steam. I forked the code to make it run on love 11. Do you think packaging it for Fedora is a good idea? I=E2=80=99ve tracked down= the license for some of the sound files but I don=E2=80=99t know the source for most. I don=E2=80=99t doubt that the creator followed the license requireme= nt but can=E2=80=99t confirm. I=E2=80=99ve debated replacing all the sounds. -- = Dennis Payne dulsi(a)identicalsoftware.com https://mastodon.gamedev.place/@dulsi --===============6899581305803998466==-- From foss at jwf.io Sun Nov 21 23:41:25 2021 Content-Type: multipart/mixed; boundary="===============8389071585938313020==" MIME-Version: 1.0 From: foss at jwf.io To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: Bytepath packaging question Date: Sun, 21 Nov 2021 23:41:11 +0000 Message-ID: In-Reply-To: 739df56efb686f63269572952ebddb218d44d58f.camel@identicalsoftware.com --===============8389071585938313020== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Dennis, On 11/18/21 14:57, Dennis Payne wrote: > Bytepath is a commercial game which has been released open source. I=E2= =80=99ve > avoided packaging commercial games since that might decrease sales. > However the official release requires love 10.2 and can=E2=80=99t be run > directly from steam. I forked the code to make it run on love 11. Do > you think packaging it for Fedora is a good idea? I=E2=80=99ve tracked do= wn the > license for some of the sound files but I don=E2=80=99t know the source f= or > most. I don=E2=80=99t doubt that the creator followed the license require= ment > but can=E2=80=99t confirm. I=E2=80=99ve debated replacing all the sounds. > = Do you have a link to the original and forked repositories in question? = This might help to clarify since it sounds like an unusual situation. -- = Cheers, Justin W. Flory (he/him) https://jwf.io TZ=3DEurope/Tirane --===============8389071585938313020== Content-Type: application/pgp-keys MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey-fossjwf.io-570e854f.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCkNvbW1lbnQ6IGh0dHBzOi8vZ29w ZW5wZ3Aub3JnClZlcnNpb246IEdvcGVuUEdQIDIuMi4yCgp4ak1FWGdLRVVCWUpLd1lCQkFIYVJ3 OEJBUWRBZHB5SGR4aG9xMFo4bEdpci8xbFNISHdoSDNDb3hKY2FQbFBPCldRSDFQUkxOR1dadmMz TkFhbmRtTG1sdklEeG1iM056UUdwM1ppNXBiejdDZHdRUUZnb0FId1VDWGdLRVVBWUwKQ1FjSUF3 SUVGUWdLQWdNV0FnRUNHUUVDR3dNQ0hnRUFDZ2tRRnJYRmwxUFdac0M0WmdEK0tDSFo3YWU0b2Rw RQpRbWRCTVUvVmRJcGtlSzNsUGY2MVJ2NklkLzBXMVh3QkFKVE9VTHpPd0pkZlVpK3Y2R0pmcWhE UFRjQXR5U3p3Cm42N2g5eTlNWFdVTHpqZ0VYZ0tFVUJJS0t3WUJCQUdYVlFFRkFRRUhRT3VPVGVS WU8wNGowV0t5SFp2YWlSdEcKQXhaaEllSDdublA4TlFySUpoZzdBd0VJQjhKaEJCZ1dDQUFKQlFK ZUFvUlFBaHNNQUFvSkVCYTF4WmRUMW1iQQpZYXNCQUxQWDVlMzR3cHVjL2VWWFRLVlJSK2dRUDNS TWRQNE51bDJGTWN4S0FFNjZBUDR3TCtEbDZlY3dJVUFuCndBcit4WFVteUNGUGtYZ1VkNmszM2w1 cTN5SUZBZz09Cj1yWW9ZCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0= --===============8389071585938313020== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogUHJvdG9uTWFpbAoKd25VRUFS WUlBQ2NGQW1HYTJSWUprQmExeFpkVDFtYkFGcUVFVnc2RlQxcC9uT0dyNmd4WUZyWEZsMVBXClpz QUFBQWY2QVA5V2puUURRbEltVlcyZVp5bWhLRm56RG5EM3NMQUVRMnkvdXlnSWppZE13d0QrSURR YQpnVjJxcHhiclJoOTBCcEJNMmNpZmYzRWRSMnUyVjJheExpN0pyQTQ9Cj1FVFo5Ci0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQoK --===============8389071585938313020==-- From dulsi at identicalsoftware.com Mon Nov 22 00:21:56 2021 Content-Type: multipart/mixed; boundary="===============5723893200001612777==" MIME-Version: 1.0 From: Dennis Payne To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: Bytepath packaging question Date: Sun, 21 Nov 2021 19:21:48 -0500 Message-ID: <4475ee3339c3eb753bf7b817ce05a18fb1b26c04.camel@identicalsoftware.com> In-Reply-To: b3ee7c12-e4d0-50b1-8b27-846170bdf996@jwf.io --===============5723893200001612777== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Mine: https://github.com/dulsi/BYTEPATH/ Original: https://github.com/a327ex/BYTEPATH On Sun, 2021-11-21 at 23:41 +0000, foss(a)jwf.io wrote: > Hi Dennis, > = > On 11/18/21 14:57, Dennis Payne wrote: > > Bytepath is a commercial game which has been released open source. > > I=E2=80=99ve > > avoided packaging commercial games since that might decrease sales. > > However the official release requires love 10.2 and can=E2=80=99t be run > > directly from steam. I forked the code to make it run on love 11. Do > > you think packaging it for Fedora is a good idea? I=E2=80=99ve tracked = down > > the > > license for some of the sound files but I don=E2=80=99t know the source= for > > most. I don=E2=80=99t doubt that the creator followed the license requi= rement > > but can=E2=80=99t confirm. I=E2=80=99ve debated replacing all the sound= s. > > = > = > Do you have a link to the original and forked repositories in question? > This might help to clarify since it sounds like an unusual situation. > = > -- = > Cheers, > Justin W. Flory (he/him) > https://jwf.io > TZ=3DEurope/Tirane > _______________________________________________ > legal mailing list -- legal(a)lists.fedoraproject.org > To unsubscribe send an email to legal-leave(a)lists.fedoraproject.org > 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(a)lists.fedoraproject= .org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure --===============5723893200001612777==-- From reto.gantenbein at linuxmonk.ch Mon Nov 22 22:27:46 2021 Content-Type: multipart/mixed; boundary="===============2429190158050761690==" MIME-Version: 1.0 From: Reto Gantenbein To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: Approval of license exception for new Fedora packages: raft/dqlite Date: Mon, 22 Nov 2021 23:27:39 +0100 Message-ID: In-Reply-To: 2f8b328a8d89e47cc26a2a59c1c50609e2a4f10d.camel@linuxmonk.ch --===============2429190158050761690== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi everybody On Sun, 2021-11-14 at 13:08 +0100, Reto Gantenbein wrote: > According to the rules that I found in the documentation [7] I'm > asking > you for approval of this exception. Could anyone have a look at it please? I'm kind of blocked with uploading the software to the Fedora servers if I don't get any feedback. Any response is appreciated. Cheers, Reto --===============2429190158050761690==-- From rfontana at redhat.com Tue Nov 23 00:14:14 2021 Content-Type: multipart/mixed; boundary="===============8086032048287650765==" MIME-Version: 1.0 From: Richard Fontana To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: Approval of license exception for new Fedora packages: raft/dqlite Date: Mon, 22 Nov 2021 19:13:55 -0500 Message-ID: In-Reply-To: f321449dda4cd6dc61f9138de6369e5b0c31583b.camel@linuxmonk.ch --===============8086032048287650765== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Nov 22, 2021 at 5:29 PM Reto Gantenbein wrote: > > Hi everybody > > On Sun, 2021-11-14 at 13:08 +0100, Reto Gantenbein wrote: > > According to the rules that I found in the documentation [7] I'm > > asking > > you for approval of this exception. > > Could anyone have a look at it please? I'm kind of blocked with > uploading the software to the Fedora servers if I don't get any > feedback. > > Any response is appreciated. IMO this exception is okay for Fedora. Incidentally this exception seems to be identical to what SPDX calls LGPL-3.0-linking-exception (https://spdx.org/licenses/LGPL-3.0-linking-exception.html). Richard --===============8086032048287650765==-- From besser82 at fedoraproject.org Tue Nov 23 00:29:03 2021 Content-Type: multipart/mixed; boundary="===============8309168850664947851==" MIME-Version: 1.0 From: =?utf-8?q?Bj=C3=B6rn_=27besser82=27_Esser_=3Cbesser82_at_fedoraproject=2E?= =?utf-8?q?org=3E?= To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: Brainpool Curves in Fedora (openssl, libgcrypt, gnupg) Date: Tue, 23 Nov 2021 01:28:48 +0100 Message-ID: In-Reply-To: 20211018170225.GA1888@mattdm.org --===============8309168850664947851== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Am Montag, dem 18.10.2021 um 13:02 -0400 schrieb Matthew Miller: > On Sun, Oct 17, 2021 at 12:25:52PM +0200, Felix Schwarz wrote: > > = > > Here you go: > > https://fachportal.gematik.de/fachportal-import/files/gemSpec_Krypt_V2.= 18.0.pdf > > = > > I'd like to mention that this document is not just authoritative for > > digital prescriptions but also other - maybe even more important - > > use cases related to the German health care system: > > - eAU https://www.kbv.de/html/e-au.php > > - ePA=C2=A0 (electronic patient records): https://www.kbv.de/html/epa.p= hp > = > Thanks both of you -- I'll forward these on and see if it helps. Hello Matthew, did our information help? What's the status? Thanks, Bj=C3=B6rn --===============8309168850664947851== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ0FBZEZpRUVaNHpqL3VRd01S V1cyNHdXOVM2WUFIV1V3aDBGQW1HY05jRUFDZ2tROVM2WUFIV1UKd2gwdzBRLytQc2FHcDB2eldw UzU2Vi9VTk5mN3ZJNU0wV3l6RkdOaXVqWkZ5T1BFZXprNndMR09UVHBhT3VXTwp3dFRoYXE5MlVC T0dsTEFqRmdOMWFwYUt3QUhlUFNaTm5BZ2JDU0RtbEFQSElMM3RvclhOQit2M1I4TkFwVnlTCkRs RnN0Qm1HSDVTWWVCY2ZFNlRwZmMzY3RpZlpGTGdJRFg5ZzBMb3E5bDVxWERmQjhaYXlOWmVEZUhl N1ZIQ1kKY0t2eWRlRi9vMzg5N2d3NEVpRUlxQndyc1FneVJ5THVBb0h0Uk5VNWppUSttdTRxYXkx d2hvMEtRMTRqWjF3Lwo3VVQ4R2YrNGZ3NS9kaXRCbDkwamZ5dFhDRFEwRmFZOFl2L0dSaFJHeHR4 MGlQcVF0VU9xNlVzc2FCUCtBT2Q2CmN1UU1oUzNyQnJEMmlOckpEMC90VHJ2aThKQWVzQ1VKTWpu eUtHMTlaOThVWm1VdURDREFZdWs2Y0NwTGIyNmIKclRzWUFOMnhmem9UTlF2UE9maHRFdkJEL293 ME1LZUsrYTB3V3hlMmI2cm1CZ1VuOGRTUVpKcG1UMklPQWlRawpndUZleHNiVFNQekY4d092aHhT a3NOWUE2c2xQbGx2RTkvYy9TaUlRbit1WThUTlpFVjVENDBHbUhnZkQrbTF0CnBGRWlhVVNZamZZ amt5VHVTOStTVVo0QWEzNEFIN2I2ekJwWk9MenFuMkZXZ3Nyc1dscDQ5WERmVENiVkdEM24KcTlt ZWhvNWF3R1g3WXZQSlZza1c3cWdBT2QxckxLUTlhK2JSRzBBVVB6VG96ekt2b0t0dmtrZ0Q5MEFG bUQzVwpSRHpIL0ZMM25lK2FzVE9USGh3Ym9jSGw3UjljKzFUano2VVdWK1BRWnE0VGh0dkloOFU9 Cj1NK0U0Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============8309168850664947851==-- From jlovejoy at redhat.com Wed Nov 24 19:09:54 2021 Content-Type: multipart/mixed; boundary="===============5213626154861299351==" MIME-Version: 1.0 From: Jilayne Lovejoy To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: Approval of license exception for new Fedora packages: raft/dqlite Date: Wed, 24 Nov 2021 12:09:41 -0700 Message-ID: <0a7c8000-4f1a-9568-fa73-e148b41f72a2@redhat.com> In-Reply-To: CAC1cPGzRGnhw0BN_seKMHKndpQR4-EysZ8MH06MfwLsjCZHh7A@mail.gmail.com --===============5213626154861299351== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 11/22/21 5:13 PM, Richard Fontana wrote: > On Mon, Nov 22, 2021 at 5:29 PM Reto Gantenbein > wrote: >> Hi everybody >> >> On Sun, 2021-11-14 at 13:08 +0100, Reto Gantenbein wrote: >>> According to the rules that I found in the documentation [7] I'm >>> asking >>> you for approval of this exception. >> Could anyone have a look at it please? I'm kind of blocked with >> uploading the software to the Fedora servers if I don't get any >> feedback. >> >> Any response is appreciated. > IMO this exception is okay for Fedora. > > Incidentally this exception seems to be identical to what SPDX calls > LGPL-3.0-linking-exception > (https://spdx.org/licenses/LGPL-3.0-linking-exception.html). > That is correct. The SPDX license expression would be either: =C2=A0=C2=A0 LGPL-3.0-or-later WITH LGPL-3.0-linking-exception or =C2=A0=C2=A0 LGPL-3.0-only WITH LGPL-3.0-linking-exception Unfortunately, the project doesn't seem to specify if it's LGPL-3.0 = "only" or "or later" (a difference that is not distinct at this point in = time, but bad practice to not specify in any case). I have filed an = issue in hopes they can fix that: = https://github.com/canonical/raft/issues/252 Jilayne --===============5213626154861299351==-- From jlovejoy at redhat.com Wed Dec 1 00:35:36 2021 Content-Type: multipart/mixed; boundary="===============1057981780869943595==" MIME-Version: 1.0 From: Jilayne Lovejoy To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: Approval of license exception for new Fedora packages: raft/dqlite Date: Tue, 30 Nov 2021 17:35:26 -0700 Message-ID: <17d0bd02-5708-d9bf-8030-9da30e7b4351@redhat.com> In-Reply-To: 0a7c8000-4f1a-9568-fa73-e148b41f72a2@redhat.com --===============1057981780869943595== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 11/24/21 12:09 PM, Jilayne Lovejoy wrote: > > > On 11/22/21 5:13 PM, Richard Fontana wrote: >> On Mon, Nov 22, 2021 at 5:29 PM Reto Gantenbein >> wrote: >>> Hi everybody >>> >>> On Sun, 2021-11-14 at 13:08 +0100, Reto Gantenbein wrote: >>>> According to the rules that I found in the documentation [7] I'm >>>> asking >>>> you for approval of this exception. >>> Could anyone have a look at it please? I'm kind of blocked with >>> uploading the software to the Fedora servers if I don't get any >>> feedback. >>> >>> Any response is appreciated. >> IMO this exception is okay for Fedora. >> >> Incidentally this exception seems to be identical to what SPDX calls >> LGPL-3.0-linking-exception >> (https://spdx.org/licenses/LGPL-3.0-linking-exception.html). >> > That is correct. The SPDX license expression would be either: > =C2=A0=C2=A0 LGPL-3.0-or-later WITH LGPL-3.0-linking-exception > or > =C2=A0=C2=A0 LGPL-3.0-only WITH LGPL-3.0-linking-exception > > Unfortunately, the project doesn't seem to specify if it's LGPL-3.0 = > "only" or "or later" (a difference that is not distinct at this point = > in time, but bad practice to not specify in any case). I have filed an = > issue in hopes they can fix that: = > https://github.com/canonical/raft/issues/252 > Fixed! it's LGPL-3.0-only WITH LGPL-3.0-linking-exception see LGPL-3.0-only WITH LGPL-3.0-linking-exception :) Jilayne --===============1057981780869943595==-- From reto.gantenbein at linuxmonk.ch Thu Dec 2 06:52:26 2021 Content-Type: multipart/mixed; boundary="===============4242309463602887805==" MIME-Version: 1.0 From: Reto Gantenbein To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: Approval of license exception for new Fedora packages: raft/dqlite Date: Thu, 02 Dec 2021 07:52:18 +0100 Message-ID: <53e0d17f6b5e74cc12d085b075705840cd4bf3ba.camel@linuxmonk.ch> In-Reply-To: 17d0bd02-5708-d9bf-8030-9da30e7b4351@redhat.com --===============4242309463602887805== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Jilayne On Tue, 2021-11-30 at 17:35 -0700, Jilayne Lovejoy wrote: > Fixed! it's LGPL-3.0-only WITH LGPL-3.0-linking-exception > see LGPL-3.0-only WITH LGPL-3.0-linking-exception > = That's great. Thanks a lot for your effort. Cheers, Reto --===============4242309463602887805==-- From cglombek at redhat.com Thu Dec 2 23:25:07 2021 Content-Type: multipart/mixed; boundary="===============1835039275282272137==" MIME-Version: 1.0 From: Christian Glombek To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Re: Brainpool Curves in Fedora (openssl, libgcrypt, gnupg) Date: Fri, 03 Dec 2021 00:24:47 +0100 Message-ID: In-Reply-To: c6dc7c3a1dfdb338599dbaedb5d6d71354770465.camel@fedoraproject.org --===============1835039275282272137== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I'm hitting this problem as well with the German ID (eAU), see BZ: https://bugzilla.redhat.com/show_bug.cgi?id=3D2000306 Some BSI tech guidelines relating to ECCs are actually available in english, too, e.g.: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidel= ines/TR03111/BSI-TR-03111_V-2-0_pdf.pdf?__blob=3DpublicationFile https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidel= ines/TR03116/BSI-TR-03116-TS_v1.pdf?__blob=3DpublicationFile&v=3D1 Quoting from the former doc: > 1.1. Patents and side-channel attacks > In implementations, patents and side-channel attacks play an important ro= le. > The algorithms described in this guideline have been carefully selected t= o allow patent-free > and/or license-free implementations. Nevertheless, some of the described = algorithms or its par- > ticular implementations may be subject of patent rights. The BSI shall no= t be held responsible > for identifying any or all such patent rights. > Implementors and security evaluators shall also pay attention to [6], whi= ch gives a general > guidance to assess the side-channel resistance of implementations on smar= tcards There is more anecdotal evidence e.g. here by ARM Mbed: https://tls.mbed.org/kb/cryptography/elliptic-curve-performance-nist-vs-bra= inpool Quote: Can you optimize Brainpool curves to be as fast as the NIST curves? > > Unfortunately, this is not possible. The design decision for Brainpool to > use random primes was aimed at: > > - avoiding possible patent issues with fast reduction algorithms > - avoiding potential security issues with non-random primes > > Nitrokey docs also show using Brainpool curves in their docs: https://docs.nitrokey.com/pro/linux/ecc.html > [...] A suitable version of GnuPG is included in the GNU/Linux distributions Ubuntu (since 18.04), Debian (from Stretch onwards), > Arch Linux, Fedora (from Release 26 onwards) and openSUSE Tumbleweed [...] They apparently haven't tested their guide on Fedora in a while ;) All of the above makes it look to me as though Brainpool curves were specifically designed to NOT touch on any patents. I'd be curious if any other of the big distros exclude the Brainpool curves too. On the linked BZ it was stated that Xubuntu includes them. It would be great if the current exclusion of those curves would be reevaluated. Thanks, Christian --===============1835039275282272137== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGRpdiBkaXI9Imx0ciI+PGRpdiBkaXI9Imx0ciI+PGRpdiBpZD0iZ21haWwtOjNsIiBjbGFzcz0i Z21haWwtQXIgZ21haWwtQXUgZ21haWwtQW8iIHN0eWxlPSJkaXNwbGF5OmJsb2NrIj48ZGl2IGlk PSJnbWFpbC06ZHAiIGNsYXNzPSJnbWFpbC1BbSBnbWFpbC1BbCBlZGl0YWJsZSBnbWFpbC1MVy1h dmYgZ21haWwtdFMtdFcgZ21haWwtdFMtdFkiIGFyaWEtbGFiZWw9Ik1lc3NhZ2UgQm9keSIgcm9s ZT0idGV4dGJveCIgYXJpYS1tdWx0aWxpbmU9InRydWUiIHN0eWxlPSJkaXJlY3Rpb246bHRyO21p bi1oZWlnaHQ6ODVweCIgdGFiaW5kZXg9IjEiPjxkaXY+SSYjMzk7bSBoaXR0aW5nIHRoaXMgcHJv YmxlbSBhcyB3ZWxsIHdpdGggdGhlIEdlcm1hbiBJRCAoZUFVKSwgc2VlIEJaOiA8YSBocmVmPSJo dHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19idWcuY2dpP2lkPTIwMDAzMDYiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19idWcuY2dpP2lkPTIw MDAzMDY8L2E+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Tb21lIEJTSSB0ZWNoIGd1aWRlbGlu ZXMgcmVsYXRpbmcgdG8gRUNDcyBhcmUgYWN0dWFsbHkgYXZhaWxhYmxlIGluIGVuZ2xpc2gsIHRv bywgZS5nLjo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmJz aS5idW5kLmRlL1NoYXJlZERvY3MvRG93bmxvYWRzL0VOL0JTSS9QdWJsaWNhdGlvbnMvVGVjaEd1 aWRlbGluZXMvVFIwMzExMS9CU0ktVFItMDMxMTFfVi0yLTBfcGRmLnBkZj9fX2Jsb2I9cHVibGlj YXRpb25GaWxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuYnNpLmJ1bmQuZGUvU2hhcmVk RG9jcy9Eb3dubG9hZHMvRU4vQlNJL1B1YmxpY2F0aW9ucy9UZWNoR3VpZGVsaW5lcy9UUjAzMTEx L0JTSS1UUi0wMzExMV9WLTItMF9wZGYucGRmP19fYmxvYj1wdWJsaWNhdGlvbkZpbGU8L2E+PC9k aXY+PGRpdj48YSBocmVmPSJodHRwczovL3d3dy5ic2kuYnVuZC5kZS9TaGFyZWREb2NzL0Rvd25s b2Fkcy9FTi9CU0kvUHVibGljYXRpb25zL1RlY2hHdWlkZWxpbmVzL1RSMDMxMTYvQlNJLVRSLTAz MTE2LVRTX3YxLnBkZj9fX2Jsb2I9cHVibGljYXRpb25GaWxlJmFtcDt2PTEiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5ic2kuYnVuZC5kZS9TaGFyZWREb2NzL0Rvd25sb2Fkcy9FTi9CU0kv UHVibGljYXRpb25zL1RlY2hHdWlkZWxpbmVzL1RSMDMxMTYvQlNJLVRSLTAzMTE2LVRTX3YxLnBk Zj9fX2Jsb2I9cHVibGljYXRpb25GaWxlJmFtcDt2PTE8L2E+PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5RdW90aW5nIGZyb20gdGhlIGZvcm1lciBkb2M6PC9kaXY+PGRpdj48cHJlIGlkPSJnbWFp bC1tXzY0MTQ1NTMxMTcxMjU0NTYyMTFtXy03NDYwNjY1NDk3NjE1MzM5NzE4bV83ODE2MjQ5ODU1 NTIwNDE1MjAwZ21haWwtY29tbWVudF90ZXh0XzgiPjxmb250IHNpemU9IjIiPjxzcGFuPiZndDsg MS4xLiBQYXRlbnRzIGFuZCBzaWRlLWNoYW5uZWwgYXR0YWNrcwomZ3Q7IEluIGltcGxlbWVudGF0 aW9ucywgcGF0ZW50cyBhbmQgc2lkZS1jaGFubmVsIGF0dGFja3MgcGxheSBhbiBpbXBvcnRhbnQg cm9sZS4KJmd0OyBUaGUgYWxnb3JpdGhtcyBkZXNjcmliZWQgaW4gdGhpcyBndWlkZWxpbmUgaGF2 ZSBiZWVuIGNhcmVmdWxseSBzZWxlY3RlZCB0byBhbGxvdyBwYXRlbnQtZnJlZQomZ3Q7IGFuZC9v ciBsaWNlbnNlLWZyZWUgaW1wbGVtZW50YXRpb25zLiBOZXZlcnRoZWxlc3MsIHNvbWUgb2YgdGhl IGRlc2NyaWJlZCBhbGdvcml0aG1zIG9yIGl0cyBwYXItCiZndDsgdGljdWxhciBpbXBsZW1lbnRh dGlvbnMgbWF5IGJlIHN1YmplY3Qgb2YgcGF0ZW50IHJpZ2h0cy4gVGhlIEJTSSBzaGFsbCBub3Qg YmUgaGVsZCByZXNwb25zaWJsZQomZ3Q7IGZvciBpZGVudGlmeWluZyBhbnkgb3IgYWxsIHN1Y2gg cGF0ZW50IHJpZ2h0cy4KJmd0OyBJbXBsZW1lbnRvcnMgYW5kIHNlY3VyaXR5IGV2YWx1YXRvcnMg c2hhbGwgYWxzbyBwYXkgYXR0ZW50aW9uIHRvIFs2XSwgd2hpY2ggZ2l2ZXMgYSBnZW5lcmFsCiZn dDsgZ3VpZGFuY2UgdG8gYXNzZXNzIHRoZSBzaWRlLWNoYW5uZWwgcmVzaXN0YW5jZSBvZiBpbXBs ZW1lbnRhdGlvbnMgb24gc21hcnRjYXJkczxicj48YnI+PC9zcGFuPjwvZm9udD48L3ByZT48cHJl IGlkPSJnbWFpbC1tXzY0MTQ1NTMxMTcxMjU0NTYyMTFtXy03NDYwNjY1NDk3NjE1MzM5NzE4bV83 ODE2MjQ5ODU1NTIwNDE1MjAwZ21haWwtY29tbWVudF90ZXh0XzgiPjxmb250IHNpemU9IjIiPjxz cGFuPjxmb250IGZhY2U9ImFyaWFsLHNhbnMtc2VyaWYiPlRoZXJlIGlzIG1vcmUgYW5lY2RvdGFs IGV2aWRlbmNlIGUuZy4gaGVyZSBieSBBUk0gTWJlZDo8YnI+PGEgaHJlZj0iaHR0cHM6Ly90bHMu bWJlZC5vcmcva2IvY3J5cHRvZ3JhcGh5L2VsbGlwdGljLWN1cnZlLXBlcmZvcm1hbmNlLW5pc3Qt dnMtYnJhaW5wb29sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90bHMubWJlZC5vcmcva2IvY3J5 cHRvZ3JhcGh5L2VsbGlwdGljLWN1cnZlLXBlcmZvcm1hbmNlLW5pc3QtdnMtYnJhaW5wb29sPC9h PiA8YnI+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZSBpZD0iZ21haWwtbV82NDE0NTUz MTE3MTI1NDU2MjExbV8tNzQ2MDY2NTQ5NzYxNTMzOTcxOG1fNzgxNjI0OTg1NTUyMDQxNTIwMGdt YWlsLWNvbW1lbnRfdGV4dF84Ij48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBmYWNlPSJhcmlh bCxzYW5zLXNlcmlmIj5RdW90ZTo8YnI+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4 O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgi PjxoMj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6bW9ub3NwYWNlIj5DYW4geW91IG9wdGltaXpl IEJyYWlucG9vbCBjdXJ2ZXMgdG8gYmUgYXMgZmFzdCBhcyB0aGUgTklTVCBjdXJ2ZXM/PC9zcGFu PjwvaDI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Om1vbm9zcGFjZSI+Cgo8L3NwYW4+PHA+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5Om1vbm9zcGFjZSI+VW5mb3J0dW5hdGVseSwgdGhpcyBpcyBu b3QgcG9zc2libGUuIFRoZSBkZXNpZ24gZGVjaXNpb24gZm9yIEJyYWlucG9vbCB0byB1c2UgcmFu ZG9tIHByaW1lcyB3YXMgYWltZWQgYXQ6PC9zcGFuPjwvcD48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6bW9ub3NwYWNlIj4KCjwvc3Bhbj48dWw+PGxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpt b25vc3BhY2UiPmF2b2lkaW5nIHBvc3NpYmxlIHBhdGVudCBpc3N1ZXMgd2l0aCBmYXN0IHJlZHVj dGlvbiBhbGdvcml0aG1zPC9zcGFuPjwvbGk+PGxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpt b25vc3BhY2UiPmF2b2lkaW5nIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZXMgd2l0aCBub24tcmFu ZG9tIHByaW1lczwvc3Bhbj48L2xpPjwvdWw+PC9ibG9ja3F1b3RlPjxmb250IHNpemU9IjIiPjxm b250IGZhY2U9ImFyaWFsLHNhbnMtc2VyaWYiPjxicj48L2ZvbnQ+PC9mb250PjwvZGl2PjxkaXY+ PGZvbnQgc2l6ZT0iMiI+PGZvbnQgZmFjZT0iYXJpYWwsc2Fucy1zZXJpZiI+Tml0cm9rZXkgZG9j cyBhbHNvIHNob3cgdXNpbmcgQnJhaW5wb29sIGN1cnZlcyBpbiB0aGVpciBkb2NzOiA8YSBocmVm PSJodHRwczovL2RvY3Mubml0cm9rZXkuY29tL3Byby9saW51eC9lY2MuaHRtbCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZG9jcy5uaXRyb2tleS5jb20vcHJvL2xpbnV4L2VjYy5odG1sPC9hPiA8 YnI+PC9mb250PjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IHNpemU9IjIiPjxmb250IGZhY2U9ImFy aWFsLHNhbnMtc2VyaWYiPjxicj48L2ZvbnQ+PC9mb250PjwvZGl2PjxkaXY+PGZvbnQgc2l6ZT0i MiI+PGZvbnQgZmFjZT0iYXJpYWwsc2Fucy1zZXJpZiI+Jmd0OyBbLi4uXSBBIHN1aXRhYmxlIHZl cnNpb24gb2YgR251UEcgaXMgaW5jbHVkZWQgaW4gdGhlIEdOVS9MaW51eCBkaXN0cmlidXRpb25z IApVYnVudHUgKHNpbmNlIDE4LjA0KSwgRGViaWFuIChmcm9tIFN0cmV0Y2ggb253YXJkcyksPC9m b250PjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IHNpemU9IjIiPjxmb250IGZhY2U9ImFyaWFsLHNh bnMtc2VyaWYiPiZndDsgQXJjaCBMaW51eCwgRmVkb3JhIAooZnJvbSBSZWxlYXNlIDI2IG9ud2Fy ZHMpIGFuZCBvcGVuU1VTRSBUdW1ibGV3ZWVkIFsuLi5dPGJyPjwvZm9udD48L2ZvbnQ+PC9kaXY+ PGRpdj48Zm9udCBzaXplPSIyIj48Zm9udCBmYWNlPSJhcmlhbCxzYW5zLXNlcmlmIj48YnI+PC9m b250PjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IHNpemU9IjIiPjxmb250IGZhY2U9ImFyaWFsLHNh bnMtc2VyaWYiPlRoZXkgYXBwYXJlbnRseSBoYXZlbiYjMzk7dCB0ZXN0ZWQgdGhlaXIgZ3VpZGUg b24gRmVkb3JhIGluIGEgd2hpbGUgOyk8YnI+PC9mb250PjwvZm9udD48L2Rpdj48ZGl2Pjxmb250 IHNpemU9IjIiPjxmb250IGZhY2U9ImFyaWFsLHNhbnMtc2VyaWYiPjxicj48L2ZvbnQ+PC9mb250 PjwvZGl2PjxkaXY+PGZvbnQgc2l6ZT0iMiI+PGZvbnQgZmFjZT0iYXJpYWwsc2Fucy1zZXJpZiI+ QWxsIG9mIHRoZSBhYm92ZSBtYWtlcyBpdCBsb29rIHRvIG1lIGFzIHRob3VnaCBCcmFpbnBvb2wg Y3VydmVzIHdlcmUgc3BlY2lmaWNhbGx5IGRlc2lnbmVkIHRvIE5PVCB0b3VjaCBvbiBhbnkgcGF0 ZW50cy4gPGJyPjwvZm9udD48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBzaXplPSIyIj48Zm9udCBm YWNlPSJhcmlhbCxzYW5zLXNlcmlmIj48Zm9udCBzaXplPSIyIj48Zm9udCBmYWNlPSJhcmlhbCxz YW5zLXNlcmlmIj5JJiMzOTtkIGJlIGN1cmlvdXMgaWYgYW55IG90aGVyCiBvZiB0aGUgYmlnIGRp c3Ryb3MgZXhjbHVkZSB0aGUgQnJhaW5wb29sIGN1cnZlcyB0b28uIE9uIHRoZSBsaW5rZWQgQlog Cml0IHdhcyBzdGF0ZWQgdGhhdCBYdWJ1bnR1IGluY2x1ZGVzIHRoZW0uPC9mb250PjwvZm9udD48 L2ZvbnQ+PC9mb250PjwvZGl2PjxkaXY+PGZvbnQgc2l6ZT0iMiI+PGZvbnQgZmFjZT0iYXJpYWws c2Fucy1zZXJpZiI+PGJyPjwvZm9udD48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBzaXplPSIyIj48 Zm9udCBmYWNlPSJhcmlhbCxzYW5zLXNlcmlmIj5JdCB3b3VsZCBiZSBncmVhdCBpZiB0aGUgY3Vy cmVudCBleGNsdXNpb24gb2YgdGhvc2UgY3VydmVzIHdvdWxkIGJlIHJlZXZhbHVhdGVkLjwvZm9u dD48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBzaXplPSIyIj48Zm9udCBmYWNlPSJhcmlhbCxzYW5z LXNlcmlmIj48YnI+PC9mb250PjwvZm9udD48L2Rpdj48ZGl2Pjxmb250IHNpemU9IjIiPjxmb250 IGZhY2U9ImFyaWFsLHNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+PC9mb250PjwvZGl2PjxkaXY+ PGZvbnQgc2l6ZT0iMiI+PGZvbnQgZmFjZT0iYXJpYWwsc2Fucy1zZXJpZiI+Q2hyaXN0aWFuPGJy PjwvZm9udD48L2ZvbnQ+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+Cg== --===============1835039275282272137==-- From rfontana at redhat.com Mon Dec 6 21:51:00 2021 Content-Type: multipart/mixed; boundary="===============9061773669058025527==" MIME-Version: 1.0 From: Richard Fontana To: legal at lists.fedoraproject.org Subject: [Fedora-legal-list] Fedora license categories Date: Mon, 06 Dec 2021 16:50:41 -0500 Message-ID: --===============9061773669058025527== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable A bunch of us are looking into various possible changes in how the information on Fedora good/bad licenses is maintained, reviewed, classified and represented. One aspect of this is the likely effective replacement of such wiki pages as https://fedoraproject.org/wiki/Licensing:Main with a repository (such as https://pagure.io/fedora-legal/license-data). Among other things this has prompted a review of how licenses are currently categorized by Fedora. In particular, Fedora has separate lists of good and bad licenses for content https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses_3 https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses_3 and for documentation https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses_2 https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses_2 A question that has arisen is whether we actually need to treat documentation and content as separate categories. "Content" (and documentation, software, fonts, etc.) are not defined in that wiki page as far as I can tell. (FWIW the FPCA defines "Content" in a way that includes documentation: "any copyrightable material that is not Code, such as, without limitation, (i) non-functional data sets, (ii) documentation, (iii) wiki edits, (iv) music files, (v) graphic image files, (vi) help files, and (vii) other kinds of copyrightable material that the Fedora Council has classified as "content" rather than "code".") There is some overlap in the content and documentation license lists and the other lists as well -- for example, CC-BY is given as a good documentation license and a good content license. I think the answer is "yes", because of this policy: "Note that content must be freely distributable without restriction for inclusion in Fedora, and that a written statement from the content owner granting this is considered an approved license for Fedora. The one exception is that we permit content (but only content) which restricts modification as long as that is the only restriction." And indeed the content license lists includes a few non-libre licenses including at least one well known one that does not permit derivative works -- CC BY-ND. I'm assuming that Fedora would not allow documentation under a non-libre license, if only because there isn't a similar caveat in the documentation license section and all the good documentation licenses appear to be assumed to be libre. I think there may be some arguable counterexamples that might be explained away as covering things that are non-documentation content as opposed to documentation. I also am pretty sure that Fedora has not attempted to officially list all the approved non-libre licenses for "content" but I'm not sure if this is something intentional. (The categorical example that comes to mind is the inclusion of certain kinds of files from standards documents, such as schemas and the like.) Separately, I wonder if Fedora really needs separate categories for software and documentation, if the criteria for approval are basically the same -- essentially, whether the license is libre (by Fedora's own assessment) -- except that documentation licenses are seen as normally unsuitable for software. It is clear (to me at least) that any good Fedora software license should be good for documentation as well, if only because in practice documentation in packages is often covered by the software license -- indeed, this is probably much more common than cases where a special documentation license is used. Anyway, I was just wondering if anyone had any thoughts or comments on this. Richard --===============9061773669058025527==--