Something that isn't transparent in this discussion is the fact that Linux is extremely corporate now.
By that I mean, the vast majority of contributions are sponsored by corporations.
Both Linus and Greg know that. They are keenly aware that if Linux takes a hardline GPL approach it will gain the reputation of being unfriendly to corporations. That perception will kill Linux in the long run.
When they say they "Care about Linux more than GPL" they are really saying they care about corporate Linux since non-corporate Linux virtually doesn't exist anymore.
I have nothing against that and honestly I think they have more clear opinions due to their positions as top-level maintainers. I just think the motivations and incentives behind their opinions should be clear to more people.
The people's Linux is virtually dead. People need to eat. An analysis of that phenomenon would be interesting as well but is beyond the scope of this discussion.
This seems to be an extremely glass-half-full view.
The other view is that what would have otherwise been "non-people's" OS contributions now belong to the people. All these "corporate" coders are putting code out in the open. Isn't this better than everybody working on closed-source kernels?
Those that are violating the GPL would have done what instead? License a closed-source kernel? Use a BSD and not contribute back?
Even though corporate Linux may not always co-align with my interests as a user, it seems to align at least as much as any non-corporate dev who's contributing to Linux. I'm only one person, but the GPL projects that don't have full-time or at least paid maintainers seem to align with my interests as a user with the same or less frequency as the ones with a corporate maintainer.
So I'm not sure that corporate/non-corporate is a useful distinction for this.
>They are keenly aware that if Linux takes a hardline GPL approach it will gain the reputation of being unfriendly to corporations. That perception will kill Linux in the long run.
I'm not sure I agree with either of these statements, to be honest. Those corporations that are violating the license aren't contributing back to Linux anyway; so losing them won't kill Linux. And Google or other corporate Linux sponsors are not going to be scared away by having to conform to the GPL.
> Those corporations that are violating the license aren't contributing back to Linux anyway; so losing them won't kill Linux.
I don't think that's what the grandparent was worried about. If the kernel developers defend the GPL too ardently, some companies that currently contribute, or that are considering contribution, may be worried about violating the license and decide that it's in their best interests to avoid Linux altogether. I agree that it wouldn't actually kill Linux, but it could potentially do more harm than good by scaring away potential contributors that are a little more on the fence.
By that argument, every non-copyleft licensed codebase is "dead" with respect to the "people".
In reality, the opposite is true even though it burns up FSF folks. Linux is alive and well. You can download, read, edit and contribute back to the kernel for free. Maybe your patches won't be accepted, but the license doesn't guarantee that they will be anyway.
It is true that you may periodically experience a scofflaw that sells you a router that hides some kernel code, but this should only bother you on philosophical grounds. The vendor has no obligation to allow you to "repair" or modify the device. The vendor is under no obligation to accept a patch from you if you find a flaw. Putting linux in a device does not grant the end user any specific right to change the device's behavior. People seem to be confusing "hackable" with "has GPL code". A shitty router with linux code will probably remain a shitty router.
I can see why the FSF and SFC might be throwing a fit; Clang and LLVM can replace GCC, and Linus isn't at all militant about license enforcement. The effective power of the FSF is in rapid decline.
> In reality, the opposite is true even though it burns up FSF folks. Linux is alive and well. You can download, read, edit and contribute back to the kernel for free. Maybe your patches won't be accepted, but the license doesn't guarantee that they will be anyway.
This isn't untrue, but it does not take away the main point: the community that drives the development agenda and dictates priorities is no longer a community of independent programmers (in the broad sense of the word; many contributions used to come from people who were hired by commercial entities, but they were still relatively small groups, and contributions were limited to small pieces that were specifically interesting for their small-ish employers: a driver for this or that network card, improvements in this routing protocol and so on).
This is no longer the case, and the development agenda of the Linux kernel is almost completely dictated by large players, at the expense of small ones and, to a large degree, individual users.
> at the expense of small ones and, to a large degree, individual users.
Is that a real expense at all though? I would argue that, empirically, it is zero. As in zero evidence of contributions to Linux detracting from my needs as a small player and user.
Every community is going to drive things in their "own" direction, and that direction is largely dictated by use by those developers. If it were a difference, an expense on the people, there would be a community with differing views of what the kernel should be doing. They could contribute code towards their ends, or fork. Given that there is practically zero interest in this, I would say that it's fairly clear that a so-called "corporate Linux," in the form of largely corporate code contributions, has come at zero expense to the "people."
> People seem to be confusing "hackable" with "has GPL code".
Well, to be fair, wasn't the GPLv3 created to make those two strongly correlated? I know Linux is gpl 2, and Linus is publically against v3, but I get the feeling this was considered a large loophole in the spirit of the license.
Also, one of the advantages of the GPL (I think there are disadvantages too, but that's another post) is that all those companies can contribute without the fear that one of them will 'defect' and run off with things, perhaps hiring up enough developers to make their fork the 'best' one.
I can not imagine that Linus is sold to corporations. IMHO, his stance is that he wants:
- Linux to be working well on all the new hardware
- he wants open source for all the code he wants to hack.
- he does not care if some firmware is closed source as long as this does not harm Linux behavior.
A lot companies use Linux kernel and don't release any of the source. They are working on the backs of millions of hours of human labor. For example DJI uses linux on its drone and open wrt on its controller. I don't see any source code for that. LeTv and many other Chinese cellphone makers don't release source code for their kernels. They really have no alternate they could go to. I think it makes sense that kernel community would be more aggressive about making companies return the code with which their products couldn't really exist without.
The Linux kernel codebase is pretty flexible. Are there really changes that had to take place to put the kernel into a drone? If not, there's nothing for DJI to release.
Isn't there already a mechanism for handling binary-only kernel modules/drivers? Perhaps DJI's 'changes' can be expressed in such a binary-only module.
There seems to be a fairly large part of the tech community that is willfully ignorant of how these licenses work and how the kernel copyright holders have addressed violations in the past. These folks seem to think that because some corporation downloaded the Linux kernel source, that the company's entire codebase should be open source. As always, it's much more complex.
My understanding is that they have to provide clear instructions on where to get the source.
In general, bringing up Linux on a new platform does require extensive modifications. They often use u-boot too, things like switching on the system DDR, DDR timing etc require significant changes to u-boot (which is also gpl).
In my experience those changes rarely get released.
I've never heard anyone say a company should release everything just because they used the Linux kernel... But that's just me.
> My understanding is that they have to provide clear instructions on where to get the source.
No. Only when they distributed their software to you (the Linux kernel under the GPL) then you can request the sourcecode for that under the GPL.
If you never had any code being distributed by them to you, they have no obligation to you.
This is a common misunderstanding. You have two choices when distributing GPLv2 software commercially: you can either provide the source code alongside the binaries (section 3(a)), or you can provide a written offer to provide the source code on request to any third party (section 3(b)). Non-commercial distribution can forward on a 3(b) offer rather than making their own.
Exactly. Except that if you as third party do not receive the the Program (or a work based on it, under Section 2) in object code or executable form, then you have no rights under section 3.
So a company that sells GPL'd software is only required to provide the source to any of their purchasers (however, those purchasers are not restricted in any way and can give the source to someone else). So the only way I could get the source code from that company is if I purchase their product.
> So a company that sells GPL'd software is only required to provide the source to any of their purchasers (however, those purchasers are not restricted in any way and can give the source to someone else). So the only way I could get the source code from that company is if I purchase their product.
That's not correct. The text of the license says:
> 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,
It say any third party. There is nothing in there that limits it to only those who purchased it from the company. If the company elects to go with the written offer approach and I buy a copy from them, and then I give you a copy, they are obligated to give you source code if you ask even though you did not purchase from them.
As explained in the GPLv2 FAQ:
> What does this “written offer valid for any third party” mean? Does that mean everyone in the world can get the source to any GPL'ed program no matter what?
> If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it.
> If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.
> The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.
Also relevant from the FAQ:
> My friend got a GPL-covered binary with an offer to supply source, and made a copy for me. Can I use the offer myself to obtain the source?
> Yes, you can. The offer must be open to everyone who has a copy of the binary that it accompanies. This is why the GPL says your friend must give you a copy of the offer along with a copy of the binary—so you can take advantage of it.
OK, I stand corrected. However, it sounds like technically you must possess a copy of the binary to request source code, although the GPL doesn't require you to furnish proof that you have such a binary. IE there must be a chain of transferring the written offer from company to purchaser to third party. Or in other words you must have a copy of that written offer in order to request the source code (and the text of the FAQ seems to support that).
>Are there really changes that had to take place to put the kernel into a drone? If not, there's nothing for DJI to release.
Yes, there is. If they distribute a product with binaries built from GPL'd code in it, they must provide the source upon request. It doesn't matter if they've changed it or not.
> If they distribute a product with binaries built from GPL'd code in it, they must provide the source upon request.
That's a little bit of an overstatement. It is sometimes possible to distribute GPL binaries without incurring any source obligation, and I suspect that this is going to be come a lot more common as IOT devices become more popular. For example, Amazon, Best Buy, Walmart, and others sell assorted consumer products, such as televisions and routers, that contain Linux-based firmware, but they do not have any obligation to provide the source.
All they are doing is receiving boxes of televisions and routers and other goods from the manufacturers (or from the distributors who receive them from the manufacturers), and then selling those items to the consumer on a one to one basis. A copy of Linux comes in to them embedded in some physical thing, such as the FLASH memory in a television or router, and they sell that particular physical hardware and that particular copy of Linux to a consumer. The first sale doctrine, which pretty much every major country I believe has in some form in its copyright law, says that doing this does not require permission of the copyright owner. If you aren't doing anything with GPL code that requires permission of the copyright owner, GPL has no power over you.
Right now, I don't think this is a big issue because usually you can find out who does have an obligation to provide the code. Buy a television or router from Best Buy, and it will be from some reasonably prominent manufacturer, such as Samsung or Netgear, and that manufacturer probably is the one who was actually making copies and putting them on the device. They have the obligation to provide source, and they usually have some reasonable way to contract support and find out how and where to actually get it.
I think this may change as IOT becomes more common. I think we'll see several companies that make generic IOT base platforms, which they sell to companies that want to make IOT devices for specific applications. Those companies will add their software to the software of the base device, and hook up the specific sensors and actuators needed for their application.
A technically sensible way to make the generic base platforms is to make a Linux-based system that has the kernel and the standard utilities on a root partition in FLASH memory, and has a memory card slot. Upon startup have the init system wait for a memory card to be inserted that contains a valid filesystem, mount that filesystem on /home, and then look for /home/iot/startup.sh. If that exists, it becomes the iot user and runs /home/iot/startup.sh.
Companies that use this generic base to build their IOT device do not have to modify or copy the kernel or anything else on the root partition. All of their code lives on that separate memory card, as user mode applications and scripts. These companies, when they want to make a manufacturing run of, say, 5000 devices, would buy 5000 units of the generic IOT base system, build and connect 5000 of their sensor and actuator modules, insert 5000 copies of their user mode application and script memory card, and ship the 5000 devices out to customers, distributors, and stores.
So you go to Best Buy and buy one of these things and want source code to the Linux contained therein, what do you do? If you ask Best Buy, they say they just passed on the box they received, and point you to the manufacturer listed on the box. When you contact them, they say the same thing...they just bought these generic Linux IOT bases, and plugged in their hardware modules and inserted their memory cards (which contain no GPL software), and if they are feeling nice they tell you the name of the company that made the IOT base. If they are not feeling nice, or they consider information like who their suppliers are to be a trade secret, they may decline to tell you where they got the base platform, and you are pretty much stuck.
It could even get worse, because I suspect that in some markets there may be multiple layers of this. You'll have at the bottom layer companies making a fairly generic Linux-based system for embedded use. At a layer above them you'll have companies that take those generic systems and partially specialize them for particular industries or fields or activities. They may add special hardware interfaces, put them in rugged cases, or things like that. A layer up from that would be the companies that turn these into products for end users.
And that isn't even the worst it can get. It is actually possible to get a GPL binary commercially that nobody has obligation to provide source for. That's because GPLv2 provides two ways to satisfy your source code obligation if you commercially distribute a GPL binary:
1. Include the source when you distribute binary.
2. Provide a written offer, valid for at least three years, to provide the source to any third party who requests it.
Suppose the maker of the generic IOT base device, the one that has Linux on its root filesystem and on startup tries to mount the memory card and run the user mode application found there, includes in each box a CD-ROM that contains the source for all the software on the root filesystem. (That's what I would do...I'd rather go to the slight added trouble up front of adding a CD-ROM to the shipment now and be done with it than have to deal with it spread out over several years).
Their customer, the company that is making, say, an IOT nose hair trimmer, doesn't care about those CD-ROMs. They just want to add their hair length sensor module, and their clipper module, insert their memory card with their software, package it all up nicely, and ship it off to the retailers. They toss the CD-ROMs in the trash.
You buy one of these nose hair trimmers. Who is obligated to give you the source? How about the generic IOT base device maker? Nope. Every GPL binary they shipped was accompanied by the complete source code, so they satisfied their GPL obligation.
How about the nose hair trimmer company? Nope. They are just shipping out copies they received, and are covered by the first sale doctrine.
If this becomes common enough for the FSF to see it as an issue that needs to be addressed in GPLv4, it will be interesting to see if they can come up with a good solution. The basic problem is that the option to satisfy your GPL obligation by including the source with the binary extinguishes your obligation in regard to that binary without guaranteeing that when the recipient of that binary redistributes that they will incur a source obligation (because first sale provides a situation in which they can distribute without incurring any copyright obligation).
Offhand, I only see one way to address this. Make it so that if you distribute a GPL binary (in a way that required copyright owner permission) then you must provide source to any third party that requests it. Back when GPLv2 was written, that could have been quite onerous, because distributing source usually meant sending a tape. Nowadays, distributing only is easy, and there are plenty of free hosting services for source code, so it probably wouldn't be too onerous. Still, that would be a pretty big change, and I think a lot of people would be very upset at the "fire and forget" option that "include the source code when you distribute the binary" provides.
In practice, doesn't sound very problematic to me. As long as the IoT base device manufacturer is compliant, someone can just buy a board (for "product development" purposes) and then release the source publicly.
Nah, there I agree with tzs, after the manufacturer sells the product, copyright has been exhausted and the distributor has no obligations unless they make new copies of the work.
From section 3, my understanding is that if you distribute then you must do one of the following:
a) include complete source code
b) include an offer of source code if contacted
c) include the offer of source code you originally received
(It's a bit more complicated than that... but close enough)
So... if they're distributing the kernel as part of a drone they're selling, these clauses would apply?
I'm not sure why "changes" they may or may not have made would have anything to do with it?
Can that happen? 3(c) is only applicable if they received the code in object or executable form. Does kernel.org distribute object code, or just source code?
I see this as a stealth attempt by the Software Conservancy to hijack the direction and tone of kernel development, dragging it more to FSF-style militancy.
Linus is right, there is no crisis in GPL violation. There will always be violators. Any law or contract or license will be violated. Becoming more militant about enforcement will simply cause most corporate partners to disengage. Most users comply with the license. Users have access to interesting and useful source code and have never been restricted from accessing the kernel. The kernel team is on good terms with most corporate users. Going after the 5% of violators will change how the kernel team interacts with the 95% of good partners.
The only thing Linus seems to be disingenuous about is his claim of support for the GPLv2. My guess is he secretly wishes he had chosen a different, non-copyleft license.
Linus has publicly said that he is very happy with having chosen GPLv2, he just doesn't like GPLv3 and doesn't like dealing with it through lawyers.
Copying my comment from reddit when this was discussed last week:
> As the thread linked shows though, Linus cares about the GPL for what it gains him not what it gains the user. The spirit of the FSF and the GPL is for the user, not the dev.
>He only cares about actions that lead to code getting back into the upstream kernel, whereas others(and the FSF) care primarily about people being able to view and modify the code they use and that is running on their devices.
>I'd argue he likes the GPL for what it gains him but isn't really a GPL/FSF advocate.
>Edit: It is important to note that this is one of the core reasons Greg/Linus and the FSF/SFC disagree I think. Karen from the SFC had an IMO excellent response in that chain that matches my thoughts if you are curious.
Linus would like to have his cake and eat it too. On almost every debate on licensing (binary blobs etc), he's consistently taken a "liberal" approach that would better suit a BSD/MIT license rather than the GPL. Through the years, he basically enjoyed the benefits of the "forceful mindshare" the GPL imposed on other developers, all the while pissing on everything the GPL promoted: "hey, you're forced to show us what you developed, but really I'm not going to force you wink wink". As much as I understand the world is not black & white, overall it's a very hypocritical stance.
I (the end-user) get a device with a blob that looks like a Linux (the kernel). I don't get any freedoms (but to whine to vendor). And I get a message from the very head of kernel developers that they aren't interested in me having anything.
Now, it's also true most users don't give a damn about their freedoms. And those who do are such a tiny minority they can be just ignored - unlike the valuable corporate partners.
The vendor isn't obliged to make their device hackable even if they do publish the source. Some do, and that's neat, but in most cases, access to the source might, at best, only result in the next iteration of device having some change in a year's time. Your little box will continue to make you unhappy. You should just get a refund.
The kernel developers aren't on the hook at all here. No one told you to buy a specific device.
Except for devices that are hackable in practice, but aren't much so because of this heartwarming attitude.
It's not unusual that someone had managed to build the kernel that boots (and even works well) but doesn't know how to interface some hardware. E.g. a hardware NAT engine of a SOHO router, so FLOSS firmwares have to NAT in software. Or some sensor on a phone. The secret is in the kernel and that kernel's source's supposed to be available but it isn't.
Here, we don't talk about the product itself, as a whole. We talk about its kernel.
Sure thing, if I don't have access to the kernel, then it's all irrelevant. We only consider the cases when the device is actually hackable (despite whatever its vendor says).
> Linus is right, there is no crisis in GPL violation. There will always be violators. Any law or contract or license will be violated.
Maybe proprietary software companies are happy with the current situation, but as a user who cares about my freedom, I'm very unhappy with the current situation.
> Becoming more militant about enforcement will simply cause most corporate partners to disengage.
Maybe people should spend less time feeling sorry for corporations and more time considering users. If you're someone who has a shitty Bluetooth light bulb running a version of GNU/Linux, the person who has given you that device has taken away your software freedom and everything that comes along with that. Having software freedom means you can completely eradicate vendor lock-in and planned obsolescence from the technology you use, as well as being able to create a community and help yourself and others as a result. Not having software freedom means that you are alone as a user of a product, at the mercy of the company that gave you that device.
You see this all the time, and it worries me that it takes Matthew Garrett posting about how insecure this stuff is for people to even _consider_ that there is a serious user-facing problem here. Yes, IoT is generally not doing well, but there are legitimate uses of this stuff (people who have disabilities for example) and not caring about their software freedom is a serious social issue.
> Most users comply with the license. Users have access to interesting and useful source code and have never been restricted from accessing the kernel.
The GPL has no restrictions on end users. It only has restrictions for distributors, to ensure that any eventual end user of a piece of software will have software freedom and all of the benefits that come with that.
> If you're someone who has a shitty Bluetooth light bulb running a version of GNU/Linux, the person who has given you that device has taken away your software freedom
How? You don't have a right to modify the device you purchased. You don't have a right to manufacture a clone of the device and run your patched code on it. The vendor can happily decline patches from you. So can Linus.
All you will have is the right to inspect code they used and learn from it or reuse it in a lightbulb you choose to manufacture that doesn't violate some other IP the original vendor has on the original bulb.
There is absolutely nothing about the GPL that grants you any particular freedom regarding the specific light bulb you purchased. If it sucks, it will continue to suck.
> You don't have a right to modify the device you purchased
Actually, at least in some jurisdictions, you do. What you don't have is an obligation that device vendor helps you - unless they took some obligations to do so (and GPL is one).
But it's entirely another story that they had chosen to use GNU or Linux bits in their software.
> How? You don't have a right to modify the device you purchased.
I absolutely have every right in the world to do whatever I want with any device I own (baring things like tweaking WiFi to violate FCC rules). Why would you even say that?
Of course you can violate your EULA in your own home and get away with it...but you are still violating your EULA and that has absolutely nothing to do with linux or Linus or the GPLV2 anyway
> You don't have a right to modify the device you purchased. You don't have a right to manufacture a clone of the device and run your patched code on it.
Yes. In fact, isn't this exactly why GPLv3 has the anti-TiVoization clause? Because TiVo under GPLv2 were entirely in their right to deny user-modified GPL-licensed software from running on their hardware.
> You don't have a right to modify the device you purchased.
Under GPLv3 you have the right to modify the device you purchased if the manufacturer (or the person you bought it from) has the same ability. Linus doesn't like the GPLv3 for what appears to be I-dont-care-about-user-freedom reasons, which is why only parts of the kernel are under GPLv2-or-later. But that's the main reason why I make all of my projects GPLv3, so that users are protected in this instance as well.
"I see this as a stealth attempt by the Software Conservancy to hijack the direction and tone of kernel development"
I see it as the Software Conservancy spitting some reality into Linus' Cheerios. But then again, I've been forced to replace devices because Qualcomm/Mediatek/Obi/D-Link decided GPL compliance wasn't their cup of tea. So I'm probably biased.
The bold text says financial gain should not be prioritized, but it them proceeds to rationalize why financial demands are required:
"Financial penalties are a legitimate tool to achieve compliance when used judiciously. Logically, if the only penalty for violation is simply compliance with the original rules, bad actors will just wait for an enforcement action before even reading the GPL. That social model for copyleft and its enforcement is untenable and unsustainable. An enforcement system without a financial penalty favors bad actors over good ones, since the latter bear the minimal (but non-trivial) staffing cost of compliant distribution while the former avoid it. Copyright holders (or their designated agent) therefore are reasonable to request compensation for the cost of their time providing the compliance education that accompanies any constructive enforcement action. Nevertheless, pursuing damages to the full extent allowed by copyright law is usually unnecessary, and can in some cases work against the purpose of copyleft."
Based on their 990 forms that they've submitted to the IRS in 2011-2013, they are averaging $100,000/year in settlements. Which is pretty impressive considering that they don't develop software.
I do realize that they have other sources of income, via donations and conference services and what not. But that doesn't change the fact that their legal activities bring them revenue.
This is one of Linus' main points in the discussion, it will change the tone and signal to partners that interactions with the kernel community will carry with it interactions with the Software Conservancy, which most companies will see as an expensive, frustrating and pointless waste of resources.
> If they are not violating the terms of the license, what would change?
Increased vigilance in enforcement of anything almost invariably means greater incidence of prosecuting non-violators, causing them to incur costs to establish that they are not in violation.
In the case of Linux, this increases the expected costs of using the kernel even in accord with the license.
What the Conservancy is "interested in" is a different thing than what interaction with them causes.
Enforcers often are (or claim to be) interested only in compliance. Their efforts to secure compliance where they believe compliance is lacking incur costs that would not otherwise exist, even where compliance already exists.
A dangerously close analog to the "nothing to hide"[0] argument.
As mentioned in the parent article and other linked discussions, there is not certainty in litigation. The terms of the license are complex, and there can be healthy debate over what is and is not a violation.
Membership in the 5% and 95% is not clear until after litigation. You do not get to decide that you are in compliance. You get to take actions which you understand to be in compliance. If someone disagrees, they can sue.
Taking a stance of aggressive litigation will make everyone think twice about using software that opens them up to expensive litigation.
"A dangerously close analog to the "nothing to hide"[0] argument."
No, it really isn't. The idea that a company that is complying would walk away because those that aren't are gone after is foolish. It's like saying a freelancer shouldn't pursue people who stiff them on payment, because other potential clients might hear about it, and choose not to hire them.
Of course, a freelancer who has a healthy practice and good relationship with many clients can and likely will lose some clients if they take a publicly aggressive stance with other clients.
And, be clear, egregious violations aren't the concern. The concern is if you see a freelancer constantly partaking of expensive or just annoying audits on good faith partners. It can drive folks away.
This is why the lines are drawn at 95/5. If it were actually the other direction, things would be different.
For the same reason that video game companies that use invasive DRM just end up turning off legitimate customers. You treat legitimate customers like criminals, and people don't want to be your customers.
> The only thing Linus seems to be disingenuous about is his claim of support for the GPLv2.
I don't believe he's being disingenuous. What's happening is that Linus, and Greg, see the GPL as a tool, a lever if you will, to multiply the amount of code contributed to Linux and other open systems. From that engineering POV they see it as an important contributor to the success of Linux. As a consequence of that, they are in no hurry to change it as it meets their need.
What they clearly don't agree with is the political motivations that drove the creation of the license in the first place. Nor do they appear to be overly concerned, on either a moral or legal level, about its violation. My guess is that, while it continues to help in their endeavour, they will continue to support it. If it were to get in the way, they would feel forced to re-think it. What I read in the thread is the view that they are concerned that a significant increase in legal actions could become a problem for them.
I have some sympathy for both sides. I'd probably err on the side of Linus and Greg as my pragmatism generally outweighs my activism.
No, it's GPL. It's a perfectly reasonable, and not uncommon, strategy to use legal instruments for protective or signalling reasons but not as an offensive weapon.
Patents are a similar example. They're often held defensively and for cultural signalling. When they're pursued aggressively, it's generally considered trolling.
And yeah, it's a sweet deal. TBH I think that's the point - a lot of people get a sweet deal, including corporations. Where the argument seems to lie is how much should we care about free loaders if everyone's getting some candy.
The point is that people going to the SFC for help are clearly "not getting some candy", otherwise they wouldn't be bitching. A "non-enforcement" deal is much, much sweeter for corporations and sociopaths than it is for people doing the actual work.
The phone makers don't care about specific the kernel used in Android. They care that they can access AOSP. AOSP could use other kernels and other licenses, it wouldn't impact Android's success or value at this point.
Go look at the kernel version in Android, even Android 7.0...kernel 3.10. We might be overestimating how important linux is to Android.
OEMs that produce devices end up doing non-free things writing checks to companies like Micorosft for intellectual property, so it isn't like AOSP delivers on the promise to let anyone make a phone, GPL kernel or not.
If Google actually follows through with this Fuchsia project, do you think OEMs will balk because the kernel isn't GPL'd? No one will care.
>Going after the 5% of violators will change how the kernel team interacts with the 95% of good partners.
How do you figure that? The only way this could apply is if the "good partners" are violating the GPL on the sly, or with a wink and a nod (not bloodly likely) which would make them not so good anymore.
The GPL has no reason to exist if its terms are not enforced.
....and Linus' point is that the victory will be pyrrhic, since people will simply avoid the GPL altogether.
We've already seen this with the GPLv3/AGPL. Really outside of the FSF, the only adoption is in dual-licensers who use it to drive purchases of the alternatively-licensed sources.
Enforcement of the license people agreed to will cause people to avoid using the license?
The only way that makes sense is if people thought that the GPL was the thing to use was due to it being toothless, a notion that it's strictly better to disabuse people of.
> Enforcement of the license people agreed to will cause people to avoid using the license?
If it means lawsuits, yes. Companies will either seek out a non-GPL solution, or they will be even more secretive about their use of linux. Either way, linux loses and 95% of linux users lose....and the violations will continue anyway.
There is no catch 22. You simply have to figure out what the goals actually are. Linus' goal is to have a vibrant community that has access to the changes he approves in the kernel. The FSF's goal is to eradicate non-free software.
Linus doesn't care about the odd scofflaw because they don't interfere with his goal. The FSF on the other hand cannot abide scofflaws because their only goal is to eliminate them.
And yet at the end of the day, Linus chose a license that demands its users release any changes they distribute, rather than a permissive license like the BSDs.
Linus probably doesn't care about the odd scofflaw because he has better things to do (like maintain a kernel) than to juggle lawsuits.
It becomes obvious from the discussion that Linus is specifically focused on those cases that companies became Linux-friendly after long-term encouragement. He probably took part in such cases.
In addition, he has in mind that companies can abuse the GPLv2 and just do code dumps.
It makes sense what he has in mind but his attitude is too much drama.
maybe he wishes he chose another license, but it would be very ingenuous to think the outcome would have been the same or better. Not saying that Linux wouldn't have succeed (or done better) without the GPL but you cannot say the reverse either...
> My guess is he secretly wishes he had chosen a different, non-copyleft license.
He always wanted a copyleft license because it enabled kernel development to really take off by enabling him to make use of other people's contributions, and he's always been consistent about that.
I bet that what he really regrets, though, is not requiring copyright assignment for inclusion into mainline, so rogue developers can't just join up with the SFC and sue people against his wishes.
The Linus/GregKH attitude might work because it's the Linux kernel. It's almost irreplaceable for those who are using it, it has a huge developer community, it has many corporate sponsors to back up those developers, etc. It's not at all clear that the same approach would work for another project without those things. The way Linux kernel developers make such assumptions and pronouncements reminds me a lot of the way some people talk about social issues from a highly privileged position - utterly blind to the reality for those in different circumstances.
As I immediately reacted on Twitter, I think lawsuits are a lot like nukes. Using them might always be terrible, but their absence negates all leverage in any other kind of negotiation. That includes the kind of negotiation that Greg K-H talks about. In those negotiations, he still benefits from the kind of enforcement he himself eschews. Those who live under an umbrella shouldn't dump on the people holding it up IMO, as the LF stalwarts are doing in their attempts to defend their turf.
Disclosure: I work for Red Hat, which as a company and a community has probably held just about every possible position on this issue - often simultaneously.
I know of one case where Red Hat countersued a patent troll over a GPL violation. It was a pretty good illustration of the "nuclear deterrent" effect that such litigation can have. I'm not aware of any cases where Red Hat has brought any original suits of this nature, but then again I probably wouldn't be even if they did exist.
The whole discussion has been one of the best example of people violently agreeing with each other. Sadly, the article only mention the first few statements and not one of the later done by Greg, which makes it look like a bigger disagreement than it is.
That is a far cry from implied disagreement from the earlier quoted "I do [want companies to comply], but I don't ever think that suing them is the right way to do it". Maybe the Gregs comment is more colorful and has some slight implied differences, but so far I have see little in the discussion to specific when exactly those differences has an practical impact. Both sides seems to be in an agreement (or atleast, not in explicit disagreement) about the status of VMware, as none in the mailinglist (from what I can see) has said that the lawsuit should not exist.
What left is the last paragraph of the article, where at least there is direct conflict. Linus don't trust/like FSF and by extension, SFC. For that, one of the other developers described the situation perfectly. If developers went to SFC instead of the lawyers of LF, maybe Linus should ask why that happened in the first place.
> If developers went to SFC instead of the lawyers of LF, maybe Linus should ask why that happened in the first place.
I think the answer to that is another question: why would LF bother, when they can reap all of the benefits while SFC bears the cost and takes the flak? They get to play godfather in this situation, pretending their hands are clean. The analogy only falls down because godfathers don't typically rat out their own triggermen.
Yes they do. They have to maintain their own branch, which may be very costly when new versions of linux would arrive. Successful upstreaming mitigates that.
They can already hide behind legal firewalls like the Chinese border. If the Software Conservancy continues, they'll just push more development to places where scofflaws can ignore them.
> ... Bradley isn't the one making the decisions here. It's the developers
Gee, this debate seems to have given some large amount of power to the individual contributors to the kernel. Any individual developer could defect from Linus' stance and work with the SFC on an infringement case. I'm curious to see if any of them are more dogmatic with respect to copyleft.
I suppose it makes sense that features CONFIG_'d off shouldn't be considered for infringement, but for many binary distributions of the kernel it probably still catches a lot of developers.
I always thought it was baloney red tape to do copyright assignments but if it had taken place here it would be a very different debate. The developers would have effectively ceded all control over this discussion to the assignee (who probably would've been The Linux Foundation, if anywhere).
> Any individual developer could defect from Linus' stance and work with the SFC on an infringement case.
I was looking for a source and was unable to find it quickly, but I'm pretty sure a significant number of kernel developers have joined some kind of SFC organization that allows the SFC to use their copyright in order to sue for compliance.
As mentioned in the linked email thread, the kernel developers working with Conservancy do not typically assign their copyright to Conservancy, and do not cede their decision-making authority over legal matters to Conservancy.
(Also, they go by "Conservancy" or "Software Freedom Conservancy", not "SFC", to avoid acronym confusion.)
Some developers on various projects (including the kernel) have voluntarily signed over copyrights to Conservancy for various reasons, but their GPL compliance project does not require that.
One thing that wasn't brought up (edit: ok, quickly glossed over) in the article — if you go to court, you can lose!
There are various legal arguments I can think of, that would essentially trash the GPL, and a company with 8 figures to spend on lawyers could make very convincing (I don't agree with these, but a judge and jury could easily):
1. It's unclear whom the actual copyright holder or holders of Linux are, and who has standing to sue on their behalf.
2. Since Linux is open-source, free-as-in-beer, etc, it's public-domain.
3. Linux is a derivative work not entitled to copyright protection.
And so on. Again, when one side might have orders of magnitude more budget for lawyers, this kind of stuff will be very convincing. (Many corps will pony up money to protect Linux, but they'll generally be on the opposite side when it comes to the GPL).
1. Enforcement would not be on "Linux" but would be about a specific section of the code, under which the copyright holder (the dev) is suing.
2. Has no legal basis, something being "Free as in beer" does not make is public domain, that would be easily countered
3. That would probably be more dangerous to the company arguing that then it would be to Linux, since most of the companies that would be targeted by GPL enforcement likely have alot of IP that could also be considered "derivative"
Going to court and losing, while not fun, should be instructive to the GPL community. A loss will either point out areas that need to be changed in the next GPL license version, or that a GPL-style license is not viable.
Yes, it could prove helpful to the GPL community, but it might prove harmful to the kernel community. For all intents and purposes, the Linux kernel is permanently stuck in GPLv2. If a disastrous court case somehow weakens GPLv2 and a new and improved GPLv4 which fixes that weakness comes out, the kernel will be stuck with the now weakened GPLv2.
That was one of the first points addressed in the article: the OP referenced the recent outcome in the VMWare case as an example of an undesirable outcome.
Fair enough; it was one fairly ambiguous sentence and easy to miss.
Not meaning to criticize the article - which I found very interesting - just felt it could be a good conversation thread to discuss an aspect the article didn't really cover.
I agree on the analysis. You don't need enforce Linux in court, Linux will then keep getting more popular, to the point that those GPL-violation will gradually find that upstreaming/releasing their code is actually more beneficial than making the code closed. In the long run everybody wins.
Even Microsoft is embracing Linux as it pretty much has no other choices due to the ever increasing popularity of Linux.
Note that there exists a different organization known as "SFLC", but the linked discussion occurred with the Software Freedom Conservancy (or just "Conservancy"), which specifically avoids using the acronym "SFC" to avoid confusion with SFLC.
By that I mean, the vast majority of contributions are sponsored by corporations.
Both Linus and Greg know that. They are keenly aware that if Linux takes a hardline GPL approach it will gain the reputation of being unfriendly to corporations. That perception will kill Linux in the long run.
When they say they "Care about Linux more than GPL" they are really saying they care about corporate Linux since non-corporate Linux virtually doesn't exist anymore.
I have nothing against that and honestly I think they have more clear opinions due to their positions as top-level maintainers. I just think the motivations and incentives behind their opinions should be clear to more people.
The people's Linux is virtually dead. People need to eat. An analysis of that phenomenon would be interesting as well but is beyond the scope of this discussion.