I've worked at Microsoft and can attest that while it's OK to use open source tools internally the IP lawyers don't want anyone touching GPL v3 tools to do anything. If you suspect a project might have been even the slightest contact with anything GPL 3 you must call for an immediate code scan and legal review. You cant even use GPL 3 inside of an internal web tool. I imagine Apple and other proprietary software publishers have the same mandate to their troops.
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.
> So yes, GPL 3 is hurting open source more than helping it.
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 is designed to preserve the end-user's freedom. In order to do that, it only grants other distributors the right to copy it if they agree to grant the same rights to others they distribute it to.
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.
I don't think the FSF distinguishes between users and programmers. To them a user has the right to be a programmer on any piece of the software, and the license reflects this.
Yup. FSF's licenses are rooted in copyright, they say nothing about users, only distributors, because usage doesn't involve copying.
AGPL would be a notable exception though.
The GPL licenses give users freedom by forcing distributors to behave in certain ways.
sigh, Every time I hear this argument, I imagine a kid being given a big bag of candy, and asked to share and share alike in school. Feeling cheated out on eating it all, the kid cries about how repressed they are from not be able to decide who should be denied a taste.
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.
There's a strong willingness to adopt open source tools in every large company but GPL 3 is poisoning the well, and that's impeding universal adoption of the open source ecosystem. Sure FSF doesn't care, and that's unfortunate, because that stance is actually keeping proprietary enterprise software on life support. Unintended consequences I suppose.
GPL prevents DRM and patents. In what way is those two good for the open source ecosystem?
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.
> I've worked at Microsoft and can attest that while it's OK to use open source tools internally the IP lawyers don't want anyone touching GPL v3 tools to do anything.
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.
While Apple has not publicly said anything about it, it's pretty clear from their actions that they consider touching anything under the GPLv3 verboten.
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.
Sorry, are you asking why Apple and Microsoft do not allow distribution of GPLv3 licensed packages?
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.
You're just describing the changes in the license, and none of those seem particularly objectionable. You seem to agree that the DRM restriction is quite harmless. The anti-tivoization clause might reasonably apply to iOS, but I don't think iOS includes any version of these utilities, and that still wouldn't explain excluding them from OS X. It's not like they couldn't just take them back out later on.
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.
Have you watched Apple's patent war with Samsung? They rely heavily on patents to attack competitors. If they distributed something under the GPLv3, then there's the chance that Samsung could have looked at that, said "hey, that GPLed package implements something that your patent license covered, that means that we now have a license to that patent."
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."
Well, this thread is about Apple, and the one you were responding to was comparing Apple with Microsoft. The part about "other proprietary software vendors" was in there, but I'm not trying to back that up since that's too broad a category to discuss as a whole. There are several different kind of proprietary software vendors, that sell software in many different ways, and so discussing them as a category is likely not to be useful.
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.
> If they distributed something under the GPLv3, then there's the chance that Samsung could have looked at that, said "hey, that GPLed package implements something that your patent license covered, that means that we now have a license to that patent."
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.
Sure, and that kind of stuff does happen. And Apple likely makes decisions based on limiting their liability to that kind of thing. They have publicly stated that they objected to Ogg Theora because they had a patent license for H.264, and didn't think it was worth the risk to ship something like Ogg Theora, which may be covered by unknown patents.
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.
I agree with lambda that it is probably the patent clause.
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.
Distributing something under GPLv2 (or for that matter the BSD license) allows the licensee to make an unlimited number of copies. You can't comply with the GPLv2 without authorizing an unlimited number of copies. Licensing an unlimited number of copies while only paying for a patent license for one is just begging for a lawsuit by the patent holder, your customers, or both.
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.
> So yes, GPL 3 is hurting open source more than helping it.
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 don't speak for Microsoft. I can only say there was plenty of willingness to use and contribute to open source but the whole GPL 3 question makes that confusing.
Before GPLv3, Microsoft extorted millions from companies by threatening them with undisclosed patents that claimed to cover all linux distributions.
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.
Well, and Linus would never agree to move to the GPLv3 even if that were an option (assuming that copyright were assigned to him or an organization he had a controlling voice in). In his opinion, the GPLv2 is the perfect license, and he doesn't like the additional restrictions imposed by the GPLv3.
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.
Looking at the opinions of specific individuals is kind of missing the point. Theo de Raadt and Bill Gates don't much care for GPLv3 either.
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.
Right, and so like Linus and the Linux kernel, that's why they don't ship code under the GPLv3.
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.
Sure free software has moral agenda, but imagine you work for a big company and you can't use a lot great open source tools at your job because the license is deliberately crafted to scare and challenge the IP lawyers of any software company.
>imagine you work for a big company and you can't use a lot great open source tools at your job
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.
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?
Indeed, that's what the GPL requires. There is absolutely no necessity to put the sources online like they do.
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,
Apple considers iOS to be a branch of OS X, so I imagine they consider it covered by these releases. I can't really imagine what FOSS code they would feel compelled to include in iOS that's not already in OS X, anyway.
I find it very mildly ironic that the author is comparing these "ancient" versions to MacPorts. Am I naïve, or do the overwhelming majority of OS X developers use Homebrew nowadays? I've always thought Homebrew to be much more robust than MacPorts. However, I've never actually used MacPorts heavily (and probably never will).
There is a tool we use at work (rpmbuild, I believe) that's not available via homebrew and only through macports. It's a nightmare, because if you install macports, it interferes with brew (or at least, brew will complain a lot). I've taken to running a VM in lieu of macports.
Hah, that sounds really, really painful. Wouldn't you take to finding a way to compiling it yourself or committing a Formula for it instead of installing MacPorts? But if a VM works, don't fix what isn't broken, I guess. (Biochemistry is my day job, so forgive me if I'm missing an obvious detail of full-time development).
Most developers I know who use OSX use brew; fink used to be the big thing, then macports. I know for some certain packages, macports is still preferred.
I don't use any of the extra package managers for OSX. I'd rather let Apple manage the tools available in OSX. If I need to do work where I find the command-line tools on OSX lacking, I'll end up working on a remote server or use a local Linux VM.
I try to not muck around with the base installs too much - it makes it too difficult to migrate between machines.
You should look into homebrew[1] if you haven't already. It installs everything in /usr/local and does not mess with the base install. To migrate between machines you can do something as simple as brew list > brew.txt
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.
It's like death by a thousand cuts, only in reverse -- homebrew is lovely crafted with a lot of attention to detail, so it just tends to work pretty well in practice, which was not my experience with MacPorts.
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"
Hard to explain exactly. The UX is just a lot better and more intuitive. It seems to be more reliable. It doesn't require root privileges to install things, which can be good or bad depending on your use case. I think it makes sense on OS X machines.
Not mentioned and highly significant: Apple hasn't shipped anything which is licensed under GPL v3. That cuts them off from a lot of upstream development, including particularly upstream versions of bash.
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'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.
Is it significant though? I can’t really see why bash of all software should be critical. As pointed out elsewhere in this thread, other operating systems do not rely on bash being installed.
It is the GPL's fault. There was enough change in the social implications of v3 that Apple, and a lot of other stakeholders, don't want to mess with it anymore. The FreeBSD team, for example, has very similar reasons for not including GPL3-infected software, and are actively replacing all GPL software with BSD-licensed software in the base install.
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.
I was only addressing the GPLv3 programs because that was the grandparent was addressing. For Yosemite, lot of the other software, with the notable exception of Vim, seems to be fairly close in version to what the current release is. OpenSSL is an outlier too, but that may very well be a case of the amount of API changes with OpenSSL 1 that didn't provide a clear benefit, but did create new openings for problems.
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.
Cherry-picking the BSD ones is problematic for backwards compatibility without making significant alterations. Many gnu tools support options that their BSD variants do not and some have slight differences in behavior even when using BSD compatible flags.
The GPL is a viral license; it's an intentional choice on their part, and "viral" and "infected" are pretty accurate ways to describe it. Whether you believe that this nature is a good thing for development or a bad thing, disagreeing about the fundamental nature of how the GPL works isn't productive.
But the "viralness" of the GPL applies to modified versions of the covered work, and this is a discussion of the distribution of GPLv3-licensed software in Mac OS X, which is not a modified work. Thus the "viralness" does not apply and throwing out the phrase "GPL3-infected software" adds nothing to the discussion and only stokes flames.
However, there are additional legally questionable terms of distribution which the GPL3 imposes which remain open legal questions. For example, how inclusive is the patent grant? A lot of companies don't want to go anywhere near that minefield, even with using GPL3 software internally, which suggests that it's a much bigger problem than the FSF doesn't want to discuss.
A lot of companies don't want to go anywhere near that minefield, even with using GPL3 software internally, which suggests that it's a much bigger problem than the FSF doesn't want to discuss.
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.
The language shows a lack of knowledge around what a copyright license is, and how it works.
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.
I can't take 100,000 lines of my own code, link it against 10 lines of GPLed code, and re-distribute the result under a license of my choice. I have to use a variant of the GPL.
This is the viral aspect that your argument does not address.
Yes, you can. You can release your code however you want. The BSD license applies to the code provided by the project that chose to license their code under it. You can choose to also license your code as BSD, but you are not required to.
If I ignore or remove the BSD license from the 10 lines, I am removing the permission I had to use them.
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.
I know exactly how a license works. The GPL in its wording frustrates the distribution of free and open software precisely in its requirement that all derivative works by default must also be GPLed. This frustration is amplified when one wants to use a mutually incompatible license, like the CDDL. So yes, a license that makes it hard to cooperate with others is infective and judging by how many companies have avoided the GPLv3, is ineffective as well in encouraging sharing.
Referring to the GPL as viral isn't done because of the rules about redistributing or relicensing the original work. It's called viral because derivative works that I make which use or include the GPL'd code must also be GPL'd. It thus spreads to other projects due to proximity.
That is incorrect. Derivative works must respect every copyright license that is included in it, regardless of type.
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.
I'm not sure what you think we're debating here. I'm not talking about changing the license on the original work. I'm talking about other works which link against or include parts of the original. If you write ReallyCoolTool and license it as GPL, and I write AwesomeGUIApp, which invokes your tool behind the scenes, the GPL requires that I license my code as GPL. By contrast, if you'd used MIT or BSD or similar, I'd be required to comply with the original license when it came to your code, but could license my code as Apache or keep it closed source or do whatever. The viral nature refers to what a project's license does to other code that somebody down the road writes that utilizes the original GPL project.
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.
why is that statement irrational? GPL3 was intentionally changed to be more viral. I think it's creators have even used the terminology themselves. Calling GPL3 software infected seems like perfectly fair turnabout.
>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.
It's not about needing to open source their code. Apple ships and maintains GPLv2 software, like CUPS. However, the additional requirements of GPLv3, like the questionable patent clauses, make Apple, like a lot of other companies, nervous about including GPLv3 software.
Yes. This point also highlights the distinction between interactive shell and system shell. You probably want a bunch of featutes in your interactive shell. You probably want a small, readable code base in your system shell. These two goals are generally at odds.
Not happy with the shell quality, code quality, or license. Bash is massive compared to pdksh (what openbsd uses), has frightening code, and openbsd rejects GPL code as much as possible (gcc/binutils is the only GPL software in the tree, and no new GPL software is considered).
The way the article is framed, you'd think that it's somehow the GPL's fault that these applications aren't being updated. Seriously? Why doesnt Apple write their own implementations of those applications? Why shift blame to the license? What a crock of shit
that's how Apple works. They don't make mistakes, they remedy mistakes that others have caused--loudly--while hinting at someone else owning responsibility for the issue.
Sort of like the 'You're holding it wrong" response to iPhone reception back a few years ago.
As someone in the comments section of the original post put it, "newer doesn't mean better". Obviously software with security, stability, or performance issues should be re-written, but software doesn't "age" in the usual sense of the word; the source code can be re-compiled for brand-new machines/processors. A 2004 version of grep will always do everything I need grep to do.
Am I misunderstanding what the author means by 'real release' in terms of OpenSSL? OpenSSL themselves pushed 0.9.8za and Apple later adopted it after a significant amount of nagging in the developer's forums on the issue.
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.