Yet. (One way to accomplish this will be merging the operating systems, and the other way is continuing the march to making these restrictions more and more similar.)
A default OSX install these days will only allow sandboxed installs from AppStore, or unsandboxed from developers registered with Apple. The jump from that to "only Appstore" is not that big and sooner or later will happen, it's mostly a commercial issue. Some time after that, the various options to change these policies will go away, and you will be left with something very similar to iOS in terms of lockdown.
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.
Yeah: four different manufacturers, four different spreadsheet programs. Loads of fun, that was - not.
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.
JavaScriptCore seems to have been almost entirely relicensed under APSL; there are at most just two or three files still under GPL (involving date parsing), and in many configurations those are no longer compiled.
JavaScriptCore code is either LGPL or BSD licensed, depending on whether it derives from the original KJS source base or is new code written by Apple. There's no APSL code in JavaScriptCore last I checked.
Basically things didn't move much. If it were really such a purge they'd be following the author's advice, as well as switching to zsh as the default shell on new accounts/machines before dropping bash in a couple of years.
It's that that big of a deal actually. You can still disable SIP, you can still override kernel extension signing (and signing on pretty much anything else), and you can sill install any GPLv3 software you want. It's just the default base install that has changed, and everyone knows there is no one-size fits all. While there are plenty of commercial reasons to not go beyond GPLv3 from the vendor point of view, it doesn't really change anything for "us". Even if we had a stable bash from 2015, we'd still want the 2016 version and install it anyway...
I used the nix package manager for a while, but it's arcane, so I went to MacPorts. Homebrew is obviously the main one, though.
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.
Wonder what is holding them back from going full lockdown on all apple devices. Is it because PR and trying to keep a good image with the developer crowd, is it because they can't demand that every third-party application goes through them or they loose business customers, or some other thing I just don't see?
The goal of locking down a platform has been the same on practically every consumer product ever produced that is locked down: To be able to take a cut whenever a third-party product is sold. Been true from everything between a gaming consoles, phones, e-book readers, espresso machines and printers.
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.
Locking you into Apple hardware and software is most certainly their stated goal. You can read it directly from the horse's mouth:
`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...
You are using a disingenuous interpretation of what he said.
His quote is:
"tie all of our products together, so we further lock customers into our ecosystem"
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.
I am not being disingenuous at all. Let's examine the quote a little closer, shall we?
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.
I personally think they go overboard in the name of security on iOS, for example the banning of JIT and (formerly) dynamic libraries combined with the App review process is overkill. You don't need both.
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 ...
It's obvious to me that Apple won't lock down the Mac OS at this time for the reasons that you and `belorn` mentioned.
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.
Requiring every commercial app to go through Apple's review process and give Apple a 30% cut of revenues doesn't do anything to harden the platform from a security perspective.
Apple would not have to release their keys. They would have to make it possible for users to run their own modified versions of software. This can obviously be accomplished in many ways.
But if they shipped GPL3 software with the OS, they would like to code-sign the binaries.
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.
I doubt you would find a competent lawyer making any claim which has the word “guaranteed” in it. This still leaves it completely obvious that anyone could, for instance, ask the FSF what they would consider reasonable, and do that, and thereby avoid any reasonable risk of getting sued. The FSF has never been against code-signing.
But the FSF GPL faq says they would have to release the keys:
"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."
It also says: If each instance of the device uses a different key, then you need only give each purchaser a key for that instance.
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.
It's pretty clear that a second, local signing key is absolutely not something Apple wants in its iOS ecosystem, because that would open up sideloading of apps bypassing the app store.
True, they'd need a way to limit it to the GPL components for iOS devices, which makes it a lot more complex and ugly to implement. (I had mostly been thinking about macbooks, where the feature might be an easier sell)
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)
Yes, but they would want to have that key to be limited to only allow replacing of GPLv3 binaries. Just because I can demand a key to replace GPLv3 components doesn't mean I can demand a key to replace other software components, so the verification system has to be able to use different keys for different parts of the system. (If that is wrong, and I can demand a key for everything, then that is the obvious answer why we'll never see GPLv3 on there. Or even if it is unclear what the actual situation is)
That could be an argument now, but this started way before they added code signing.
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)
Code signing and gatekeeper on the Mac is fairly recent, but iOS has had it since the beginning. Maybe they were planning for this end-game all along since they started iPhone development, likely around 2005 or so (at least a couple of years before the 2007 launch)? I could totally see them assuming they would need to embed bash in iOS and not wanting to use GPLv3, and the rest of the os variants follow.
Linux is under GPLv2 explicitly, not the "GPLv2 or later" that a number of projects adopt.
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]
Strictly speaking, "purge" does not have to be immediate or sudden. A purge can happen over a decade.
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.
It takes a long time and lots of work to replace things like the gcc toolchain, purge pour code of gcc'isms, test, debug, add missing or equivalent features.
I get the feeling everyone's purging the GPL, and I'm not sure this is a good long-term goal. I still think we need legal protection against backdoors, spying, and DRM; and our legislators have only given us copyright law to try to perform legal judo with. We'll see how things work out, but I'm not optimistic with the overall GPL purge. I fear that it's taking us to a world where Black Mirror is a familiar reality instead of a fictional horror.
The GPL is a defense mechanism. OpenWrt is the source code for routers, which are quite literally the gatekeepers of the internet. It was obtained via GPL enforcement. It doesn't look like that would have happened without the GPL.
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.
Thanks for taking the time to put in such a lengthy reply. That said, I respectfully don't see the relationship between the source code license and, perhaps, what the software is used for, in particular, the social ramifications of technology that Black Mirror often addresses. The anti-sociopathic psychological nudge due to publishing source code doesn't seem very compelling to me. I'm open to being convinced otherwise.
> That said, I respectfully don't see the relationship between the source code license and, perhaps, what the software is used for, in particular, the social ramifications of technology that Black Mirror often addresses.
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.
I really liked this last bit given the reaction to the MBP:
>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.
Also, it's hard to argue that an ancient version of bash shipping in 2016 is driving away developers when they've shipped an ancient version of bash forever, and developers were lining up for Macs during most of that time.
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.
The scenario the author outlined 4 years ago was one possible outcome but it turns out he was wrong. Instead projects like homebrew have flourished and it's now easier than ever to get fresh packages for popular GPL software on macOS.
GPL is not about maximizing adoption, it's about maximizing freedom of your work and anything based upon it. It's about not having your work just stolen, embraced and extended, monopolized, and disappeared.
No it does not. For instance, if I write router code, and a vendor uses it in a product, it does not allow me to fix a bug in a product I paid for. It does not allow me to see and learn from how they did it. And given telco behavior it effectively locks me out of using my own code.
"it does not allow me to fix a bug in a product I paid for"
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)?
One of the main differences in GPLv3 versus older versions are clauses intended to make sure that this doesn't happen – this is the so-called 'Tivoisation' issue, where manufacturers are nominally compliant with the GPL (sharing changes to the code) but don't actually allow that code to be used on devices.
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.
Thanks for the clarification. Am I correct in understanding then, that with respect to the OP ("Apple's Great GPL Purge"), this wouldn't apply as the code in question isn't GPL3? And it looks like in at least the ROM case I described, the end user is not going to be able to fix it?
That's generally correct, yes. The GPL3 anti-Tivoization clauses were added specifically to deal with this sort of thing, but one of the side-effects appear to have been a reluctance on the part of hardware manufacturers to continue shipping GPL 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.
It's useful to think of the copies of BSD-licensed software as OO-style object instances.
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.
Why is the RMS definition of freedom different from 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.
The assertion that there is one general and correct notion of freedom is dubious when we hear freedom being shouted misguidedly all the time (politics stuff).
GPL ensures GPL softwares remains free of charge for the user. It isn't concerned with the person that tries to make money with GPL software. it's free as liberty, not free as "free market", though it gives the user freedom of choosing free software instead of paid one.
Not quite. The GPL ensures that GPL software remains free to audit and modify in perpetuity.
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.
There exist many companies that charge money for free software, please stop perpetuating this misrepresentation of reality. This business model has existed since the very beginning of GNU (with RMS himself selling physical copies of the Emacs source code).
Please stop perpetuating this misrepresentation that you can pay big bucks for RedHat Enterprise Linux or get the exact same software for free if you're willing to accept a name change to CentOS.
You're confusing the meaning of the word "free" here. It refers to freedom, not price. RHEL and SLE both are free software distributions (mostly) and so you have the legal right (as per their license) to distribute the software.
Right, which means that they can't base their business on selling copies of the software. They make money by selling support and access to supplemental (proprietary) resources.
GPL preserves the hacker's freedom to modify the code in the hardware they own. It doesn't preserve a corporation's freedom to take the code, package it up and sell it in some other hardware. Which licenses are more free? Depends who you are and what you're trying to do.
So lets use the definition of freedom that most philosophers use when discussing liberty and not define freedom as: 'A liberty for everyone to do what he likes, to live as he pleases, and not to be tied by any laws.'
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.
Stallman's use of "free" and "freedom" are best thought of as referring to the software, not the user. I feel like a lot of commenters below are missing this distinction.
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.
The GPL, fundamentally, is about control and restrictions. It's about specifying things you cannot do with the code, ensuring that the original author's political and social goals are retained no matter what. There's nothing inherently wrong with that, but where some people see freedom other people see restriction.
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.
The GPL, fundamentally, is about giving permission where copyright law would otherwise make illegal. It's about specifying things you can do with the code, ensuring that the original author can not sue over copyright when the copyrighted work is used within the scope of the license. Some people see freedom in this, while other people see restriction because they want more than what the license gives.
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.
Pretty well. Sony's porting of AVX, for example is pretty nice, there's a good performance boost in hand there. ARM's also made some substantial improvements to LLVM, in fact dumping their old proprietary compiler for one built around LLVM. Neither of these things would have likely happened if the two projects in question had been GPL-encumbered.
Re: compilers; as I understand it, using a GPL compiler doesn’t extend its license unto the produced binaries. Those vendors could be using GCC instead, and still contribute to its development without danger of jeopardizing their intellectual property.
I think you're missing the point of GPL, especially in regard to other licenses that you're saying are more free.
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.
This isn't the case, we use and release plenty of gplv2/3 code and LK was permissively licensed before it was adopted by the Fuschia people.
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..
I can't be sure without looking up the lists of older software that was removed, but while almost all of the remaining packages he's listed are now GPLv3 upstream, I don't think the majority of software decided to do the GPLv3 conversion - Samba, or anything that's actually under the GNU project, certainly, but I'd be surprised if all the packages (or even 99% of them) happened to have all relicensed under GPLv3.
126 comments
[ 5.3 ms ] story [ 186 ms ] threadThank 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.
as of 10.12 (opensource.apple.com not yet updated):
gnutar replaced by bsd tar
keymgr gone?
efex gone?
(gnu) make is also included
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 ...
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/
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
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.
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.
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.
>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.
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..
Apple is getting rid of Bash? When?