Apple's Great GPL Purge (2014)
meta.ath0.com
meta.ath0.com
When source code is available, evil actors are just less likely to act evil. Even if nobody is reading the source code, just the act of publishing it psychologically nudges people towards acting less sociopathically. When people feel watched, they are less likely to try to cheat others, delete their ebooks, spy on them, or experiment on their emotions like Facebook did. This happens even if nobody is actually watching; just the potential of being watched is enough.
And people do need a nudge to publish source code. Sure, unimportant bits of code that you don't really care about, that aren't core to your business, that you'd rather have someone else maintain for you; that's when you really love "open source" and you push your changes upstream and you look like a wonderful community member. It's for the missing important bits, the secret firmware blobs controlling our phone chips, our BIOS, our cars; even our refrigerators and our light bulbs; that's when you need GPL enforcement.
I know hackers hate lawyers, but GPL enforcement rarely goes as far as lawyers. The GPL is a deterrent, a firearm that anyone can use and almost always remains dormant. People seem to be pushing towards legal disarmament, MIT license everywhere. I don't think this is enough to deter bad actors.
Because you might be assuming that the user always controls the software.
However, as long as the source code is kept secret, the developers/distributors also have some level of control on the users. It becomes possible (and easy) to insert malware-like stuff in the software (i.e things unwanted by users, like tracking/spying, license checks, forced upgrades, feature removal, remote file removal, malware installation, etc), allowing black-mirroresque situations (software or devices forcing you to watch advertisements before you can watch what you wanted, complete history of your browsing).
If the program is licensed under a free software license, it implies that the source code is public and modifiable. It makes these things are a lot harder to hide, and a lot harder to keep enabled.
Now, paradoxically, GPL is less free than many open source licenses. The GPL restrictions will limit adoptions, as we're seeing here.
Stated differently, GPL was an important starting "assist" that's now slowing us down. It's time to turn it off.
The BSD license allows anyone to do what they wish with that BSD licensed code.
Nothing happens to the original BSD licensed code just because someone uses it in a closed product. It's still available under the same bsd license.
Would you go into more detail here? It seems to me, to use the router as an example, even if they were to make the source code available, getting updated code to run on the router would still be difficult, if not impossible, depending on how the software is running on the hardware. Is it burned into ROM? Are you able to flash firmware? I'm admittedly speaking from ignorance here. How are these types of issues addressed purely from the point of view of the GPL (or any other license, for that matter)?
To quote the license:
“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
It's this sort of thing that's really important for 'Free' software.
Certainly in the case of ROM you are correct – but it's a bit of an unusual case really. The only other option would be outright banning the inclusion of GPL software on such devices, but that seems overboard.
Hardware makers wanted to exercise the right to use open source software without returning that right to the people who bought their products from them. GPLv3 was designed to remove the loophole that allowed them to do that. It's true that GPL has more restrictions than BSD or MIT. But the freedom those licenses give is the freedom to steal without giving back.
I hate when people claim using BSD licensed code is stealing. It's not just a lie, it's a total perversion of freedom itself.
Once the router company clones the source, it becomes this new code-base, that they can add to, without revealing those new changes. You are still allowed to make any changes you want to the original code-base, but:
1. That is not the code-base you want. You want the one running on your router.
2. You don't have all the build environment, and toolchain magic needed to produce a new binary blob for your router.
Also, blah blah DMCA.
Yes, but you should add that you are talking about the RMS definition of freedom, not about the word freedom as it is generally understood.
Some dictionary definitions of freedom are:
> the power or right to act, speak, or think as one wants without hindrance or restraint.
> absence of subjection to foreign domination or despotic government.
> the state of not being imprisoned or enslaved.
So the changes in GPL v3 are about maximising the freedom of your software and it's users, at the expense of curtailing the freedom of Apple/TIVO & friends to distribute it.
It says nothing about the cost of the liscense to the end user of the software. It's confusing, because you may think "I have the source, I can just compile it for free". But the reason that you have the source (and the binary, in some cases), is that most GPL software is also offered free of charge.
As a side note, it's more practical to get usage of a piece of software with the restrictions of the GPL used, if the software is also available free of cost.
Damn it, we need a different word.
This is the very reason most successful companies doing free software, do it by selling consulting, support contracts, training or hardware.
Anyone whose software cannot fit those models usually ends up looking for another source of income.
Personally I prefer John Loke definition: 'Freedom of people under government is to be under no restraint apart from standing rules to live by that are common to everyone in the society ... and not be subject to the inconstant, uncertain, unknown, and arbitrary wills of others'.
Rules, which are common to everyone, and the CC license share-and-share-alike encapsulate in the name.
The GPL puts (somewhat onerous, some would argue) limitations on the user in order for the software to remain free. Think of it as liberating the software by giving it rights.
If you release your code under the BSD license, no one can 'steal' it. That's a misrepresentation of reality. They're using it according to the license. If I release code under the BSD license and someone takes it, uses it in some closed-source router whose code or behaviour I can't fix or modify, then so be it.
Likewise, your code is never 'monopolized' or 'disappeared'. Anyone else who wants to do something with that code is still able. Nothing is taken away from the rest of the world by one person using that code for their own purposes, whether you disagree with those purposes or not.
If you release your code under the GPL license, no one is 'restricting' usage of the code. That's a misrepresentation of reality. The area outside the license, which include adding legal restrictions, are as if there were no license and is enforced solely by copyright.
Anyone else who wants to do something with that code is still able. Nothing is taken away from the rest of the world by limiting what legal restrictions may be added to the software license, whether you want to add such restrictions or not.
The BSD's have been using ZFS without any issues for a while.
However, GPL may cause issues which makes people leery of using ZFS with Linux
That's the point of it.
What about the contributions of embedded compiler vendors back to LLVM?
The freedom GPL preserves is that of the user.
If you ship me GPL-based binaries, it's my right as a user to see what's actually running. I also get to redistribute that under the same license as was afforded to you, but principally, I always get to see what's running.
Somebody can take MIT code, alter it, compile it down and ship that. That's great if you're a developer. Super easy. But as a user, why do you expect me to trust this stuff? Especially when there's a GPL version out there that does let me audit it.
They just gave a death sentence to GCC on the NDK, by declaring it as deprecated and it will only stay around until clang support catches up with GCC.
Brillo has even less GPL components than Android and in Fuchsia I imagine not a single one, given that they are even doing their own micro-kernel.
GCC wasn't given a death sentence, we are just moving on to llvm. GCC devs have been moving to llvm for years and not because of the license. I'm sure DannyBee will say something about this down thread..
In this case, "GPL Purge" is actually incorrect. They haven't eliminated the bash shell, emacs text editor, and other packages that are GPL, just chose not to ship with later versions that are GPLv3.
I doubt you will find a competent lawyer willing to state that releasing the source code for those tools without disclosing the signing key is 100% guaranteed compatible with the GPLv3.
As a semi-workaround, they could use a separate signing key for GPLv3-licensed code they ship or even separate keys for each tool, but again, I don't think you will find a lawyer who is willing to claim it would be legal to retract the signing keys when people start signing malware with it.
"The only time you would be required to release signing keys is if you conveyed GPLed software inside a User Product, and its hardware checked the software for a valid cryptographic signature before it would function. In that specific case, you would be required to provide anyone who owned the device, on demand, with the key to sign and install modified software on the device so that it will run."
https://www.gnu.org/licenses/gpl-faq.en.html#GiveUpKeys
Sounds exactly like how iOS code signing works...?
Allowing each device to generate a second, local signing key and allowing the user to export it for signing modified components likely would fulfill this requirement. Most Apple devices probably already have some crypto module that could generate and manage such a key.
If they ship a binary and give you its signing key, you can change it into any binary you want and resign it, and the OS will have to accept it (if it doesn't, they aren't complying with the GPL because, apparently, they didn't give you the full effective signing key)
That renders the entire system useless.
More likely they avoid GPL3 because they aren't 200% convinced they can safely put it in the same package as their closed source software.
(They need 200% conviction because having to open source their closed source software or even significant parts of it would have an enormous impact on their market value)
Linux also doesn't require copyright assignment, so there's no one entity that could change the license - it would be an enormous PITA, and a number of people would refuse for various reasons (people doing work for companies that chafe under the TiVo clauses or the patent clauses...)
Plus, Linus himself likely wouldn't relicense his contributions, so that's a nonstarter. [1]
[1] - http://lkml.iu.edu/hypermail/linux/kernel/0601.3/0559.html
It's always been better to install more up-to-date software, since the system default unix software has been ancient for a long time. It seems like default system Python was python 2.3 or 2.4 forever, although they've upgraded to python 2.7.
And Apple has quite a few developers as well. I don't think they would want to make the platform impossible to use.
Enabling developers and internal business software is nice for PR and market share, while 30% cut on all sold third-party products is a strong incentive to lock down. My guess would be that its the market share towards business that prevents the lockdown, not security or developers, mainly because I suspect it is easier to run the numbers on that and determine what bring most revenue.
It's also not nearly as commonly used as a way to profit off third parties as it is to keep out third parties. The 10NES being a great example, or K-Cups, or proprietary e-book formats or phones locked to carriers.
`In 2010, a year before his death, Steve Jobs outlined Apple’s strategy in an email to the company’s 100 most senior employees. He heralded the “Post PC era,” vowed “Holy War with Google,” promised to “further lock customers into our ecosystem,”...` - http://qz.com/196005/the-steve-jobs-email-that-outlined-appl...
Discussed recently here on HN - https://news.ycombinator.com/item?id=12864727
Security wasn't mentioned once in that email.
Yes, he uses the word "lock", but not in the same context we are talking about here.
He is talking about leveraging the connection between their products so say that a person with an iPhone may not want to leave the Mac for a PC because the customer may miss the interoperability/integration features available.
For example, Apple provides their "Continuity" APIs for things like Handoff between iOS and Mac. This is something that Apple can do to make their ecosystem more attractive to customers and discourage them from leaving because it is less likely developers are going to write apps that go to this level of coordination between say your Windows desktop, your Android phone, Pebble watch, and Roku TV.
This strategy does not automatically imply that Mac must be locked down so nobody is allowed to distribute apps outside the Mac App Store.
It says "further lock customers into our ecosystem". Obviously, "locking customers into their ecosystem" is a primary goal here and "tying all of our products together" is just one way of achieving that.
It is a way to do it "further" than what they've done already.
> This strategy does not automatically imply that Mac must be locked down...
OK, but we already established that the goal here is to "lock customers into our ecosystem". In light of that statement, do you really think Apple wouldn't jump at the chance to make the Mac OS just like iOS? Odds are that they would love to do such a thing, but they can't for one of the reasons that `belorn` stated above.
Why do you think they didn't make iOS so that anybody could deploy apps to it? Do you really, truly think it was for the purpose of security?
EDIT: I guess my main question for you is, what reason do you have to think that Apple wouldn't want to lock down the Mac OS? That's essentially what `belorn` was asking above.
BUT...context of where this all stems from is important to remember. On the Mac side before the iPhone, the Windows world was getting hammered with security problems and the perception of this was having negative repercussions throughout the PC world. Average users were scared to touch their PCs and especially afraid to try installing new applications. Mac users were the complete opposite of this and their market was dominated by consumers who loved getting (buying) the latest OS updates and buying the latest, coolest apps. Money flowed in the Mac world. But as Mac started getting more attention, lots of different press coverage wondered if Mac could be vulnerable to the same kind of vulnerabilities Windows users were constantly dealing with now that it is a bigger target. So keeping Mac secure for the benefit of their users became a profit incentive for Apple.
On the iPhone side, remember, Apple was walking a tightrope with the phone carrier (AT&T) when they first got started. They didn't have the leverage they have now. Remember that mobile carriers have been obstinate about updates in the name of (their own) "security". They didn't want a bad update, that they couldn't test, somehow bring down the entire cellphone network. Nor did the carriers want nefarious apps that would secretly make expensive phone calls to pay-per-minute numbers. It's no surprise that when Jobs finally was convinced to open the platform to 3rd party native apps, there was some kind of vetting system introduced to appease the mobile carriers from saying 'no'. This is not to say that security was the only thing on their mind and there are other reasons they would like the model they have, but it was a factor. (Consistent user experience is another factor, which is something the App Review process could help enforce since the iPhone was new. Mac has less of this problem because there had been many years of conventions laid down which developers were very good about following in the eco-system already, which is another key difference between the iPhone and Mac ecosystems.)
As for why Apple doesn't lock down the Mac as they do now, the simple answer is that it doesn't help their bottom line in any way. Mac and iOS have very different use cases and heritages. And Apple has been successful with their current Mac carrot/stick trade-off. Most Mac developers I've talked with say that while dealing with the Mac App Store is annoying, they do get a lot more visibility and sales than by not being on the store. Users are no longer confused about how to "install" their apps which saves them customer support costs. (Yes, the open DMG, drag-and-drop to Applications thing is confusing for people.) For indie developers, building a store front and dealing with a payment processor doesn't save them a huge amount of money for what Apple provides for their 30% cut. And remember, sales seem to be better on MAS for most developers so this ends up paying for itself. (And if you are a game developer, you see basically the same arrangement with Steam/Value.)
For those who can't get on the Mac App Store, perhaps due to the technical restrictions, Developer ID for GateKeeper is one option. Apple still gets $99/year for this. And it is worth pointing out, if Apple was truly only obsessed about their 30% cut for MAS, they wouldn't have these technical restrictions and would let anybody do anything on MAS so they could get their cut.
So if Apple decided to lock down the Mac entirely, what does it get them? Most developers are already voluntarily using Mac App Store and Developer ID. Those developers who are not already participating in those systems and not giving Apple money, locking down the system isn't likely going to get any of these developers to hand over any more money.
A lot of these developers are probably making software for their own in-house purposes, developing web sites, or developing for Android. Apple locking down these use cases would only result in people moving back to the PC. And internally, this would probably break all of Apple engineering as they all work on operating system components which don't fit the lock down model either.
And most importantly, remember that Apple's gross margins on hardware is like 40%. If we're talking about chasing customers away, that's a lot of money to lose. Who cares about the cut on a freebie flashlight app, website, or command line tool, which isn't going to make any money, compared to the profit on selling all those $2000 Macs.
That doesn't mean that Apple wouldn't jump at the chance if things changed though. They most certainly would. That's because the primary goal is to lock customers into their ecosystem.
Some Apple fans won't acknowledge that goal and they seem to take offense at that very notion or they start telling you that you're "being disingenuous" for even suggesting it.
Even if only an academic exercise, it would be cool to actually strip out SIP and mandatory kernel extension signing.
At the time of writing, Apple still hasn't open sourced Sierra's XNU[1].
[1] 10.11.6 source: https://opensource.apple.com/source/xnu/xnu-3248.60.10/
as of 10.12 (opensource.apple.com not yet updated):
gnutar replaced by bsd tar
keymgr gone?
efex gone?
(gnu) make is also included
Apple is getting rid of Bash? When?
Going so far as to go through the pain of yanking out gcc for the llvm suite for the OS and ported applications.
All replaced with BSD licensed rewrites now.
>I’m also intrigued to see how far they are prepared to go with this. They already annoyed and inconvenienced a lot of people with the Samba and GCC removal. Having wooed so many developers to the Mac in the last decade, are they really prepared to throw away all that goodwill by shipping obsolete tools and making it a pain in the ass to upgrade them?
Seems like developers have been overstating their importance to Apple forever.
If anything, I think Apple's increased focus on iOS and the rest of the industry finally making really good stuff would be a more significant factor if Apple starts to bleed developers.
Apple cares about developers, those that love and enjoy writing applications for Apple OSes.
The ones that were there in the good and bad days.
Those that jumped into Apple OS just when they coincidently had a UNIX with a pretty UI because they choose not to get Be instead, not so much.
Thank god, then, for HomeBrew/MacPorts/Fink/et. al. A 'chsh' and I can have a modern Bash as a shell.
Seriously, mobile dragged us back to the bad old days of the '80s and basically made sure IBM clones and DOS couldn't exist. We're all screwed.
The computers were a packaged experience of hardware and software, designed to work together.
Hence why people have found memories of their 8 or 16 bit systems, while most might not even remember how their MS-DOS systems looked like or what OEM brand it was.
We will soon look back to the Microsoft era as a golden age where you only had to avoid getting milked by one company, rather than every single one out there.