BSD/MIT licenses don't have the nice, clear runtime exceptions.
And we actually had significant issues sharing code between runtimes and other parts of the project. Whole patch series blocked on that nonsense. Getting to a clean baseline fixed.
But we didn't delete code (yet).
Conversation
They also don't need runtime exceptions because they're so permissive not to conflict with anything. That's the whole point.
1
1
It's not about a conflict, but an undesirable notice requirement?
1
So it's explicitly that legal/corporate wants to use FOSS code without even giving credit. Folks have been shipping license notices for decades. It's NBD. Wasting actual contributors' time trying to take away this crediting is despicably disrespectful.
1
I don't want the act of compiling my code to add requirements on distribution? It's my code...
This doesn't seem like not giving credit at all.
I don't want reformatting my image with ImageMagick to add restrictions on it, it's my image...
1
It's not the act of compiling but of linking, and this is already the case unless you're using -nostdlib or (depending on target) dynamic linking. The ImageMagick analogy makes no sense because this is not a format conversion.
2
I do not see any reasonable argument for runtime library to have "linking exceptions" when it's already permissive licensed. If you're linking it, a requirement to credit/include notice isn't a bad thing. Otherwise recipient is unaware of relevant ©s on the binary they received.
1
Eek. I never thought of this. Are there projects using a particular libc due to licensing?
2
1
Maybe Androids use of Bionic?
2
3
Yes that's also why Android did their own libc rather than using glibc.
2
1
There are also other requirements like providing both forwards and backwards compatibility based on API levels. You're always meant to build with the latest NDK and APIs in the headers along with the symbols for the API are exposed based on API level so that it can be extended.
It also has to deal with all the Android things like signal chaining, system properties, internal user/group database, the dynamic user/groups used by the application layer, etc. It gets to skip a lot of things that aren't used but also has to provide a lot of additional things.
1
1
More recently, there's also the security hardening stuff like cross-DSO CFI, internally using read-only memory, etc. Also more things that don't need to be supported anymore: non-PIE executables, text relocations, etc.
Not a typical libc at all and couldn't be used elsewhere.
2