My perspective on GPL and related licenses changed a lot after working with lawyers on the topic. Some of the things I thought to be completely safe were not as definitive to the lawyers.
I don’t know Apple’s reasoning, but I know that choosing non-GPL licenses when available was one of the guiding principals given to us by corporate lawyers at another company.
On the engineering level, other liceneses likely get selected because it’s easy. You don’t need to consult the legal department to know how to comply with licenses like MIT, BSD, etc, so you just pull the thing in, make any required attributions, and continue on with your day. It’s a lot less friction, which is extremely attractive.
Yes, although even for the more liberal licenses you actually still want legal review at a sufficiently large company to ensure that your engineering read of the license is accurate. What if someone changed the wording slightly in some way that turns out to be legally significant, etc.
That might apply in a handful of cases, but the vast majority will check out when a quick diff against a reference license file shows that the only changes are party names.
I think it's very unlikely to happen, in general. I'm just saying a large corporation will want to check every time because they cannot really afford to do otherwise.
you didn't have to be a large corporations, there's a bunch of automated tools that help you check for your dependencies' licenses and flag anything non standard.
I work at a large corporation, but one that only has 6% of Apple’s annual revenue. Even the emails we send to end users get a review from the legal team prior to us hitting send.
Yeah, there are some assumptions which can be made about licenses and their suitability for our purposes, but no serious organization is touching that code until there has been a full audit of those license terms and the origin of every commit to the repository.
The kind of places I usually work for, you do need to consult with legal regardless of the license.
And to prevent your scenario, usually CI/CD systems are gapped to internal repos, unless dependencies are validated and uploaded into those repos, the build is going to break.
This was basically the justification I was told when I was at Apple. The GPLv3 is too viral for the liking of Apple's legal department. They do not want to be the test case for the license.
The funny thing is that the rest of the world has moved on and is no longer afraid of the GPLv3. The reality that people aren't, as Apple's legal people predicted, being legally obliterated hasn't changed Apple legal's stance. Doomsday cults actually get stronger when doomsday fails to drive.
The reason why doomsday never came is that the GPLv3 bomb was never dropped. Linux, Android, and busybox all rejected v3, because it's basically a ban on embedded development[0], and that's all the FOSS most embedded developers care about using.
Likewise, if you don't do any embedded, you don't need to worry about v3, it's functionally identical to v2 except the compliance story is slightly easier (you don't immediately lose your license if you fuck up a source release).
There's very few companies that have their fingers in both the embedded and desktop markets; those are the ones that need to worry about GPLv3 doomsday. AFAIK that's only Apple and Microsoft[1], both of which have very hostile attitudes towards v3 as a result.
[0] To be clear, when you hear "embedded development", think "TiVoization". The business model of embedded development is putting your proprietary software in a box to sell. GPLv3 wants to make it so that if you do that, you can't stop someone from modifying the OS around the software by making the software detect that and break. But that also makes it significantly harder to defend your business model. Remember: the embedded landscape is chock full of very evil DRM schemes, many of which would break trivially if the app had to support running on arbitrarily modified OSes or with arbitrarily modified libraries.
[1] Microsoft controls the signing keys for UEFI, and while they are willing to sign stuff to let Linux boot, they will not sign GRUB because that's GPLv3 and they worry signing any v3 software will obligate them to release their signing keys.
Most organizations don't have many billions of dollars at stake. I doubt you'll find many Fortune 500 companies with a flippant attitude towards the GPLv3. You don't even see the GPLv3 used much by the "we love Open Source" crowd. Most externally released FOSS is under non-viral Open Source licenses.
No big company wants to spend a million(s) dollars defending themselves from an NPE with an East Texas mailbox in a frivolous licensing suit. Worst case is a judge deciding the license infects their proprietary code because they're built on the same cluster.
The rest of the world has hardly moved on. I've heard of multiple companies with the same GPLv3 policy as Apple for largely the same reasons.
I think the rest of the world is very much moving in Apple's direction: look at what Ubuntu is doing, and any big open source project with more than a single corporate backer (i.e. not just using open source as a marketing channel) isn't using GPL.
Replacing GPL coreutils with Rust reimplementations. The conspiracy theorists say that's the reason behind the huge RiiR push. There's effectively zero GPL'ed Rust software.
It makes me sad to realize that it was possible that the GPL was necessary to bootstrap free software culture and that we no longer need it now that we've won.
One large side of the industry is turning to managed services. They run free/libre software, but build lock-in on higher level and avoid giving direct contact.
On the other market, the desktop free/libre software won as with Android and free/libre parts of MacOS/iOS.
However they don't do that to benefit the free/libre software in any way, but for getting software cheap or even for free.
The amount by which this flows in one direction, there isn't a win.
MIT and BSD predates it, and GPL only had a go at it for two reasons:
1 - Sun decided to inovate by spliting UNIX into user and developer SKUs, thus making the until then irrelevant GCC, interesting to many organisations not willing to pay for UNIX development SDK.
2 - AT&T tried to get control back over UNIX's destiny, and made BSD's future uncertain
There was an Ubuntu engineer recently talking about using the rust coreutils which are bsd licensed instead the old gpl ones. But he made it clear it was more about “rust is better” than anything to do with the license.
Which is a fair choice, since so much of Linux development and driver development is driven by commercial interests - there would very likely be a fork from the last GPLv2 commit which all the vendors would switch to...
I've had similar training back in the day. This was when my employer (Nokia) was making Linux based phones and they needed to educate their engineers on what was and wasn't legally dodgy to stay out of trouble. Gplv2 was OK with permission (with appropriate measures to limit its effect). Particularly with Java, you had to be aware of the so-called classpath exception Sun added to make sure things like dynamic linking of jar files would not get you into trouble. Permissive licenses like Apache 2.0, MIT, and BSD were not considered a problem. GPLv3 was simply a hard no. You'd get no permission to use it, contribute to it, etc.
Apple, Nokia, and many other large companies, employ lawyers that advice them to steer clear of things like GPLv3. The history of that particular license is that it tried to make a few things stricter relative to GPLv2 which unintentionally allowed for things like commercial Linux distributions mixing closed and open source. That's why Android exists and is Linux based, for example. That could not have happened without the loopholes in GPLv2. In a way that was a happy accident and definitely not what the authors of that license had in mind when they wrote the GPL.
It's this intention that is the problem. GPLv3 might fail to live up to its intentions in some respects because of untested (in court), ambiguous clauses, etc. like its predecessor. But the intention is clearly against the notion of mixing proprietary and OSS code. Which, like it or not, is what a lot of big companies do for a living. So, Apple is respecting licenses like this by keeping anything tainted by it at arms length and just not dealing with it.
As someone on the Networks side, I had the pleasure to write multiple Excel files with all the dependencies of our product listing all the relevant facts for every single jar file.
At a big company I worked for, GPL licenses were strictly forbidden. But I got the vibe that was more about not wanting to wind up in a giant court case because of engineers not being careful in how they combined code.
I'd be super curious if there are explicit intentional acts that people generally think are okay under GPL but where lawyers feel the risk is too high.
Linking against GPL code on a backend server which is never distributed - neither in code or binary form. (Because what might happen tomorrow? Maybe now you want to allow enterprise on prem.)
I don’t know Apple’s reasoning, but I know that choosing non-GPL licenses when available was one of the guiding principals given to us by corporate lawyers at another company.