All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Nikulin <nikulinpi@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy
Date: Mon, 23 Oct 2017 16:11:14 +0300	[thread overview]
Message-ID: <CAN3U_kXLFda=iRR9V41uDUnaxx4onSkJsLfXjbHjkkO5NoD5TA@mail.gmail.com> (raw)
In-Reply-To: <20171023075022.GA2821@kroah.com>

>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 <gregkh@linuxfoundation.org> 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

  reply	other threads:[~2017-10-23 13:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19 15:28 [GIT PULL] Documentation: Add a file explaining the requested Linux kernel license enforcement policy Pavel Nikulin
2017-10-20  7:29 ` Greg KH
2017-10-20 18:25 ` Alan Cox
2017-10-21  8:03   ` Greg KH
2017-10-21 19:16   ` Pavel Nikulin
2017-10-22  2:28     ` Bradley M. Kuhn
2017-10-23  7:50     ` Greg KH
2017-10-23 13:11       ` Pavel Nikulin [this message]
2017-10-23 14:35         ` Theodore Ts'o
2017-10-23 17:47           ` Damian Tometzki
2017-10-23 18:26           ` Damian Tometzki
  -- strict thread matches above, loose matches on Subject: below --
2017-10-16  9:25 Greg KH
2017-10-16 13:11 ` David Woodhouse
2017-10-16 13:46   ` Greg KH
2017-10-16 14:31     ` Bradley M. Kuhn
2017-10-16 14:50     ` David Woodhouse
2017-10-17 14:57       ` Greg KH
2017-12-10  8:21       ` Pavel Machek
2017-10-17  8:06     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN3U_kXLFda=iRR9V41uDUnaxx4onSkJsLfXjbHjkkO5NoD5TA@mail.gmail.com' \
    --to=nikulinpi@gmail.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.