Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Pavel Machek]

Hi!

> > I don't feel that is true at all, what we are doing here is providing a
> > well-documented way toward compliance and the reinstatement of our
> > license.  That's a key issue with regards to the existing trolls we are
> > currently facing today, which we have to address in order to preserve
> > our community.
> 
> Which trolls? Do you mean Broadcom or Patrick? :)

Do you have link to the Broadcom case? According to wikipedia there
were some problems in 2003 with FSF, but I don't think that's what you
are refering to.

Thanks,
Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Pavel Machek]

Hi!

> > I don't feel that is true at all, what we are doing here is providing a
> > well-documented way toward compliance and the reinstatement of our
> > license.  That's a key issue with regards to the existing trolls we are
> > currently facing today, which we have to address in order to preserve
> > our community.
> 
> Which trolls? Do you mean Broadcom or Patrick? :)

Do you have link to the Broadcom case? According to wikipedia there
were some problems in 2003 with FSF, but I don't think that's what you
are refering to.

Thanks,
Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Damian Tometzki]

Hello all,

i'am new in the community. For me the intention of the document is clear but is 
very spongy written. 
It leaves a lot of interpretations and unclear to me. 
Who is the community and who is we ? The names in the document ? In my opinion, 
the list is incomplete or is that the community ?
And what are with all the other people's where contribute to the community. 
Many of the people's in the document work in a company which also has the 
interest in further development.

Nevertheless, I will also try to make my contribution as a private person and 
in  my free time after work. 
Even if the entry is not made easy if one is not working with the well-known 
company. 

-Damian- 



signature.asc
Description: PGP signature

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Damian Tometzki]

Hello all,

i'am new in the community. For me the intention of the document is clear but is 
very spongy written. 
It leaves a lot of interpretations and unclear to me. 
Who is the community and who is we ? The names in the document ? In my opinion, 
the list is incomplete or is that the community ?
And what are with all the other people's where contribute to the community. 
Many of the people's in the document work in a company which also has the 
interest in further development.

Nevertheless, I will also try to make my contribution as a private person and 
in  my free time after work. 
Even if the entry is not made easy if one is not working with the well-known 
company. 

-Damian- 



signature.asc
Description: PGP signature

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Damian Tometzki]

Hello all,

i'am new in the community. For me the intention of the document is clear but is 
very spongy written.
It leaves a lot of interpretations and unclear to me.
Who is the community and who is we ? The names in the document ? In my opinion, 
the list is incomplete or is that the community ?
And what are with all the other people's where contribute to the community. 
Many of the people's in the document work in a company which also has the 
interest in further development.

Nevertheless, I will also try to make my contribution as a private person and 
in  my free time after work.
Even if the entry is not made easy if one is not working with the well-known 
company.

-Damian-

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Damian Tometzki]

Hello all,

i'am new in the community. For me the intention of the document is clear but is 
very spongy written.
It leaves a lot of interpretations and unclear to me.
Who is the community and who is we ? The names in the document ? In my opinion, 
the list is incomplete or is that the community ?
And what are with all the other people's where contribute to the community. 
Many of the people's in the document work in a company which also has the 
interest in further development.

Nevertheless, I will also try to make my contribution as a private person and 
in  my free time after work.
Even if the entry is not made easy if one is not working with the well-known 
company.

-Damian-

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Theodore Ts'o]

On Mon, Oct 23, 2017 at 04:11:14PM +0300, Pavel Nikulin wrote:
> The people signing there effectively say: "we, to big extend, limit
> our options to call for expedient permanent license revocation" - the
> only thing that will ever tickle a commercial entity.

This makes no sense.  If a commercial entity is permanently in
violation, then the license stays revoked.  The whole *point* of
ethical copyright enforcement is that if the commercial entity comes
into compliance, that they can also have a way to have their ability
to use the GPL'ed code in question be also restored.

> When I first heard news of this and had a glancing look on the
> document, it looked to me almost as if it is a change to terms made on
> behalf of the "community," only after I read the document through few
> times over, I got an understanding of the semantics there.

So you're not a lawyer and have not consulted a lawyer, and yet you
feel comfortable making pronouncements about legal implications?  Just
trying to be clear...

- Ted

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Theodore Ts'o]

On Mon, Oct 23, 2017 at 04:11:14PM +0300, Pavel Nikulin wrote:
> The people signing there effectively say: "we, to big extend, limit
> our options to call for expedient permanent license revocation" - the
> only thing that will ever tickle a commercial entity.

This makes no sense.  If a commercial entity is permanently in
violation, then the license stays revoked.  The whole *point* of
ethical copyright enforcement is that if the commercial entity comes
into compliance, that they can also have a way to have their ability
to use the GPL'ed code in question be also restored.

> When I first heard news of this and had a glancing look on the
> document, it looked to me almost as if it is a change to terms made on
> behalf of the "community," only after I read the document through few
> times over, I got an understanding of the semantics there.

So you're not a lawyer and have not consulted a lawyer, and yet you
feel comfortable making pronouncements about legal implications?  Just
trying to be clear...

- Ted

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Pavel Nikulin]

>If you don't agree with this, that's great, don't sign onto the
>agreement.  But as you don't seem to be part of our community in the
>first place, I don't really understand your concern here at all.

My last patch submitted to kernel was over a decade ago, yes I have
not much say here. My worry is that people other than me and who
were much more involved with kernel development will have
themselves in hot water when it comes to enforcing their copyright.

The people signing there effectively say: "we, to big extend, limit
our options to call for expedient permanent license revocation" - the
only thing that will ever tickle a commercial entity.

When I first heard news of this and had a glancing look on the
document, it looked to me almost as if it is a change to terms made on
behalf of the "community," only after I read the document through few
times over, I got an understanding of the semantics there.



At least, lawyers you talk with now should consider moving a stament
specifying who is making this statement to the start of the document,
and to specify the undefined reference to a "community," so other
people will not have to prove in court that the this statement was not
done on their behalf if defendants will resort to "semantic equilibristics"
with this document (and I am certainly sure some will).

Attribution, and who and to whom one is giving permissions or
promises is a big thing. I had to got to court two times in my life when
my work on microcontroller boot loaders and a PID controller were
used illegaly. In first case, the company tried to undermine my standing
in court by bringing a back dated informal permission for use of project's
code made on behalf of the whole project by a minor contributor who
fraudulently issued it for money.

As right in this case, that fraudulent informal permission had a "no sue"
promise in it. If they were successful in proving the legal force of such
permission, I bet a court in Russia, would've sided with them.

The second time, I ever had to resort to legal action ended amicably,
but we still had heated conversation whether I did or didn't alienate
my right for attribution and copyright.

On 23 October 2017 at 10:50, Greg KH  wrote:
> On Sat, Oct 21, 2017 at 10:16:12PM +0300, Pavel Nikulin wrote:
>> If you say that your lawyers have comprehensively researched that,
>> I can't say they did a good job.
>
> Is there a open source knowledgable lawyer that you recommend we work
> with in place of the ones that were consulted for this statement?
>
> Remember, get two lawyers in a room, and you now have 3 opinions :)
>
> I know that not everyone we consulted agreed with everything in the
> document, but that's to be expected.  However, they all agreed that for
> the issue we are currently facing, this statement will make a difference
> and help resolve the issue.
>
> If you don't agree with this, that's great, don't sign onto the
> agreement.  But as you don't seem to be part of our community in the
> first place, I don't really understand your concern here at all.
>
> thanks,
>
> greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Pavel Nikulin]

>If you don't agree with this, that's great, don't sign onto the
>agreement.  But as you don't seem to be part of our community in the
>first place, I don't really understand your concern here at all.

My last patch submitted to kernel was over a decade ago, yes I have
not much say here. My worry is that people other than me and who
were much more involved with kernel development will have
themselves in hot water when it comes to enforcing their copyright.

The people signing there effectively say: "we, to big extend, limit
our options to call for expedient permanent license revocation" - the
only thing that will ever tickle a commercial entity.

When I first heard news of this and had a glancing look on the
document, it looked to me almost as if it is a change to terms made on
behalf of the "community," only after I read the document through few
times over, I got an understanding of the semantics there.



At least, lawyers you talk with now should consider moving a stament
specifying who is making this statement to the start of the document,
and to specify the undefined reference to a "community," so other
people will not have to prove in court that the this statement was not
done on their behalf if defendants will resort to "semantic equilibristics"
with this document (and I am certainly sure some will).

Attribution, and who and to whom one is giving permissions or
promises is a big thing. I had to got to court two times in my life when
my work on microcontroller boot loaders and a PID controller were
used illegaly. In first case, the company tried to undermine my standing
in court by bringing a back dated informal permission for use of project's
code made on behalf of the whole project by a minor contributor who
fraudulently issued it for money.

As right in this case, that fraudulent informal permission had a "no sue"
promise in it. If they were successful in proving the legal force of such
permission, I bet a court in Russia, would've sided with them.

The second time, I ever had to resort to legal action ended amicably,
but we still had heated conversation whether I did or didn't alienate
my right for attribution and copyright.

On 23 October 2017 at 10:50, Greg KH  wrote:
> On Sat, Oct 21, 2017 at 10:16:12PM +0300, Pavel Nikulin wrote:
>> If you say that your lawyers have comprehensively researched that,
>> I can't say they did a good job.
>
> Is there a open source knowledgable lawyer that you recommend we work
> with in place of the ones that were consulted for this statement?
>
> Remember, get two lawyers in a room, and you now have 3 opinions :)
>
> I know that not everyone we consulted agreed with everything in the
> document, but that's to be expected.  However, they all agreed that for
> the issue we are currently facing, this statement will make a difference
> and help resolve the issue.
>
> If you don't agree with this, that's great, don't sign onto the
> agreement.  But as you don't seem to be part of our community in the
> first place, I don't really understand your concern here at all.
>
> thanks,
>
> greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Sat, Oct 21, 2017 at 10:16:12PM +0300, Pavel Nikulin wrote:
> If you say that your lawyers have comprehensively researched that,
> I can't say they did a good job.

Is there a open source knowledgable lawyer that you recommend we work
with in place of the ones that were consulted for this statement?

Remember, get two lawyers in a room, and you now have 3 opinions :)

I know that not everyone we consulted agreed with everything in the
document, but that's to be expected.  However, they all agreed that for
the issue we are currently facing, this statement will make a difference
and help resolve the issue.

If you don't agree with this, that's great, don't sign onto the
agreement.  But as you don't seem to be part of our community in the
first place, I don't really understand your concern here at all.

thanks,

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Sat, Oct 21, 2017 at 10:16:12PM +0300, Pavel Nikulin wrote:
> If you say that your lawyers have comprehensively researched that,
> I can't say they did a good job.

Is there a open source knowledgable lawyer that you recommend we work
with in place of the ones that were consulted for this statement?

Remember, get two lawyers in a room, and you now have 3 opinions :)

I know that not everyone we consulted agreed with everything in the
document, but that's to be expected.  However, they all agreed that for
the issue we are currently facing, this statement will make a difference
and help resolve the issue.

If you don't agree with this, that's great, don't sign onto the
agreement.  But as you don't seem to be part of our community in the
first place, I don't really understand your concern here at all.

thanks,

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Bradley M. Kuhn]

> On Thu, Oct 19, 2017 at 06:28:12PM +0300, Pavel Nikulin wrote:
> Modification of GPL V2 terms are explicitly disallowed.

Greg KH replied at 03:29 (US/Eastern) on Friday:
>> Again, we are not modifying the license, so all should be fine

I agree with Greg; the Linux Kernel Enforcement Statement does not change
the license of Linux as a whole, and it does not modify the GPLv2.

Pavel Nikulin wrote at 11:28 (US/Eastern) on Thursday:
> Greg, are you trying to put a new addendum to the terms of GPL v2?
...
Pavel Nikulin wrote further at 15:16 (US/Eastern) today:
> If you say that your lawyers have comprehensively researched that,
> I can't say they did a good job. Almost every line sounds close to
> being a contractual agreement.
...
> And even this last phrase does not states explicitly that the nature of
> the document as non-legally binding.
...
> Moreover, you put "additional permissions under our license" wording
> there,

Certainly this issue is complicated.
https://sfconservancy.org/blog/2017/oct/20/additional-permissions/ might
help.  I decided yesterday to write a blog post digging deep into the weeds
on this, for those interested.
-- 
Bradley M. Kuhn
Distinguished Technologist of Software Freedom Conservancy

Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Bradley M. Kuhn]

> On Thu, Oct 19, 2017 at 06:28:12PM +0300, Pavel Nikulin wrote:
> Modification of GPL V2 terms are explicitly disallowed.

Greg KH replied at 03:29 (US/Eastern) on Friday:
>> Again, we are not modifying the license, so all should be fine

I agree with Greg; the Linux Kernel Enforcement Statement does not change
the license of Linux as a whole, and it does not modify the GPLv2.

Pavel Nikulin wrote at 11:28 (US/Eastern) on Thursday:
> Greg, are you trying to put a new addendum to the terms of GPL v2?
...
Pavel Nikulin wrote further at 15:16 (US/Eastern) today:
> If you say that your lawyers have comprehensively researched that,
> I can't say they did a good job. Almost every line sounds close to
> being a contractual agreement.
...
> And even this last phrase does not states explicitly that the nature of
> the document as non-legally binding.
...
> Moreover, you put "additional permissions under our license" wording
> there,

Certainly this issue is complicated.
https://sfconservancy.org/blog/2017/oct/20/additional-permissions/ might
help.  I decided yesterday to write a blog post digging deep into the weeds
on this, for those interested.
-- 
Bradley M. Kuhn
Distinguished Technologist of Software Freedom Conservancy

Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Pavel Nikulin]

If you say that your lawyers have comprehensively researched that,
I can't say they did a good job. Almost every line sounds close to
being a contractual agreement. If you say that this is only a personal
promise, you have to state that. Like writing "this is not a an addendum
to license terms and only a personal promise from people in the list
below"

In the language that is written there, that is not any much clear up until
you reach the statement at the very end:

>Except where noted below, we speak only for ourselves, and not for
>any company we might work for today, have in the past, or will in the
>future.

And even this last phrase does not states explicitly that the nature of the
document as non-legally binding.

Moreover, you put "additional permissions under our license" wording
there, if there were no "our" there, it would've opened a huge can of
worms. And even this way, that "our" there can be a problem.

As of now, the statement reads as if that the party making the statement
is the undefined "we", "our", and "our development community" until you
reach the very end of the document. You need to write that "we," "our,"
and the community are you and people in the list below at the start of
the statement.

I support the idea to denounce vexatious profit-seeking enforcement.
I don't like the prospect of violators being able to stall the enforcement
even further. Whatever new legal language will be put into the kernel,
it can't do anything with people doing vexatious enforcement today, but
it may weaken legitimate GPL enforcers.


The lengthy explanation for the last phrase, I'm sorry for bringing this to
lkml.


In not so few cases when GPL was successfully enforced, violators
were able to greatly delay the enforcement and stall for time at close
to no cost, all because they knew that they loose little even in the
worst case scenario.

If we go forward and open a can of worms on topic of how the
community should decide to run enforcement action, we should also
bring up principle that if contributors start with it, they should not settle
until they reach full compliance or do something that will weaken the
case for further enforcement by anybody else.

Companies release uncompilable modified kernel sources, simply
wrong sources, or kernels that can't run because a vital piece of code
needed for runtime functioning is is a "secret blob" with data and/or
functions. In all such cases, proving that such evasive maneuvers do
not constitute compliance is hard. They began to think that this is an
effective tactic against enforcement, especially if any of co-authors
accept any of above as a settlement.

If violators knew how high are the stakes, they will not do that. I want
that it became accepted that "a death sentence for a tech company" -
permanent license revocation for the Linux kernel should be the end
result of vexations defense tactics even if the company will show a
phony change of heart and finally becomes compliant at the end of
very long and costly legal battle.

We should also not throw out the idea of using expedited injunctions
in countries allowing them (besides Germany, I believe that includes
some US states) if doing so is needed to harm companies hiding
behind proxy entities, "clouds," ones persistent in using vexatious
deference tactics, or simply ones believing that they loose nothing
if they try to challenge every request for GPL compliance.

On 20 October 2017 at 21:25, Alan Cox  wrote:
> On Thu, 19 Oct 2017 18:28:12 +0300
> Pavel Nikulin  wrote:
>
>> Hold!
>>
>> Greg, are you trying to put a new addendum to the terms of GPL v2?
>
> In many parts of the world if you make a promise about not enforcing a
> right to take some action (sometimes even an implied one) you cannot then
> take that action.
>
> So if you say "I won't sue you just because you've got a tiny GPL
> compliance issue", then in much of the world if you attempt to do so
> you'll find you can't.
>
> I do think it's poorly drafted because it doesn't contain any "unless you
> sue us" caveat so you won't find my name on it.
>
> Alan

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Pavel Nikulin]

If you say that your lawyers have comprehensively researched that,
I can't say they did a good job. Almost every line sounds close to
being a contractual agreement. If you say that this is only a personal
promise, you have to state that. Like writing "this is not a an addendum
to license terms and only a personal promise from people in the list
below"

In the language that is written there, that is not any much clear up until
you reach the statement at the very end:

>Except where noted below, we speak only for ourselves, and not for
>any company we might work for today, have in the past, or will in the
>future.

And even this last phrase does not states explicitly that the nature of the
document as non-legally binding.

Moreover, you put "additional permissions under our license" wording
there, if there were no "our" there, it would've opened a huge can of
worms. And even this way, that "our" there can be a problem.

As of now, the statement reads as if that the party making the statement
is the undefined "we", "our", and "our development community" until you
reach the very end of the document. You need to write that "we," "our,"
and the community are you and people in the list below at the start of
the statement.

I support the idea to denounce vexatious profit-seeking enforcement.
I don't like the prospect of violators being able to stall the enforcement
even further. Whatever new legal language will be put into the kernel,
it can't do anything with people doing vexatious enforcement today, but
it may weaken legitimate GPL enforcers.


The lengthy explanation for the last phrase, I'm sorry for bringing this to
lkml.


In not so few cases when GPL was successfully enforced, violators
were able to greatly delay the enforcement and stall for time at close
to no cost, all because they knew that they loose little even in the
worst case scenario.

If we go forward and open a can of worms on topic of how the
community should decide to run enforcement action, we should also
bring up principle that if contributors start with it, they should not settle
until they reach full compliance or do something that will weaken the
case for further enforcement by anybody else.

Companies release uncompilable modified kernel sources, simply
wrong sources, or kernels that can't run because a vital piece of code
needed for runtime functioning is is a "secret blob" with data and/or
functions. In all such cases, proving that such evasive maneuvers do
not constitute compliance is hard. They began to think that this is an
effective tactic against enforcement, especially if any of co-authors
accept any of above as a settlement.

If violators knew how high are the stakes, they will not do that. I want
that it became accepted that "a death sentence for a tech company" -
permanent license revocation for the Linux kernel should be the end
result of vexations defense tactics even if the company will show a
phony change of heart and finally becomes compliant at the end of
very long and costly legal battle.

We should also not throw out the idea of using expedited injunctions
in countries allowing them (besides Germany, I believe that includes
some US states) if doing so is needed to harm companies hiding
behind proxy entities, "clouds," ones persistent in using vexatious
deference tactics, or simply ones believing that they loose nothing
if they try to challenge every request for GPL compliance.

On 20 October 2017 at 21:25, Alan Cox  wrote:
> On Thu, 19 Oct 2017 18:28:12 +0300
> Pavel Nikulin  wrote:
>
>> Hold!
>>
>> Greg, are you trying to put a new addendum to the terms of GPL v2?
>
> In many parts of the world if you make a promise about not enforcing a
> right to take some action (sometimes even an implied one) you cannot then
> take that action.
>
> So if you say "I won't sue you just because you've got a tiny GPL
> compliance issue", then in much of the world if you attempt to do so
> you'll find you can't.
>
> I do think it's poorly drafted because it doesn't contain any "unless you
> sue us" caveat so you won't find my name on it.
>
> Alan

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Fri, Oct 20, 2017 at 07:25:37PM +0100, Alan Cox wrote:
> On Thu, 19 Oct 2017 18:28:12 +0300
> Pavel Nikulin  wrote:
> 
> > Hold!
> > 
> > Greg, are you trying to put a new addendum to the terms of GPL v2?
> 
> In many parts of the world if you make a promise about not enforcing a
> right to take some action (sometimes even an implied one) you cannot then
> take that action.
> 
> So if you say "I won't sue you just because you've got a tiny GPL
> compliance issue", then in much of the world if you attempt to do so
> you'll find you can't.
> 
> I do think it's poorly drafted because it doesn't contain any "unless you
> sue us" caveat so you won't find my name on it.

But it does have that caveat:
...with respect to any non-defensive assertion...

I discussed that in my FAQ blog post as well.

thanks,

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Fri, Oct 20, 2017 at 07:25:37PM +0100, Alan Cox wrote:
> On Thu, 19 Oct 2017 18:28:12 +0300
> Pavel Nikulin  wrote:
> 
> > Hold!
> > 
> > Greg, are you trying to put a new addendum to the terms of GPL v2?
> 
> In many parts of the world if you make a promise about not enforcing a
> right to take some action (sometimes even an implied one) you cannot then
> take that action.
> 
> So if you say "I won't sue you just because you've got a tiny GPL
> compliance issue", then in much of the world if you attempt to do so
> you'll find you can't.
> 
> I do think it's poorly drafted because it doesn't contain any "unless you
> sue us" caveat so you won't find my name on it.

But it does have that caveat:
...with respect to any non-defensive assertion...

I discussed that in my FAQ blog post as well.

thanks,

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Alan Cox]

On Thu, 19 Oct 2017 18:28:12 +0300
Pavel Nikulin  wrote:

> Hold!
> 
> Greg, are you trying to put a new addendum to the terms of GPL v2?

In many parts of the world if you make a promise about not enforcing a
right to take some action (sometimes even an implied one) you cannot then
take that action.

So if you say "I won't sue you just because you've got a tiny GPL
compliance issue", then in much of the world if you attempt to do so
you'll find you can't.

I do think it's poorly drafted because it doesn't contain any "unless you
sue us" caveat so you won't find my name on it.

Alan

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Alan Cox]

On Thu, 19 Oct 2017 18:28:12 +0300
Pavel Nikulin  wrote:

> Hold!
> 
> Greg, are you trying to put a new addendum to the terms of GPL v2?

In many parts of the world if you make a promise about not enforcing a
right to take some action (sometimes even an implied one) you cannot then
take that action.

So if you say "I won't sue you just because you've got a tiny GPL
compliance issue", then in much of the world if you attempt to do so
you'll find you can't.

I do think it's poorly drafted because it doesn't contain any "unless you
sue us" caveat so you won't find my name on it.

Alan

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Thu, Oct 19, 2017 at 06:28:12PM +0300, Pavel Nikulin wrote:
> Hold!
> 
> Greg, are you trying to put a new addendum to the terms of GPL v2?

Nope, as I said many times, that's not what is happening here.

> I read the FAQ you posted, having you writing in that FAQ that this is
> not a change to license terms is not enough.

Really?  Why not?  According to whom?  {hint, not according to all of
the legal people I have worked with on this topic, and it was a boatload
of them...}

> Modification of GPL V2 terms are explicitly disallowed.

Again, we are not modifying the license, so all should be fine, thanks
for agreeing!

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Thu, Oct 19, 2017 at 06:28:12PM +0300, Pavel Nikulin wrote:
> Hold!
> 
> Greg, are you trying to put a new addendum to the terms of GPL v2?

Nope, as I said many times, that's not what is happening here.

> I read the FAQ you posted, having you writing in that FAQ that this is
> not a change to license terms is not enough.

Really?  Why not?  According to whom?  {hint, not according to all of
the legal people I have worked with on this topic, and it was a boatload
of them...}

> Modification of GPL V2 terms are explicitly disallowed.

Again, we are not modifying the license, so all should be fine, thanks
for agreeing!

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Pavel Nikulin]

Hold!

Greg, are you trying to put a new addendum to the terms of GPL v2?
I read the FAQ you posted, having you writing in that FAQ that this is
not a change to license terms is not enough. Modification of GPL V2
terms are explicitly disallowed. IF you want to put such writing into
kernel, a very explicit statement that aforementioned is nothing but a
personal promise of you and ONLY people whom put their names
there should be included. Like in a bold bold upper case text.

1. First

>Notwithstanding the termination provisions of the GPL-2.0 ... ... ...

Well, how we put it. That has no power over whether expedited
injunction will be issued if the license formally stays V2

The text of a license is the binding contract. 1. You can't put a
provision with a binding force to a contract retroactively. 2. This
has to be a change the formal enforcement provisions of the license,
no way other than that. They are not orthogonal to terms of GPL like
the developer certificate of origin.

2. Seconds

> then your license
+ from a PARTICULAR copyright holder is reinstated (a) provisionally,
+ unless and until the copyright holder explicitly and finally
+ terminates your license,

This effectively leaves things as they already are

>(b) permanently, if the copyright holder
+ fails to notify you of the violation by some reasonable means prior to
+ 60 days after the cessation.

That's reasonable to say, but the codes of different countries have
own opinions over temporal reach of contract power. Say, a router
ships with a GPL incompliant firmware, an incompliance is found and
fixed, yet somebody 100% can sue for an incompliance in the past,
unless this phrase will be a part of binding terms of the contract.

3.

Copyright owners of kernel code have full right to seek compliance in
courts, individually for the part of code they wrote in any way they
wish, period. That includes asking courts for injunctions that may
have ruinous consequences. Having an expedited injunction provisions
on the table compels companies to get into compliance like nothing
else. This makes a difference whether an enforcement action has any
actual force or not.

Permanent incompliance leads to permanent license revocation under GPL
v2, unlike GPL v3.

When Linus took a specific commitment to keep Linux under V2 for
practical impossibility of changing the license for such a large
project, that was discussed over and over. People who contribute to
Linux kernel do so knowing that their copyright can be enforced under
that specific term. That is true for contributions that were made long
before the discussion over enforcement terms was a thing.

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Pavel Nikulin]

Hold!

Greg, are you trying to put a new addendum to the terms of GPL v2?
I read the FAQ you posted, having you writing in that FAQ that this is
not a change to license terms is not enough. Modification of GPL V2
terms are explicitly disallowed. IF you want to put such writing into
kernel, a very explicit statement that aforementioned is nothing but a
personal promise of you and ONLY people whom put their names
there should be included. Like in a bold bold upper case text.

1. First

>Notwithstanding the termination provisions of the GPL-2.0 ... ... ...

Well, how we put it. That has no power over whether expedited
injunction will be issued if the license formally stays V2

The text of a license is the binding contract. 1. You can't put a
provision with a binding force to a contract retroactively. 2. This
has to be a change the formal enforcement provisions of the license,
no way other than that. They are not orthogonal to terms of GPL like
the developer certificate of origin.

2. Seconds

> then your license
+ from a PARTICULAR copyright holder is reinstated (a) provisionally,
+ unless and until the copyright holder explicitly and finally
+ terminates your license,

This effectively leaves things as they already are

>(b) permanently, if the copyright holder
+ fails to notify you of the violation by some reasonable means prior to
+ 60 days after the cessation.

That's reasonable to say, but the codes of different countries have
own opinions over temporal reach of contract power. Say, a router
ships with a GPL incompliant firmware, an incompliance is found and
fixed, yet somebody 100% can sue for an incompliance in the past,
unless this phrase will be a part of binding terms of the contract.

3.

Copyright owners of kernel code have full right to seek compliance in
courts, individually for the part of code they wrote in any way they
wish, period. That includes asking courts for injunctions that may
have ruinous consequences. Having an expedited injunction provisions
on the table compels companies to get into compliance like nothing
else. This makes a difference whether an enforcement action has any
actual force or not.

Permanent incompliance leads to permanent license revocation under GPL
v2, unlike GPL v3.

When Linus took a specific commitment to keep Linux under V2 for
practical impossibility of changing the license for such a large
project, that was discussed over and over. People who contribute to
Linux kernel do so knowing that their copyright can be enforced under
that specific term. That is true for contributions that were made long
before the discussion over enforcement terms was a thing.

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Mon, Oct 16, 2017 at 03:50:19PM +0100, David Woodhouse wrote:
> On Mon, 2017-10-16 at 15:46 +0200, Greg KH wrote:
> > > conversations with the TAB on early drafts of this — but I'm a little
> > > concerned that what we've ended up with is a bit one-sided. We're
> > > giving something away, for nothing in return.
> >
> > I don't feel that is true at all, what we are doing here is providing a
> > well-documented way toward compliance and the reinstatement of our
> > license.  That's a key issue with regards to the existing trolls we are
> > currently facing today, which we have to address in order to preserve
> > our community.
> 
> Which trolls? Do you mean Broadcom or Patrick? :)
> 
> I think think this directly addresses either of them. Not unless you're
> planning to get Patrick, or those who aspire to his methods, to sign up
> to this document somehow?

In consulting with a _lot_ of people, and lawyers involved in cases with
Patrick, they have told us that this _will_ help with the troll issue
that Patrick is currently engaging in.

> I do agree that *both* of them need dealing with somehow though.
> 
> I'm actually *more* worried about the Broadcoms of this world, because
> with Patrick there's an easy safeguard that most people seem to have
> forgotten about — do not break the law. Make sure you are so obviously
> complying with the GPL that any claim to the contrary would be
> immediately thrown out of court and your costs awarded. (I know that's
> over-simplifying quite a bit — but while I don't condone Patrick's
> actions, at a personal level I do find it slightly hard to sympathise
> with his victims.)

You should sympathise, as the "victims" here are almost always companies
that had no idea what was going on in the first place.  Their first
interaction with this "Linux thing" is a person demanding that they pay
up in court, and then, when they initially comply because they think
that is what they need to do, they get hit again with loads of other
issues out of their control and are forced to pay even more money.

Does that help us as a community?  No.  It ensures that no one wants to
use Linux in their products.

Yes, the correct response is of course providing tools and education and
other methods in which companies can learn, change, and then track their
open source usage and ensure that they are compliant.  And that is what
a lot of people have been doing for the past few years, look at the
links I did provide with regards to that.

Heck, one of those free e-books could pretty much be subtitled "How to
avoid being hit by a copyright troll!"

So that's one front in fixing this obvious problem where companies are
just not compliant.  We have to also cut off the ability for trolls to
go after companies like this, and that's what this statement is for, and
will help out immediately.

I understand you are wanting to help solve the Broadcom issues in the
world.  Great, let's work to address that, and we can take it off-line
if you want.  But that's not what we are trying to solve here at all.

Don't get into the common mistake that lots of people are doing right
now of, "Oh look, why didn't they also do this and this and this as I
wish they always would have!"  That's not how you solve specific
problems.

> > > This would have been better if it specified that it applied to
> > > *unintentional* violations, and also gave a time limit — automatic
> > > reinstatement *only* happens if complete compliance is achieved within
> > > 90 days, for example. That would help genuine developers who are only
> > > *accidentally* committing a criminal offence through not paying enough
> > > attention, while not giving succour to those who intentionally do so.
> >
> > Defining "unintentional" and "accidentally", might be a bit difficult,
> > given that GPLv3 didn't even attempt to do something like that. 
> 
> Sure. But as you know, those who are *intentionally* violating the
> licence will drag out their repeated candidate releases for years,
> fixing one thing at a time and costing us loads of time and money as we
> painstakingly investigate each attempt. While genuine mistakes are much
> more quickly fixed.

Intentional violators are a different issue here, as you say.  And
really, this 30 days thing means nothing to them, as it is not meant to
at all.

> So a time limit may well have worked as as primitive proxy for "intent".

Maybe, if so, why doesn't GPLv3 have this in it?  :)

> And more to the point, it deprives us of the *one* lever we have, short
> of the last resort of legal action, for persuading them to come into
> *complete* compliance as we define it.

I disagree, see my previous public statements about how I feel is the
best way to work with companies to get them to properly comply with our
license.

Hint, it's not to bring in lawyers, we have many many other "levers" we
can, and do, use to solve it.

thanks,

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Mon, Oct 16, 2017 at 03:50:19PM +0100, David Woodhouse wrote:
> On Mon, 2017-10-16 at 15:46 +0200, Greg KH wrote:
> > > conversations with the TAB on early drafts of this — but I'm a little
> > > concerned that what we've ended up with is a bit one-sided. We're
> > > giving something away, for nothing in return.
> >
> > I don't feel that is true at all, what we are doing here is providing a
> > well-documented way toward compliance and the reinstatement of our
> > license.  That's a key issue with regards to the existing trolls we are
> > currently facing today, which we have to address in order to preserve
> > our community.
> 
> Which trolls? Do you mean Broadcom or Patrick? :)
> 
> I think think this directly addresses either of them. Not unless you're
> planning to get Patrick, or those who aspire to his methods, to sign up
> to this document somehow?

In consulting with a _lot_ of people, and lawyers involved in cases with
Patrick, they have told us that this _will_ help with the troll issue
that Patrick is currently engaging in.

> I do agree that *both* of them need dealing with somehow though.
> 
> I'm actually *more* worried about the Broadcoms of this world, because
> with Patrick there's an easy safeguard that most people seem to have
> forgotten about — do not break the law. Make sure you are so obviously
> complying with the GPL that any claim to the contrary would be
> immediately thrown out of court and your costs awarded. (I know that's
> over-simplifying quite a bit — but while I don't condone Patrick's
> actions, at a personal level I do find it slightly hard to sympathise
> with his victims.)

You should sympathise, as the "victims" here are almost always companies
that had no idea what was going on in the first place.  Their first
interaction with this "Linux thing" is a person demanding that they pay
up in court, and then, when they initially comply because they think
that is what they need to do, they get hit again with loads of other
issues out of their control and are forced to pay even more money.

Does that help us as a community?  No.  It ensures that no one wants to
use Linux in their products.

Yes, the correct response is of course providing tools and education and
other methods in which companies can learn, change, and then track their
open source usage and ensure that they are compliant.  And that is what
a lot of people have been doing for the past few years, look at the
links I did provide with regards to that.

Heck, one of those free e-books could pretty much be subtitled "How to
avoid being hit by a copyright troll!"

So that's one front in fixing this obvious problem where companies are
just not compliant.  We have to also cut off the ability for trolls to
go after companies like this, and that's what this statement is for, and
will help out immediately.

I understand you are wanting to help solve the Broadcom issues in the
world.  Great, let's work to address that, and we can take it off-line
if you want.  But that's not what we are trying to solve here at all.

Don't get into the common mistake that lots of people are doing right
now of, "Oh look, why didn't they also do this and this and this as I
wish they always would have!"  That's not how you solve specific
problems.

> > > This would have been better if it specified that it applied to
> > > *unintentional* violations, and also gave a time limit — automatic
> > > reinstatement *only* happens if complete compliance is achieved within
> > > 90 days, for example. That would help genuine developers who are only
> > > *accidentally* committing a criminal offence through not paying enough
> > > attention, while not giving succour to those who intentionally do so.
> >
> > Defining "unintentional" and "accidentally", might be a bit difficult,
> > given that GPLv3 didn't even attempt to do something like that. 
> 
> Sure. But as you know, those who are *intentionally* violating the
> licence will drag out their repeated candidate releases for years,
> fixing one thing at a time and costing us loads of time and money as we
> painstakingly investigate each attempt. While genuine mistakes are much
> more quickly fixed.

Intentional violators are a different issue here, as you say.  And
really, this 30 days thing means nothing to them, as it is not meant to
at all.

> So a time limit may well have worked as as primitive proxy for "intent".

Maybe, if so, why doesn't GPLv3 have this in it?  :)

> And more to the point, it deprives us of the *one* lever we have, short
> of the last resort of legal action, for persuading them to come into
> *complete* compliance as we define it.

I disagree, see my previous public statements about how I feel is the
best way to work with companies to get them to properly comply with our
license.

Hint, it's not to bring in lawyers, we have many many other "levers" we
can, and do, use to solve it.

thanks,

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Mon, Oct 16, 2017 at 03:46:32PM +0200, Greg KH wrote:
> On Mon, Oct 16, 2017 at 02:11:01PM +0100, David Woodhouse wrote:
> > On Mon, 2017-10-16 at 11:25 +0200, Greg KH wrote:
> > > Documentation: Add a file explaining the requested Linux kernel
> > > license enforcement policy
> > > 
> > > Here's a pull request to add a new file to the kernel's Documentation 
> > > directory.
> > > It adds a short document describing the views of how the Linux kernel 
> > > community
> > > feels about enforcing the license of the kernel.
> > > 
> > > The patch has been reviewed by a large number of kernel developers 
> > > already, as
> > > seen by their acks on the patch, and their agreement of the statement with
> > > their names on it.  The location of the file was also agreed upon by the
> > > Documentation maintainer, so all should be good there.
> > > 
> > > For some background information about this statement, see this article
> > > written by some of the kernel developers involved in drafting it:
> > >   
> > > http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
> > > and this article that answers a number of questions that came up in the
> > > discussion of this statement with the kernel developer community:
> > >   
> > > http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
> > > 
> > > If anyone has any further questions about it, please let me, and the TAB
> > > members, know and we will be glad to help answer them.
> > 
> > It's a shame you don't explicitly mention the FSF's / Conservancy's
> > Principles of Community-Oriented GPL Enforcement:
> > https://www.fsf.org/licensing/enforcement-principles
> 
> What?  I thought I did in my blog post!  Ugh, you are right, it's not
> there, my fault, it was in an earlier draft, I swear, sorry about that,
> must have gotten lost when I turned it from text into a
> markdown-formatted document.  I'll go add it and push out the updated
> post in a bit.

Ok, in reviewing my previous drafts, and my notes for this, I see why I
didn't include it in the final version, so I'll just leave my post
as-is.

thanks,

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Mon, Oct 16, 2017 at 03:46:32PM +0200, Greg KH wrote:
> On Mon, Oct 16, 2017 at 02:11:01PM +0100, David Woodhouse wrote:
> > On Mon, 2017-10-16 at 11:25 +0200, Greg KH wrote:
> > > Documentation: Add a file explaining the requested Linux kernel
> > > license enforcement policy
> > > 
> > > Here's a pull request to add a new file to the kernel's Documentation 
> > > directory.
> > > It adds a short document describing the views of how the Linux kernel 
> > > community
> > > feels about enforcing the license of the kernel.
> > > 
> > > The patch has been reviewed by a large number of kernel developers 
> > > already, as
> > > seen by their acks on the patch, and their agreement of the statement with
> > > their names on it.  The location of the file was also agreed upon by the
> > > Documentation maintainer, so all should be good there.
> > > 
> > > For some background information about this statement, see this article
> > > written by some of the kernel developers involved in drafting it:
> > >   
> > > http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
> > > and this article that answers a number of questions that came up in the
> > > discussion of this statement with the kernel developer community:
> > >   
> > > http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
> > > 
> > > If anyone has any further questions about it, please let me, and the TAB
> > > members, know and we will be glad to help answer them.
> > 
> > It's a shame you don't explicitly mention the FSF's / Conservancy's
> > Principles of Community-Oriented GPL Enforcement:
> > https://www.fsf.org/licensing/enforcement-principles
> 
> What?  I thought I did in my blog post!  Ugh, you are right, it's not
> there, my fault, it was in an earlier draft, I swear, sorry about that,
> must have gotten lost when I turned it from text into a
> markdown-formatted document.  I'll go add it and push out the updated
> post in a bit.

Ok, in reviewing my previous drafts, and my notes for this, I see why I
didn't include it in the final version, so I'll just leave my post
as-is.

thanks,

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[David Woodhouse]

On Mon, 2017-10-16 at 15:46 +0200, Greg KH wrote:
>  I'll go add it and push out the updated post in a bit.

Thanks. I think it's especially important to show how useful
Conservancy's work in this area is.

If there's anyone who's nodding in approval to this document but who
*hasn't* joined Conservancy's group of kernel developers to help drive
the policies and decision-making there, I'd strongly recommend that you
do so: https://sfconservancy.org/copyleft-compliance/

> > conversations with the TAB on early drafts of this — but I'm a little
> > concerned that what we've ended up with is a bit one-sided. We're
> > giving something away, for nothing in return.
>
> I don't feel that is true at all, what we are doing here is providing a
> well-documented way toward compliance and the reinstatement of our
> license.  That's a key issue with regards to the existing trolls we are
> currently facing today, which we have to address in order to preserve
> our community.

Which trolls? Do you mean Broadcom or Patrick? :)

I think think this directly addresses either of them. Not unless you're
planning to get Patrick, or those who aspire to his methods, to sign up
to this document somehow?

I do agree that *both* of them need dealing with somehow though.

I'm actually *more* worried about the Broadcoms of this world, because
with Patrick there's an easy safeguard that most people seem to have
forgotten about — do not break the law. Make sure you are so obviously
complying with the GPL that any claim to the contrary would be
immediately thrown out of court and your costs awarded. (I know that's
over-simplifying quite a bit — but while I don't condone Patrick's
actions, at a personal level I do find it slightly hard to sympathise
with his victims.)

> > This would have been better if it specified that it applied to
> > *unintentional* violations, and also gave a time limit — automatic
> > reinstatement *only* happens if complete compliance is achieved within
> > 90 days, for example. That would help genuine developers who are only
> > *accidentally* committing a criminal offence through not paying enough
> > attention, while not giving succour to those who intentionally do so.
>
> Defining "unintentional" and "accidentally", might be a bit difficult,
> given that GPLv3 didn't even attempt to do something like that. 

Sure. But as you know, those who are *intentionally* violating the
licence will drag out their repeated candidate releases for years,
fixing one thing at a time and costing us loads of time and money as we
painstakingly investigate each attempt. While genuine mistakes are much
more quickly fixed.

So a time limit may well have worked as as primitive proxy for "intent".

We do have a time limit operating in *one* direction, to the benefit of
the criminal — if you stop offending within 30 days, your licence is
automatically reinstated. But we didn't do it in the opposite direction
— however long they take to come into compliance, we still promise that
their licence is reinstated by default when they do. Again it's one-
sided.

And more to the point, it deprives us of the *one* lever we have, short
of the last resort of legal action, for persuading them to come into
*complete* compliance as we define it.

My main concern is that we used to be able to iterate with a violator
until *we* agreed they were compliant. Now I fear that all they have to
do is get into the grey area where they don't think we'll really sue
for what's *left* — if we've signed away our ability to withhold the
licence from them for the original violations.

So given that Patrick was never going to sign this in the first place,
so it doesn't really protect anyone from his abuse, it seems that *all*
we've done is make live easier for the other kind of troll AFAICT. It's
a nice idea, but I'm just not sure it's really going to help overall.

smime.p7s
Description: S/MIME cryptographic signature

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[David Woodhouse]

On Mon, 2017-10-16 at 15:46 +0200, Greg KH wrote:
>  I'll go add it and push out the updated post in a bit.

Thanks. I think it's especially important to show how useful
Conservancy's work in this area is.

If there's anyone who's nodding in approval to this document but who
*hasn't* joined Conservancy's group of kernel developers to help drive
the policies and decision-making there, I'd strongly recommend that you
do so: https://sfconservancy.org/copyleft-compliance/

> > conversations with the TAB on early drafts of this — but I'm a little
> > concerned that what we've ended up with is a bit one-sided. We're
> > giving something away, for nothing in return.
>
> I don't feel that is true at all, what we are doing here is providing a
> well-documented way toward compliance and the reinstatement of our
> license.  That's a key issue with regards to the existing trolls we are
> currently facing today, which we have to address in order to preserve
> our community.

Which trolls? Do you mean Broadcom or Patrick? :)

I think think this directly addresses either of them. Not unless you're
planning to get Patrick, or those who aspire to his methods, to sign up
to this document somehow?

I do agree that *both* of them need dealing with somehow though.

I'm actually *more* worried about the Broadcoms of this world, because
with Patrick there's an easy safeguard that most people seem to have
forgotten about — do not break the law. Make sure you are so obviously
complying with the GPL that any claim to the contrary would be
immediately thrown out of court and your costs awarded. (I know that's
over-simplifying quite a bit — but while I don't condone Patrick's
actions, at a personal level I do find it slightly hard to sympathise
with his victims.)

> > This would have been better if it specified that it applied to
> > *unintentional* violations, and also gave a time limit — automatic
> > reinstatement *only* happens if complete compliance is achieved within
> > 90 days, for example. That would help genuine developers who are only
> > *accidentally* committing a criminal offence through not paying enough
> > attention, while not giving succour to those who intentionally do so.
>
> Defining "unintentional" and "accidentally", might be a bit difficult,
> given that GPLv3 didn't even attempt to do something like that. 

Sure. But as you know, those who are *intentionally* violating the
licence will drag out their repeated candidate releases for years,
fixing one thing at a time and costing us loads of time and money as we
painstakingly investigate each attempt. While genuine mistakes are much
more quickly fixed.

So a time limit may well have worked as as primitive proxy for "intent".

We do have a time limit operating in *one* direction, to the benefit of
the criminal — if you stop offending within 30 days, your licence is
automatically reinstated. But we didn't do it in the opposite direction
— however long they take to come into compliance, we still promise that
their licence is reinstated by default when they do. Again it's one-
sided.

And more to the point, it deprives us of the *one* lever we have, short
of the last resort of legal action, for persuading them to come into
*complete* compliance as we define it.

My main concern is that we used to be able to iterate with a violator
until *we* agreed they were compliant. Now I fear that all they have to
do is get into the grey area where they don't think we'll really sue
for what's *left* — if we've signed away our ability to withhold the
licence from them for the original violations.

So given that Patrick was never going to sign this in the first place,
so it doesn't really protect anyone from his abuse, it seems that *all*
we've done is make live easier for the other kind of troll AFAICT. It's
a nice idea, but I'm just not sure it's really going to help overall.

smime.p7s
Description: S/MIME cryptographic signature

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Bradley M. Kuhn]

I want to thank everyone who has spent years putting together this Linux
Kernel Enforcement Statement.  Conservancy issued a public thank-you today:
https://sfconservancy.org/news/2017/oct/16/linux-kernel-enforcement-statement/

Greg wrote:
> What?  I thought I did in my blog post!  Ugh, you are right, it's not
> there, my fault, it was in an earlier draft, I swear, sorry about that,

No problem!  Here's the stable URL for that link when you add it:
   https://sfconservancy.org/copyleft-compliance/principles.html

When Conservancy released those Principles of Community-Oriented GPL
Enforcement, we asked for the copyleft-using community (in general) and the
Linux community (in particular) to join us in discussing it and looking for
ways to adopt those Principles in everyday work.  I'm thus really glad to see
this great outcome!

The additional permission in Greg's proposed patch is an excellent way to
begin incorporation of those Principles into Linux's license officially, via
an opt-in exception for copyright holders.  Conservancy plans this week to
officially sign it for the Linux copyrights that have been assigned to us.

I also would like to invite everyone to the mailing list created specifically
for this subject, at
https://lists.sfconservancy.org/mailman/listinfo/principles-discuss .  Folks
should feel free to Cc that list with this thread, and/or (if the discussion
becomes OT for LKML) start a new thread there.

Greg, finally, I noticed you had some links to resources about compliance in
your blog post.  Your readers may also be interested in FSF and Conservancy's
Copyleft Guide, which is at https://copyleft.org/guide/.  A direct link to
the chapters on GPL compliance are:
https://copyleft.org/guide/comprehensive-gpl-guidepa2.html#x17-116000II
https://copyleft.org/guide/comprehensive-gpl-guidepa3.html#x26-152000III

I think the latter (the case studies) are particularly useful and my talk on
the most recent case study was well-received at Embedded Linux Conference
2015.
--
Bradley M. Kuhn
Distinguished Technologist of Software Freedom Conservancy

Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Bradley M. Kuhn]

I want to thank everyone who has spent years putting together this Linux
Kernel Enforcement Statement.  Conservancy issued a public thank-you today:
https://sfconservancy.org/news/2017/oct/16/linux-kernel-enforcement-statement/

Greg wrote:
> What?  I thought I did in my blog post!  Ugh, you are right, it's not
> there, my fault, it was in an earlier draft, I swear, sorry about that,

No problem!  Here's the stable URL for that link when you add it:
   https://sfconservancy.org/copyleft-compliance/principles.html

When Conservancy released those Principles of Community-Oriented GPL
Enforcement, we asked for the copyleft-using community (in general) and the
Linux community (in particular) to join us in discussing it and looking for
ways to adopt those Principles in everyday work.  I'm thus really glad to see
this great outcome!

The additional permission in Greg's proposed patch is an excellent way to
begin incorporation of those Principles into Linux's license officially, via
an opt-in exception for copyright holders.  Conservancy plans this week to
officially sign it for the Linux copyrights that have been assigned to us.

I also would like to invite everyone to the mailing list created specifically
for this subject, at
https://lists.sfconservancy.org/mailman/listinfo/principles-discuss .  Folks
should feel free to Cc that list with this thread, and/or (if the discussion
becomes OT for LKML) start a new thread there.

Greg, finally, I noticed you had some links to resources about compliance in
your blog post.  Your readers may also be interested in FSF and Conservancy's
Copyleft Guide, which is at https://copyleft.org/guide/.  A direct link to
the chapters on GPL compliance are:
https://copyleft.org/guide/comprehensive-gpl-guidepa2.html#x17-116000II
https://copyleft.org/guide/comprehensive-gpl-guidepa3.html#x26-152000III

I think the latter (the case studies) are particularly useful and my talk on
the most recent case study was well-received at Embedded Linux Conference
2015.
--
Bradley M. Kuhn
Distinguished Technologist of Software Freedom Conservancy

Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Mon, Oct 16, 2017 at 02:11:01PM +0100, David Woodhouse wrote:
> On Mon, 2017-10-16 at 11:25 +0200, Greg KH wrote:
> > Documentation: Add a file explaining the requested Linux kernel
> > license enforcement policy
> > 
> > Here's a pull request to add a new file to the kernel's Documentation 
> > directory.
> > It adds a short document describing the views of how the Linux kernel 
> > community
> > feels about enforcing the license of the kernel.
> > 
> > The patch has been reviewed by a large number of kernel developers already, 
> > as
> > seen by their acks on the patch, and their agreement of the statement with
> > their names on it.  The location of the file was also agreed upon by the
> > Documentation maintainer, so all should be good there.
> > 
> > For some background information about this statement, see this article
> > written by some of the kernel developers involved in drafting it:
> > 
> > http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
> > and this article that answers a number of questions that came up in the
> > discussion of this statement with the kernel developer community:
> > 
> > http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
> > 
> > If anyone has any further questions about it, please let me, and the TAB
> > members, know and we will be glad to help answer them.
> 
> It's a shame you don't explicitly mention the FSF's / Conservancy's
> Principles of Community-Oriented GPL Enforcement:
> https://www.fsf.org/licensing/enforcement-principles

What?  I thought I did in my blog post!  Ugh, you are right, it's not
there, my fault, it was in an earlier draft, I swear, sorry about that,
must have gotten lost when I turned it from text into a
markdown-formatted document.  I'll go add it and push out the updated
post in a bit.

> I think this approach is a good thing in general,

Great!

> and I know
> Conservancy have been talking about it for a while, including
> conversations with the TAB on early drafts of this — but I'm a little
> concerned that what we've ended up with is a bit one-sided. We're
> giving something away, for nothing in return.

I don't feel that is true at all, what we are doing here is providing a
well-documented way toward compliance and the reinstatement of our
license.  That's a key issue with regards to the existing trolls we are
currently facing today, which we have to address in order to preserve
our community.

> In the long period of negotiation with violators, what typically
> happens is they keep providing "candidate" source releases which are
> ever closer to being compliant, but rarely *actually* compliant.
> 
> With a binding promise to forgive them for past violations as soon as
> they're fixed, we basically lose one of the few levers we had to
> encourage them to come *completely* into compliance. Now I fear some of
> them will only ever come close enough that they know we won't actually
> take the last resort of legal action, purely for what *remains* to be
> fixed.
> 
> This would have been better if it specified that it applied to
> *unintentional* violations, and also gave a time limit — automatic
> reinstatement *only* happens if complete compliance is achieved within
> 90 days, for example. That would help genuine developers who are only
> *accidentally* committing a criminal offence through not paying enough
> attention, while not giving succour to those who intentionally do so.

Defining "unintentional" and "accidentally", might be a bit difficult,
given that GPLv3 didn't even attempt to do something like that.  And I'm
pretty sure I remember it coming up during the drafting of that, don't
you?

We aren't in the business of showing "intent" here, we want to be able
to offer a way for someone who is not in compliance, to be able to join
our community successfully after they come back into compliance.  That's
it, we aren't trying to complicate anything, but rather, make things
more simpler and easier to understand for everyone in order to stop the
issue we are currently facing.

thanks,

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

On Mon, Oct 16, 2017 at 02:11:01PM +0100, David Woodhouse wrote:
> On Mon, 2017-10-16 at 11:25 +0200, Greg KH wrote:
> > Documentation: Add a file explaining the requested Linux kernel
> > license enforcement policy
> > 
> > Here's a pull request to add a new file to the kernel's Documentation 
> > directory.
> > It adds a short document describing the views of how the Linux kernel 
> > community
> > feels about enforcing the license of the kernel.
> > 
> > The patch has been reviewed by a large number of kernel developers already, 
> > as
> > seen by their acks on the patch, and their agreement of the statement with
> > their names on it.  The location of the file was also agreed upon by the
> > Documentation maintainer, so all should be good there.
> > 
> > For some background information about this statement, see this article
> > written by some of the kernel developers involved in drafting it:
> > 
> > http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
> > and this article that answers a number of questions that came up in the
> > discussion of this statement with the kernel developer community:
> > 
> > http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
> > 
> > If anyone has any further questions about it, please let me, and the TAB
> > members, know and we will be glad to help answer them.
> 
> It's a shame you don't explicitly mention the FSF's / Conservancy's
> Principles of Community-Oriented GPL Enforcement:
> https://www.fsf.org/licensing/enforcement-principles

What?  I thought I did in my blog post!  Ugh, you are right, it's not
there, my fault, it was in an earlier draft, I swear, sorry about that,
must have gotten lost when I turned it from text into a
markdown-formatted document.  I'll go add it and push out the updated
post in a bit.

> I think this approach is a good thing in general,

Great!

> and I know
> Conservancy have been talking about it for a while, including
> conversations with the TAB on early drafts of this — but I'm a little
> concerned that what we've ended up with is a bit one-sided. We're
> giving something away, for nothing in return.

I don't feel that is true at all, what we are doing here is providing a
well-documented way toward compliance and the reinstatement of our
license.  That's a key issue with regards to the existing trolls we are
currently facing today, which we have to address in order to preserve
our community.

> In the long period of negotiation with violators, what typically
> happens is they keep providing "candidate" source releases which are
> ever closer to being compliant, but rarely *actually* compliant.
> 
> With a binding promise to forgive them for past violations as soon as
> they're fixed, we basically lose one of the few levers we had to
> encourage them to come *completely* into compliance. Now I fear some of
> them will only ever come close enough that they know we won't actually
> take the last resort of legal action, purely for what *remains* to be
> fixed.
> 
> This would have been better if it specified that it applied to
> *unintentional* violations, and also gave a time limit — automatic
> reinstatement *only* happens if complete compliance is achieved within
> 90 days, for example. That would help genuine developers who are only
> *accidentally* committing a criminal offence through not paying enough
> attention, while not giving succour to those who intentionally do so.

Defining "unintentional" and "accidentally", might be a bit difficult,
given that GPLv3 didn't even attempt to do something like that.  And I'm
pretty sure I remember it coming up during the drafting of that, don't
you?

We aren't in the business of showing "intent" here, we want to be able
to offer a way for someone who is not in compliance, to be able to join
our community successfully after they come back into compliance.  That's
it, we aren't trying to complicate anything, but rather, make things
more simpler and easier to understand for everyone in order to stop the
issue we are currently facing.

thanks,

greg k-h

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[David Woodhouse]

On Mon, 2017-10-16 at 11:25 +0200, Greg KH wrote:
> Documentation: Add a file explaining the requested Linux kernel
> license enforcement policy
> 
> Here's a pull request to add a new file to the kernel's Documentation 
> directory.
> It adds a short document describing the views of how the Linux kernel 
> community
> feels about enforcing the license of the kernel.
> 
> The patch has been reviewed by a large number of kernel developers already, as
> seen by their acks on the patch, and their agreement of the statement with
> their names on it.  The location of the file was also agreed upon by the
> Documentation maintainer, so all should be good there.
> 
> For some background information about this statement, see this article
> written by some of the kernel developers involved in drafting it:
>   
> http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
> and this article that answers a number of questions that came up in the
> discussion of this statement with the kernel developer community:
>   
> http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
> 
> If anyone has any further questions about it, please let me, and the TAB
> members, know and we will be glad to help answer them.

It's a shame you don't explicitly mention the FSF's / Conservancy's
Principles of Community-Oriented GPL Enforcement:
https://www.fsf.org/licensing/enforcement-principles

I think this approach is a good thing in general, and I know
Conservancy have been talking about it for a while, including
conversations with the TAB on early drafts of this — but I'm a little
concerned that what we've ended up with is a bit one-sided. We're
giving something away, for nothing in return.

In the long period of negotiation with violators, what typically
happens is they keep providing "candidate" source releases which are
ever closer to being compliant, but rarely *actually* compliant.

With a binding promise to forgive them for past violations as soon as
they're fixed, we basically lose one of the few levers we had to
encourage them to come *completely* into compliance. Now I fear some of
them will only ever come close enough that they know we won't actually
take the last resort of legal action, purely for what *remains* to be
fixed.

This would have been better if it specified that it applied to
*unintentional* violations, and also gave a time limit — automatic
reinstatement *only* happens if complete compliance is achieved within
90 days, for example. That would help genuine developers who are only
*accidentally* committing a criminal offence through not paying enough
attention, while not giving succour to those who intentionally do so.

smime.p7s
Description: S/MIME cryptographic signature

Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[David Woodhouse]

On Mon, 2017-10-16 at 11:25 +0200, Greg KH wrote:
> Documentation: Add a file explaining the requested Linux kernel
> license enforcement policy
> 
> Here's a pull request to add a new file to the kernel's Documentation 
> directory.
> It adds a short document describing the views of how the Linux kernel 
> community
> feels about enforcing the license of the kernel.
> 
> The patch has been reviewed by a large number of kernel developers already, as
> seen by their acks on the patch, and their agreement of the statement with
> their names on it.  The location of the file was also agreed upon by the
> Documentation maintainer, so all should be good there.
> 
> For some background information about this statement, see this article
> written by some of the kernel developers involved in drafting it:
>   
> http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
> and this article that answers a number of questions that came up in the
> discussion of this statement with the kernel developer community:
>   
> http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
> 
> If anyone has any further questions about it, please let me, and the TAB
> members, know and we will be glad to help answer them.

It's a shame you don't explicitly mention the FSF's / Conservancy's
Principles of Community-Oriented GPL Enforcement:
https://www.fsf.org/licensing/enforcement-principles

I think this approach is a good thing in general, and I know
Conservancy have been talking about it for a while, including
conversations with the TAB on early drafts of this — but I'm a little
concerned that what we've ended up with is a bit one-sided. We're
giving something away, for nothing in return.

In the long period of negotiation with violators, what typically
happens is they keep providing "candidate" source releases which are
ever closer to being compliant, but rarely *actually* compliant.

With a binding promise to forgive them for past violations as soon as
they're fixed, we basically lose one of the few levers we had to
encourage them to come *completely* into compliance. Now I fear some of
them will only ever come close enough that they know we won't actually
take the last resort of legal action, purely for what *remains* to be
fixed.

This would have been better if it specified that it applied to
*unintentional* violations, and also gave a time limit — automatic
reinstatement *only* happens if complete compliance is achieved within
90 days, for example. That would help genuine developers who are only
*accidentally* committing a criminal offence through not paying enough
attention, while not giving succour to those who intentionally do so.

smime.p7s
Description: S/MIME cryptographic signature

[GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9:

  Linux 4.14-rc5 (2017-10-15 21:01:12 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ 
tags/enforcement-4.14-rc6

for you to fetch changes up to 9ed95129ffcabbde564b40ffbbf9c26e8702d858:

  Documentation: Add a file explaining the Linux kernel license enforcement 
policy (2017-10-16 11:14:43 +0200)


Documentation: Add a file explaining the requested Linux kernel license 
enforcement policy

Here's a pull request to add a new file to the kernel's Documentation directory.
It adds a short document describing the views of how the Linux kernel community
feels about enforcing the license of the kernel.

The patch has been reviewed by a large number of kernel developers already, as
seen by their acks on the patch, and their agreement of the statement with
their names on it.  The location of the file was also agreed upon by the
Documentation maintainer, so all should be good there.

For some background information about this statement, see this article
written by some of the kernel developers involved in drafting it:

http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
and this article that answers a number of questions that came up in the
discussion of this statement with the kernel developer community:

http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/

If anyone has any further questions about it, please let me, and the TAB
members, know and we will be glad to help answer them.

Signed-off-by: Greg Kroah-Hartman 


Greg Kroah-Hartman (1):
  Documentation: Add a file explaining the Linux kernel license enforcement 
policy

 Documentation/process/index.rst|   1 +
 .../process/kernel-enforcement-statement.rst   | 147 +
 2 files changed, 148 insertions(+)
 create mode 100644 Documentation/process/kernel-enforcement-statement.rst

[GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy

[Greg KH]

The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9:

  Linux 4.14-rc5 (2017-10-15 21:01:12 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ 
tags/enforcement-4.14-rc6

for you to fetch changes up to 9ed95129ffcabbde564b40ffbbf9c26e8702d858:

  Documentation: Add a file explaining the Linux kernel license enforcement 
policy (2017-10-16 11:14:43 +0200)


Documentation: Add a file explaining the requested Linux kernel license 
enforcement policy

Here's a pull request to add a new file to the kernel's Documentation directory.
It adds a short document describing the views of how the Linux kernel community
feels about enforcing the license of the kernel.

The patch has been reviewed by a large number of kernel developers already, as
seen by their acks on the patch, and their agreement of the statement with
their names on it.  The location of the file was also agreed upon by the
Documentation maintainer, so all should be good there.

For some background information about this statement, see this article
written by some of the kernel developers involved in drafting it:

http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
and this article that answers a number of questions that came up in the
discussion of this statement with the kernel developer community:

http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/

If anyone has any further questions about it, please let me, and the TAB
members, know and we will be glad to help answer them.

Signed-off-by: Greg Kroah-Hartman 


Greg Kroah-Hartman (1):
  Documentation: Add a file explaining the Linux kernel license enforcement 
policy

 Documentation/process/index.rst|   1 +
 .../process/kernel-enforcement-statement.rst   | 147 +
 2 files changed, 148 insertions(+)
 create mode 100644 Documentation/process/kernel-enforcement-statement.rst