Behind OS X’s modern face lies an aging collection of Unix tools
robservatory.com
robservatory.com
So yes, GPL 3 is hurting open source more than helping it.
Disclaimer: I don't speak for Microsoft. These are my personal observations. And I no longer work there.
I would disagree with this stance though. The aim of free software is a moral one, it has nothing to do with being the most-used or the most popular.
that's Big Company's fault. As an employee you'd take your complaint to them.
The license is not "deliberately crafted to scare and challenge IP lawyers", it's designed to avoid the shitty tactics that some tech companys' have been using the past few years to make their primary profits : mass IP buyups and subsequent lawsuits towards all of the other members of the industry.
The GPL and the organization behind it, the Free Software Foundation, do not care about "open source". They care about free Software, free as in freedom.
/edit: before i get a ton of downvotes: i don't fully agree with with the FSFs policies or definition of "free softare", im just pointing it out.
The GPL licenses give users freedom by forcing distributors to behave in certain ways.
Under copyright law with no license at all you would have no right to copy it at all; the GPL grants you additional rights, but only if you do the same in turn.
Complaining that that restricts your freedom is like complaining that it restricts your freedom to go to a country that forbids kidnapping. Sure, in stateless areas with no effective government, you may have the additional freedom to kidnap someone else, denying them their freedom. But on the whole, laws against kidnapping (or false imprisonment, or the like) are their to preserve freedom.
Likewise, the additional freedom that the MIT or BSD licenses grant you is the ability to deny other users the freedom to use and modify your works derived from the code.
Can we please stop having the argument that BSD or MIT give more "true freedom" than the GPL? The only additional freedom they give you is the ability to apply more restrictions to other people.
Now, you may not want to make the deal that the GPL makes, trading your code for a promise that other people who distribute it continue to offer the same freedoms that you offer. You may not really care what restrictions other people place on it, or on their modifications to it, after you've released it. You may even want to have the ability to collaborate with those who use their software licensing to restrict end user freedom. Or you may not want to deal with license compatibility headaches.
But arguing that "true freedom" comes from license like BSD or MIT, and not the GPL, is ridiculous; the GPL is designed to ensure that the software and all modifications to it will always remain free, while liberal licenses simply allow people to redistribute it with more restrictions, making the ecosystem less free, not more.
The GPL, MIT, BSD, and any other license that meets the requirements of the free software definition, Debian free software guidelines, or open source definition, are all "truly free," they just differ in whether they attempt to preserve that freedom transitively or not.
If you want to eat it all, buy your own candy. Until then, be happy about the gift you have been given and enjoy sharing.
The Linux kernel would not be the success it is without a viral license
...which is that they've never required copyright assignment, so changing the license would require the consent of everyone who has ever contributed.
I don't necessarily agree with him, but based on his influence in the kernel community, it would be pretty hard to change the license over his objections.
Ask it a different way: How many popular GNU/Linux distributions have zero GPLv3 binaries in them? I expect Linus has GPLv3 software on his own machine.
Theo de Raadt and Bill Gates don't much care for GPLv3
either.
I'm sure Linus does have GPLv3 running on his machine. He doesn't mind using the license, as it doesn't constrain him as a user in any way that he objects to. But he doesn't ship his own software under that license.
I wasn't saying anything about the relevance of his opinion, to anything other than the kernel license himself. You had asserted that the kernel hadn't moved to the GPLv3 because of lack of copyright assignment; and I was just pointing out that in addition to that, the lead developer of the kernel personally dislikes the GPLv3, so even if he had the ability to change license, he probably would not have.
Personally, I'm pretty happy with the GPLv3. I wish more developers would release code under it, instead of more liberal licenses, to help defeat things that I find unpleasant like Tivoization and software patents. But not everyone shares my opinion, and Linus's opinion carries a lot more weight than mine as the leader of the kernel project.
Why is it bad for the FSF to prioritize their interests ahead of Apple and Microsoft's?
Let me release a open source driver for hardware that you can't modify, and if you distribute it I will sue you for patent infringement. Since I have now donated to the open source ecosystem, I expect money, time and rewards to be sent to me for this great deed.
That's because they're Microsoft.
> I imagine Apple and other proprietary software publishers have the same mandate to their troops.
I have yet to hear any rational justification for this, yet people keep repeating it.
Every single piece of software that has new releases under the GPLv3 they have stopped updating. A few of the most important ones, like GCC, GDB, and Samba, they've even gone as far as to pour substantial amounts of money and effort into funding replacements (clang, lldb, Apple's smbd). Others that they don't consider very important they've just let languish, like bash, make, and other GNU utilities that they include on their systems.
If "everybody is doing it" then either somebody knows why or it's a cargo cult.
Given that they haven't made any public statements about it, it's hard to say with certainty; you can only speculate.
But the major things that the GPLv3 changed, which companies like Apple and Microsoft are likely to object to, are the anti-Tivoization clauses, the patent license clauses, and the "no effective DRM" clauses. If you check the information about what changed in GPLv3 (https://www.gnu.org/licenses/quick-guide-gplv3.html), those were pretty much the only extra restrictions added.
The anti-Tivoization clause says that if you distribute the software along with hardware, you must also distribute (or provide users with a way to change) any keys that are necessary for users to run their own modified version of software on that hardware. Given that both Apple and Microsoft ship locked down phones that don't allow users to modify their software, and are increasingly moving towards locked-down App Store models even on desktop and laptop computers, they may not want to risk every being obliged to follow that requirement.
The patent grant clause is likely the one that worries them the most. That says that if you distribute the software, and your distribution of the software relies on patents that you either hold or license from someone else, you must either pass along the rights in those licenses (if possible), or give up the patent license (that is, if you have licensed a patent from someone but don't have the ability to transfer that license to downstream recipients, than you may only distribute the software if you give up that patent license, putting you and your users on equal footing if the holder of the patent decides to enforce it).
The DRM clause may also bother them, but I doubt that they would avoid using software due to it, since it only applies to software which is itself used as part of a DRM system, saying that it can't be considered an effective technological measure (as the other freedoms provided by the GPL allow users to replace it), and so none of the legally enforced restrictions on removing DRM can apply. Since that only applies to code that is used as part of a DRM system itself, I don't think that would cause them particular problems, as long as they avoid linking any of their DRM systems to GPLed code, but there may be cases in which it would come up.
Anyhow, I can't really say which of these is the reason that they don't allow it, as they have never made any public statements about that. My guess would be the patent clause, followed by the Tivoization clause, followed by the DRM cluase, in order of importance.
And the patent license seems least objectionable of all. The primary change from GPLv2 seems to be having to include some language accounting for it in the agreement for any patents they license, which they have every incentive to do regardless in order to be covered in case an employee puts an Ubuntu ISO somewhere public, and in the worst case they're still only in the same situation they would be if the patent in question had been owned by some patent troll.
Also, the post I responded to is talking about "Apple and other proprietary software publishers." So Apple is more the exception than the rule in having any trouble at all with the anti-tivoization clause since most software vendors don't make their own hardware.
I still don't see anything that should make it so untouchable.
Or there's all of the patents that the license from other parties, like the H.264 patent portfolio. Those patents they can't relicense; so if any of those apply to any of the GPLv3 software they tried to distribute, they would be in violation of one or both of the licenses.
Also, the post I responded to is talking about "Apple and
other proprietary software publishers."
For example, vendors who sell closed-source, proprietary applications could never use any GPLed code, as linking to it would mean they were required to release the code of the whole application under the GPL. So there there's really no different between GPLv2 and v3.
Vendors who sell bundled software hardware combos could ship GPLed software, and embedded Linux is common there. However, some of them like to lock down their hardware, not allowing it to be upgraded or modified by end users. The anti-Tivoization clause specifically forbids that, so they may avoid GPLv3 software in order to avoid the anti-Tivoization clause. One example here is Android, where they even avoid GPLv2, for software that ships on phones, almost everywhere except for the kernel.
There are also some proprietary software vendors who do ship GPLv3 software. For example, Oracle, one of the biggest and most notorious proprietary software vendors, actually does ship Oracle Linux, a distro which contains an awful lot of GPLv3 software. So its clear that not every company has made the same decision; some avoid it like the plague (Microsoft and Apple), some avoid it in certain products but not others (Google avoids it Android, but ships GPLv3 code in Chrome OS), and some are fine with shipping it. You can't really make any blanket statements about all proprietary software companies.
But anyhow, as I said, for cases such as Apple, it's very obvious that they are fine shipping GPLv2 software, but very clear from their actions that they won't ship GPLv3. There are three major additional restrictions in the GPLv3, and we can speculate which one was the tipping point for Apple. My money is on patents, but I think that the anti-Tivoization may play a role too. However, unless they publicly say something, or someone leaks some internal communication about it, we will just be left speculating as to why.
The patent license only applies to derivative works so Samsung couldn't use it for its non-GPLv3 products.
> Or there's all of the patents that the license from other parties, like the H.264 patent portfolio. Those patents they can't relicense; so if any of those apply to any of the GPLv3 software they tried to distribute, they would be in violation of one or both of the licenses.
They could just not distribute that GPLv3 program.
Obviously this runs into the problem that you don't know which patents which programs infringe, but that has nothing to do with the GPL. Some troll could just as easily jump out from under the bridge and demand a hundred billion dollars for a patent on Safari.
Some troll could just as easily jump out from under the
bridge and demand a hundred billion dollars for a patent
on Safari.
Now, H.264 may be covered by unknown patents as well. But based on the existence of the MPEG-LA and its patent pool, and the fact that they'd already invested in and exposed to any potential H.264 risk, they felt like there would be more risk to them to add Ogg Theora support than just sticking with H.264. Were they right? Who knows. But that is the decision they made.
Now, we are just speculating about why they hate the GPLv3 so much. But they obviously do, and they have both done a lot to use their own patents offensively, as well as being cautious about infringing patents as a defensive stance, so my best guess is that the patent clause is their concern.
But there's no way for me to be sure; there's not much point in continuing to discuss it, because it's Apple that has made this decision, not me. I'm perfectly happy shipping GPLv3 covered software; if you want to know why Apple isn't, you could try asking them, though are unlikely to get an answer.
Suppose I'm distributing GPLv3 software as part of my commercial product. I'm fully complying with GPLv3.
Some third party comes along who is in the business of distributing software, and tells me that they have a patent covering the GPLv3 software I'm distributing.
They want me to buy a license for their patent for $1/copy sold of my commercial product. This license would cover the use of the GPLv3 software in that copy of my product. It would not cover copies or derivative works made from those copies.
GPLv3 says that I must reject this licensing deal. I can only accept a licensing deal that results in all of the copies and derivative works made from those copies or their down streams and so on receiving patent licenses.
If I cannot arrange for this open ended licensing, I have to either stop distributing the GPLv3 code, or I'll have to try to defeat the patent.
No way am I going to distribute GPLv3 code as an essential part of my product with that "all or nothing" patent licensing restriction hanging over it.
It also has the strong potential to make your partners and customers Displeased. It seems very strange to have such a strong desire to be able to do something which seems like such a bad idea.
And, all of the other people distributing the GPL software will be in the same boat, so the sensible thing to do in any event is to get together with them and buy or challenge the patent. Or modify the software so that it doesn't infringe.
It comes at no surprise that Microsoft, a company that vehemently spoke out against Free and Open Source Software for so long, would have these views.
GPL'd code is about keeping that code open source forever. Hence clauses in GPLv3 like anti-Tivoization. Little sympathy for companies that want to take without giving back.
I'd much rather have a slower adoption rate than a project that is botched legally (and irreparably) down the line.
GPLv3 was explicitly drafted to prevent this, and as by magic, Microsoft stop issuing the threats as soon the new license was released.
So no, GPL 3 is not hurting open source. It prevented a racketeering from Micosoft that was unethical, legally grey zone then, illegal today, and direct harmful to open source in every possible way.
Sources here: http://opensource.apple.com
Apple doesn't seem timely in getting sources put up. Wayback Machine shows that 10.9.5 was posted around October 7th even though that update was distributed to users on September 17 (~20 day gap), so they're not exactly adhering to the license as they should.
Also there is no sources for 10.10 and does iOS 7 and 8 really use no GPL'd or other FOSS'd code?
Correct me if I'm wrong, but the licenses don't require Apple to proactively publish sources, they just need to be able to supply them upon request.
Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#Wh...
Source is not distributed along with their binaries nor is a written offer to receive source code that I've seen. http://support.apple.com/kb/DL1761 & http://www.gnu.org/licenses/gpl-violation.html
I try to not muck around with the base installs too much - it makes it too difficult to migrate between machines.
[1] http://brew.sh
I wish more systems utilized FS tricks instead of proprietary DB's / manifests etc.
Another nice thing is they try to use the already by-default system-installed versions of libraries whenever possible -- pretty much the first thing that happens when you install any macport is it installs a gazillion dependencies that just mirror what's already on the system. (Or at least it used to be this way; keep in mind my macports knowledge is out of date!)
I also really like that in brew formulas are just ruby files, the package update mechanism is just git pull. It's also super-easy to add your own packages, and tap 3rd party sources for packages.
I do run into trouble sometimes, but it's usually easy to fix, and it happens less often than with other package managers I've used over the years.
(Sort of a taste of why it's nice: Simple things you're likely to want to do are simple:
Q. What packages do I have installed? A. "brew list"
Q. What packages are out of date? A "brew outdated"
Q. What's the homepage of package Foo? A. "brew home foo" (opens in browser)
Q. I need to modify the formula for Foo... A. "brew edit foo"
Etc.)
The format is really simple and powerful.
https://github.com/Homebrew/homebrew/blob/master/Library/For...
More complex example:
https://github.com/Homebrew/homebrew/blob/6a72fa26aa49ee5c2b...
Edit:
If that's the only reason you can't use homebrew just, you can just tap another cask with it in there(or whatever they are calling that process).
Homebrew actually merged in 4 unique bash patches in 6 days after Shellshock broke as well, and forced all users to recompile to ensure that hole was closed on our end. The author of this article would have probably been best checking both MacPorts and Homebrew, and potentially Fink as well.
I'm not sure they've ever published a reason for this, but outside speculation centers around the v3 patent grant and anti-tivoization clauses.
I've heard this more than once but it doesn't make any sense. GPLv2 says this: "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions."
Ask your lawyer what happens if you license a piece of software to someone and then try to sue them for patent infringement for using that software.
And OS X doesn't stop you from compiling your own bash (or whatever else) and replacing the one Apple shipped, so I don't see how the anti-tivoization clause would affect them either. It just doesn't make any sense.
I half suspect that there are a few IP lawyers (and/or Microsoft) who don't like the GPL for ideological reasons and go around spreading FUD about it to discourage people from using it.
That makes it sound like it's the GPL's fault that OS X users don't get up-to-date utilities. Blame Apple's bad policy, not the GPL.
I don't think we can have a rational discussion about this.
For libraries. We are talking user land tools here, which are standalone. Providing a new bash version doesn't 'infect' any other software.
I think the extended (or some would say more explicit) patent license in the GPLv3 is what troubles many companies.
Nonsense. The GPL terms have never applied to internally used software.
Besides, you make it sounds like discouraging companies that live on proprietary software & patents from using GPLv3 licensed code is somehow an unintended and unwanted consequence. The whole point of the GPL is to prevent proprietary software from capitalizing on Free Software. That they won't use it internally either sounds like a feature, not a bug.
Copyright prevent every distribution of copies and derivative works. A license is thus a permission, which permits distribution which otherwise is not permitted.
Any license is viral in that you must follow the license in order to distribute the copyrighted work. I can't just take a BSD licensed work, replace it with my own license, and ignore the BSD requirements. The license is my permission to distribute the work and if I ignore it, I am liable under copyright law.
Describing the permission as infective, restrictive, preventive and so on only show how completely fundamentalist the person is. You are given permission to use, copy and modify the program. If you feel infected by that choice, then I call that ungrateful and childish behavior.
A project can have BSD, Apache, MIT and GPL licensed software parts, and the derivative work must respect all the licenses when distributed. You can not "make" them GPL.
Trying to re-license something is like printing your own permission to enter a train. Its not only illogical, its illegal.
And that is false. I can use ReallyCoolTool GPL library, and write a AwesomeGUIApp and license my written code as Apache. Nothing prevents me from doing so.
Each license a program use is a set of permissions with conditions in them. You can never choose to ignore a set of conditions, or you loose the permissions. This is why I started this whit "shows a lack of knowledge around what a copyright license is". A copyright license is, and can only be, a set of permissions to use a copyrighted work. Its not changeable, nor can it ever be removed by anyone except the author. The viral nature of copyright enforces this.
It is childish to go around and calling a particular set of permissions as viral. Be grateful for having permission, and stop cry about it.
This is the viral aspect that your argument does not address.
This is the viral aspect that your argument does not address.
Its like if I buy a train ticket. If I throw away the ticket and write my own, I no longer have permission to enter. The permission is in the ticket.
The 10 lines will must always be under the BSD, and every time I distribute I must follow the conditions set down by the license. It infects the distribution of the work, regardless of I license the other 100,000 lines.
>The GPL is infectious; any code that uses a GPL library automatically becomes GPL as well.
Wrong. Developers make a conscious decision to use a GPL licensed library. Their code does not "automatically" become GPL against their will. Licenses are not viral. It's a nasty, pejorative term used to attack copyleft.
That might be, but it's not because the person you were replying to was wrong.
The table shows a lot of outdated non-GPL software, such as vim. Besides that, for many UNIX utilities, they could start cherry-picking from FreeBSD, NetBSD or OpenBSD, and you know, maybe even adding the missing functionality.
I think the actual reason for staleness is that there is not enough motivation for Apple to upgrade UNIX utilities. Many UNIX-savvy users can live with the older versions (in fact, many utilities have less features, because they were the BSD-variants). And if something is really too old, people just install a newer version via Homebrew.
Besides that, Macs are only a small part of their revenue and only a subset of that revenue is provided by developers and people using OS X as a UNIX. Of the developers, probably a sizeable chunk uses OS X just for developing iOS apps.
Personally, I'd like to see them update the user land with utilities from the BSDs and contribute back. But that's probably not gonna happen. The time that Apple was mostly a user-friendly UNIX vendor are over. It's a consumer device company now.
With Mavericks, the situation is a lot like any other Unix distribution. Unless you have a very good reason for it, you don't want to break working code during a (mostly-)automatic update. For example, RedHat shipped Python 2.6 as the default for many years after Python 2.7 was released -- using 2.7 would have broken user installations.
Personally, I'd like to see Apple volunteer with the efforts the BSDs are making to create good BSD-licensed alternatives to the GPL software that's shipped. However, as you briefly mentioned, a lot of the software has different quirks and design decisions that will cause code to break. BSD grep, for example, mostly Just Works, however, I had to switch back to GPL grep on my FreeBSD box because a few bits and pieces had changed enough to make things a hassle.
So, yeah, it is in this specific case the GPL's fault.
Sort of like the 'You're holding it wrong" response to iPhone reception back a few years ago.
http://www.cnn.com/2010/TECH/mobile/06/25/iphone.problems.re...
sort appears to be (2005), and doesn't have the -R flag for shuffling
also missing: head -n -NUM (all but last NUM lines) and tail -n +NUM (all but the first NUM lines)