CLA concerns

[Timothy Pearson]

Thank you for your response!

No, we are not looking to upstream any patches that contain any patented technology.  The main concern is that the language is somewhat open-ended, and an argument exists that if a third party wanted to infringe on the patented parts (which we were planning to maintain downstream as you mention) all they would need to do is to extend the code we added to tree, then claim that the combination of our code and their new infringing code was authorized by the CLA.

If it could be made clearer that our patent release /only/ holds for the patches that were signed off by us, that would probably allow us to proceed.  Just as the project and its contributors are not in general able to perform a full search to avoid infringement, it is similarly unreasonable to require us to audit the entire extant codebase against our patent portfolio before we can contribute patches in one specific, audited, and cleared area.

----- Original Message -----
> From: "krtaylor" <kurt.r.taylor at gmail.com>
> To: "Timothy Pearson" <tpearson at raptorengineering.com>, "openbmc" <openbmc at lists.ozlabs.org>
> Sent: Wednesday, May 1, 2019 1:51:30 PM
> Subject: Re: CLA concerns

> Hi Timothy, You are absolutely right to examine the CLA/CCLA IP terms
> and make sure that they are compatible with your product legal team.
> 
> I am not an attorney, but do have several years experience with these
> things. See my questions/comments below inline.
> 
> On 5/1/19 2:38 AM, Timothy Pearson wrote:
>> All,
>> 
>> While we would like to upstream the Talos II / Blackbird BMC patches to the
>> OpenBMC project, our legal folks will not approve the CLA.  The main concern is
>> the patent section, since our mainboards do contain patented technology that is
>> not part of OpenBMC, but that OpenBMC may interface with.  We are not trying to
>> upstream any code that would result in patent action, but are very concerned
>> that the CLA would end up granting a license for the patented technology that
>> exists outside of OpenBMC, merely because the OpenBMC codebase is able to
>> interface with that external technology.
> 
> Is the concern about releasing IP about the interface, in that it might
> give clues to what/how the patented technology operates? What if that
> interface was abstracted in some way and kept in a downstream private
> (behind your firewall) fork of OpenBMC that you built and supported for
> your customers?
> 
> This is a typical practice for keeping company value-add or patented
> technology separate from the upstream open code base.
> 
>> 
>> The specific clause in question is:
>> "...or by combination of Your Contribution(s) with the Work to which such
>> Contribution(s) were submitted."
>> 
>> This is ambiguous enough that legal is concerned an external entity wishing to
>> clone the patented technology from our mainboards without a license would
>> simply be able to merge our contributions with their own de novo code
>> duplicating parts of the patented technology, then claim a license for the
>> patents was automatically granted by the CLA.  As such, we are currently
>> blocked from upstreaming code to OpenBMC, despite the fact that our patches are
>> freely available under GPL and MIT licenses, and that those patches are not
>> covered by any of our patents (past or future).
> 
> Patches/features contributed to OpenBMC should not contain any patented
> technology. Any value-add or patented technology that you have should be
> kept in your downstream fork (see above).
> 
>> 
>> Is there a way to clean up the patent section of the CLA to make it clearer that
>> only the patches submitted are released from patent infringement claims, and
>> that any third party modifications to those patches (or to the codebase created
>> in part by those patches) must still be cleared by their respective authors /
>> maintainers not to infringe on the patent rights of other contributors to the
>> codebase?
> 
> You can imagine that requiring a developer to clear modifications of
> patent infringement would be a monumental task to burden the repo
> maintainer with on a per-patch basis. As said above, any patch that
> would require this special treatment should be kept in a downstream
> product fork.
> 
> I would like to learn more about this, and help if I could. Apologies in
> advance if I have misunderstood any of your points.
> 
> Kurt Taylor (krtaylor)
> 
>> 
>> Thank you!
>> 
>> --
>> Timothy Pearson
>> Raptor Engineering, LLC
>> https://www.raptorengineering.com
>> +1 (415) 727-8645