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/License... [2] https://src.fedoraproject.org/rpms/antlr3/c/6398229d293262736484dc0e3d7a87bf...
On 2026/01/14 23:29, Jerry James via legal 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/License... [2] https://src.fedoraproject.org/rpms/antlr3/c/6398229d293262736484dc0e3d7a87bf...
Does this not apply to antlr4 also? I do at least recall that there are a few packages that bundle antlrX, so maybe those need to be checked also?
On Thu, Jan 15, 2026 at 2:36 AM Cristian Le via legal legal@lists.fedoraproject.org wrote:
Does this not apply to antlr4 also? I do at least recall that there are a few packages that bundle antlrX, so maybe those need to be checked also?
I do not see the affected files in antlr4. For the record, they are:
- runtime/C/include/antlr3convertutf.h - runtime/C/src/antlr3convertutf.c - runtime/Cpp/include/antlr3convertutf.hpp
I am unaware of packages bundling the C/C++ bindings for antlr3. If you know of any, we should check them too, yes.
On Wed, Jan 14, 2026 at 3:29 PM Jerry James loganjerry@gmail.com 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/License... [2] https://src.fedoraproject.org/rpms/antlr3/c/6398229d293262736484dc0e3d7a87bf...
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?
On Sat, Jan 31, 2026 at 12:33 AM Jerry James via legal legal@lists.fedoraproject.org wrote:
On Wed, Jan 14, 2026 at 3:29 PM Jerry James loganjerry@gmail.com 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/License... [2] https://src.fedoraproject.org/rpms/antlr3/c/6398229d293262736484dc0e3d7a87bf...
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?
Purging in %prep should be sufficient.
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.
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 Jamesloganjerry@gmail.com 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/License... [2]https://src.fedoraproject.org/rpms/antlr3/c/6398229d293262736484dc0e3d7a87bf...
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?
Thank you, Jilayne. I appreciate the help. Thank you too, Neal, but I think I'll wait to hear from Jilayne and Richard before acting.
On Fri, Jan 30, 2026 at 5:31 PM Jilayne Lovejoy jlovejoy@redhat.com 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.
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 loganjerry@gmail.com 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/License... [2] https://src.fedoraproject.org/rpms/antlr3/c/6398229d293262736484dc0e3d7a87bf...
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?
On Fri, Jan 30, 2026 at 7:31 PM Jilayne Lovejoy via legal legal@lists.fedoraproject.org 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 loganjerry@gmail.com 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/License... [2] https://src.fedoraproject.org/rpms/antlr3/c/6398229d293262736484dc0e3d7a87bf...
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 -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-leave@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@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
On Thu, Feb 19, 2026 at 12:41 PM Richard Fontana rfontana@redhat.com wrote:
"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.
Thank you, Richard. This is useful information. I am pushing builds now to drop the problematic C/C++ backends from the antlr3 package. Since I have not been directed to scrub the offending files out of the source tarball, I have not taken that step.
Regards,
-
Cristian Le -
Jerry James -
Jilayne Lovejoy -
Neal Gompa -
Richard Fontana