"There simply aren't any candidates"
"There simply aren't any candidates"
Posted Jun 26, 2025 0:55 UTC (Thu) by sageofredondo (subscriber, #157944)In reply to: "There simply aren't any candidates" by comex
Parent article: Libxml2's "no security embargoes" policy
This entire article comes down to large tech companies 'not' caring about this. If they are legally required (they can be sued over) then they will care more about sharing their fixes.
> Therefore, whether the library is copyleft shouldn’t have much impact on the company’s decisions.
Company lawyers very much would disagree. They have very strong opinions on how OSS licenses affect company decisions. :-)
Much of this wall of text you post is a red herring about sharing source code fixes over speculation that large tech companies have forked code fixes. This is a solved issue-many companies publish security fixes for the kernel and other software all the time. Your arguments almost read like a random anti-GPL commenter from the 90s.
Posted Jun 26, 2025 6:51 UTC (Thu)
by comex (subscriber, #71521)
[Link] (6 responses)
Instead you are claiming that it would directly force them to do so?
No common copyleft license requires companies to contribute fixes upstream at all, let alone participate in coordinated disclosure. (In fact, license requirements to contribute fixes upstream have traditionally been considered to render a license non-free. [1])
Copyleft licenses only require companies to publish source code (or sometimes just offer to send source code) for the specific version of the code they're distributing binaries of. Which is very different from publishing something that would actually be useful to the upstream project.
I'm not speaking hypothetically. Here is Apple’s distribution of libxml2:
https://github.com/apple-oss-distributions/libxml2
Yes, Apple releases source for their patched version even though it’s not copyleft. But that’s the only merit here. In every other way, this release is the kind of ‘code thrown across the wall’ that's typical of what copyleft licenses extract from companies without strong open source cultures.
First notice that the Git history is unrelated to the upstream Git repository. This is based on an older practice of just releasing tarballs for each version. Now Apple has made this into a Git repo, but the repo is just one commit per release.
Also notice that the original libxml2 code is actually in a subdirectory. The content outside the subdirectory mainly consists of an Xcode project: Apple has replaced the entire build system with an Xcode-based one.
Anyway, we need to identify the corresponding upstream version. In my experience, this can sometimes be nontrivial. But in this case, there is a plist file indicating that the base tarball is:
https://gitlab.gnome.org/GNOME/libxml2/-/archive/v2.9.13/...
(The same plist also has a list of “OpenSourceModifications”, but they’re just links to Apple’s internal bug tracker without any accompanying explanation.)
Next we can diff that tarball against Apple’s release. Here is the resulting *448KB* diff:
https://gist.github.com/comex/6f300555ef8ddf27bcd18aba9a0...
It contains tons of changes mashed together. Some of them actually have explanatory comments, including some fun ones:
// libxml2 v2.9 changed the HTML parser's handling of whitespace in a way that broke
But most of the changes have no explanation. The internal commit messages probably did, but we can't see those.
Many of the changes appear to be backported from newer versions of libxml2. (The base version 2.9.13 is three years old, and there have been a lot of changes since then.) But other changes in the diff are original.
Of the original changes, many are trying to better adapt libxml2 to Apple platforms, such as by suppressing Clang warnings, adopting the os_log API, and changing link arguments. These improvements might theoretically be worth carrying upstream in some form, but mostly not in their existing form, which is a pile of `#ifdef __APPLE__` blocks in otherwise platform-independent code. At least they bothered to include `#ifdef __APPLE__` rather than just inserting changes that assume an Apple OS. But they likely didn't actually try to compile it on any other OS, and I bet it wouldn't compile.
More to the point, many of the changes look potentially security-related! Lots of integer-overflow-related stuff. But these appear to be mostly backports. Are any of them not backports? (It looks like most of the relevant code has been refactored upstream, so the changes aren't one-to-one.) If they're not backports, are they real bugfixes or just gratuitous hardening? If they're real bugfixes, are they applicable to the latest upstream version? And how severe are the bugs?
Good luck picking through all the changes and figuring that out for each one.
It's not impossible. An attacker might be motivated enough to do it. Or a highly motivated upstream. But not most upstreams. And definitely not an upstream that's already struggling to deal with the security issues that *are* being properly reported to it.
Thus, at least in this case, source releases do nothing to help upstream security. Perhaps some hypothetical copyleft license could require downstreams to handle security 'properly'. But not any of the current ones.
Posted Jun 26, 2025 16:49 UTC (Thu)
by clump (subscriber, #27801)
[Link]
Posted Jun 27, 2025 19:42 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
Posted Jun 28, 2025 2:45 UTC (Sat)
by sageofredondo (subscriber, #157944)
[Link] (1 responses)
A little, see below.
> Instead you are claiming that it would directly force them to do so?
Did not say that at all.
I was responding to your poor arguments that a license does not have much impact on the company's behavior; it very much does. If Microsoft knowingly links GPL source code to the Windows kernel; that must be released under the GPL. Proprietary software companies go out of their way to avoid GPL software for a reason. This is what I meant with the lawyers.
> No common copyleft license requires companies to contribute fixes upstream at all, let alone participate in coordinated disclosure.
Yes, but once again, a copyleft license must share changes if they distribute a binary. Companies cooperate over CVE releases. Therefore, if they want to reduce their rebasing burden of their forks they will coordinate with upstream releases.
> (In fact, license requirements to contribute fixes upstream have traditionally been considered to render a license non-free. [1])
> [1] https://www.gnu.org/licenses/license-list.html#eCos11
Did you add the wrong link? I am not familiar with eCos or why this is an example of upstream fixes are to make a license non-free. https://www.gnu.org/licenses/license-list.html#eCos11
> Thus, at least in this case, source releases do nothing to help upstream security. Perhaps some hypothetical copyleft license could require downstreams to handle security 'properly'. But not any of the current ones.
Your source digging does prove your argument that a company can simply dump source code to comply with copyleft requirements and not contribute back in a helpful manner as far as security is concerned.
But why does Apple do this? They are not required to by the license. If they rebase then they have to deal with conflicts with upstream commits when their fixes change things slightly different than their fixes. It feels like an organization decision with minimal compliance by the people doing the work. This is a waste of developer time, but Apple can afford it with their margins. Most companies do not have their margins and once their source code changes are 'required' to be shared; they have a monetary incentive to contribute back to reduce their rebase burden.
Not responding to most of your post since you jumped on an assumption and wrote another wall of text.
Posted Jun 30, 2025 9:06 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link]
They did not add the wrong link, you failed to read it:
> This was the old license of eCos. It is not a free software license, because it requires sending every published modified version to a specific initial developer. [...]
Posted Jul 6, 2025 12:31 UTC (Sun)
by poruid (guest, #15924)
[Link] (1 responses)
Posted Jul 6, 2025 13:47 UTC (Sun)
by kleptog (subscriber, #1183)
[Link]
> 6. Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I. Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.
Obviously it only applies to manufacturers that want to sell digital products in the EU market, but it's something. It would definitely include Apple.
[1] https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
"There simply aren't any candidates"
// H&R Block at Home 2010. Detect H&R Block at Home 2010 and mimic the old parser behavior.
"There simply aren't any candidates"
"There simply aren't any candidates"
"There simply aren't any candidates"
"There simply aren't any candidates"
"There simply aren't any candidates"
"There simply aren't any candidates"