lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 9 Nov 2017 12:19:04 +0100
From:   Daniel Lezcano <>
To:     Greg Kroah-Hartman <>
Cc:     Linus Torvalds <>,
        Linux Kernel Mailing List <>
Subject: Re: Legal question: Author, Sign-off, Company Copyright and gmail

On 09/11/2017 11:44, Greg Kroah-Hartman wrote:
> On Thu, Nov 09, 2017 at 10:45:27AM +0100, Daniel Lezcano wrote:
>> Hi all,
>> I noticed a practice when the patches are submitted where I'm a bit
>> confused about how it fits with the DCO.
>> People are creating gmail accounts to send patches on behalf of their
>> company because the company's email configuration does not allow to send
>> patches or adds extra infos, or whatever...
>> That ends up with patches submitted by a gmail account with no history
>> and verifiable origin and new files containing a company copyright [1].
> If there is a question, just ask.
>> At the first glance I would say, it is not allowed, and if a company is
>> willing to do opensource, it should provide the tools to its employees
>> to do so. But I don't want block patch submission if this practice is
>> tolerated.
> Fixing the use of a company's email server is outside of almost all
> Linux kernel divisions.  As one such example, Red Hat has a system that
> messes with patches :)
> I only know of one company that uses Exchange that has "fixed it" enough
> to allow their developers to send patches out that are not corrupted
> (and no, it's not Microsoft).  Preventing all of those companies, or
> those that use Lotus Notes, or any other horrid email system, from
> contributing to kernel development is not a good idea.
>> What is the policy in this case ?
> I just ask all new contributors who they work for, and so we then know,
> it's not that big of a deal.

Thanks for your quick answer and clarification.

  -- Danie

 <> │ Open source software for ARM SoCs

Follow Linaro:  <> Facebook |
<!/linaroorg> Twitter |
<> Blog

Powered by blists - more mailing lists