Apple’s great GPL purge
meta.ath0.com
meta.ath0.com
------------
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?
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.
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?
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.
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.
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.
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.
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.
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/
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...
Great!
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.
IMHO it is the best there is for Linux, and better for C++ than XCode.
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.
Honestly, XCode is pretty horrible when compared to even Eclipse.
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.
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. 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?
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.
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.
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.
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.
Interesting sidenote: http://lists.freebsd.org/pipermail/freebsd-current/2010-Augu...
[1] http://concisionandconcinnity.blogspot.com/2009/03/upgrade-b...
"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."
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.
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.
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.
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 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 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?
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.
What he’s saying in this particular example might be legitimate, but he’s just not a credible source, in general.
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.
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.
it might even be the innocent Apple re-aligning with mobile industry trends which are to use anything that is not GPL3
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Not here: http://news.ycombinator.com/item?id=3561964 This is the post I originally responded to, so this is the post I was assuming we were talking about.
> 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.
That's fair.
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.
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.
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'.
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.
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.
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.
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).
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.
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.
Your response also has nothing really to do with our topic at-hand.
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)
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.
The GNU isn't "gratis" or "libre". This is my point.
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.
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.
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.
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.
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.
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.
almost every one of those projects is BSD/MIT licensed
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.
If that's what you're into.
Why the hell would they care? Apple has been been gradually squeezing the techie more and more for ages.
Apache and MIT Licenses are generally my goto these days.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
I think we can call GPLv3 a success, then!
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.
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.
Your first sentence is stupid beyond belief.
How is this relevant?
> Ask them what matters more: working software, or GPL compatible licenses.
This is a false dichotomy. Try harder.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Flat out BS. Take a second and look up the numbers.
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?
* 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.
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.
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."
Also -- MS now support a full headless installation (no Explorer etc) on Server 2008: http://technet.microsoft.com/en-us/magazine/2009.02.geekofal...
Or perhaps Terminal will no longer be installed by default by the time they complete their purge.
Google cache: http://webcache.googleusercontent.com/search?q=cache:-r0zoo9...
http://webcache.googleusercontent.com/search?q=cache:-r0zoo9...
Linux is still shipping under GPLv2.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stabl...
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.
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.
The trend of dumping GPL will continue in many of the for-profit tech businesses.
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.
So, er, a slope-related argument of some sort, then. It could be friction-y, I suppose.
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?