On Wed, Jan 17, 2024 at 6:15 PM Mark Wielaard <mark@xxxxxxxxx> wrote: > > Hi Richard, > > On Fri, Nov 24, 2023 at 08:07:02PM +0100, Mark Wielaard wrote: > > On Mon, 2023-09-18 at 20:47 -0400, Richard Fontana wrote: > > > While the Sun RPC problem *may* have been excised from glibc, just > > > last year we found another license in glibc (and at least one other > > > package), this time an IBM license [1], that we consider non-free by > > > present day standards, in that case because it involves a patent > > > license grant that discriminates according to specific use cases. I > > > think we should aspire to finding, *exposing*, and fixing these kinds > > > of problems. Exposing should mean at a minimum that we don't > > > perpetuate a community-wide decades-old practice of covering these > > > problems up, which seems to be one practical effect of indulging in > > > effective licensing. I realize all this doesn't itself justify the > > > resulting use of complex composite SPDX expressions. > > > > Right, I assume you are talking about the resolv code which carries a > > patent notice from IBM saying they might sue you if you use that code > > for anything else than doing DNS resolving over TCP/IP. Which is indeed > > a odd notice. Happy you found it and you are making IBM fix it. But > > IMHO it is just an unintended, license, bug in the upstream package. It > > will be fixed, so no need for some complicated license tag. > > So I noticed this isn't actually fixed yet. glibc is preparing their > next release, but the code still has two notices saying: > > * To the extent it has a right to do so, IBM grants an immunity from suit > * under its patents, if any, for the use, sale or manufacture of products to > * the extent that such products are used for performing Domain Name System > * dynamic updates in TCP/IP networks by means of the Software. No immunity is > * granted for any product per se or for any other function of any product. > > Which I assume is the notice you are worried about because it isn't > clear if there are actual patents and/or if any other (implied) patent > license has been granted by IBM. That's the license but it's not that I'm "worried" about this license at all (which covers very ancient code, I think from the early 1990s). Also, as I think I mentioned, IBM has agreed to relicense any IBM code under this license under the MIT license. Rather, it's an issue of licensing policy. This is not a free software license, at least by modern standards, and Fedora's policy is that 'code' must be under free software licenses (as determined by Fedora), though we now have a framework for documenting special exceptions. > Normally I would say just remove the ineffective notice, but sadly > just above it, IBM states "all paragraphs of this notice appear in all > copies". Sigh. > > So what is the correct license tag to use here? Would SPDX provide an > identifier for this? No, we didn't submit this one to SPDX because Fedora's approach is not to seek SPDX identifiers for licenses that are "not allowed". (I suspect if we had decided to allow it, SPDX would have added an identifier.) We have a Fedora-defined identifier, `LicenseRef-IBM-BIND`. However, the actual problem here is that I never got back to Florian Weimer about how to actually get this changed in glibc and it keeps slipping my mind. I think the only complication here is that there is currently no active contributor to glibc from IBM, and it would possibly be inappropriate for a non-IBMer to submit a patch to glibc to change a license that seems to be from IBM. It's really just a process issue. Personally, I don't really care too much if, in the License tag, this is represented as 'MIT' or 'LicenseRef-IBM-BIND', except that with the latter it will fail rpminspect unless (I think) we document a usage exception. Richard -- _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
