On Fri, Jan 30, 2026 at 7:31 PM Jilayne Lovejoy via legal
<[email protected]> wrote:
>
> Hi Jerry,
>
> I did a bit of digging and looks like this was added to the repo back in 2022 
> when we started the SPDX conversion.
>
> That seems to suggest that it had been considered a "bad" license previously, 
> but I can't find a legacy record of that.
>
> Reviewing the license now, it's a bit unclear to me as to what makes it 
> not-allowed. It states (edits on format, mine):
> " Unicode, Inc. hereby grants the right to:
>  freely use the information supplied in this file in the creation of products 
> supporting the Unicode Standard,
>     and
> to make copies of this file in any form for internal or external distribution 
> as long as this notice remains attached."
>
> The first part is a bit restrictive but the "and" and the second part seems 
> to help.

"Freely use the information supplied . . . in the creation of products
supporting the Unicode Standard" makes it non-FOSS (leaving aside what
it actually means).

In principle, if I wanted to use the information in Unicode files to
create some competing standard, I've breached the license.

There are so many of these problematic legacy Unicode licenses in
nominally-FOSS projects that we now have a "unicode-mess" label in
fedora-license-data and a backlog of issues concerning them.

Richard


>
> I believe Richard is OOO right now. Let me confer with him early next week 
> and one of us will get back to you!
>
> Thanks,
> Jilayne
>
>
>
> On 1/30/26 3:33 PM, Jerry James via legal wrote:
>
> On Wed, Jan 14, 2026 at 3:29 PM Jerry James <[email protected]> wrote:
>
> I've been using scancode to take an in-depth look at packages I
> maintain.  I'm up to packages that start with "a"!  While looking at
> the antlr3 package, I found that it contains 3 files with the
> LicenseRef-Unicode-legacy-source-code license, which is not allowed
> for Fedora [1].  The files are part of the C/C++ backend.  They have
> been built into binary RPMs for Fedora since 2010 [2] (Fedora 12?).
>
> Repoquery shows that nothing in Fedora uses the C/C++ backend.  I will
> build updates for F42, F43, and Rawhide that disable it.  My question
> is whether I need to do anything more than that.  Do I need to scrub
> the offending files out of the tarball, for example?
>
> References:
> [1] 
> https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/data/LicenseRef-Unicode-legacy-source-code.toml
> [2] 
> https://src.fedoraproject.org/rpms/antlr3/c/6398229d293262736484dc0e3d7a87bf4f8f990a
>
> Is there anybody who can advise me on this?  I assume this license is
> not allowed in Fedora due to the Limitations clause at the end.  Do I
> need to scrub the sources, or is simply not building the code into the
> binary RPMs sufficient?
>
>
> --
> _______________________________________________
> legal mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
> Do not reply to spam, report it: 
> https://forge.fedoraproject.org/infra/tickets/issues/new



-- 
Richard Fontana
IBM Legal (supporting Red Hat)

-- 
_______________________________________________
legal mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new

Reply via email to