4 ms·
To be clear, the only GPL source in Android is the kernel. Google took great pains[0] to avoid shipping copyleft code. This is why they were able to make most o
by kmeisthax 3y ago
To be clear, the only GPL source in Android is the kernel. Google took great pains[0] to avoid shipping copyleft code. This is why they were able to make most of Honeycomb proprietary[1]. They can't withhold source on the kernel, but most of what makes Android Android isn't part of Linux and thus the GPL does not apply[2].
From https://source.android.com/docs/setup/contribute/licenses https://source.android.com/docs/setup/contribute/licenses:
> For userspace (nonkernel) software, Google prefer Apache 2.0 (and similar licenses such as BSD and MIT) over other licenses such as the GNU Lesser General Public License (LGPL).
Android is already permissively licensed and that's half of why Google can legally lock things down[3] so easily. The other half being that Google requires a CLA from outside contributors, which is just plain silly for a permissively licensed project. Then again, GNU did the same thing at one point.
In the alternate world where BSD was unambiguously legal and RMS was the Ted Nelson[4] of Free Software, I don't think they would have independently invented copyleft. A lot of the BSD people had very reactionary opinions to the concept, and while some of it might be motivated by their personal disdain for RMS, it's hard to separate RMS and copyleft.
Given all that, a legally unambiguous BSD almost certainly would have wound up being eaten by Microsoft rather than AT&T and the UNIX Wars. All the anger from early 2000s Microsoft about Linux was solely because the GPL prevented them from just writing a better version of Linux or GNU that other people couldn't have. Microsoft was very good at taking open standards and extending them with the goal of making their implementation replace the standard. The GPL copyleft was the perfect thorn in the foot of a Microsoft that liked to cheat the norms of standards bodies.
[0] At least on early versions of Android, this went as far as changing all the system paths. GNU and Android can technically coexist under the same Android/Linux kernel.
[1] Even the FOSS release of Ice Cream Sandwich deliberately omitted all the Honeycomb-related tags to frustrate attempts to use Honeycomb under the FOSS terms of the later AOSP release.
[2] Linux is commonly stated to be GPLv2, but it additionally has an exception stating that user-mode code never trips the GPL copyleft, as a "just in case" sort of thing. This is the reason why Nvidia is allowed to have kernel modules, and also the reason why Linus explicitly refused GPLv3. The v3 anti-TiVo clause forbids you from shipping an application on the same consumer electronics system as GPL software, if the application refuses to run if the GPL software is modified. This is perfectly reasonable for GNU but flies in the face of the whole "user mode APIs are not copylefted" thing.
[3] Android ain't done 'till Termux won't run.
[4] https://en.wikipedia.org/wiki/Project_Xanadu https://en.wikipedia.org/wiki/Project_Xanadu
- samatman 3y ago> Given all that, a legally unambiguous BSD almost certainly would have wound up being eaten by Microsoft rather than AT&T and the UNIX Wars. All the anger from early 2000s Microsoft about Linux was solely because the GPL prevented them from just writing a better version of Linux or GNU that other people couldn't have. Microsoft was very good at taking open standards and extending them with the goal of making their implementation replace the standard. The GPL copyleft was the perfect thorn in the foot of a Microsoft that liked to cheat the norms of standards bodies. This is a strange counterfactual to propose, given that Microsoft at one time sold the most installed Unix on the market: Xenix. Which it later abandoned. Given that they were licensing System 7 from AT&T, why would a tweak to BSD licensing result in them "eating" it?
- pjmlp 3y agoSometimes I wonder how much they repent themselves of having sold Xenix, and later on not holding on to a better POSIX support on NT, having to ship a Linux VM in the end. I for one only bothered with Linux initially after having learned UNIX on Xenix at the technical school, and using DG/UX on university campus, because POSIX support on Windows NT was so flanky, and later on it was more practical to deal with dual boot than SUA.
- kmeisthax 3y agoMicrosoft's biggest existential risk in the 80s was not having a "real OS"[0]. They had DOS, which they bought from SCP[1] to fix a problem IBM was having, and they had XENIX, which they had to license from AT&T. DOS was technically unsound - it almost sort of worked for personal computing but nobody was going to build workstations out of IBM PCs running DOS. They wanted to build a "real OS" on top of XENIX, going as far as to add porting aids between DOS 2 and XENIX in what they dubbed "XEDOS". Then Bell Labs started selling System V directly in 1983 and Microsoft chickened out of UNIX. In this environment, Microsoft wound up writing several attempts at home-grown "real OS" projects: Multitasking DOS 4, and ADOS, which then became OS/2. None of these succeeded. OS/2 got close, but Microsoft really didn't like working with IBM, and Windows 3[2] was selling way better. Microsoft ultimately got itself out of this dilemma with NT and Windows 95, both of which used a slightly modified Win32 API that was "real OS" compatible. However, that was almost a decade during which any number of companies could have easily upended, if not killed the company. BSD didn't start separating itself from AT&T owned code until 1989. Had they done so earlier, Microsoft could have pivoted to a BSD-based XENIX and saved themselves the cost of an AT&T license (which drastically increased with SysV). Microsoft could have shipped Windows on top of that instead of, say, the hackery that was WIN-OS/2 or waiting for Dave Cutler to design and build NT. [0] Virtual memory, apps run in protected mode ring 3, and preemptive multitasking. [1] Seattle Computer Products, not the SCP Foundation [2] Which is not a "real OS" in the sense that it's technically near identical to the Macintosh's system software.