Apple’s great GPL purge(meta.ath0.com)
meta.ath0.com
Apple’s great GPL purge
http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/
214 comments
Make no mistake, Apple could give a rat's ass about the developer community, and why should they? We represent a vanishingly small fraction of the total consumer space and we are orders of magnitude more demanding.
That isn't necessarily true. Xcode is a very awesome IDE, it has had its growing pains but with the new clang based backend it can go far and fast. Not being reliant on older and more stagnant and more tightly coupled GCC to get there.
It is in Apple's best interest to have a compiler that is also used to do the checking of code in real time within the IDE be the same. It makes more sense because otherwise you get differing results in the IDE versus compile time. It is within Apple's best interest to help developers develop and make it easy to find issues, clang's output for errors are absolutely fantastic. If you type something wrong it provides suggestions for what you may have meant (and most of the time they are accurate).
I think Xcode is one location where Apple is showing that it does care about developers by building a better product with better integrated tools (git for example ...). Are there things we miss from the old Xcode, sure, but overall it is clear that Apple understand they need to provide developers with tools that help them get their job done.
---
Clang though is helping the ENTIRE development community. It is an BSD licensed compiler with some absolutely awesome features.
1. Their human readable error messages. I've spent a lot less time Googling random compiler failures or trying to parse GCC's or MSVC's output so that I can understand it and fix the error (especially in heavily templated C++ code) just by having the compiler give me human readable errors. This goes a long way for a developer that misplaced a semicolon or is attempting to use a const variable into some Boost code that expects a non-const variable thereby causing thousands of lines of template errors to be thrown. 2. The LLVM allows for very interesting "languages" to be easily prototyped and tested, and JIT compilation and a few other things can be created. 3. clang can read incomplete code files and make code completion suggestions. Not just tied to Xcode, but as a library. clang_complete for Vim is absolutely fantastic and by far my favourite Vim script.
---
Why exactly should Apple be required to ship GPL versions of the software when they could ship BSD licensed utilities without having to worry about being GPL compliant. Just because a few people prefer the GPL version they can't remove it from their system? They believe the GPL licensed tools to be inferior (and with the GPLv3 causes more legal headaches than it is worth) and thus they are replacing them with a set of tools that fit their requirements. Why does that mean that they "could give a rat's ass about the developer community"? Why exactly would they continue to develop clang/llvm as an open source project?
It is in Apple's best interest to have a compiler that is also used to do the checking of code in real time within the IDE be the same. It makes more sense because otherwise you get differing results in the IDE versus compile time. It is within Apple's best interest to help developers develop and make it easy to find issues, clang's output for errors are absolutely fantastic. If you type something wrong it provides suggestions for what you may have meant (and most of the time they are accurate).
I think Xcode is one location where Apple is showing that it does care about developers by building a better product with better integrated tools (git for example ...). Are there things we miss from the old Xcode, sure, but overall it is clear that Apple understand they need to provide developers with tools that help them get their job done.
---
Clang though is helping the ENTIRE development community. It is an BSD licensed compiler with some absolutely awesome features.
1. Their human readable error messages. I've spent a lot less time Googling random compiler failures or trying to parse GCC's or MSVC's output so that I can understand it and fix the error (especially in heavily templated C++ code) just by having the compiler give me human readable errors. This goes a long way for a developer that misplaced a semicolon or is attempting to use a const variable into some Boost code that expects a non-const variable thereby causing thousands of lines of template errors to be thrown. 2. The LLVM allows for very interesting "languages" to be easily prototyped and tested, and JIT compilation and a few other things can be created. 3. clang can read incomplete code files and make code completion suggestions. Not just tied to Xcode, but as a library. clang_complete for Vim is absolutely fantastic and by far my favourite Vim script.
---
Why exactly should Apple be required to ship GPL versions of the software when they could ship BSD licensed utilities without having to worry about being GPL compliant. Just because a few people prefer the GPL version they can't remove it from their system? They believe the GPL licensed tools to be inferior (and with the GPLv3 causes more legal headaches than it is worth) and thus they are replacing them with a set of tools that fit their requirements. Why does that mean that they "could give a rat's ass about the developer community"? Why exactly would they continue to develop clang/llvm as an open source project?
"I think Xcode is one location where Apple is showing that it does care about developers by building a better product with better integrated tools (git for example ...)."
I guess this is a matter of opinion. Every time I am forced (read: paid) to use Xcode for some project, not only do I dislike the fact that I have to dig out my macbook because Apple's tools don't work on any other platform, but I find actually using them painful. It's been a few months since I've used it so maybe times-are-a-changing.
The last time I used Xcode (4.0.1?), it still basically seemed that it was using the iTunes container. Of course, I have no idea how much actual codebase Xcode shares with iTunes. Apple is probably just trying to be visually consistent between their products here. But I've never been a huge fan of iTunes either. I find the menus and configuration painful.
Though it's apparent that I'm not a huge Apple fan, I'm not trying to troll anyone here. Reading your statement, I saw your praise for their developer tools and it really made me think about the fact that, while a lot of Apple's hardware is competently designed, I'm not really a fan of their software whatsoever.
Off the top of my head, I can't think of a single app they've written (besides mail.app) that I like.
And kudos for them integrating git? Since pretty much every other developer tool includes support for it, I wouldn't say this is all that exceptional.
I guess this is a matter of opinion. Every time I am forced (read: paid) to use Xcode for some project, not only do I dislike the fact that I have to dig out my macbook because Apple's tools don't work on any other platform, but I find actually using them painful. It's been a few months since I've used it so maybe times-are-a-changing.
The last time I used Xcode (4.0.1?), it still basically seemed that it was using the iTunes container. Of course, I have no idea how much actual codebase Xcode shares with iTunes. Apple is probably just trying to be visually consistent between their products here. But I've never been a huge fan of iTunes either. I find the menus and configuration painful.
Though it's apparent that I'm not a huge Apple fan, I'm not trying to troll anyone here. Reading your statement, I saw your praise for their developer tools and it really made me think about the fact that, while a lot of Apple's hardware is competently designed, I'm not really a fan of their software whatsoever.
Off the top of my head, I can't think of a single app they've written (besides mail.app) that I like.
And kudos for them integrating git? Since pretty much every other developer tool includes support for it, I wouldn't say this is all that exceptional.
"I guess this is a matter of opinion. Every time I am forced (read: paid) to use Xcode for some project, not only do I dislike the fact that I have to dig out my macbook because Apple's tools don't work on any other platform, but I find actually using them painful."
I think it all depends on what you compare XCode with, and what kind of applications you are developing.
Personally, I find all IDE's painful to use, compared to just editing with gvim and building/testing using command-line tools. The fundamental problem with IDE's is that they are supposed to integrate a complete development workflow, which is never the same workflow you are used to, and which adds layers of complexity that are usually completely unnecessary if you write your own build & test scripts, customized for each project.
That said, of all the IDE's I've used over time, XCode is easily the best. There has been a regression from XCode 3 to XCode 4 in some ways, but it's getting better. I'd say the quality of the total XCode package is on par with Visual Studio, which is saying a lot. Environments such as Netbeans or Eclipse don't even come close to XCode 4 in terms of user friendlyness, speed, and integration.
If it were even remotely possible, I'd develop iOS and OS X applications using just gvim and command-line tools, but it simply isn't possible to get all the UI work, storyboarding, CoreData model creation, etc. done without something like XCode.
Personally, I think it's very hard to maintain that XCode is not a great tool for the problems it is supposed to solve, especially if Apple gets around to fixing all the (minor) regressions they introduced with XCode 4.
I think it all depends on what you compare XCode with, and what kind of applications you are developing.
Personally, I find all IDE's painful to use, compared to just editing with gvim and building/testing using command-line tools. The fundamental problem with IDE's is that they are supposed to integrate a complete development workflow, which is never the same workflow you are used to, and which adds layers of complexity that are usually completely unnecessary if you write your own build & test scripts, customized for each project.
That said, of all the IDE's I've used over time, XCode is easily the best. There has been a regression from XCode 3 to XCode 4 in some ways, but it's getting better. I'd say the quality of the total XCode package is on par with Visual Studio, which is saying a lot. Environments such as Netbeans or Eclipse don't even come close to XCode 4 in terms of user friendlyness, speed, and integration.
If it were even remotely possible, I'd develop iOS and OS X applications using just gvim and command-line tools, but it simply isn't possible to get all the UI work, storyboarding, CoreData model creation, etc. done without something like XCode.
Personally, I think it's very hard to maintain that XCode is not a great tool for the problems it is supposed to solve, especially if Apple gets around to fixing all the (minor) regressions they introduced with XCode 4.
The tools not working on other platforms isn't an Apple only problem, though. Visual Studio is Windows only, and unless I'm missing something, there are no good cross platform IDEs for C/C++ development. At least many of the underlying XCode tools uses are cross-platform (clang, git, ...). It's more than can be said for any MS dev tool.
unless I'm missing something, there are no good
cross platform IDEs for C/C++
Not only are the IDEs buggy, not knowing what to do on even simple cases of auto-completion, but working on huge code-bases like that of Firefox is completely unfeasible, unless you deactivate all features that you'd expect from an IDE, which is why many people working on such huge code bases are better off with simple text editors, such as Vim and there are Vim/Emacs enthusiasts even on the Visual Studio team, which says a lot.
Also, when comparing XCode to Visual Studio, well Visual Studio at least runs on more than 90% of all desktops / laptops out there. And you are allowed to install Windows in VMWare or other virtualization tools. And so you can do development in Visual Studio even if you are on OS X or on Linux, granted with some hoops along the way, but it is doable. AFAIK you are disallowed by the license of OS X to install it as a virtual machine and even if possible, companies such as VMWare / Oracle / Microsoft don't even make attempts at fixing the problems with OS X, as that's not a use-case they can support.
At least many of the underlying XCode tools
uses are cross-platform (clang, git, ...)
There is Git integration with Visual Studio available: http://gitscc.codeplex.com/ ; Also, you can build your Visual Studio projects with GCC or clang for example. There's even commercial support available for debugging with GDB: http://www.wingdb.com/
"AFAIK you are disallowed by the license of OS X to install it as a virtual machine"
That changed with OS X Lion - you're now allowed to run it in a VM, and the various VM providers have support pages about it:
http://kb.vmware.com/selfservice/microsites/search.do?langua...
http://kb.parallels.com/112121
That changed with OS X Lion - you're now allowed to run it in a VM, and the various VM providers have support pages about it:
http://kb.vmware.com/selfservice/microsites/search.do?langua...
http://kb.parallels.com/112121
> For C++ there are no good IDEs period.
I challenge you to try KDevelop, which likely has the most complete C++ parser outside gcc, clang and EDG, and uses it to great effect for things like semantic syntax highlighting, smart code-completion and useful information tooltips, plus other features. It also does reasonably well on large codebases like its own, or kdelibs, or Qt - or all of those within the same session, for that matter.
Its development version also has respectable C++11 support that is probably second only to gcc.
I challenge you to try KDevelop, which likely has the most complete C++ parser outside gcc, clang and EDG, and uses it to great effect for things like semantic syntax highlighting, smart code-completion and useful information tooltips, plus other features. It also does reasonably well on large codebases like its own, or kdelibs, or Qt - or all of those within the same session, for that matter.
Its development version also has respectable C++11 support that is probably second only to gcc.
eclipse? netbeans? intelliJ? (editors: vim? emacs?)
edit: it's also easy to load a windows VM on pretty much any other platform and develop for windows, if that's what you're after. full-screen 2560x1440 virtualbox windows VM performance is actually quite nice.
if i want to use my linux laptop to develop for OSX, I am violating Apple's EULA by having a hackintosh virtualbox image. though it does work pretty well, i'd rather not have to deal with it. but i guess this is a bit off-topic.
your point is a good one. but, i guess what i'm getting at is that if i'm doing windows or linux development, i have many choices about what my hardware can be. with apple development, officially, i have only one choice: apple hardware.
edit: it's also easy to load a windows VM on pretty much any other platform and develop for windows, if that's what you're after. full-screen 2560x1440 virtualbox windows VM performance is actually quite nice.
if i want to use my linux laptop to develop for OSX, I am violating Apple's EULA by having a hackintosh virtualbox image. though it does work pretty well, i'd rather not have to deal with it. but i guess this is a bit off-topic.
your point is a good one. but, i guess what i'm getting at is that if i'm doing windows or linux development, i have many choices about what my hardware can be. with apple development, officially, i have only one choice: apple hardware.
[deleted]
Qt Creator is quite good for C++, cross platform, +free.
http://qt.nokia.com/products/developer-tools/
IMHO it is the best there is for Linux, and better for C++ than XCode.
IMHO it is the best there is for Linux, and better for C++ than XCode.
Clang is one side, but the other side is things like bash. Apple isn't developing a superior, BSD-licensed shell; they're just planning to ship the same old version of bash until the end of time. Some parts of OS X are getting better but other parts are stagnating.
What crystal ball are you looking at that says they are going to continue shipping bash? zsh is a viable replacement that is MIT licensed ...
There are plenty of other shells out there as well that they could replace bash with. Bash isn't the end all be-all of shells.
There are plenty of other shells out there as well that they could replace bash with. Bash isn't the end all be-all of shells.
The good side is that with zsh and some other software getting their place in OS/X; Linux and OSX communities will diverge away from each other. I kind of like this as a Linux user and developer. With OS/X or Apple we share so little in principles (read a lot of comments here), vision and development(now) and it is good if we end up being 2 mutually exclusive ecosystem similar to Windows/Linux.
Being a former Apple employee and having enjoyed Apple's ditching of the classic Mac OSes for OS/X, both worlds have had pretty much similar environments. After 2012 the Apple and Linux development communities appear to be totally accelerating in different directions.
Being a former Apple employee and having enjoyed Apple's ditching of the classic Mac OSes for OS/X, both worlds have had pretty much similar environments. After 2012 the Apple and Linux development communities appear to be totally accelerating in different directions.
OS X and Linux never shared a common parent or converged. The BSD heritage is what makes it Unixy. BSD has been oil to Linux's water for a long time.
For Linux and OS/X, noone said they share common parent; the shared common tools such as bash, samba and a lot of stuff removed as mentioned by this article will create diverging ecosystems (and before replying watch out, noone says diverging kernels).
You can still install those common tools if you wish. Just like on FreeBSD you don't get bash by default...
They're not developing a BSD-licensed shell because they already ship zsh.
In early versions of OSX (I think till Panther?) tcsh was even the default shell. They should revert to that again if they are shipping bash support only as a legacy kind of thing.
Edit: But I guess shells are boring business. According to Wikipedia Bash 4.0 brought support for "associative arrays". shrug Those who care about that are able to get the most recent version by their own.
Edit: But I guess shells are boring business. According to Wikipedia Bash 4.0 brought support for "associative arrays". shrug Those who care about that are able to get the most recent version by their own.
XCode is actually pretty horrible as IDEs go. It doesn't even have a solid plugin architecture. When will you see vi/vim plugin for XCode? That makes it pretty much a toy and unusable.
Honestly, XCode is pretty horrible when compared to even Eclipse.
Honestly, XCode is pretty horrible when compared to even Eclipse.
Not entirely true. Xcode does have a plugin model; just explore the Xcode developer install and you'll find it is entirely built up via plugins. Unfortunately, Apple have chosen not to document it or make it public.
is this really an argument against what super_mario says? when he says it doesnt have a plugin architecture of course he means extendibility by everyone.
Developers are also disproportionately useful for a platform, since they're the ones who build the stuff people want to use; for more on that, see http://joelonsoftware.com/articles/APIWar.html , as well as the bazillion other writers pointing out similar things.
Although there is some truth in it, I think that Apple is following a different strategy. They don't really attract developers by a developer-friendly environment, but by the number of worthy users of their platform.
Regarding the embedded devices (i.e. iOS, App Store, etc.) you could even call this a developer-hostile environment. Yet there are lots of developers taking this hassle just to get access to Apple's user base.
Regarding the embedded devices (i.e. iOS, App Store, etc.) you could even call this a developer-hostile environment. Yet there are lots of developers taking this hassle just to get access to Apple's user base.
> Apple could give a rat's ass about the developer community, and why should they? We represent a vanishingly small fraction of the total consumer space and we are orders of magnitude more demanding.
This is a popular refrain, but I don't think it holds up well at all under scrutiny:
1. By your logic, who should care about developers? Only open source projects or ISVs? And yet everyone does, a lot.
2. iOS platform developers buy Macs (and often multiple iOS devices) to develop iOS apps.
3. Xcode, warts and all, is basically free. Same with all of the OS X and iOS developer documentation. Have you priced Visual Studio or an MSDN subscription lately?
4. No one who feels this way has had Quinn the Eskimo answer a Core OS or Networking question for them in the Apple Dev Forums. If you don't care about developers, you don't pay folks like him to dispense wisdom to a bunch of yahoos who each paid $99/year.
This is a popular refrain, but I don't think it holds up well at all under scrutiny:
1. By your logic, who should care about developers? Only open source projects or ISVs? And yet everyone does, a lot.
2. iOS platform developers buy Macs (and often multiple iOS devices) to develop iOS apps.
3. Xcode, warts and all, is basically free. Same with all of the OS X and iOS developer documentation. Have you priced Visual Studio or an MSDN subscription lately?
4. No one who feels this way has had Quinn the Eskimo answer a Core OS or Networking question for them in the Apple Dev Forums. If you don't care about developers, you don't pay folks like him to dispense wisdom to a bunch of yahoos who each paid $99/year.
1. Pretty much just open source projects or ISVs, and I think you'll find "everyone" gets a lot smaller the further you get from the Valley.
2. No disrespect intended but BFD? Are you proposing that developer hardware purchases represent anything besides a rounding error in Apple's hardware sales?
3. I see Xcode's pay-to-upgrade model and $99/yr developer subscriptions as a variation on the MSDN/Visual Studios theme.
4. Wait, what? Cult of Personality issues aside, we're talking about a company that's pulling in billions in profits quarterly nickle-and-diming their developer community. How is this beneficial to developers again?
2. No disrespect intended but BFD? Are you proposing that developer hardware purchases represent anything besides a rounding error in Apple's hardware sales?
3. I see Xcode's pay-to-upgrade model and $99/yr developer subscriptions as a variation on the MSDN/Visual Studios theme.
4. Wait, what? Cult of Personality issues aside, we're talking about a company that's pulling in billions in profits quarterly nickle-and-diming their developer community. How is this beneficial to developers again?
1. I think you underestimate the amount of dev talent being consumed outside of "software companies", for a wide variety of platforms (including desktops).
2. Fair point, but are you proposing Apple doesn't care whether devs buy Android and WinMo devices instead? None of these platforms are fighting for developer attention in a vacuum, but they are fighting for developer attention.
3. Xcode charging $5 to upgrade is quite a "variation" on that theme indeed. $99/year dev subscriptions, again, are outside MSDN theme-level fees by an order of magnitude.
4. My point is that if you're paying $0.30 per day to rent a Ferrari, Ferrari is not "nickel-and-diming" you. Is "totally free" the only fee level at which you're interested in consuming tools and developer support? Do you make such decisions for an organization with money riding on the results?
2. Fair point, but are you proposing Apple doesn't care whether devs buy Android and WinMo devices instead? None of these platforms are fighting for developer attention in a vacuum, but they are fighting for developer attention.
3. Xcode charging $5 to upgrade is quite a "variation" on that theme indeed. $99/year dev subscriptions, again, are outside MSDN theme-level fees by an order of magnitude.
4. My point is that if you're paying $0.30 per day to rent a Ferrari, Ferrari is not "nickel-and-diming" you. Is "totally free" the only fee level at which you're interested in consuming tools and developer support? Do you make such decisions for an organization with money riding on the results?
Developers make the software that goes on their platform. Microsoft didn't gain their huge market share in the 90s through magical spells; they won by being extremely developer-friendly. Without a "developer community", Apple wouldn't exist as a company.
How many billions have Apple already paid out to iOS and Mac App Store developers?
How many attendees did they have at WWDC?
Getting rid of GPL in now way means getting rid of developers.
> So, which of those things are they planning for OS X, eh?
Fairly, clear I would have thought. There is substantial overlap between the OS X and iOS codebases. Having anti- TiVoization clauses in code central to OS X poses problems whenever they want to use a funky feature in iOS, or indeed on the AppleTV. It makes things much simpler if this type of code can be avoided.
Fairly, clear I would have thought. There is substantial overlap between the OS X and iOS codebases. Having anti- TiVoization clauses in code central to OS X poses problems whenever they want to use a funky feature in iOS, or indeed on the AppleTV. It makes things much simpler if this type of code can be avoided.
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?
Apple has made fantastic amounts of money and become the daring of the media & tech world since they went down the route of the closed iPhone/iOS buisiness.
Apple has made fantastic amounts of money and become the daring of the media & tech world since they went down the route of the closed iPhone/iOS buisiness.
Apple's failure to update GNU software was actively impacting the security of OS X. Charlie Miller made mincemeat of OS X because of the sorry state of security of 3rd party utilities (http://rixstep.com/1/20080422,00.shtml).
As Charlie Miller noted in his '07 BH presentation: (https://www.blackhat.com/presentations/bh-usa-07/Miller/Pres...)
How to Find a Mac OS X 0-Day:
1) Find some open source package they use that is out of date
2) Read the change log for that software
3) Find a good bug
4) Profit!
"The Samba on Mac OS X (on Monday) had an exploitable remote root vulnerability in it...it hadn’t been updated since February 2005!"
If anything, Apple removing GPL software creates a better situation, because fink/macports/homebrew will be available to pick up the slack and provide more timely updates.
Plus, it seems like FreeBSD is trying to get rid of as much GNU stuff as they can, so that more of what they release is covered under a BSD license (see BSD grep, for example). It may be that Apple is just picking up some of these changes from FreeBSD and doing a little bit of housekeeping on their end.
As Charlie Miller noted in his '07 BH presentation: (https://www.blackhat.com/presentations/bh-usa-07/Miller/Pres...)
How to Find a Mac OS X 0-Day:
1) Find some open source package they use that is out of date
2) Read the change log for that software
3) Find a good bug
4) Profit!
"The Samba on Mac OS X (on Monday) had an exploitable remote root vulnerability in it...it hadn’t been updated since February 2005!"
If anything, Apple removing GPL software creates a better situation, because fink/macports/homebrew will be available to pick up the slack and provide more timely updates.
Plus, it seems like FreeBSD is trying to get rid of as much GNU stuff as they can, so that more of what they release is covered under a BSD license (see BSD grep, for example). It may be that Apple is just picking up some of these changes from FreeBSD and doing a little bit of housekeeping on their end.
> It's not like Apple were keeping this stuff updated
Well, obviously as the major point of the article is that Apple clearly refuses to ship software covered by GPLv3, so you're getting the rapidly ancient, last GPLv2 versions. It's quite a rare exception for updated GNU software to be available under GPLv2--the FSF basically moved their entire code base from GPLv2+ to GPLv3+ when GPLv3 was released and that has cascading effects since GPLv2 and GPLv3 are incompatible. I was unaware of the sorry state of things on MacOS actually as I don't use Apple products, but it at least enlightened me about all the bash bashing we tend to see on HN.
Well, obviously as the major point of the article is that Apple clearly refuses to ship software covered by GPLv3, so you're getting the rapidly ancient, last GPLv2 versions. It's quite a rare exception for updated GNU software to be available under GPLv2--the FSF basically moved their entire code base from GPLv2+ to GPLv3+ when GPLv3 was released and that has cascading effects since GPLv2 and GPLv3 are incompatible. I was unaware of the sorry state of things on MacOS actually as I don't use Apple products, but it at least enlightened me about all the bash bashing we tend to see on HN.
Yeah, I recently realized why various bash examples I tried out don't work on OSX. I guess it's an obvious thing to check, but somehow it never occurred to me that OSX's bash would be five years old.
Also worth noting, osx uses bsd versions of various utilities like grep and sed, instead of gnu counterparts
Interesting sidenote: http://lists.freebsd.org/pipermail/freebsd-current/2010-Augu...
Interesting sidenote: http://lists.freebsd.org/pipermail/freebsd-current/2010-Augu...
Some bash examples contains Linuxisms that is not UNIX-03 compliant which OS X is in full, might be that as well.
GPL2 and GPL3 are compatible. You just can't make GPL2 derivatives of GPL3 software.
No, they are not unfortunately. From the FAQ:
"Is GPLv3 compatible with GPLv2? (#v2v3Compatibility)
No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2.
However, if code is released under GPL “version 2 or later,” that is compatible with GPLv3 because GPLv3 is one of the options it permits."
http://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility
"Is GPLv3 compatible with GPLv2? (#v2v3Compatibility)
No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2.
However, if code is released under GPL “version 2 or later,” that is compatible with GPLv3 because GPLv3 is one of the options it permits."
http://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility
to upgrade bash on OS X: brew install bash then follow directions at [1]
[1] http://concisionandconcinnity.blogspot.com/2009/03/upgrade-b...
[1] http://concisionandconcinnity.blogspot.com/2009/03/upgrade-b...
I use MacPorts and "oh-my-Zsh"... but thinking about it, it should not be all that hard to update all of the outdated GNU stuff in Mac OS... but I don't think the system would actually use the updated stuff, so the security problems probably would still remain.
"The Samba on Mac OS X (on Monday) had an exploitable remote root vulnerability in it...it hadn’t been updated since February 2005!"
If anything, Apple removing GPL software creates a better situation, because fink/macports/homebrew will be available to pick up the slack and provide more timely updates.
Plus, it seems like FreeBSD is trying to get rid of as much GNU stuff as they can, so that more of what they release is covered under a BSD license (see BSD grep, for example). It may be that Apple is just picking up some of these changes from FreeBSD and doing a little bit of housekeeping on their end.
First, a nit pick: Samba doesn't exist on current releases of Mac OS X. They've rewritten their SMB stack and it's under a dual BSD/ASPL license: http://opensource.apple.com/source/smb/smb-552.3/
Second: bingo.
Why should Apple relinquish any control over their platform? If their eyes, removing GPL code reduces risk to their platform. There's going to be a constant fear that GPL code could "contaminate" non-GPL code. Why bother?
As you note, other BSD platforms are undertaking the same endeavor, so Apple's not alone and can support that effort. Which seems to be exactly what they're doing. They remove a perceived major risk to their products and continue helping the OSS community.
Finally, again as you note, there are better ways to keep rarely used software up to date. (Rarely used by the majority of Apple's user base.) I bet Apple desperately wants to get out of the business of shipping updates to command-line-only software, just as they've gotten out of the business of shipping Flash and Java updates. Why should they exert significant effort to try and update software that's rarely used on their platform and is better kept up to date via other mechanisms. Apple can provide the base, and anyone who needs OSS libraries, utilities or apps not provided by that base can use something like Homebrew and much more easily stay up to date. And if Apple stops vending that software, systems like Homebrew are far less likely to be broken by Apple OS updates. Win-win.
If anything, Apple removing GPL software creates a better situation, because fink/macports/homebrew will be available to pick up the slack and provide more timely updates.
Plus, it seems like FreeBSD is trying to get rid of as much GNU stuff as they can, so that more of what they release is covered under a BSD license (see BSD grep, for example). It may be that Apple is just picking up some of these changes from FreeBSD and doing a little bit of housekeeping on their end.
First, a nit pick: Samba doesn't exist on current releases of Mac OS X. They've rewritten their SMB stack and it's under a dual BSD/ASPL license: http://opensource.apple.com/source/smb/smb-552.3/
Second: bingo.
Why should Apple relinquish any control over their platform? If their eyes, removing GPL code reduces risk to their platform. There's going to be a constant fear that GPL code could "contaminate" non-GPL code. Why bother?
As you note, other BSD platforms are undertaking the same endeavor, so Apple's not alone and can support that effort. Which seems to be exactly what they're doing. They remove a perceived major risk to their products and continue helping the OSS community.
Finally, again as you note, there are better ways to keep rarely used software up to date. (Rarely used by the majority of Apple's user base.) I bet Apple desperately wants to get out of the business of shipping updates to command-line-only software, just as they've gotten out of the business of shipping Flash and Java updates. Why should they exert significant effort to try and update software that's rarely used on their platform and is better kept up to date via other mechanisms. Apple can provide the base, and anyone who needs OSS libraries, utilities or apps not provided by that base can use something like Homebrew and much more easily stay up to date. And if Apple stops vending that software, systems like Homebrew are far less likely to be broken by Apple OS updates. Win-win.
For what it’s worth, the guy who writes Rixstep.com is a vitriolic asshole who has been periodically bashing nice projects for incredibly lame reasons for a decade now, and who seems to bear unreasonable grudges and fixate on them.
What he’s saying in this particular example might be legitimate, but he’s just not a credible source, in general.
What he’s saying in this particular example might be legitimate, but he’s just not a credible source, in general.
I've been a Apple & FreeBSD user for decades and it really looks to me like Apple is coming up for a long cycle of public and embarrassing security failures because of this...
Or perhaps I should say, I don't think Apple is going to either update the lagging GNU utilities to current or put for the effort to migrate to current BSD alternatives until they have a protracted public shaming which demonstrably impacts the bottom line of iOS sales. Which sort of reminds me of what MS went through before they started taking security more seriously. (I haven't used Windows in years, so I can't really comment on the state of MS security today).
Which is a shame because there is a lot of opportunity in the eddies of GNU, BSD, and Darwin. We all could benefit from an Apple sponsored security focused FOSS code review / bug hunt / development effort. Sort of like what Google does only focused on Security.
Or perhaps I should say, I don't think Apple is going to either update the lagging GNU utilities to current or put for the effort to migrate to current BSD alternatives until they have a protracted public shaming which demonstrably impacts the bottom line of iOS sales. Which sort of reminds me of what MS went through before they started taking security more seriously. (I haven't used Windows in years, so I can't really comment on the state of MS security today).
Which is a shame because there is a lot of opportunity in the eddies of GNU, BSD, and Darwin. We all could benefit from an Apple sponsored security focused FOSS code review / bug hunt / development effort. Sort of like what Google does only focused on Security.
I don't think that is the case, there won't be a requirement for public shaming, Apple is already removing more and more GPL licensed tools each release cycle and it won't be long until they are using more up-to-date BSD licensed tools.
Also, one thing I have noticed is that Apple has started reacting faster to security threats and is at least willing to acknowledge the researchers behind them in their updates, which is much better compared to what previously happened. Not only that but before Lion was released many security researchers received an advanced copy.
The other thing is that almost all of the GPL utilities are command line utilities and are not shipped with iOS so even if there are vulnerabilities in them it is highly unlikely that there will be a target painted on iOS's back. I don't foresee that there will be any major impact on their iOS product line.
Also, one thing I have noticed is that Apple has started reacting faster to security threats and is at least willing to acknowledge the researchers behind them in their updates, which is much better compared to what previously happened. Not only that but before Lion was released many security researchers received an advanced copy.
The other thing is that almost all of the GPL utilities are command line utilities and are not shipped with iOS so even if there are vulnerabilities in them it is highly unlikely that there will be a target painted on iOS's back. I don't foresee that there will be any major impact on their iOS product line.
Actually what I was inferring is that between the rate of migration from older GNU tools to current BSD tools and the rate of response for security issues would combine to create a series of security failures in Mac OS. If that went on long enough and is publicized enough, it will effect iOS simply by guilt by association.
Certainly I have also noticed a slight improvement on the way Apple handles security problems but I don't really think it's an adequate response. More importantly I have the general impression that long term Apple is moving away from Mac OS & workstations and towards iOS & devices. So them ignoring Mac OS problems or becoming slower to react on them would not really surprise me... at least until people started to view iOS in an equally negative light because of it.
In any event, I honestly wish that Apple would maintain a larger presence in the FOSS community and put more effort into a more positive two way relationship.
Certainly I have also noticed a slight improvement on the way Apple handles security problems but I don't really think it's an adequate response. More importantly I have the general impression that long term Apple is moving away from Mac OS & workstations and towards iOS & devices. So them ignoring Mac OS problems or becoming slower to react on them would not really surprise me... at least until people started to view iOS in an equally negative light because of it.
In any event, I honestly wish that Apple would maintain a larger presence in the FOSS community and put more effort into a more positive two way relationship.
> In any event, I honestly wish that Apple would maintain a larger presence in the FOSS community and put more effort into a more positive two way relationship.
With respect, I think that what you really mean is that you wish they would have a greater presence in the FSF-adherent "free" software community. Their credentials in the open-source world are pretty well burnished: Bonjour, Darwin, WebKit, LLVM and Clang, and so on. They do not, however, care much for the GPL, and I do not blame them.
With respect, I think that what you really mean is that you wish they would have a greater presence in the FSF-adherent "free" software community. Their credentials in the open-source world are pretty well burnished: Bonjour, Darwin, WebKit, LLVM and Clang, and so on. They do not, however, care much for the GPL, and I do not blame them.
Apple have always acknowledged whoever found any exploits in their OS. It may not be in the update docs, but it is in the security-announce mailing list Apple uses for all updates that have security fixes. https://lists.apple.com/mailman/listinfo/security-announce
I've been a Apple & FreeBSD user for decades and it really looks to me like Apple is coming up for a long cycle of public and embarrassing security failures because of this...
Apple isn't going to allow Mac OS X security to degrade. Apple does a lot of behind the scenes activity with security that they don't talk about much.
Every Mac OS X and iOS update addresses many security vulnerabilities; here's the list for 10.7.3 as an example: http://support.apple.com/kb/HT5130
Apple isn't going to allow Mac OS X security to degrade. Apple does a lot of behind the scenes activity with security that they don't talk about much.
Every Mac OS X and iOS update addresses many security vulnerabilities; here's the list for 10.7.3 as an example: http://support.apple.com/kb/HT5130
I am only using Linux on both server and client and I am happy to have a consistent development experience since 6 years.
I am interested why isnt just Apple or just FreeBSD enough for your purposes? Why do you need to use both? Just as a hobby or do both have any use special case?
I am interested why isnt just Apple or just FreeBSD enough for your purposes? Why do you need to use both? Just as a hobby or do both have any use special case?
Personally, I use FreeBSD for anything that's headless, and OS X is the only OS I'll touch for a desktop. FreeBSD makes for a fantastic, consistent experience for servers of all kinds, and OS X has everything I could want on a desktop. (I do still use bootcamp occasionally for games, but that is getting rarer)
but the question is why can't you use OS/X for server and BSD for desktop?
This comes as no surprise at all. At least to those of us who have been looking at the various BSD projects, and how businesses are shunning the GPLv3.
On paper the GPLv3 is awesome, but it adds some major restrictions that make it unappealing to corporations. I did some contract work for a company whose lawyers forbid the use of LGPL'ed libraries in their software even-though it means re-inventing the wheel a couple of times or using inferior libraries. They were deadly afraid that their code would somehow become infected and that they would have to open source they wouldn't allow it. Quite a bit of the code I ended up writing was later released under the BSD license free for use by the world, and one could replicate their product with their own libraries and a couple of weekends. (Company not named because 1, my name isn't attached to it so it won't be easy to find, and 2, I am under NDA still)
Why wouldn't it be in Apple's best interest to use BSD replacements for GPL licensed software if those are available and are comparable. Apple's LLVM/clang compiler for example is available under a BSD license and even-though they hired the project lead the entire project is still open source and being openly developed. There has in the past (I haven't paid attention lately) been code sharing between Apple's Darwin Kernel/Userland back to FreeBSD and vice-versa.
The same movement to remove GPL licensed software is being done in two major BSD based projects, FreeBSD and OpenBSD. Both for very different reasons but with the same end result. I don't necessarily think this is a bad thing, more competition is a good thing.
I am still hoping that FreeBSD picks up the CIFS stuff that Sun released with OpenIndiana because it works much faster/better compared to Samba and I've had WAY less issues with it.
The GPL isn't so much fostering or creating an atmosphere for open source development, it creates traps and makes it harder to use the end product. btrfs will most likely never be available within any OS other than Linux. Isn't that the opposite of what you'd want as an open source developer, isn't the idea to spread your code as far and wide as possible, to have people use it no matter where? ZFS by comparison is available in FreeBSD, it is now available on Linux and Mac OS X. If I release something as open source I want people to use it, modify it, play with it and spread it around as far and wide. Would I like for people to contribute their changes, absolutely, but do I think that forcing them to do so under a license is the best way to go about asking for changes? No.
On paper the GPLv3 is awesome, but it adds some major restrictions that make it unappealing to corporations. I did some contract work for a company whose lawyers forbid the use of LGPL'ed libraries in their software even-though it means re-inventing the wheel a couple of times or using inferior libraries. They were deadly afraid that their code would somehow become infected and that they would have to open source they wouldn't allow it. Quite a bit of the code I ended up writing was later released under the BSD license free for use by the world, and one could replicate their product with their own libraries and a couple of weekends. (Company not named because 1, my name isn't attached to it so it won't be easy to find, and 2, I am under NDA still)
Why wouldn't it be in Apple's best interest to use BSD replacements for GPL licensed software if those are available and are comparable. Apple's LLVM/clang compiler for example is available under a BSD license and even-though they hired the project lead the entire project is still open source and being openly developed. There has in the past (I haven't paid attention lately) been code sharing between Apple's Darwin Kernel/Userland back to FreeBSD and vice-versa.
The same movement to remove GPL licensed software is being done in two major BSD based projects, FreeBSD and OpenBSD. Both for very different reasons but with the same end result. I don't necessarily think this is a bad thing, more competition is a good thing.
I am still hoping that FreeBSD picks up the CIFS stuff that Sun released with OpenIndiana because it works much faster/better compared to Samba and I've had WAY less issues with it.
The GPL isn't so much fostering or creating an atmosphere for open source development, it creates traps and makes it harder to use the end product. btrfs will most likely never be available within any OS other than Linux. Isn't that the opposite of what you'd want as an open source developer, isn't the idea to spread your code as far and wide as possible, to have people use it no matter where? ZFS by comparison is available in FreeBSD, it is now available on Linux and Mac OS X. If I release something as open source I want people to use it, modify it, play with it and spread it around as far and wide. Would I like for people to contribute their changes, absolutely, but do I think that forcing them to do so under a license is the best way to go about asking for changes? No.
>'The GPL isn't so much fostering or creating an atmosphere for open source development, it creates traps and makes it harder to use the end product. '
Of course it is, it actually ENSURES that the source code stays OPEN. 'traps'??
>'Isn't that the opposite of what you'd want as an open source developer, isn't the idea to spread your code as far and wide as possible, to have people use it no matter where?'
I believe a huge amount of programmers want to provide open source code to open source code projects, not for proprietary projects. Which is why GPL is such a popular licence.
Apple wants to incorporate open source into their proprietary products, that is why they don't like GPL. Apple sponsoring Clang/LLVM development makes perfect sense since they are stuck at gcc 4.2.1 due to not accepting GPLv3, and they will eventually need to update their compiler toolchain (gcc 4.2 branch is old).
Don't take me wrong, I think Clang/LLVM are great projects and although the compile speed advantage it had over GCC has diminshed greatly it's error reporting/diagnostics is really 'best of class' amongst the compilers I've used. The speed of the generated code lags behind gcc however, and it also lacks advanced optimizations such as pgo (profile guided optimization).
I look at it as a great alternative, but GCC remains my main compiler toolchain, partly because of the licence which ensures that all the enhancements done to it will be available to me as an end user but also because of the strong developer support it has from companies like Red Hat, IBM, Google, etc employing full-time developers working solely on GCC.
Of course it is, it actually ENSURES that the source code stays OPEN. 'traps'??
>'Isn't that the opposite of what you'd want as an open source developer, isn't the idea to spread your code as far and wide as possible, to have people use it no matter where?'
I believe a huge amount of programmers want to provide open source code to open source code projects, not for proprietary projects. Which is why GPL is such a popular licence.
Apple wants to incorporate open source into their proprietary products, that is why they don't like GPL. Apple sponsoring Clang/LLVM development makes perfect sense since they are stuck at gcc 4.2.1 due to not accepting GPLv3, and they will eventually need to update their compiler toolchain (gcc 4.2 branch is old).
Don't take me wrong, I think Clang/LLVM are great projects and although the compile speed advantage it had over GCC has diminshed greatly it's error reporting/diagnostics is really 'best of class' amongst the compilers I've used. The speed of the generated code lags behind gcc however, and it also lacks advanced optimizations such as pgo (profile guided optimization).
I look at it as a great alternative, but GCC remains my main compiler toolchain, partly because of the licence which ensures that all the enhancements done to it will be available to me as an end user but also because of the strong developer support it has from companies like Red Hat, IBM, Google, etc employing full-time developers working solely on GCC.
I believe a huge amount of programmers want to provide open source code to open source code projects, not for proprietary projects.
Why not? Worst case scenario, some people use their software without giving anything back. Best case scenario, improvements find their way back into their code. But none of this can happen if the license is prohibitive.
Why not? Worst case scenario, some people use their software without giving anything back. Best case scenario, improvements find their way back into their code. But none of this can happen if the license is prohibitive.
Worst case scenario, some person/group/company takes you code and makes it a million times better. But keeps it for themselves.
So what?
In that case they created a great value for someone (users).
No imagine if the code was released under more restrictive license. They don't use, they create nothing greater, and users don't get better product. Whose win is this exactly?
Because that's a false dichotomy. Corporations will always prefer BSD code to GPL code. But there are many examples of corporations contributing GPL code to GPL projects. If the same projects were BSD licensed, then the corporation might have just forked them and their improvements would then not have been made widely available.
You just gave another false dichotomy. Just because a corporation looks to use BSD licensing doesn't mean it won't contribute back. You're attempting to derive intent from a license choice. It's not that simple.
> You just gave another false dichotomy.
No, I didn't. Notice how I used words like "might", implying that the scenario I described is but one of many plausible scenarios.
Certainly corporations contribute code to BSD-licensed projects. But equally certain is the fact that some corporations contribute code to GPL-licensed projects when they otherwise would have kept their code to themselves if they weren't legally compelled to open it.
No, I didn't. Notice how I used words like "might", implying that the scenario I described is but one of many plausible scenarios.
Certainly corporations contribute code to BSD-licensed projects. But equally certain is the fact that some corporations contribute code to GPL-licensed projects when they otherwise would have kept their code to themselves if they weren't legally compelled to open it.
It's their right. I really can't understand why people find this bad in any way.
If they don't want to contribute, but they are capable of improving the code and making tons of money, great for them.
Developer doesn't really lose anything.
If they don't want to contribute, but they are capable of improving the code and making tons of money, great for them.
Developer doesn't really lose anything.
It's a philosophical issue. The original developer who uses GPL often thinks of what they are doing as gifting their work to the world. Having it sequestered into a money making project is rather like seeing the birthday present you bought for a friend sold on Ebay.
They didn't lose anything, but they didn't gain anything either. If they had GPL'd their project, they would have gained improvements. So by choosing the BSD license they've lost potential gains. So it is seen by many as a loss.
Scenario A:
I make my code BSD. A company eagerly writes some proprietary improvements, and then goes bankrupt. Its code is a dead end.
Scenario B:
I make my code GPL. A company grudgingly writes some GPLed improvements, and then goes bankrupt. The community benefits from their improvements.
I make my code BSD. A company eagerly writes some proprietary improvements, and then goes bankrupt. Its code is a dead end.
Scenario B:
I make my code GPL. A company grudgingly writes some GPLed improvements, and then goes bankrupt. The community benefits from their improvements.
The company in scenario A isn't the same one in scenario B. If a company isn't going to contribute their improvements to a BSD project, what makes you think they're going to open-source their entire code base just to "grudgingly" use a GPL project?
How do you know they aren't the same company? Who said anything about "their entire code base"? As this article says, Apple distributes plenty of GPL software. Did they release their entire code base?
Let me contrive a hypothetical, if it's still not clear to you...
Imagine you're a ruthless corporation and you don't care at all about the open source community. There is an open source software package that solves 95% of a problem for you.
If it's BSD, you will probably take it, write that 5%, use it, and not contribute anything back.
If it's GPL, you will probably take it, write that 5%, use it, and then grudgingly release that 5% back to the community so you don't get sued.
Note that I'm not saying GPL is always the best option and BSD is always worse. I'm just pointing out that, in your previous post, you miss out on one of the advantages of the GPL: it can encourage the release of open source code that otherwise would not have happened.
Let me contrive a hypothetical, if it's still not clear to you...
Imagine you're a ruthless corporation and you don't care at all about the open source community. There is an open source software package that solves 95% of a problem for you.
If it's BSD, you will probably take it, write that 5%, use it, and not contribute anything back.
If it's GPL, you will probably take it, write that 5%, use it, and then grudgingly release that 5% back to the community so you don't get sued.
Note that I'm not saying GPL is always the best option and BSD is always worse. I'm just pointing out that, in your previous post, you miss out on one of the advantages of the GPL: it can encourage the release of open source code that otherwise would not have happened.
Or, if it's GPL, you won't take it, and you will write your own in-house version which you'll never release. That is the more likely scenario.
You're presenting a bit of a false dichotomy. If a company that's adamant against open-sourcing their work can't use a GPL solution, they're not going to shrug their shoulders, use it anyway, and then release their changes. They're going to spend more money on an in-house solution because they have complete control over it and know it won't bite them in the ass in the future.
You're presenting a bit of a false dichotomy. If a company that's adamant against open-sourcing their work can't use a GPL solution, they're not going to shrug their shoulders, use it anyway, and then release their changes. They're going to spend more money on an in-house solution because they have complete control over it and know it won't bite them in the ass in the future.
> Or, if it's GPL, you won't take it, and you will write your own in-house version which you'll never release.
Yes, that's why I said "probably", not "definitely". It's misleading to ignore both possibilities and pretend that only one will ever happen. That's why I made my original post.
> You're presenting a bit of a false dichotomy.
Only if you misread my post.
> If a company that's adamant against open-sourcing their work can't use a GPL solution, they're not going to shrug their shoulders, use it anyway, and then release their changes.
If they're "adamant against open-sourcing their work", then by definition they will never open source anything. So? That's not the type of corporation I was talking about in my post.
Yes, that's why I said "probably", not "definitely". It's misleading to ignore both possibilities and pretend that only one will ever happen. That's why I made my original post.
> You're presenting a bit of a false dichotomy.
Only if you misread my post.
> If a company that's adamant against open-sourcing their work can't use a GPL solution, they're not going to shrug their shoulders, use it anyway, and then release their changes.
If they're "adamant against open-sourcing their work", then by definition they will never open source anything. So? That's not the type of corporation I was talking about in my post.
> It's misleading to ignore both possibilities and pretend that only one will ever happen.
Then why did you ignore the third possibility?
> Only if you misread my post.
No, that's pretty much the definition of a false dichotomy. You only provided two scenarios when there exist more.
> That's not the type of corporation I was talking about in my post.
Then what did you mean by:
> Imagine you're a ruthless corporation and you don't care at all about the open source community.
Then why did you ignore the third possibility?
> Only if you misread my post.
No, that's pretty much the definition of a false dichotomy. You only provided two scenarios when there exist more.
> That's not the type of corporation I was talking about in my post.
Then what did you mean by:
> Imagine you're a ruthless corporation and you don't care at all about the open source community.
> Then why did you ignore the third possibility?
I didn't. I was contriving a hypothetical to illustrate how the GPL can produce a positive result in some cases that BSD-like licenses cannot. That's why I started my post with "Let me contrive a hypothetical".
I even explicitly pointed this out at the end of my post by saying, "Note that I'm not saying GPL is always the best option and BSD is always worse. I'm just pointing out that, in your previous post, you miss out on one of the advantages of the GPL: it can encourage the release of open source code that otherwise would not have happened."
I did this because I knew that otherwise someone would misinterpret my post as saying the GPL is universally perfect in all situations, or that the situation I described in my contrived hypothetical was the only possible situation that could ever occur. I'm not sure how I could have made that more clear.
> > That's not the type of corporation I was talking about in my post.
> Then what did you mean by:
> > Imagine you're a ruthless corporation and you don't care at all about the open source community.
A ruthless corporation that doesn't care about the open source community (which I think describes most corporations, FWIW) is very different than "a company that's adamant against open-sourcing". The former will contribute open source code when it is in their economic best interest, but they won't go out of their way to play nice with the open source folks. The latter will sacrifice their economic interests just to stick to their ideology.
I didn't. I was contriving a hypothetical to illustrate how the GPL can produce a positive result in some cases that BSD-like licenses cannot. That's why I started my post with "Let me contrive a hypothetical".
I even explicitly pointed this out at the end of my post by saying, "Note that I'm not saying GPL is always the best option and BSD is always worse. I'm just pointing out that, in your previous post, you miss out on one of the advantages of the GPL: it can encourage the release of open source code that otherwise would not have happened."
I did this because I knew that otherwise someone would misinterpret my post as saying the GPL is universally perfect in all situations, or that the situation I described in my contrived hypothetical was the only possible situation that could ever occur. I'm not sure how I could have made that more clear.
> > That's not the type of corporation I was talking about in my post.
> Then what did you mean by:
> > Imagine you're a ruthless corporation and you don't care at all about the open source community.
A ruthless corporation that doesn't care about the open source community (which I think describes most corporations, FWIW) is very different than "a company that's adamant against open-sourcing". The former will contribute open source code when it is in their economic best interest, but they won't go out of their way to play nice with the open source folks. The latter will sacrifice their economic interests just to stick to their ideology.
If they don't want to contribute any coding work back to the community at large, then let them start from scratch and build something they have full control over. I don't see why the open-source community should have to accommodate them if they're not going to contribute back to that community.
I've seen that happen. I've got no problem with it. In fact I think allowing it to happen is much more Free than the approach favored by the FSF.
The code that I release to the world is my own work product, and it is my choice to make it available to others. If someone else improves on it, that's great. Period. I feel no need to try to dictate to them what they can do with it. That's their work product, and their choice if they want to make it available to others.
The code that I release to the world is my own work product, and it is my choice to make it available to others. If someone else improves on it, that's great. Period. I feel no need to try to dictate to them what they can do with it. That's their work product, and their choice if they want to make it available to others.
> Which is why GPL is such a popular licence.
this may have been true with desktop software but it is a lot less true with web software - where MIT and BSD style licenses are much more prevalent.
I think modern authors are more interested in others using their software unencumbered than they are concerned about some ideological battle or keeping software 'open'.
this may have been true with desktop software but it is a lot less true with web software - where MIT and BSD style licenses are much more prevalent.
I think modern authors are more interested in others using their software unencumbered than they are concerned about some ideological battle or keeping software 'open'.
But GPL for web software is like BSD for desktop software. If you only are running it on a server and not distributing it, you don't have to release your modifications to GPL code. That's why the AGPL exists (but it is unfortunately unpopular).
Have a look at the top projects on Github and note that most (all?) are MIT or BSD licesed:
https://github.com/popular/watched
Modern web developers don't seem to care and prefer to keep it simple. The GPL definitely hasn't adapted well to a web world.
https://github.com/popular/watched
Modern web developers don't seem to care and prefer to keep it simple. The GPL definitely hasn't adapted well to a web world.
Agreed. I think the only time I ever saw Stallman pussy out on something was removing the SaaS stuff from the GPL3 and separating it off into the AGPL3. Without even the FSF fully behind Free Software ideals in the web world, things seem quite stagnant on that front now.
In terms of JavaScript, using it on a website almost certainly counts as distribution. Imagine if jquery were GPL.
>'this may have been true with desktop software but it is a lot less true with web software'
Oh it still IS true with desktop software, as in applications. Here GPL is pretty much the de facto standard open source licence.
I'm not sure what you mean by 'web software', web applications? If you are talking of frameworks/programming languages then those categories are indeed generally open sourced through MIT/BSD-style licencing or LGPL (where only changes directly made to the LGPL licenced code needs to be open sourced.
>'I think modern authors are more interested in others using their software unencumbered than they are concerned about some ideological battle or keeping software 'open'.'
I think 'modern authors' are being made aware of how companies are increasingly using or even basing their entire existance on open source but not contributing back at anything nearly the same extent. Worse, enhancements are being kept in-house thus requiring duplication of effort in order to gain those enhancements.
I think keeping open source 'open' is absolutely key. In some areas it is less necessary to enforce this through licences, traditionally these have been programming languages, frameworks, single purpose libraries - generally code which serves as building blocks. It also depends on how much you are reliant on/hoping for external help.
When Google releases a video codec or a programming language as open source then they aren't really looking for any contributions, they have enough man-power to develop it all themselves in the direction they so choose. They also have the man-power to match any features of proprietary forks.
If on the other hand you are releasing something which you believe is promising but you need help with it, or you release something finished which can be better, then GPL/LGPL makes perfect sense as you will as an 'end user' be subject to any enhancements done to your code in the form of source code.
Also, while companies undoubtably love 'using' BSD/MIT licenced code, when it comes to 'contributing' GPL seems favoured. Linux, GCC comes directly to mind as projects where companies pay developers to write GPL licenced code. Also companies who later choose to open source their proprietary projects generally seems to favour GPL, for example practically all commercial games which have been open sourced are licenced as GPL.
This brings me to my last point, which is that GPL is great for cooperative development. This is perhaps particularly attractive for large players competing in a field where they want to cooperate on something, obvious example is again the Linux kernel where companies like Red Hat, IBM, Oracle etc compete for the same market but cooperately develop the base product (Linux). I can't see something like this ever working using a BSD/MIT style licence as then they wouldn't be legally bound to share enhancements.
Oh it still IS true with desktop software, as in applications. Here GPL is pretty much the de facto standard open source licence.
I'm not sure what you mean by 'web software', web applications? If you are talking of frameworks/programming languages then those categories are indeed generally open sourced through MIT/BSD-style licencing or LGPL (where only changes directly made to the LGPL licenced code needs to be open sourced.
>'I think modern authors are more interested in others using their software unencumbered than they are concerned about some ideological battle or keeping software 'open'.'
I think 'modern authors' are being made aware of how companies are increasingly using or even basing their entire existance on open source but not contributing back at anything nearly the same extent. Worse, enhancements are being kept in-house thus requiring duplication of effort in order to gain those enhancements.
I think keeping open source 'open' is absolutely key. In some areas it is less necessary to enforce this through licences, traditionally these have been programming languages, frameworks, single purpose libraries - generally code which serves as building blocks. It also depends on how much you are reliant on/hoping for external help.
When Google releases a video codec or a programming language as open source then they aren't really looking for any contributions, they have enough man-power to develop it all themselves in the direction they so choose. They also have the man-power to match any features of proprietary forks.
If on the other hand you are releasing something which you believe is promising but you need help with it, or you release something finished which can be better, then GPL/LGPL makes perfect sense as you will as an 'end user' be subject to any enhancements done to your code in the form of source code.
Also, while companies undoubtably love 'using' BSD/MIT licenced code, when it comes to 'contributing' GPL seems favoured. Linux, GCC comes directly to mind as projects where companies pay developers to write GPL licenced code. Also companies who later choose to open source their proprietary projects generally seems to favour GPL, for example practically all commercial games which have been open sourced are licenced as GPL.
This brings me to my last point, which is that GPL is great for cooperative development. This is perhaps particularly attractive for large players competing in a field where they want to cooperate on something, obvious example is again the Linux kernel where companies like Red Hat, IBM, Oracle etc compete for the same market but cooperately develop the base product (Linux). I can't see something like this ever working using a BSD/MIT style licence as then they wouldn't be legally bound to share enhancements.
Consider also the possibility that Apple sponsored Clang/LLVM because was written in a way that made it nearly impossible to analyze code exactly as the compiler would. The separation of LLVM and Clang means that Static analyzer in clang is doing the same thing as when you compile.
"I believe a huge amount of programmers want to provide open source code to open source code projects, not for proprietary projects. Which is why GPL is such a popular licence."
I really wish developers would stop calling the GNU "free". If you are restricting the end user (IE: you can't use this in proprietary projects), it's not freedom.
The BSD license is true freedom.
I really wish developers would stop calling the GNU "free". If you are restricting the end user (IE: you can't use this in proprietary projects), it's not freedom.
The BSD license is true freedom.
The BSD license forces me to reiterate that license text (AND copyright notices)! How dare they?
PD all the way.</sarcasm-attempt>
(By the way: The end user can use GPL code in proprietary projects - once end users redistribute it, they stop being end users by definition, and only then the GPL requirements kick in)
PD all the way.</sarcasm-attempt>
(By the way: The end user can use GPL code in proprietary projects - once end users redistribute it, they stop being end users by definition, and only then the GPL requirements kick in)
"The BSD license forces me to reiterate that license text (AND copyright notices)! How dare they?"
Compared to all of the requirements of the GNU, it's nothing. the GNU is like finding out you built your house with nuclear material.
"(By the way: The end user can use GPL code in proprietary projects - once end users redistribute it, they stop being end users by definition, and only then the GPL requirements kick in)"
If you include GNU software in your proprietary app, the second someone asks for your source code, you must give it to them. Once a user has the code, they can compile it and release it for free (The general view of the OSS community is that software should be free as in beer).
If your application is popular enough, this will happen and you will be forced to either go out of business, move onto another product, or charge for support.
It's okay though. It's just pushed app developers like me to only create web services. The result? the end user pays me a monthly fee and need internet access to use it. It actually makes it much easier for me to predict my future earnings.
Compared to all of the requirements of the GNU, it's nothing. the GNU is like finding out you built your house with nuclear material.
"(By the way: The end user can use GPL code in proprietary projects - once end users redistribute it, they stop being end users by definition, and only then the GPL requirements kick in)"
If you include GNU software in your proprietary app, the second someone asks for your source code, you must give it to them. Once a user has the code, they can compile it and release it for free (The general view of the OSS community is that software should be free as in beer).
If your application is popular enough, this will happen and you will be forced to either go out of business, move onto another product, or charge for support.
It's okay though. It's just pushed app developers like me to only create web services. The result? the end user pays me a monthly fee and need internet access to use it. It actually makes it much easier for me to predict my future earnings.
There are multiple different definitions of the word "free". Deal with it. Pretending there's only one definition of the word "free" and that all other ones are wrong is just stupid flamebait.
"There are multiple different definitions of the word "free". Deal with it. Pretending there's only one definition of the word "free" and that all other ones are wrong is just stupid flamebait."
Okay. I believe DRM is free. If you don't like it you just don't understand the different definitions of "free" (and you might just be a troll).
Okay. I believe DRM is free. If you don't like it you just don't understand the different definitions of "free" (and you might just be a troll).
By "definitions" I was referring to common definitions you can find in a dictionary, not definitions you just unilaterally invent.
Please, Hacker News is not the place for tired old flamewars. Go back to late 90s /. if you want to argue about whether GPL or BSD is more free.
Please, Hacker News is not the place for tired old flamewars. Go back to late 90s /. if you want to argue about whether GPL or BSD is more free.
"By "definitions" I was referring to common definitions you can find in a dictionary, not definitions you just unilaterally invent."
I'm not arguing the definition of "free". I'm arguing that GNU means that definition. It does not.
Since the 90s, the GNU has actually gotten more restrictive. The BSD license, on the other hand, has not.
Also, calling me a "troll" will not make me change my mind or silence me.
I'm not arguing the definition of "free". I'm arguing that GNU means that definition. It does not.
Since the 90s, the GNU has actually gotten more restrictive. The BSD license, on the other hand, has not.
Also, calling me a "troll" will not make me change my mind or silence me.
I never called you a troll. You, on the other hand, did call me a troll.
Calling my opinion "flamebait" implied it. We all know what that means.
Your response also has nothing really to do with our topic at-hand.
Your response also has nothing really to do with our topic at-hand.
It doesn't have anything to do with the topic at hand because the topic at hand is decades-old flamebait that you've undoubtedly seen play out on mailing lists, Slashdot, etc. There's nothing to gain from talking about the GPL/BSD freedom debate that can't be had from a Google search. Literally the only reason I can imagine you bringing this up is to instigate a flamewar.
Educate yourself:
http://en.wikipedia.org/wiki/Gratis_versus_Libre
I've known about the GNU since it's inception. Do you honestly think I don't know about this?
The GNU isn't "gratis" or "libre". This is my point.
The GNU isn't "gratis" or "libre". This is my point.
How is GNU not libre? Because the end user cannot run GPL'd software for certain purposes with no strings attached?
I'm sure that the point you're raising has been discussed to death in a thousand flamewars, but I happen to be unfamiliar with them. Sorry about that.
Could somebody please sketch out how this argument goes? I will outline my understanding so far, and I will use some jargon and concepts from CS, AI, decision theory and economics, please tell me if that makes me harder to understand:
A1: Community effort is good when it makes people better off (as opposed to achieving some narrow goal).
A2: Most software is community effort, so good software is that which makes people better off. The way to ensure that is to make software free.
B2: Free? Then how would programmers gather resources necessary to support themselves why working in a capitalist economy?
A3: Free is a toxic word. Let's taboo it. Instead, let's talk about what matters to the user who has already acquired software somehow without hurting the programmer:
0. The user has acquired the software without hurting anybody, and it's nobody's business how the software is used, in which manner and to what ends.
1. The user has some software but it's not quite enough to accomplish his task, so he creates the solution using everything at his disposal — and that includes other software he has.
When software is distributed in a form that impedes understanding and editing it, this actively hurts user who is trying to reprogram or extend the software, which is a legitimate manner of use, because every manner of use is legitimate.
2. He wants to help other people (other economic agents), so he uses all the resources at his disposal, including software, to help them. This encompasses sharing software.
B3: But this is a very skewed and simplistic view of economy. Sometimes success depends on hindering your competition (cf. minimax). Sometimes you have to hurt other people to secure your freedoms. Sometimes you have to manipulate the market, withhold information, not do everything in your power to reach the declared goal, not take risks, or take unreasonably high risks.
A4: So what? There are some fundamental rights, and since they don't necessarily conflict, we should simply avoid situations where they do. When that's not possible, we should seek compromises. In the case of software, the right thing to do is to err on the side of more freedom, because otherwise the equilibrium will fall at the point where no further progress is possible, and we don't want that.
B5: Say what you want, but I have I paid job, and my job security depends on me hindering other people's ability to do the same. The best way to do this is not to share the source code I have written. Oh, and by the way, I have an emotional attachment to it, and I cringe to think of somebody messing with it. It is also badly written and I would be ashamed to have it published, but I have no time to clean it up.
A5: This is why we can't have nice things.
B6: Most of hardware is closed source. There is a lot of nice hardware. Some of the nicest hardware is made by some of the most secretive organizations. So you're obviously wrong in your conclusion, and you must have erred in one of the logical steps in your argument.
I'm sure that the point you're raising has been discussed to death in a thousand flamewars, but I happen to be unfamiliar with them. Sorry about that.
Could somebody please sketch out how this argument goes? I will outline my understanding so far, and I will use some jargon and concepts from CS, AI, decision theory and economics, please tell me if that makes me harder to understand:
A1: Community effort is good when it makes people better off (as opposed to achieving some narrow goal).
A2: Most software is community effort, so good software is that which makes people better off. The way to ensure that is to make software free.
B2: Free? Then how would programmers gather resources necessary to support themselves why working in a capitalist economy?
A3: Free is a toxic word. Let's taboo it. Instead, let's talk about what matters to the user who has already acquired software somehow without hurting the programmer:
0. The user has acquired the software without hurting anybody, and it's nobody's business how the software is used, in which manner and to what ends.
1. The user has some software but it's not quite enough to accomplish his task, so he creates the solution using everything at his disposal — and that includes other software he has.
When software is distributed in a form that impedes understanding and editing it, this actively hurts user who is trying to reprogram or extend the software, which is a legitimate manner of use, because every manner of use is legitimate.
2. He wants to help other people (other economic agents), so he uses all the resources at his disposal, including software, to help them. This encompasses sharing software.
B3: But this is a very skewed and simplistic view of economy. Sometimes success depends on hindering your competition (cf. minimax). Sometimes you have to hurt other people to secure your freedoms. Sometimes you have to manipulate the market, withhold information, not do everything in your power to reach the declared goal, not take risks, or take unreasonably high risks.
A4: So what? There are some fundamental rights, and since they don't necessarily conflict, we should simply avoid situations where they do. When that's not possible, we should seek compromises. In the case of software, the right thing to do is to err on the side of more freedom, because otherwise the equilibrium will fall at the point where no further progress is possible, and we don't want that.
B5: Say what you want, but I have I paid job, and my job security depends on me hindering other people's ability to do the same. The best way to do this is not to share the source code I have written. Oh, and by the way, I have an emotional attachment to it, and I cringe to think of somebody messing with it. It is also badly written and I would be ashamed to have it published, but I have no time to clean it up.
A5: This is why we can't have nice things.
B6: Most of hardware is closed source. There is a lot of nice hardware. Some of the nicest hardware is made by some of the most secretive organizations. So you're obviously wrong in your conclusion, and you must have erred in one of the logical steps in your argument.
As the author of a program/library, it just depends on what's important to you. If you want wide use of your code, a permissive license is the way to go. If you want to ensure your users offer the same freedom to users of their modifications that you gave them with the original, then a license like the GPL is the way to go. For you, it sounds like a license more permissive than the GPL would be appropriate. For others, I think a GPL-like license is a valid move.
When you're choosing a library or framework to build on top of, you pick the right tool for the job. Licensing is the same way, they're tools that have appropriate uses some of the time.
When you're choosing a library or framework to build on top of, you pick the right tool for the job. Licensing is the same way, they're tools that have appropriate uses some of the time.
Waffling on which is appropriate gets you nowhere. After all, the whole debate around this article is whether Apple choosing one side of this argument is equivalent to a malicious action. To say "Well, the GPL is appropriate sometimes and not in other cases" is completely unhelpful either way, and nearly a tautology anyways.
He's quite clear that he considers GPL and permissive licenses as both non-evil choices, implying that Apple's preference for permissive licenses also isn't evil.
> On paper the GPLv3 is awesome, but it adds some major restrictions that make it unappealing to corporations.
Oh, stop with the FUD. The only people GPLv3 is a problem for is proprietary software companies, and people who think they're in that business. Of course, on HN that's probably a lot of people's employers (mine, too), but let's not pretend that this extends to "corporations" generally.
Oh, stop with the FUD. The only people GPLv3 is a problem for is proprietary software companies, and people who think they're in that business. Of course, on HN that's probably a lot of people's employers (mine, too), but let's not pretend that this extends to "corporations" generally.
Agreed. It's probably a slightly lower number now, but a few years ago 80% of all software written was custom in-house software where the choice of license is fairly moot since the GPL restrictions don't apply if you don't distribute your software.
I could see how the inclusion of BTFS in FreeBSD might promote free software, and its inclusion would not be prohibited by any version of the GPL.
But how does the use of GPL code in a proprietary project, as would be the case in your consulting example, benefit free software? The whole point of the GPL, any version, is to make sure that derivative work is itself free software. It's not that GPL "sounds good on paper" and in reality, it's totally different.
GPLv3 on paper: You can't use it to make proprietary software. You can't use it to take away users' freedom.
GPLv3 in reality: See above.
But how does the use of GPL code in a proprietary project, as would be the case in your consulting example, benefit free software? The whole point of the GPL, any version, is to make sure that derivative work is itself free software. It's not that GPL "sounds good on paper" and in reality, it's totally different.
GPLv3 on paper: You can't use it to make proprietary software. You can't use it to take away users' freedom.
GPLv3 in reality: See above.
If BTRFS was included as GPL code in the FreeBSD kernel by default it would taint the entire kernel and it would become a GPL governed piece of work...
There is a reason why ext2 for example isn't enabled by default in FreeBSD and why it is mostly stagnant in the tree. Nobody wants to touch it with a 10 ft pole...
Use of an LGPL library would make my life easier, also in the past when I have done work with LGPL libraries (and BSD/MIT and other licenses as well) I have contributed back bugfixes, or new features that benefit said library. When companies shun the GPL and LGPL the same benefits are not available, there is no choice for the corporation to use it and or give back, it becomes a requirement, even if it means that part of our secret sauce now because not so secret.
Good luck getting that past management.
Forcing someones hand is not a good way to start a mutual beneficial relationship.
There is a reason why ext2 for example isn't enabled by default in FreeBSD and why it is mostly stagnant in the tree. Nobody wants to touch it with a 10 ft pole...
Use of an LGPL library would make my life easier, also in the past when I have done work with LGPL libraries (and BSD/MIT and other licenses as well) I have contributed back bugfixes, or new features that benefit said library. When companies shun the GPL and LGPL the same benefits are not available, there is no choice for the corporation to use it and or give back, it becomes a requirement, even if it means that part of our secret sauce now because not so secret.
Good luck getting that past management.
Forcing someones hand is not a good way to start a mutual beneficial relationship.
same movement is in Mobile ..
it might even be the innocent Apple re-aligning with mobile industry trends which are to use anything that is not GPL3
it might even be the innocent Apple re-aligning with mobile industry trends which are to use anything that is not GPL3
A lot of the reason why the same movement exists in mobile is because the GPL v 3 could require manufacturers to release binary blobs that they are not allowed to release, for example for their boot loaders or for the GSM chips and all that sort of fun stuff...
The Tivozation clause that was added is dangerous to companies that use proprietary chips that are not open sourced and there are no open drivers available for it.
The Tivozation clause that was added is dangerous to companies that use proprietary chips that are not open sourced and there are no open drivers available for it.
>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?
The answer is: all the way. I don't understand any other conclusion you could draw from this. Other than a few non-essential command line tools (like emacs), Apple will clean the system of anything they can't control.
A lot of code is shared between OS X and iOS, so the 'tivoisation' clause means that they can't use GPLv3 on iOS, so best to avoid it on Mac OS X too.
Homebrew will still be around to install all the command-line goodies you need. No pain in the ass required.
Regardless of Apple's goals in this action, a lot of the OSS world is moving to permissive licenses, so this isn't a terribly surprising move.
The answer is: all the way. I don't understand any other conclusion you could draw from this. Other than a few non-essential command line tools (like emacs), Apple will clean the system of anything they can't control.
A lot of code is shared between OS X and iOS, so the 'tivoisation' clause means that they can't use GPLv3 on iOS, so best to avoid it on Mac OS X too.
Homebrew will still be around to install all the command-line goodies you need. No pain in the ass required.
Regardless of Apple's goals in this action, a lot of the OSS world is moving to permissive licenses, so this isn't a terribly surprising move.
>Regardless of Apple's goals in this action, a lot of the OSS world is moving to permissive licenses, so this isn't a terribly surprising move.
Guess I hadn't noticed "a lot of the OSS world moving to permissive licenses". The GPL is still the workhorse of many free systems with code coming out all the time. I mean, if you're counting web development code (like the Rails ecosystem), I suppose you could make the argument that the MIT license is surging... but there's a whole world of code beyond generating dynamic HTML that continues to be licensed under the old-guard licenses.
Guess I hadn't noticed "a lot of the OSS world moving to permissive licenses". The GPL is still the workhorse of many free systems with code coming out all the time. I mean, if you're counting web development code (like the Rails ecosystem), I suppose you could make the argument that the MIT license is surging... but there's a whole world of code beyond generating dynamic HTML that continues to be licensed under the old-guard licenses.
> Guess I hadn't noticed "a lot of the OSS world moving to permissive licenses". The GPL is still the workhorse of many free systems with code coming out all the time.
I don't have the stats handy right now, but in general the percentage of new projects using permissive licenses has increased sharply, and many non-FSF GPLv2 products have not made the jump to GPLv3.
I don't have the stats handy right now, but in general the percentage of new projects using permissive licenses has increased sharply, and many non-FSF GPLv2 products have not made the jump to GPLv3.
Most major new projects seem to come with non GPL licenses...
I didn't have this impression. Could you give some examples?
https://github.com/popular/watched
almost every one of those projects is BSD/MIT licensed
almost every one of those projects is BSD/MIT licensed
>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?
Why the hell would they care? Apple has been been gradually squeezing the techie more and more for ages.
Why the hell would they care? Apple has been been gradually squeezing the techie more and more for ages.
Interestingly, Homebrew is broken right now, at least for me, given that I've installed Xcode 4.2 and it didn't seem to install GCC (instead installing LLVM) while homebrew recipes seem to require GCC. (or at least homebrew is complaining about it.)
Homebrew is warning about it, but should still attempt to compile. There is also an homebrew recipe for installing GCC v 4.6 so you can always install that...
I solved this problem by uninstalling Xcode 4.2, downloading Xcode 4.1 from Apple's site <https://developer.apple.com/downloads/index.action>; and then redownloading 4.2 and updating. You'll probably need to register to download, but it's free.
You can get it here https://github.com/kennethreitz/osx-gcc-installer
I believe this installer is missing some headers (included in the OSX GCC) which will break the install of various Ruby libraries.
If that's what you're into.
If that's what you're into.
I don't really see any malicious intent here. I've started avoiding the GPLv3 myself just because it makes code that I publish harder for people to take advantage of. What's the point of me writing some code if it's only going to sit on Github, as if it were ment for some sort of museum?
Apache and MIT Licenses are generally my goto these days.
Apache and MIT Licenses are generally my goto these days.
This is nothing new. A number of large companies avoid GPLv3 because the potential of losing IP is too high; it's a difficult license to interpret, and the legal implications of some of its clauses haven't been fully defined yet (eg. what all is covered by "convey"?).
So, I wouldn't say that them avoiding it suggests anything sinister like some of the posters are mentioning... they're probably just playing it safe.
So, I wouldn't say that them avoiding it suggests anything sinister like some of the posters are mentioning... they're probably just playing it safe.
You hit the nail on the head with the "convey" question. A fairly large number of people think there's a good chance that the AGPL is redundant because the GPLv3 is broad enough in its range of likely court interpretations. I've flip flopped back and forth on the BSD/GPL side of the fence a number of times, lately I've started moving back to BSD-land again. (Especially with things like the "Do what the fuck you want" license, version 3.)
I don't buy that. I find it hard to believe that a court could find that a slightly ambiguous clause means something so different from what the people publishing their code under it understand it to mean. If AGPL didn't exist, and if everyone using GPL claimed "convey" included a hosted service, then there'd be a case. But given that AGPL exists, and given that the intent of most people who use this license is not to prohibit hosted services, that's a major stretch.
Interpretation of contracts is not necessarily based on intent, especially if you're using someone else's contract, and especially if it's not a consumer contract (where, in many cases, a contract deemed to be deliberately misleading may not be valid).
Businesses don't like GPLv3 because... it's (arguably) bad for them. BSD licenced software surges. News at 11.
"Businesses don't like GPLv3 [blah, blah]..." except for the ones who use and benefit from it.
Especially. The wide GPLv3 provides greater protection from certain players controlling markets via patents. Businesses that would otherwise be threatened by this would seem to benefit from GPLv3. And sure business aspiring to these monopoly positions via patents indeed wouldn't benefit. I think was already clear where Apple stood on this "spectrum" of patented-focused-ness.
Especially. The wide GPLv3 provides greater protection from certain players controlling markets via patents. Businesses that would otherwise be threatened by this would seem to benefit from GPLv3. And sure business aspiring to these monopoly positions via patents indeed wouldn't benefit. I think was already clear where Apple stood on this "spectrum" of patented-focused-ness.
>BSD licenced software surges. News at 11.
Actually if you listened to the GPL fanatics that are all over some tech forums (note: I'm not implying that all people using GPL are fanatics, just that there is a subset that's fanatical about it, ironically they are usually technically ignorant) this shouldn't happen - instead everyone should just "steal" BSD software and not contribute (let alone create) stuff back.
Actually if you listened to the GPL fanatics that are all over some tech forums (note: I'm not implying that all people using GPL are fanatics, just that there is a subset that's fanatical about it, ironically they are usually technically ignorant) this shouldn't happen - instead everyone should just "steal" BSD software and not contribute (let alone create) stuff back.
This does happen, though. How much of Apple's kernel code has made it back into other BSD kernels?
We don't take much Apple code into the FreeBSD kernel, because it simply isn't a good technical fit. Userland code, on the other hand, we take plenty of -- and at the last FreeBSD devsummit I attended, the people Apple sent were begging us to take more and the holdup was FreeBSD developers (myself included) not being sure that we really liked the solutions OS X had developed.
That's not a fair comparison. Apple's kernel is Mach/XNU, which is a completely different architecture than the 4.4BSD derived kernels used by Free-, Net-, Open-, etc. BSD. That said, the API for kauth has been implemented (albeit not via open code from apple) on NetBSD. https://developer.apple.com/library/mac/#technotes/tn2127/_i... http://netbsd.gw.com/cgi-bin/man-cgi?kauth++NetBSD-current
Apple guides development for WebKit and releases code for mDNSResponder (Avahi is admittedly used more in OSS operating systems, although NetBSD-current notably uses mDNSResponder), Darwin Streaming Server (the backend to their proprietary QuickTime Streaming Server, and ALAC.
They don't release everything as open source, but they certainly don't disregard its importance.
Apple guides development for WebKit and releases code for mDNSResponder (Avahi is admittedly used more in OSS operating systems, although NetBSD-current notably uses mDNSResponder), Darwin Streaming Server (the backend to their proprietary QuickTime Streaming Server, and ALAC.
They don't release everything as open source, but they certainly don't disregard its importance.
Webkit is mostly LGPL. This is a bad example, because the codebase is derived from KDE.
mDNSResponder is Apache. This was released to drive industry acceptance of Bonjour/Zeroconf.
Darwin Streaming Server is APSL (the Darwin license) and patent encumbered. IIRC, there was talk of it being open sourced to drive H264 acceptance.
Darwin mostly does count as sharing code for the sake of being open, and to their credit Apple does keep updating it, but I struggle to think of other Apple releases for which this appears to be the most important consideration.
mDNSResponder is Apache. This was released to drive industry acceptance of Bonjour/Zeroconf.
Darwin Streaming Server is APSL (the Darwin license) and patent encumbered. IIRC, there was talk of it being open sourced to drive H264 acceptance.
Darwin mostly does count as sharing code for the sake of being open, and to their credit Apple does keep updating it, but I struggle to think of other Apple releases for which this appears to be the most important consideration.
Apple's kernel code is largely _available_, even in other BSDs do not necessarily want to take it. In practice, it's very common for companies who use permissive licensed software to contribute back to it.
I'm not saying it doesn't happen. I'm saying there are reasons for contributing to opensource and opensourcing your projects, other than being forced by the license. Sometimes it doesn't make sense and in those cases GPL forces the company to reinvent the wheel which is counter productive. And there are business models that could rely on GPL to make them viable (offer custom licensing for a fee for eg.) Point is GPL isn't the ultimate license of opensource, and BSD is a viable license, which you won't hear from GPL fanboys.
>'Sometimes it doesn't make sense and in those cases GPL forces the company to reinvent the wheel which is counter productive.'
Same goes for a company taking BSD/MIT licenced open source code, enhancing it and not releasing those enhancements back. In order to have those enhancements reinventing/duplication of effort is needed here aswell.
Also by dual-licencing your open source code you can provide it under GPL for FOSS projects while also offering a proprietary licence for companies for a fee. x264 makes good money this way.
Same goes for a company taking BSD/MIT licenced open source code, enhancing it and not releasing those enhancements back. In order to have those enhancements reinventing/duplication of effort is needed here aswell.
Also by dual-licencing your open source code you can provide it under GPL for FOSS projects while also offering a proprietary licence for companies for a fee. x264 makes good money this way.
> And there are business models that could rely on GPL to make them viable (offer custom licensing for a fee for eg.)
This seems to be the most common GPL-based business model; particularly popular with Oracle, whose newest open-source/commercial license product (confusingly called Oracle NoSQL; it's more or less an autosharding network available BDB JE) is actually AGPL.
This seems to be the most common GPL-based business model; particularly popular with Oracle, whose newest open-source/commercial license product (confusingly called Oracle NoSQL; it's more or less an autosharding network available BDB JE) is actually AGPL.
The number of BSD code sucked by proprietary code and never returned; causes a great number of rewrites; you won't hear much of them; well because of the closed nature of proprietary forks. That way BSD licenses are unfortunately not good for the open source ecosystem, but I accept they are good for proprietary projects or patent-users, commercial users.
But the point is that the proprietary code will be proprietary code even if you GPL you just make the company that would use BSD licensed code rewrite it (or steal it since there's no practical way of enforcing it - and unethical company gets rewarded). There is no way to force a company to contribute if it won't/can't. And GPL is all or nothing deal, BSD allows you to upstream selective patches but keep some parts you can't/won't release.
What about Google's great GPL purge? Also called "Android".
Google modified all what was going to interface with the programs, like the libc so they did not have to use GPL.
There is nothing bad on this, people is free to use whatever they want.
As a company, GPL sometimes is too restrictive.
Google modified all what was going to interface with the programs, like the libc so they did not have to use GPL.
There is nothing bad on this, people is free to use whatever they want.
As a company, GPL sometimes is too restrictive.
He missed this one, which may also be problematic:
> You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license.
This was intended to avoid situations similar to the Microsoft/Novell patent grant agreement, but could have quite broad scope.
> You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license.
This was intended to avoid situations similar to the Microsoft/Novell patent grant agreement, but could have quite broad scope.
It sounds more like they won't sign any non-exclusive patent agreements, like an IP monopsony.
As far as I can see, the main case this covers is, for instance, say Apple adopts GPLv3 Bash. IBM decided to sue over their patent on causing the letter 'w' to be displayed on a computer screen (or whatever). Currently, Apple can do three things; fight it, settle, or stop using bash (the last is impractical, of course). This clause of GPLv3 almost removes the settlement option; IBM would be highly unlikely to license the patent to, not only Apple, but anyone redistributing the redistributable source from MacOS.
For a slightly more realistic example (most of the GPL stuff Apple uses, except for GCC, is not really all that vulnerable to patents), take the bluez Bluetooth stack, used by Android. There's a very real risk that one of the many holders of Bluetooth related patents may assert one against Google or against an OEM over bluez, and in that case, if the patent was valid, licensing it would be the obvious solution. This would work, because bluez is GPLv2; it wouldn't necessarily work if it were GPLv3.
I can see what the FSF was going for with this clause, but it does make it substantially riskier for companies to depend upon GPL(v3) components.
For a slightly more realistic example (most of the GPL stuff Apple uses, except for GCC, is not really all that vulnerable to patents), take the bluez Bluetooth stack, used by Android. There's a very real risk that one of the many holders of Bluetooth related patents may assert one against Google or against an OEM over bluez, and in that case, if the patent was valid, licensing it would be the obvious solution. This would work, because bluez is GPLv2; it wouldn't necessarily work if it were GPLv3.
I can see what the FSF was going for with this clause, but it does make it substantially riskier for companies to depend upon GPL(v3) components.
it does make it substantially riskier for companies to depend upon GPL(v3) components.
I think we can call GPLv3 a success, then!
I think we can call GPLv3 a success, then!
I vote for BSD. If only I can enjoy good food, why should I care about the recipe used? It is the working software that matters, I could not care less for source code.
Open source is important only after the people working on the software decide they will no longer work on it. From that point on, I do hope they open source the whole thing so other people can carry on. However if we impose a GPL-like license on the code, it may discourage people from taking the project full time and doing more interesting stuff. Again, what matters most is the survival of the software.
Open source is important only after the people working on the software decide they will no longer work on it. From that point on, I do hope they open source the whole thing so other people can carry on. However if we impose a GPL-like license on the code, it may discourage people from taking the project full time and doing more interesting stuff. Again, what matters most is the survival of the software.
> It is the working software that matters, I could not care less for source code.
Working software doesn't matter at all. It's your users interests that matter, and GPL compatible licenses are the only ones that guarantee their freedom.
Working software doesn't matter at all. It's your users interests that matter, and GPL compatible licenses are the only ones that guarantee their freedom.
There are hundreds of millions of users of Apple devices now.
Ask them what matters more: working software, or GPL compatible licenses.
Your first sentence is stupid beyond belief.
Your first sentence is stupid beyond belief.
> There are hundreds of millions of users of Apple devices now.
How is this relevant?
> Ask them what matters more: working software, or GPL compatible licenses.
This is a false dichotomy. Try harder.
How is this relevant?
> Ask them what matters more: working software, or GPL compatible licenses.
This is a false dichotomy. Try harder.
Yes, that would be a false dichotomy. However, the post you quote does not set it up as a dichotomy. My reading of it is that it asks the question "which of these two things is more important?" I would suggest that it would be better framed as "is the guarantee of future source access sufficiently important that it effects their choice of tools?"
GPL advocates tend to believe that access to source is sufficiently important to effect their choice of tools. You are entitled to that opinion.
There is clearly also a significant body of users don't particularly care about access to source, and simply want tools that work. You may argue that this is shortsighted, but they are entitled to that opinion. It is entirely reasonable to discount future use of your tool of choice vs. current use of your tool of choice.
There is a group of GPL advocates (not all of them, happily) who advance the argument that this is because the people who don't care are stupid and/or ignorant, and that if they only knew what the GPL advocates know, they would of course have the same preferences as do said GPL advocates. This is an incredibly egotistical position, without a place in serious discussion -- a line of reasoning that requires the assumption that a significant population is entirely irrational or entirely composed of people stupider than the individual advancing the line of reasoning cannot be taken seriously.
GPL advocates tend to believe that access to source is sufficiently important to effect their choice of tools. You are entitled to that opinion.
There is clearly also a significant body of users don't particularly care about access to source, and simply want tools that work. You may argue that this is shortsighted, but they are entitled to that opinion. It is entirely reasonable to discount future use of your tool of choice vs. current use of your tool of choice.
There is a group of GPL advocates (not all of them, happily) who advance the argument that this is because the people who don't care are stupid and/or ignorant, and that if they only knew what the GPL advocates know, they would of course have the same preferences as do said GPL advocates. This is an incredibly egotistical position, without a place in serious discussion -- a line of reasoning that requires the assumption that a significant population is entirely irrational or entirely composed of people stupider than the individual advancing the line of reasoning cannot be taken seriously.
> I would suggest that it would be better framed as "is the guarantee of future source access sufficiently important that it effects their choice of tools?"
This is also a false dichotomy, although more cunningly hidden. It still assumes that giving users source access is somehow a hindrance to the creation of high quality software but Freedom and quality are orthogonal axises.
Removing freedom to see the source might not effect peoples choice it's self I agree, but really why should it also effect the quality of the software?
The obvious answer is software developed within business models based on vendor lock-in. However if you ask customers, "is the guarantee of freedom to change suppliers sufficiently important to your choice of supplier?" You'll get a very different set of answers.
> ...This is an incredibly egotistical position...
I agree.
GPL is not a license for developers, it's for users. In particular it's about giving users the choice of who to work with, and making it easy for them to do so. Whether that means modifying software themselves, directly paying people to modify software or simply changing some URLs in a config file (e.g. rsync.net) they have the freedom to choose. A freedom that is enforced directly in the programs they use, not via convenient business arrangements.
This is also a false dichotomy, although more cunningly hidden. It still assumes that giving users source access is somehow a hindrance to the creation of high quality software but Freedom and quality are orthogonal axises.
Removing freedom to see the source might not effect peoples choice it's self I agree, but really why should it also effect the quality of the software?
The obvious answer is software developed within business models based on vendor lock-in. However if you ask customers, "is the guarantee of freedom to change suppliers sufficiently important to your choice of supplier?" You'll get a very different set of answers.
> ...This is an incredibly egotistical position...
I agree.
GPL is not a license for developers, it's for users. In particular it's about giving users the choice of who to work with, and making it easy for them to do so. Whether that means modifying software themselves, directly paying people to modify software or simply changing some URLs in a config file (e.g. rsync.net) they have the freedom to choose. A freedom that is enforced directly in the programs they use, not via convenient business arrangements.
> Removing freedom to see the source might not effect peoples choice it's self I agree, but really why should it also effect the quality of the software?
We are in violent agreement. Freedom to see the source is entirely orthogonal to quality. However, the space of implementations is not fully populated; there are domains in which there is only a (good, closed) solution and a (poor, GPL) solution (this is in no way a criticism of the quality of GPL'd software in general; there are also domains with only a (good, open) solution, or where the GPL solution is significantly better than all competitors). It's not unreasonable for some users to prefer the (good, closed) tool in that situation.
We are in violent agreement. Freedom to see the source is entirely orthogonal to quality. However, the space of implementations is not fully populated; there are domains in which there is only a (good, closed) solution and a (poor, GPL) solution (this is in no way a criticism of the quality of GPL'd software in general; there are also domains with only a (good, open) solution, or where the GPL solution is significantly better than all competitors). It's not unreasonable for some users to prefer the (good, closed) tool in that situation.
BTW, anyone who wants GCC for Mac OS X can easily do so using the OS X GCC installer: https://github.com/kennethreitz/osx-gcc-installer
You can also just install XCode, which is free with the OS.
Yes, I know the complaint is that it's "too large" just for gcc and related toolchain. But that's not true for me. I find it far, far easier to just download one thing from Apple and install it, then to spend cycles of my own to figure out how to save myself a little bit of disk space.
Yes, I know the complaint is that it's "too large" just for gcc and related toolchain. But that's not true for me. I find it far, far easier to just download one thing from Apple and install it, then to spend cycles of my own to figure out how to save myself a little bit of disk space.
The new XCode 4.2 and presumably the next versions of it do not ship with a real GCC, which is one of the things mentioned in the article.
This causes problems for software that doesn't compile right with LLVM yet (arguably bugs in the software, but tell that to someone who can't use the LLVM compiled binaries any more).
Eventually, the version of Xcode that includes GCC will be too old to do anything useful with.
So then you wouldn't be able to "just install XCode", unfortunately.
This causes problems for software that doesn't compile right with LLVM yet (arguably bugs in the software, but tell that to someone who can't use the LLVM compiled binaries any more).
Eventually, the version of Xcode that includes GCC will be too old to do anything useful with.
So then you wouldn't be able to "just install XCode", unfortunately.
They will ship with a different compiler, clang, and then with homebrew you can compile and install GCC to your hearts content.
For all of my personal projects and projects at work I am using clang because the errors and warnings it gives me are clearer, pinpoint the problem and it compiles my codebase almost 30% faster than GCC.
For all of my personal projects and projects at work I am using clang because the errors and warnings it gives me are clearer, pinpoint the problem and it compiles my codebase almost 30% faster than GCC.
[deleted]
The newest Xcode actually doesn't ship with gcc, which is the complaint here I suppose. It hasn't impacted me all that much, but I don't use a ton of non-OSX specific software (and none outside of homebrew/ports).
Gcc binary is the gcc+llvm, but you also have gcc-4.2
gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
but gcc-4.2 is the real deal gcc-4.2 --version i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
but gcc-4.2 is the real deal gcc-4.2 --version i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Huh? Sure it does. That's how I got it. See: https://devimages.apple.com.edgekey.net/downloads/xcode/xcod...
It installs a "gcc" command-line wrapper which actually calls the LLVM compiler.
Hmm, it looks like it's actually a gcc frontend that uses LLVM as its backend - more than just a command-line wrapper. But I hadn't realized that it wasn't standard gcc.
Heh, I've been using the gcc command on my mac since I switched and I, quite literally, have never come across a program that wouldn't compile for me. That level of compatibility is... well... staggering. heh.
Same here, hence why I assumed it was standard gcc. In fact, I just did "sudo port install python27 py27matplotlib" which pulled in a lot of code and there were zero problems.
You do know that MacPorts installs plain gcc as a dependency for many packages?
This shouldn't be too surprising; it _is_ GCC, but using an LLVM backend (it's not clang).
It also installs "gcc-4.2", which is actually the gcc-4.2 driver.
[deleted]
Apple's PC sales are a rapidly diminishing part of their business, and the share made up by hackers far smaller still. They're perfectly happy to let those devs for whom up-to-date tools and FOSS are important go elsewhere; look at any college classroom and you'll see they have way more new customers to replace them.
This isn't to say they'll actively discourage hackers from using their products, but if it comes down to a product being hack-friendly or adhering to Apple's core principles, hack-friendliness doesn't stand a chance.
This isn't to say they'll actively discourage hackers from using their products, but if it comes down to a product being hack-friendly or adhering to Apple's core principles, hack-friendliness doesn't stand a chance.
Actually, Apple's PC business has never been better. They sold 5,198,000 Macs last quarter, a record. Mac sales are up 26% compared to the same quarter last year. Of course they sold 37 million iPhones, but the amount of revenue the Mac generates isn’t small by any means.
I don’t have a problem with them not shipping software that’s incompatible with how they do business; I suspect hackers and other clueful users will continue using the available tools like Homebrew to install whatever they want.
I don’t have a problem with them not shipping software that’s incompatible with how they do business; I suspect hackers and other clueful users will continue using the available tools like Homebrew to install whatever they want.
If Apple is driven by profit, then the main purpose of Mac, iPod, and even iPad these days is to sell more iPhones (brand halo and integration). Isn't that crazy?
Macs were only 14% of revenue last quarter ($6.6B/46.3B). By contrast, iPhones were 52% ($14.4B). And Macs have ~28% gross margin, while iPhones have ~60%, so they add even less than 14% to the profit picture.
While any other PC manufacturer would die to have Apple's Mac business, it's mouse-nuts to Apple.
Macs were only 14% of revenue last quarter ($6.6B/46.3B). By contrast, iPhones were 52% ($14.4B). And Macs have ~28% gross margin, while iPhones have ~60%, so they add even less than 14% to the profit picture.
While any other PC manufacturer would die to have Apple's Mac business, it's mouse-nuts to Apple.
Its also a stable base. The iPad might or the iPhone might die off to some competitive product, Andoid or whatever, but, as long as PC = Windows, there will be a large market for Macs (no, most people wont consider Linux)
once macs have died, and i was there an 18year old mac c++ programmer. believe me many things like that can happen again in tech world.
My statement, which was apparently unclear, is that PCs represent a declining share of Apple's business, and that hackers represent a declining share of that. That's not to say both aren't growing, but that neither is the keystone of Apple's future growth and success.
"the share made up by hackers far smaller still."
Apple laptops like the MacBook Air are pretty popular amongst your average hacker crowd. You still get a reasonable Terminal Application and most of what you are (basically) looking for from a Unix text environment.
Apple laptops like the MacBook Air are pretty popular amongst your average hacker crowd. You still get a reasonable Terminal Application and most of what you are (basically) looking for from a Unix text environment.
Grandparent said hackers make up a small fraction of Apple's customers, not that Apple is unpopular among hackers.
Well, that's true only insofar that _all_ non IOS customers are making up a smaller fraction of Apple's customers. Within the PC/Laptop Crowd, I think the technical enthusiast/Hacker group is pretty important to that product line. They certainly put a lot more effort into their Terminal Application than Microsoft does. Does Microsoft even offer a Terminal Application? I typically download SecureCRT/Putty. Also - Does microsoft come with SSH?
I guess the point I'm trying to make is "Hackers are important to Apple, insofar that that Macintosh PC/Laptop line is important to Apple."
I guess the point I'm trying to make is "Hackers are important to Apple, insofar that that Macintosh PC/Laptop line is important to Apple."
Have you seen this blog before: http://blog.commandlinekungfu.com/ ALl the things you never knew you could do with Bash (at least a modern Linux one) and Powershell (and occasionally cmd.exe)
Also -- MS now support a full headless installation (no Explorer etc) on Server 2008: http://technet.microsoft.com/en-us/magazine/2009.02.geekofal...
Also -- MS now support a full headless installation (no Explorer etc) on Server 2008: http://technet.microsoft.com/en-us/magazine/2009.02.geekofal...
PowerShell (Windows' shell as of 7) is actually really nice, but it doesn't make any attempt at all to ease the transition to and from *nix shells.
The shell itself is ok, but it still has a rubbish interface / terminal emulator. It's a Corvette engine wrapped in a rusted out Yugo chassis.
It has aliases for a few built in unix commands... but could be more harmful than helpful. Like Javascript, C++ and Java all have 'similar' syntaxes.
Its important to note that one of the main things that differentiates between platforms is the quality and quantity of the available content. If you want to build a platform the first things to do is build great development tools for that platform at making it a platform that is attractive to developers and power users. This strategy has been critical in resurgence of Apple and I doubt that they would want to become a less attractive development platform.
"Apple's PC sales are a rapidly diminishing part of their business..."
Flat out BS. Take a second and look up the numbers.
Flat out BS. Take a second and look up the numbers.
Actually - that part is quite true - but it's only because the iPhone (and iPad) is such a rapidly _increasing_ part of their business.
Thank you. I didn't expect that to be such a controversial statement. Allow me to clarify: the share of apple's revenue generated by its pc business is rapidly falling. It has been supplanted by ios devices.
Actually, it is true. In particular, profit-wise the Mac business is tiny, less than 10% of profits. They could shut down Mac and you would barely notice in their next earnings statement.
I wish it weren't so, because I love my Mac. But Apple's future is iOS, not Mac OS. Maybe someday they'll merge and it'll all be one thing?
I wish it weren't so, because I love my Mac. But Apple's future is iOS, not Mac OS. Maybe someday they'll merge and it'll all be one thing?
Actually it would hurt their iOS market greatly. iOS devices are worthless without their third party apps. And these apps can only be produced on a Mac. In fact, I bought my Mac so that I could build iOS apps. If not for 3rd party apps, it would simply boil down to the device, the software that Apple ships with and the browser. Android devices will clearly win hands down in such a scenario. Initially it would be the case of worse is better but over time it would overtake iOS devices in terms of features and sales.
iOS apps can only be produced on a Mac because that's how Apple wants it. In the unlikely event that Apple did decide to ditch the Mac, they'd port their iOS developer tools to another platform.
I think Apple's Mac roadmap is:
* Mac continues to evolve slowly, not have major innovations. Innovations that do occur will be on things that are aligned with iOS-like devices (like Launchpad, Mac App Store, Macbook Air's).
* Someday they will ditch Mac, when an iOS device can be used to (1) create new iOS apps, and (2) be a productivity machine (e.g. w/ keyboard / etc).
Those of us who like to poke under the hood will have to move back to Linux or something else.
* Mac continues to evolve slowly, not have major innovations. Innovations that do occur will be on things that are aligned with iOS-like devices (like Launchpad, Mac App Store, Macbook Air's).
* Someday they will ditch Mac, when an iOS device can be used to (1) create new iOS apps, and (2) be a productivity machine (e.g. w/ keyboard / etc).
Those of us who like to poke under the hood will have to move back to Linux or something else.
I love my Mac because it's NOT iOS. I just can't see how all-software-from-the-app-store would be able to support the beautiful mess of tools I use every single day.
I agree. The day that happens is the day I (sadly) go back to Linux for my dev environment.
The Mac sales are not diminishing at all. They are INCREASING. The fact the iOS is also increasing, and increasing at a much higher rate, doesn't mean Mac sales are decreasing.
I wasn't aware Bash had also moved to GPLv3. Wonder how long till that gets removed.
Anything whose copyright is owned by the FSF and was GPL2 is now GPL3.
Yup. Only option would be to fork from the last GPL2 release and evolve it as GPL2.
More likely they'll just switch to a new default shell. Perhaps that will be zsh, or perhaps they'll just go back to tcsh.
Or perhaps Terminal will no longer be installed by default by the time they complete their purge.
Or perhaps Terminal will no longer be installed by default by the time they complete their purge.
Or use a different shell, like ksh or zsh.
Or move on to another shell. Such as zsh, or tcsh, csh or countless others that exists.
Is there any reason not to make zsh the default? Better license, better shell.
There really isn't. I hope they do that.
Unfortunately, the article is no longer available. The page shows "Access Forbidden".
Google cache: http://webcache.googleusercontent.com/search?q=cache:-r0zoo9...
Google cache: http://webcache.googleusercontent.com/search?q=cache:-r0zoo9...
Google's Cache:
http://webcache.googleusercontent.com/search?q=cache:-r0zoo9...
Slightly shorter ...
http://webcache.googleusercontent.com/search?q=cache:-r0zoo9...
http://webcache.googleusercontent.com/search?q=cache:-r0zoo9...
Everyone is battling over why corporations or Apple specifically doesn't like GPLv3, and noone has mentioned Linus has said he doesn't like GPLv3 either and will stick with v2 for Linux.
Linux is still shipping under GPLv2.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stabl...
Linux is still shipping under GPLv2.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stabl...
They're smart -- several organisations I know of stopped contributing upstream to projects once they went GPLv3. They're now looking for BSD-licensed alternatives and plan to contribute to them instead.
A few game development projects I follow also switched from LGPL licenses to BSD licenses (and saw contributions go up!). (See SDL, Ogre3D, etc.)
It's actually kind of refreshing to see many people going back to the basics.
A few game development projects I follow also switched from LGPL licenses to BSD licenses (and saw contributions go up!). (See SDL, Ogre3D, etc.)
It's actually kind of refreshing to see many people going back to the basics.
This isn't to say that Apple's implementations were that great, though. I know a few IT techs happy to see something other than the buggy install of Samba for CIFS.
Personally, Apple's exclusion of the "nounix" option in mount_smbfs was a HUGE pain in the ass, to the point where I was a click away from submitting it as a bug. Not that it got better with Lion.
Personally, Apple's exclusion of the "nounix" option in mount_smbfs was a HUGE pain in the ass, to the point where I was a click away from submitting it as a bug. Not that it got better with Lion.
OSX has always been based primarily on BSD-licensed open source. Obviously they don't want their deep pockets to attract lawsuits. The lesson here should be obvious, make the GPL too onerous and fewer companies will risk using it. The FSF suing Cisco was an example that Apple took seriously.
[deleted]
This is a GPLv3 problem, and it's not limited to Apple. v3 is incompatible with many existing business policies.
The trend of dumping GPL will continue in many of the for-profit tech businesses.
The trend of dumping GPL will continue in many of the for-profit tech businesses.
GPL purge would be a good thing, since GPL has done more to hurt free software than help it.
[deleted]
We only have the iPod, iPod touch/iPhone, apple TV, battery covers on newer Apple laptops, and Apple's hardware for their computers to show where they are headed. Some may accuse me of a slippery slope argument; I look at it as a continuation of a linear regression and projection. And where that's going doesn't look peachy.
It is a rather interesting point they do not have any GPL 3 software distributed, and for probably for both the reasons stated. However, the way the whole Mac feel is as it was a curated device (regardless the actual platform). Both Apple and Microsoft seem to want to converge on a "trusted platform"; where the trust is against you.
It is a rather interesting point they do not have any GPL 3 software distributed, and for probably for both the reasons stated. However, the way the whole Mac feel is as it was a curated device (regardless the actual platform). Both Apple and Microsoft seem to want to converge on a "trusted platform"; where the trust is against you.
> Some may accuse me of a slippery slope argument; I look at it as a continuation of a linear regression and projection.
So, er, a slope-related argument of some sort, then. It could be friction-y, I suppose.
So, er, a slope-related argument of some sort, then. It could be friction-y, I suppose.
"Slippery slope" is a specific type of usually-fallacious argument that relies only on what is possible, not what is likely based on actual evidence and trends. It's not a generic term for any argument that seeks to prove "X is heading toward Y".
Why, any man whose purse has been let blood
By sharpers, when he finds all drained away
Must compare how he stands with how he stood.
/
If a quack doctor's breezy ineptitude
Has cost me a leg, must I forget straightway
All that I can't do now, all that I could?
By sharpers, when he finds all drained away
Must compare how he stands with how he stood.
/
If a quack doctor's breezy ineptitude
Has cost me a leg, must I forget straightway
All that I can't do now, all that I could?
[deleted]
------------
Apple’s great GPL purge
Posted on 5 February 2012 by meta Apple obligingly allows you to browse and download the open source software they use in OS X. Since they have listings for each version of OS X, I decided to take a look at how much software they were using that was only available under the GNU public license. The results are illuminating:
10.5: 47 GPL-licensed packages. 10.6: 44 GPL-licensed packages. 10.7: 29 GPL-licensed packages. This clearly supports the idea that Apple is aggressively trying to remove all GPL-licensed software from OS X. While the removal of Samba and GCC got some attention, the numbers show that there’s a more general purging going on.
The 29 remaining GPL-licensed packages aren’t too healthy either. Lion apparently ships with bash 3.2. That’s from 2006. The current version is 4.2.10. Why no upgrade? Because Apple’s shipping the last version of bash that was under the GPL version 2.
The message is pretty obvious: Apple won’t ship anything that’s licensed under GPL v3 on OS X. Now, why is that?
There are two big changes in GPL v3. The first is that it explicitly prohibits patent lawsuits against people for actually using the GPL-licensed software you ship. The second is that it carefully prevents TiVoization, locking down hardware so that people can’t actually run the software they want.
So, which of those things are they planning for OS X, eh?
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?