Kernel contributions from organisations and individual privacy
Hi, This came up at work today and I'm not sure where the best place to ask is. I almost went straight to the lkml but I figured I'd start with newbies first. We've been using the Linux kernel in our products for a number of years now. We're doing all the right things w.r.t GPL compliance but we're not actively pushing that much upstream. This means we're effectively maintaining our own Linux fork with very few resources. I'm trying to avoid this by encouraging developers to get their changes upstreamed. This is good for our organisation because we don't have to re-do our changes when we need to take a new kernel version. Most developers see this as a good career building for them. But some developers value their individual privacy over career progression. My initial response to that was well we can just make a dummy gmail account or even setup a swdept@$organisation shared address. But SubmittingPatches actually says to sign patches with your real name not a pseudonym. Does this basically mean people that value privacy are unable to contribute? Thanks, Chris
I had a similar situation and managed to route patches via an intermediary to protect my employers anonymity at the time. You may (should) be able to find an appropriate sponsor depending on the nature of the customisations. On Wed, Jun 10, 2015 at 7:19 PM, Chris Packham <judge.packham@gmail.com> wrote:
Hi,
This came up at work today and I'm not sure where the best place to ask is. I almost went straight to the lkml but I figured I'd start with newbies first.
We've been using the Linux kernel in our products for a number of years now. We're doing all the right things w.r.t GPL compliance but we're not actively pushing that much upstream. This means we're effectively maintaining our own Linux fork with very few resources. I'm trying to avoid this by encouraging developers to get their changes upstreamed.
This is good for our organisation because we don't have to re-do our changes when we need to take a new kernel version. Most developers see this as a good career building for them. But some developers value their individual privacy over career progression.
My initial response to that was well we can just make a dummy gmail account or even setup a swdept@$organisation shared address. But SubmittingPatches actually says to sign patches with your real name not a pseudonym.
Does this basically mean people that value privacy are unable to contribute?
Thanks, Chris
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- -- Teach your kids Science, or somebody else will :/ jason@ball.net vk2vjb@google.com <vk2flnx@google.com> callsign: vk2vjb
It's not a concern for the _employer_ (unless we say something particularly inflammatory), in fact the organisation sees the benefit of the company name getting out there in technical circles. It's more a case of the _employee_ not wanting their name to show up in mailing list archives, similar to people that don't want a phone book listing or twitter/facebook/google+. One option is for someone (like me) to do the submission and work with upstream to get the change accepted, I don't have a problem with this but it does mean that if/when I move on I take the kudos (as well as the criticism) with me and the company loses out. On Thu, Jun 11, 2015 at 4:58 PM, Jason Ball <jason@ball.net> wrote:
I had a similar situation and managed to route patches via an intermediary to protect my employers anonymity at the time. You may (should) be able to find an appropriate sponsor depending on the nature of the customisations.
On Wed, Jun 10, 2015 at 7:19 PM, Chris Packham <judge.packham@gmail.com> wrote:
Hi,
This came up at work today and I'm not sure where the best place to ask is. I almost went straight to the lkml but I figured I'd start with newbies first.
We've been using the Linux kernel in our products for a number of years now. We're doing all the right things w.r.t GPL compliance but we're not actively pushing that much upstream. This means we're effectively maintaining our own Linux fork with very few resources. I'm trying to avoid this by encouraging developers to get their changes upstreamed.
This is good for our organisation because we don't have to re-do our changes when we need to take a new kernel version. Most developers see this as a good career building for them. But some developers value their individual privacy over career progression.
My initial response to that was well we can just make a dummy gmail account or even setup a swdept@$organisation shared address. But SubmittingPatches actually says to sign patches with your real name not a pseudonym.
Does this basically mean people that value privacy are unable to contribute?
Thanks, Chris
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
--
Teach your kids Science, or somebody else will :/
jason@ball.net vk2vjb@google.com callsign: vk2vjb
On 06/11/2015 01:10 AM, Chris Packham wrote:
It's not a concern for the _employer
If the copyright is owned by the company then ONLY the company can push it up stream and assign copyright to the Linux Foundation. But there is an inherent problem and it sort of bothers me which is why I'm responding. It may be the case that someone can not keep their identity a secret and contribute to the kernel. If you want to keep your identity a secret there are a WHOLE SLEW of things you can't do because they require public identification. It is NOT true that they can't contribute to the kernel because they "value" their privacy. They can not contribute because it is a PUBLIC act and LEGAL public act. And you can't do this, perhaps, anymore than you could run for office anonymous, or take an active roll in any political activity. And that is good thing. Ruben
On Thu, Jun 11, 2015 at 01:19:56AM -0400, Ruben Safir wrote:
On 06/11/2015 01:10 AM, Chris Packham wrote:
It's not a concern for the _employer
If the copyright is owned by the company then ONLY the company can push it up stream and assign copyright to the Linux Foundation.
No one assigns kernel copyright to the Linux Foundation unless you have entered into some odd business agreement with that legal entity. And that is quite rare to do so and takes lots of lawyers and time. greg k-h
On 06/11/2015 10:28 AM, Greg KH wrote:
If the copyright is owned by the company then ONLY the company can push
it up stream and assign copyright to the Linux Foundation. No one assigns kernel copyright to the Linux Foundation unless you have entered into some odd business agreement with that legal entity. And that is quite rare to do so and takes lots of lawyers and time.
It doesn't take a lot of lawyers anymore than a license would. I thought that the Foundation requests this routinely in order so that it has standing in court if a lawsuit should happen. The FSF has copyright to a large bulk of the software under GNU for this reason. Obviously you have first hand knowledge of practice I don't have, but copyright is a huge problem with contrition. In order to contribute, you must have copyright ownership. You can't prove that if your anonymous. Ruben
On Thu, Jun 11, 2015 at 10:41:57AM -0400, Ruben Safir wrote:
On 06/11/2015 10:28 AM, Greg KH wrote:
If the copyright is owned by the company then ONLY the company can push
it up stream and assign copyright to the Linux Foundation. No one assigns kernel copyright to the Linux Foundation unless you have entered into some odd business agreement with that legal entity. And that is quite rare to do so and takes lots of lawyers and time.
It doesn't take a lot of lawyers anymore than a license would. I thought that the Foundation requests this routinely in order so that it has standing in court if a lawsuit should happen.
No, it never has done this, where are you getting this crazy idea? The only thing you have to agree with when contributing Linux kernel code is the DCO, which can be found in the file Documentation/SubmittingPatches, or here online: http://developercertificate.org/ You keep your copyright on the contribution you make, it's always been that way for Linux kernel development for its entire development history (22+ years). I don't know where you got the idea that you have to assign copyright away to contribute to the kernel, but please do not spread false information like this.
The FSF has copyright to a large bulk of the software under GNU for this reason.
The FSF is insane, don't confuse the two groups please :)
Obviously you have first hand knowledge of practice I don't have, but copyright is a huge problem with contrition.
"contrition"? The state of feeling regret? What are you talking about?
In order to contribute, you must have copyright ownership. You can't prove that if your anonymous.
Which is why we can not accept anonymous contributions to the Linux kernel. But then there's the technical aspect of it all. When you put your name on code, you have "ownership" of it and you end up doing a much better job than if it is anonymous or just hidden within a larger company. And that's a good thing for both the developer, and the overall project. greg k-h
On 06/11/2015 11:38 AM, Greg KH wrote:
On Thu, Jun 11, 2015 at 10:41:57AM -0400, Ruben Safir wrote:
On 06/11/2015 10:28 AM, Greg KH wrote:
If the copyright is owned by the company then ONLY the company can push
it up stream and assign copyright to the Linux Foundation. No one assigns kernel copyright to the Linux Foundation unless you have entered into some odd business agreement with that legal entity. And that is quite rare to do so and takes lots of lawyers and time.
It doesn't take a lot of lawyers anymore than a license would. I thought that the Foundation requests this routinely in order so that it has standing in court if a lawsuit should happen.
No, it never has done this, where are you getting this crazy idea?
This idea is not crazy. During the SCO battle this problem got tossed about quite a bit and I thought that at that time the Linux Foundation and Mad Dog set up a Copyright Clearing House for the Kernel. Your saying that this never happened, so maybe I'm wrong. But it was discussed a lot, and lawyers were involved....and Linus was involved. The problem is two fold. First the Foundation and Linus need standing in court cases where violations of the GPL2 were involved...if there was such need. That is best established with assignment of the copyright, bit done through a contributor license agreement. I never claimed, BTW, that this was forced on everyone. But I thought it was encouraged since the SCO battle. Secondly, it prevents what SCO actually claimed they could do, which is pull there code, and the derivative works, from the kernel altogether. If the contributor assigned copyright, that is better than depending on the GPL2 guarantees of relicensure....the so called viral aspect of the GPL, which is the part that actually guarantees that a shared contribution project like the linux kernel can exist securely under copyright law. BTW - the crazy idea came from a conversation I had with Linus when I talked to him about the MYSQL license, fwiw, and then I bounced it off of Moglin, who referred me to Sara Brown, who put me in touch with Richard...and the the SCO thing broke out and then the conversation was all over slashdot and then moved the Wall Street Journal..and then IBM got involved and that is when I thought the TLF set up a CLA, but it must have only set up the little sworn statement you posted. OK - the earth will still spin on its axis today. I do not want to put out misinformation. Thank You for the correction ;)
The only thing you have to agree with when contributing Linux kernel code is the DCO, which can be found in the file Documentation/SubmittingPatches, or here online: http://developercertificate.org/
I didn't know that and looking at it, that is pretty flimsy. It is a good thing that up until know this hasn't bit them in the ass so far. I might be all that is possible though because a CLA, to be really blanket, would require one having to go back to every contribution to date. So it is a limited device. But it was discussed and I did talk to Mad Dog about it years ago.
You keep your copyright on the contribution you make, it's always been that way for Linux kernel development for its entire development history (22+ years). I don't know where you got the idea that you have to assign copyright away to contribute to the kernel, but please do not spread false information like this.
The FSF has copyright to a large bulk of the software under GNU for this reason.
The FSF is insane, don't confuse the two groups please :)
That might be so, but with regard to CLAs, I think they have it right.
Obviously you have first hand knowledge of practice I don't have, but copyright is a huge problem with contrition.
"contrition"? The state of feeling regret? What are you talking about?
Don't you LOVE spell checkers! contributions
In order to contribute, you must have copyright ownership. You can't prove that if your anonymous.
Which is why we can not accept anonymous contributions to the Linux kernel.
Right which is the core point.
But then there's the technical aspect of it all. When you put your name on code, you have "ownership" of it and you end up doing a much better job than if it is anonymous or just hidden within a larger company. And that's a good thing for both the developer, and the overall project.
For a maintainer...yeah. But when a lawsuit breaks out...that technical problem quickly takes a back seat. Now, for something important, when are we going to get Cherries from the Northwest to NYC?
greg k-h
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Thu, Jun 11, 2015 at 12:39:47PM -0400, Ruben Safir wrote:
On 06/11/2015 11:38 AM, Greg KH wrote:
On Thu, Jun 11, 2015 at 10:41:57AM -0400, Ruben Safir wrote:
On 06/11/2015 10:28 AM, Greg KH wrote:
If the copyright is owned by the company then ONLY the company can push
it up stream and assign copyright to the Linux Foundation. No one assigns kernel copyright to the Linux Foundation unless you have entered into some odd business agreement with that legal entity. And that is quite rare to do so and takes lots of lawyers and time.
It doesn't take a lot of lawyers anymore than a license would. I thought that the Foundation requests this routinely in order so that it has standing in court if a lawsuit should happen.
No, it never has done this, where are you getting this crazy idea?
This idea is not crazy. During the SCO battle this problem got tossed about quite a bit and I thought that at that time the Linux Foundation and Mad Dog set up a Copyright Clearing House for the Kernel. Your saying that this never happened, so maybe I'm wrong.
You are wrong. Also, the Linux Foundation didn't even exist at the time of the start of the SCO "issues", so I don't know who you were talking to.
The problem is two fold. First the Foundation and Linus need standing in court cases where violations of the GPL2 were involved...if there was such need. That is best established with assignment of the copyright, bit done through a contributor license agreement.
That is not true at all, and is not a best practice that I would encourage any project to take. In fact, I don't contribute to any such project, and strongly recommend that no one else would do so either.
I never claimed, BTW, that this was forced on everyone. But I thought it was encouraged since the SCO battle.
Nope, again, didn't happen, isn't an issue, you own your own copyright of any code you contribute to the kernel, end of story. thanks, greg k-h
On Thu, Jun 11, 2015 at 12:39:47PM -0400, Ruben Safir wrote:
The only thing you have to agree with when contributing Linux kernel code is the DCO, which can be found in the file Documentation/SubmittingPatches, or here online: http://developercertificate.org/
I didn't know that and looking at it, that is pretty flimsy.
Not at all, in fact, it's very strong. A number of other projects also use this same document (SAMBA, Docker, etc.), so it is well known and proven to work.
It is a good thing that up until know this hasn't bit them in the ass so far. I might be all that is possible though because a CLA, to be really blanket, would require one having to go back to every contribution to date.
That's only if you wanted to do something crazy like relicense the work. And even then, a CLA doesn't help you out, see all of the projects that have undertaken this task and what they have done to enable it. A CLA doesn't do much there. greg k-h
On Thu, Jun 11, 2015 at 10:57:00AM -0700, Greg KH wrote:
On Thu, Jun 11, 2015 at 12:39:47PM -0400, Ruben Safir wrote:
The only thing you have to agree with when contributing Linux kernel code is the DCO, which can be found in the file Documentation/SubmittingPatches, or here online: http://developercertificate.org/
I didn't know that and looking at it, that is pretty flimsy.
Not at all, in fact, it's very strong. A number of other projects also use this same document (SAMBA, Docker, etc.), so it is well known and proven to work.
It is a good thing that up until know this hasn't bit them in the ass so far. I might be all that is possible though because a CLA, to be really blanket, would require one having to go back to every contribution to date.
That's only if you wanted to do something crazy like relicense the work. And even then, a CLA doesn't help you out, see all of the projects that have undertaken this task and what they have done to enable it. A CLA doesn't do much there.
Not at all. You have a good point there are definitely legal situations other than relicensing which are problematic. Lets say Apple decides that are going to take the Linux Kernel and alter it extensively, in order for it to work with a new hardware platform that they created. And lets say don't return the code base to the public. Now who is going to protect the license and sue them? You have literaly thousands of partiticpants who have standing now in this case. Apple can just blow there nose at you if they are willing to put up with the bad publicity. anyway... http://www.h-online.com/open/features/Copyright-assignment-Once-bitten-twice... and I'm finished with this commentary. Broadly I agree with you and the CLA discussion is a side track.
greg k-h
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
On 06/11/2015 07:26 PM, Ruben Safir wrote:
Not at all. You have a good point there are definitely legal situations other than relicensing which are problematic.
Lets say Apple decides that are going to take the Linux Kernel and alter it extensively, in order for it to work with a new hardware platform that they created. And lets say don't return the code base to the public. Now who is going to protect the license and sue them? You have literaly thousands of partiticpants who have standing now in this case.
That means a thousand possible plaintiffs. s/Apple/VMware/ and you get this: http://sfconservancy.org/news/2015/mar/05/vmware-lawsuit/ A number of GPL enforcement projects involving the Linux kernel have resulted in GPL compliance already. -- All rights reversed.
On 06/11/2015 07:37 PM, Rik van Riel wrote:
On 06/11/2015 07:26 PM, Ruben Safir wrote:
Not at all. You have a good point there are definitely legal situations other than relicensing which are problematic.
Lets say Apple decides that are going to take the Linux Kernel and alter it extensively, in order for it to work with a new hardware platform that they created. And lets say don't return the code base to the public. Now who is going to protect the license and sue them? You have literaly thousands of partiticpants who have standing now in this case.
That means a thousand possible plaintiffs.
s/Apple/VMware/ and you get this:
http://sfconservancy.org/news/2015/mar/05/vmware-lawsuit/
A number of GPL enforcement projects involving the Linux kernel have resulted in GPL compliance already.
yeah, I've been following this case...it is an interesting case but not exacly on point. First of all the case is in Germany and their rules of standing are different.
-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies- bounces@kernelnewbies.org] On Behalf Of Rik van Riel Sent: Thursday, June 11, 2015 4:38 PM To: kernelnewbies@kernelnewbies.org Subject: Re: Kernel contributions from organisations and individual privacy
On 06/11/2015 07:26 PM, Ruben Safir wrote:
Not at all. You have a good point there are definitely legal situations other than relicensing which are problematic.
Lets say Apple decides that are going to take the Linux Kernel and alter it extensively, in order for it to work with a new hardware platform that they created. And lets say don't return the code base to the public. Now who is going to protect the license and sue them? You have literaly thousands of partiticpants who have standing now in this case.
That means a thousand possible plaintiffs.
s/Apple/VMware/ and you get this:
I don't see in that web site the amount of damages they are asking for. Maybe I missed it. Might get more money coming in for the plaintiff's lawyers if instead of asking for contributions that yield a tee shirt, it was constructed more like an investment, as in X% of total "contributions" gets the investor X% of (damages - legal fees) should they win. Might as well use the patent troll model to do some good for a change. 8^) Jeff Haran
On 06/11/2015 08:13 PM, Jeff Haran wrote:
On 06/11/2015 07:26 PM, Ruben Safir wrote:
Not at all. You have a good point there are definitely legal situations other than relicensing which are problematic.
Lets say Apple decides that are going to take the Linux Kernel and alter it extensively, in order for it to work with a new hardware platform that they created. And lets say don't return the code base to the public. Now who is going to protect the license and sue them? You have literaly thousands of partiticpants who have standing now in this case.
That means a thousand possible plaintiffs.
s/Apple/VMware/ and you get this:
I don't see in that web site the amount of damages they are asking for. Maybe I missed it.
They are not asking for damages, but for license compliance.
Might get more money coming in for the plaintiff's lawyers if instead of asking for contributions that yield a tee shirt, it was constructed more like an investment, as in X% of total "contributions" gets the investor X% of (damages - legal fees) should they win.
I suspect that is not possible, since not every Linux kernel copyright holder will want to be part of a lawsuit (of any kind). The Conservancy is a non-profit. The defendants usually end up paying the legal costs (and sometimes a contribution for help with GPL compliance), but starting new actions is something that is funded by people like us, who care about preserving the GPL license. -- All rights reversed.
-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies- bounces@kernelnewbies.org] On Behalf Of Rik van Riel Sent: Thursday, June 11, 2015 6:28 PM To: Jeff Haran; kernelnewbies@kernelnewbies.org Subject: Re: Kernel contributions from organisations and individual privacy
On 06/11/2015 08:13 PM, Jeff Haran wrote:
On 06/11/2015 07:26 PM, Ruben Safir wrote:
Not at all. You have a good point there are definitely legal situations other than relicensing which are problematic.
Lets say Apple decides that are going to take the Linux Kernel and alter it extensively, in order for it to work with a new hardware platform that they created. And lets say don't return the code base to the public. Now who is going to protect the license and sue them? You have literaly thousands of partiticpants who have standing now in this case.
That means a thousand possible plaintiffs.
s/Apple/VMware/ and you get this:
I don't see in that web site the amount of damages they are asking for. Maybe I missed it.
They are not asking for damages, but for license compliance.
Might get more money coming in for the plaintiff's lawyers if instead of asking for contributions that yield a tee shirt, it was constructed more like an investment, as in X% of total "contributions" gets the investor X% of (damages - legal fees) should they win.
I suspect that is not possible, since not every Linux kernel copyright holder will want to be part of a lawsuit (of any kind).
The Conservancy is a non-profit. The defendants usually end up paying the legal costs (and sometimes a contribution for help with GPL compliance), but starting new actions is something that is funded by people like us, who care about preserving the GPL license.
All sounds very noble, but it would not seem to create much of a deterrence for violators. What is the downside to a large company for violating GPL? They are likely to not get sued in the first place. If they are they can delay using court procedures until they've changed their code to not violate or GPL'ed it. Worst for them is paying legal fees and a contribution. I am guessing those aren't huge, not for a big company. Seems like unless there is some monetary sting like a piece of the proceeds on the sale of violating products, there is no deterrence and you guys will be in court for the rest of time chasing a never ending stream of new violators. As for every copyright holder not wanting to be a part of the suit, I thought that was what class action suits were for. Good luck to you but it sounds futile to me. Jeff Haran
Jeff Haran <Jeff.Haran@citrix.com> writes:
What is the downside to a large company for violating GPL?
Losing all rights to the software in question forever is probably the largest downside. If we talk about the Linux kernel (as I assume we do in this forum) then I have a hard time believing any company can survive that. Note that loosing the rights to use the Linux kernel will not only affect the products your company produce, but also your rights to *use* any Linux based product. The legal department would also end up with a limited selection of phones they could legally use. So, I'd say the downside is infinite. Why do companies still risk this? For little or no gain whatsoever? Or even negative gain, since we all know that you get many times back for every contribution you make to open source. I guess it is the result of tech staff and legal staff not talking together. The legal staff will hopefully have some understanding of the GPL, and know that violating it leaves them without any rights to the software in question. But they will probably assume that those rights are for sale, or that it is possible to buy the rights to an equivalent software product. The technical staff will know that this is impossible, but they are probably not aware of the finer details of the GPL. So there you go: Noone understand the full consequences. Bjørn
-----Original Message----- From: Bjørn Mork [mailto:bjorn@mork.no] Sent: Saturday, June 13, 2015 8:40 AM To: Jeff Haran Cc: Rik van Riel; kernelnewbies@kernelnewbies.org Subject: Re: Kernel contributions from organisations and individual privacy
Jeff Haran <Jeff.Haran@citrix.com> writes:
What is the downside to a large company for violating GPL?
Losing all rights to the software in question forever is probably the largest downside. If we talk about the Linux kernel (as I assume we do in this forum) then I have a hard time believing any company can survive that.
Has this ever actually happened? Specifically has a company that violated Linux's GPL ever been sued over the violation, lost the case and as a result lost the ability to use the Linux kernel forever? Thanks, Jeff Haran
On 06/15/2015 07:08 PM, Jeff Haran wrote:
Jeff Haran <Jeff.Haran@citrix.com> writes:
What is the downside to a large company for violating GPL?
Losing all rights to the software in question forever is probably the largest downside. If we talk about the Linux kernel (as I assume we do in this forum) then I have a hard time believing any company can survive that.
Has this ever actually happened?
Specifically has a company that violated Linux's GPL ever been sued over the violation, lost the case and as a result lost the ability to use the Linux kernel forever?
No, but they have come close, in several lawsuits, mostly in Germany. All of the companies in question decided that coming into compliance with the GPL was a better option than losing the rights to use, copy, distribute, and modify Linux. -- All rights reversed.
-----Original Message----- From: Rik van Riel [mailto:riel@surriel.com] Sent: Monday, June 15, 2015 4:56 PM To: Jeff Haran; Bjørn Mork Cc: kernelnewbies@kernelnewbies.org Subject: Re: Kernel contributions from organisations and individual privacy
On 06/15/2015 07:08 PM, Jeff Haran wrote:
Jeff Haran <Jeff.Haran@citrix.com> writes:
What is the downside to a large company for violating GPL?
Losing all rights to the software in question forever is probably the largest downside. If we talk about the Linux kernel (as I assume we do in this forum) then I have a hard time believing any company can survive that.
Has this ever actually happened?
Specifically has a company that violated Linux's GPL ever been sued over the violation, lost the case and as a result lost the ability to use the Linux kernel forever?
No, but they have come close, in several lawsuits, mostly in Germany.
All of the companies in question decided that coming into compliance with the GPL was a better option than losing the rights to use, copy, distribute, and modify Linux.
My original post concerned deterrence, not compliance. Sure, once they've violated, once they've been identified as violators, once their lawyers have received the cease and desist letter and decided to ignore it in hopes that you will go away, once they get their butts hauled into court and the lawyers start paying attention, once they figure out they will likely lose, once they've stalled court proceedings for years while engineering changes the code to no longer violate or they decide to GPL their code, then they comply with the law. But there would seem to be little in the way of deterrence here, "deterrence" in the sense that they are dissuaded from violating in the first place because the eventual cost of doing so will be too high should they be prosecuted and found guilty. Seems like they can violate at will and so long as they eventually come around there is little downside to having done the original violation. And from their perspective if they get away with it they gain because they get to keep their IP secret, and to the bean counters that is tangible value even if it makes no sense technically. Jeff Haran
On 06/12/2015 07:29 PM, Jeff Haran wrote:
What is the downside to a large company for violating GPL? They are likely to not get sued in the first place. If they are they can delay using court procedures until they've changed their code to not violate or GPL'ed it. Worst for them is paying legal fees and a contribution. I am guessing those aren't huge, not for a big company. Seems like unless there is some monetary sting like a piece of the proceeds on the sale of violating products, there is no deterrence and you guys will be in court for the rest of time chasing a never ending stream of new violators.
Creating a new kernel for one's product is not as easy as it sounds. Even replacing the kernel with a BSD kernel, and then replacing the userland code, and possibly writing a bunch of new device drivers, is very much non-trivial. Replacing Linux with something else in a product could easily cost several millions of dollars. -- All rights reversed.
On Fri, 12 Jun 2015 23:29:51 -0000, Jeff Haran said:
Seems like unless there is some monetary sting like a piece of the proceeds on the sale of violating products,
You know what's an even bigger monetary sting than having to pay a percentage? A court order banning the sale of your product entirely until such time as you get into compliance with the GPL to the plaintiff's and judge's satisfaction. And in fact, that is the single relief usually requested in a GPL violation case - a ban on the offending product's distribution until the company complies. And violating a direct court order like that is something that no company that intends to stay in business wants to even try to get away with - it's a really good way to have the judge have a hissy fit and throw all your top corporate officers in the slammer for contempt of court.
On Thu, Jun 11, 2015 at 07:26:23PM -0400, Ruben Safir wrote:
Lets say Apple decides that are going to take the Linux Kernel and alter it extensively, in order for it to work with a new hardware platform that they created. And lets say don't return the code base to the public. Now who is going to protect the license and sue them? You have literaly thousands of partiticpants who have standing now in this case. Apple can just blow there nose at you if they are willing to put up with the bad publicity.
Like I tell companies all the time when they ask me about this, "Look at the major copyright holders of the kernel, do you think your lawyers are better than Intel and IBM's lawyers?" And like Rik points out, you end up with thousands of different companies and individuals who can enforce the license, which is a wonderful thing to have and has worked out quite well so far. So all is well, don't fret. greg k-h
On Thu, 11 Jun 2015 19:26:23 -0400, Ruben Safir said:
Lets say Apple decides that are going to take the Linux Kernel and alter it extensively, in order for it to work with a new hardware platform that they created. And lets say don't return the code base to the public. Now who is going to protect the license and sue them? You have literaly thousands of partiticpants who have standing now in this case. Apple can just blow there nose at you if they are willing to put up with the bad publicity.
They can't just blow their nose at actual lawsuits. Even Apple's pockets aren't deep enough to survive several thousand contempt of court judgments when they try to blow off several thousand lawsuits. And I suspect Apple doesn't want that much bad publicity - the *last* thing they need is showing up in the news as a bunch of selfish bozos. Remember that the Jobs Reality Distortion Field can only reach so far and do so much....
On Fri, 12 Jun 2015 00:39:21 -0400, Ruben Safir said:
those lawsuites would be challenged for law of standing.
I do believe that has *never* been much of a problem for the guys at gpl-violations.org - it's pretty much a slam dunk: 1) You distributed the kernel without source. 2) The kernel is covered by the GPLv2. 3) I am the author of the following lines of code: drivers/foo/...... Now I, personally, might have trouble establishing standing, because I don't have *that* many lines of code in the kernel, and they're mostly 2-4 line patches of no large significance - Apple could probably take my code out, and fix the build failures and so on in some other way, and ship it. On the other hand, even Apple is going to squirm if they get a letter that starts "Hi, I'm Ted T'so and we seem to have a slight problem...." (where Ted's name can be replaced by several hundred others big enough that if you excise the code they wrote, your kernel has problems). (For the record, it was Chris Hellwig that ended up filing suit against VMWare - and the last I heard, VMWare hasn't even *tried* to dismiss the suit due to lack of standing on Hellwig's part...)
On 06/11/2015 01:10 AM, Chris Packham wrote:
It's not a concern for the _employer_ (unless we say something particularly inflammatory), in fact the organisation sees the benefit of the company name getting out there in technical circles.
It's more a case of the _employee_ not wanting their name to show up in mailing list archives, similar to people that don't want a phone book listing or twitter/facebook/google+. One option is for someone (like me) to do the submission and work with upstream to get the change accepted, I don't have a problem with this but it does mean that if/when I move on I take the kudos (as well as the criticism) with me and the company loses out.
One thing the employees who want to stay anonymous can do is grant the company copyright on the code (if their employment agreement doesn't do that already). Then another employee, who does not mind participating upstream, can submit the code, with the company name as copyright on new files added, and their own name in the Signed-off-by: line of the patches. At least, I believe this should work... -- All rights reversed.
On Thu, Jun 11, 2015 at 02:58:01PM +1000, Jason Ball wrote:
I had a similar situation and managed to route patches via an intermediary to protect my employers anonymity at the time. You may (should) be able to find an appropriate sponsor depending on the nature of the customisations.
You can do that, but then the second party has to claim responsibility for the code as well, legally and technically. Both are usually not cheap to pay for. good luck, greg k-h
On Wed, Jun 10, 2015 at 09:19:00PM +1200, Chris Packham wrote:
Hi,
This came up at work today and I'm not sure where the best place to ask is. I almost went straight to the lkml but I figured I'd start with newbies first.
We've been using the Linux kernel in our products for a number of years now. We're doing all the right things w.r.t GPL compliance but we're not actively pushing that much upstream. This means we're effectively maintaining our own Linux fork with very few resources. I'm trying to avoid this by encouraging developers to get their changes upstreamed.
This is good for our organisation because we don't have to re-do our changes when we need to take a new kernel version. Most developers see this as a good career building for them. But some developers value their individual privacy over career progression.
My initial response to that was well we can just make a dummy gmail account or even setup a swdept@$organisation shared address. But SubmittingPatches actually says to sign patches with your real name not a pseudonym.
Does this basically mean people that value privacy are unable to contribute?
It means that people who wish to be anonymous may not contribute to the kernel. Kernel development is done on an individual basis, while being supported by companies. If you aren't willing to put your name on the code, then I don't want to ever see it contributed to the kernel as something must be wrong with it. Dummy email addresses are not acceptable, nor are aliases (i.e. linux@company), sorry, I will not accept that anymore either. Remember, you are asking other people to help maintain your work for you, why would they accept your code if you don't even feel good enough to claim responsibility for it? thanks, greg k-h
participants (8)
-
Bjørn Mork -
Chris Packham -
Greg KH -
Jason Ball -
Jeff Haran -
Rik van Riel -
Ruben Safir -
Valdis.Kletnieks＠vt.edu