sdbusplus commits missing CLA

sdbusplus commits missing CLA

[Patrick Williams]

Kurt,

We have a few commits for the openbmc/sdbusplus repository that have
been floating around in Gerrit since early 2018 and seem to be stuck in
"missing CLA limbo".  It appears that there was some discussion on the
CLA at one point but I don't know what happened to it.  I don't see a
CLA from the Bosch company in the Google Doc folder.

https://gerrit.openbmc-project.xyz/q/owner:mark.jonas%2540de.bosch.com

There was recently a request to revive this work because someone else is
finding it useful (and we've had a feature request open for a long time
on one of them as well).  What options do we, the maintainers, have in
this situation?

I don't really want to blindly reimplement this feature since there was
good work done here.  There appears to have been no plagiarism issues.
Since the commits have a S-O-B by two people from the same company, it
seems reasonable that they fully intended to contribute this work
publicly.  I'm not looking to restart a "why do we have CLAs"
discussion, but it seems like we need some direction on what maintainers
should do when there is a missing CLA.

-- 
Patrick Williams

Re: sdbusplus commits missing CLA

[krtaylor]

On 2/20/20 2:35 PM, Patrick Williams wrote:
> Kurt,

(Not a lawyer)

> We have a few commits for the openbmc/sdbusplus repository that have
> been floating around in Gerrit since early 2018 and seem to be stuck in
> "missing CLA limbo".  It appears that there was some discussion on the
> CLA at one point but I don't know what happened to it.  I don't see a
> CLA from the Bosch company in the Google Doc folder.

I have not received a CLA from Bosch, or an ICLA from the developer(s) 
referenced.

> https://gerrit.openbmc-project.xyz/q/owner:mark.jonas%2540de.bosch.com
> 
> There was recently a request to revive this work because someone else is
> finding it useful (and we've had a feature request open for a long time
> on one of them as well).  What options do we, the maintainers, have in
> this situation?

We cannot accept/merge the code until resolved. If they cannot complete 
a ICLA/CCLA for this submission, it should be abandoned.

> I don't really want to blindly reimplement this feature since there was
> good work done here.  There appears to have been no plagiarism issues.
> Since the commits have a S-O-B by two people from the same company, it
> seems reasonable that they fully intended to contribute this work
> publicly.  I'm not looking to restart a "why do we have CLAs"

CLA's protect the company, individual and the project. We must have 
permission from the company that a developer they are employing has 
their permission to submit code to the project. If they don't care, that 
is what the ICLA is for.

Kurt Taylor (krtaylor)

> discussion, but it seems like we need some direction on what maintainers
> should do when there is a missing CLA.
> 

Re: sdbusplus commits missing CLA

[Andrew Jeffery]

On Sat, 22 Feb 2020, at 06:40, krtaylor wrote:
> On 2/20/20 2:35 PM, Patrick Williams wrote:
> > Kurt,
> 
> (Not a lawyer)
> 
> > We have a few commits for the openbmc/sdbusplus repository that have
> > been floating around in Gerrit since early 2018 and seem to be stuck in
> > "missing CLA limbo".  It appears that there was some discussion on the
> > CLA at one point but I don't know what happened to it.  I don't see a
> > CLA from the Bosch company in the Google Doc folder.
> 
> I have not received a CLA from Bosch, or an ICLA from the developer(s) 
> referenced.
> 
> > https://gerrit.openbmc-project.xyz/q/owner:mark.jonas%2540de.bosch.com
> > 
> > There was recently a request to revive this work because someone else is
> > finding it useful (and we've had a feature request open for a long time
> > on one of them as well).  What options do we, the maintainers, have in
> > this situation?
> 
> We cannot accept/merge the code until resolved. If they cannot complete 
> a ICLA/CCLA for this submission, it should be abandoned.

So "contributors" can DoS the project by authoring patches and not signing
a CLA?

What happens if someone forks the repo in question and applies the
unaccepted patch, and we end up changing the bitbake recipe to point at the
fork? And if that's bad, how is that different to consuming projects that don't
have a CLA (e.g. Linux, u-boot, qemu etc)?

I feel like this needs a bit more thought...

Andrew

Re: sdbusplus commits missing CLA

[krtaylor]

On 2/23/20 6:14 PM, Andrew Jeffery wrote:
> 
> 
> On Sat, 22 Feb 2020, at 06:40, krtaylor wrote:
>> On 2/20/20 2:35 PM, Patrick Williams wrote:
>>> Kurt,
>>
>> (Not a lawyer)
>>
>>> We have a few commits for the openbmc/sdbusplus repository that have
>>> been floating around in Gerrit since early 2018 and seem to be stuck in
>>> "missing CLA limbo".  It appears that there was some discussion on the
>>> CLA at one point but I don't know what happened to it.  I don't see a
>>> CLA from the Bosch company in the Google Doc folder.
>>
>> I have not received a CLA from Bosch, or an ICLA from the developer(s)
>> referenced.
>>
>>> https://gerrit.openbmc-project.xyz/q/owner:mark.jonas%2540de.bosch.com
>>>
>>> There was recently a request to revive this work because someone else is
>>> finding it useful (and we've had a feature request open for a long time
>>> on one of them as well).  What options do we, the maintainers, have in
>>> this situation?
>>
>> We cannot accept/merge the code until resolved. If they cannot complete
>> a ICLA/CCLA for this submission, it should be abandoned.
> 
> So "contributors" can DoS the project by authoring patches and not signing
> a CLA?

Never been a problem in any project I've been a part of. But,there are 
plans to make it easier for a maintainer to check (maybe fully automate) 
whether a contributor is part of a CLA group, see "Community Support" 
thread.

> 
> What happens if someone forks the repo in question and applies the
> unaccepted patch, and we end up changing the bitbake recipe to point at the

Why would we do that? We can't stop anyone from forking our project, in 
fact most companies that build a product based on OBMC will fork a 
"supported"" version anyway. They can add or remove anything they wish.

> fork? And if that's bad, how is that different to consuming projects that don't
> have a CLA (e.g. Linux, u-boot, qemu etc)?

It still remains the responsibility of the company to accept the risk of 
shipping open source code as a part of their product. This is as old as 
the open source movement itself.

> 
> I feel like this needs a bit more thought...

The CLA protects all participants; companies and individuals. I know for 
a fact that several of our participating companies (if not all) would 
have a big problem with the CLA not being in place. It is up to us as a 
community to incorporate it into our processes, and we have discussed it 
at length. I don't feel like the current policy/process is horrible and 
needs fixing.

What changes would you propose?

Kurt Taylor (krtaylor)

> Andrew
>