Kernel contributions from organisations and individual privacy

Kernel contributions from organisations and individual privacy

[Chris Packham]

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

Kernel contributions from organisations and individual privacy

[Jason Ball]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
--
Teach your kids Science, or somebody else will :/

jason at ball.net
vk2vjb at google.com <vk2flnx@google.com>
callsign: vk2vjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150611/20eed147/attachment.html 

Kernel contributions from organisations and individual privacy

[Chris Packham]

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 at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
>
> --
>
> --
>
> Teach your kids Science, or somebody else will :/
>
> jason at ball.net
> vk2vjb at google.com
> callsign: vk2vjb
>
>

Kernel contributions from organisations and individual privacy

[Ruben Safir]

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

Kernel contributions from organisations and individual privacy

[Greg KH]

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

Kernel contributions from organisations and individual privacy

[Ruben Safir]

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

Kernel contributions from organisations and individual privacy

[Greg KH]

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

Kernel contributions from organisations and individual privacy

[Ruben Safir]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
> 

Kernel contributions from organisations and individual privacy

[Greg KH]

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

Kernel contributions from organisations and individual privacy

[Greg KH]

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

Kernel contributions from organisations and individual privacy

[Ruben Safir]

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-shy-1049631.html

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 at 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

Kernel contributions from organisations and individual privacy

[Rik van Riel]

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.

Kernel contributions from organisations and individual privacy

[Ruben Safir]

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.

Kernel contributions from organisations and individual privacy

[Jeff Haran]

> -----Original Message-----
> From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
> bounces at kernelnewbies.org] On Behalf Of Rik van Riel
> Sent: Thursday, June 11, 2015 4:38 PM
> To: kernelnewbies at 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:
> 
> http://sfconservancy.org/news/2015/mar/05/vmware-lawsuit/
> 

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

Kernel contributions from organisations and individual privacy

[Rik van Riel]

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:
>>
>> http://sfconservancy.org/news/2015/mar/05/vmware-lawsuit/
>>
> 
> 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.

Kernel contributions from organisations and individual privacy

[Jeff Haran]

>-----Original Message-----
From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-
>bounces at kernelnewbies.org] On Behalf Of Rik van Riel
>Sent: Thursday, June 11, 2015 6:28 PM
>To: Jeff Haran; kernelnewbies at 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:
>>>
>>> http://sfconservancy.org/news/2015/mar/05/vmware-lawsuit/
>>>
>>
>> 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

Kernel contributions from organisations and individual privacy

[Bjørn Mork]

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

Kernel contributions from organisations and individual privacy

[Ruben Safir]

On 06/13/2015 11:40 AM, Bj?rn Mork wrote:
> 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.


they just don't want to give back to the community.

Kernel contributions from organisations and individual privacy

[Jeff Haran]

> -----Original Message-----
> From: Bj?rn Mork [mailto:bjorn at mork.no]
> Sent: Saturday, June 13, 2015 8:40 AM
> To: Jeff Haran
> Cc: Rik van Riel; kernelnewbies at 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

Kernel contributions from organisations and individual privacy

[Rik van Riel]

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.

Kernel contributions from organisations and individual privacy

[Jeff Haran]

> -----Original Message-----
> From: Rik van Riel [mailto:riel at surriel.com]
> Sent: Monday, June 15, 2015 4:56 PM
> To: Jeff Haran; Bj?rn Mork
> Cc: kernelnewbies at 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

Kernel contributions from organisations and individual privacy

[Rik van Riel]

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.

Kernel contributions from organisations and individual privacy

[Valdis.Kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150614/66aeded0/attachment.bin 

Kernel contributions from organisations and individual privacy

[Valdis.Kletnieks at vt.edu]

On Sun, 14 Jun 2015 17:25:40 -0400, Nicholas Krause said:
> Why are we even trying to prove this,  it seems any intelligent company who has
> a interest in staying in business will comply

The problem is companies that have mixed in their own "secret sauce", and
are afraid of said sause becoming non-secret as part of their required GPL
compliance.  If you have a competent legal department, you'll file lots
of motions and so on to delay that final court order as long as you can.

See VMWare for the details - they've got enough legal staff that it took
like 7 years for Hellwig to team up with funded legal support.  And it will
almost certainly be an eventual loss for VMWare - but they can delay that for
months or years.

And VMWare certainly doesn't want to release their code - mostly because
it's almost certainly a creeping horror worthy of mockery.

If you don't believe me, go look at the GPL kernel drivers for VMWare Workstation
or Player, which are probably similar to the ESXi code that VMWare
would have to release.  How bad are the WS/Player drivers?  Let's just
say that Greg KH probably wouldn't let them into drivers/staging. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150614/8f49f37b/attachment.bin 

Kernel contributions from organisations and individual privacy

[Valdis.Kletnieks at vt.edu]

On Sun, 14 Jun 2015 19:36:23 -0400, nick said:
> a embedded version of Linux called NX OS I believe and its all open to my
> knowledge. Again this is stupidity in my option or companies being lazy by
> hiding there terribly written drivers.

Remember Nick - it's not a technical decision, it's a business decision.
If a company can improve the bottom line by $1M by doing something technically
ugly, something technically ugly *will* be done.

And it's usually no use standing up and fighting it if you work at the
company, because quite frankly, you're expendable.  Unless you're a superstar
who will cost more than $1M in recruiting costs and signing bonuses to
replace, the company will can your ass, recruit a replacement, do the ugly
thing, and *still* come up with more money.

And let's face it - if you're a superstar, why are you working at a company
whose product is so messed up that technically ugly work-arounds are called for? :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150614/5eda4f05/attachment.bin 

Kernel contributions from organisations and individual privacy

[Greg KH]

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

Kernel contributions from organisations and individual privacy

[Valdis.Kletnieks at vt.edu]

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....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150611/77927cfb/attachment.bin 

Kernel contributions from organisations and individual privacy

[Ruben Safir]

On 06/11/2015 11:31 PM, Valdis.Kletnieks at vt.edu wrote:
> They can't just blow their nose at actual lawsuits.


those lawsuites would be challenged for law of standing.

Kernel contributions from organisations and individual privacy

[Valdis.Kletnieks at vt.edu]

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...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150612/a06473fe/attachment.bin 

Kernel contributions from organisations and individual privacy

[Rik van Riel]

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.

Kernel contributions from organisations and individual privacy

[Greg KH]

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

Kernel contributions from organisations and individual privacy

[Greg KH]

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 at 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