gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Discussion, and Help Wanted: Moving to Gitlab fo


From: Schanzenbach, Martin
Subject: Re: [GNUnet-developers] Discussion, and Help Wanted: Moving to Gitlab for Git, CI, and Issues
Date: Sun, 7 Apr 2019 18:46:18 +0200


> On 7. Apr 2019, at 13:36, Christian Grothoff <address@hidden> wrote:
> 
> On 4/7/19 11:11 AM, Schanzenbach, Martin wrote:
>>>> On 4/7/19 8:33 AM, Schanzenbach, Martin wrote:
>>>>> Contributors should be able to do anything they want in their own
>>>>> namespaces including committing code that does not compile (e.g. for
>>>>> their gnunet.git forks). However, in order to get it into the "main"
>>>>> gnunet project codebase, the CI must pass for the respective pull
>>>>> request and I would argue that 1-2 "main" devs should sign off on the
>>>>> commit (this allows us to control the CAA issue a bit).
>>>> Eh, sorry, but under forthcoming EU regulation, we cannot even host
>>>> contributor's code without having a signed the CAA. So Git pushes should
>>>> only be possible for people that signed the CAA, and in that case if a
>>>> CAA-signing contributor has pushed a change to a namespace/branch that
>>>> by convention is to be merged, we should ideally automate the merge.
>>> 
>>> I think you misunderstand the new regulation. Having a CAA does not protect 
>>> the platform from this.
>>> It is not enough to have the user state that the code is his, the platform 
>>> must verify/ensure that.
>>> No legal document is able to absolve us from this.
>> 
>> Btw I also think it only applied to commercial platforms. So is there really 
>> a need to worry???
> 
> A hostile actor can very easily classify you as "commercial", starting
> with GNUnet e.V. applying for grants and hiring devs thus potentially
> providing income for some people. And as we learned with Telekom, legal
> disputes with the wrong party can bankrupt you easily even if you
> _would_ win it, and the Vorstand has _personal_ liability in case of
> gross negligence. IANAL, but I believe the CAA should help us against
> any claims of _gross_ negligence. OTOH, I'm sure there will be lawyers
> that would twist the situation of allowing anyone to upload any code
> without any such contract as gross negligence.

The CAA does not help in any way. You are still liable as a platform. It has 
literally nothing to do with the copyright infringements if the contributor 
copied code from somewhere else. You cannot delegate this responsibility 
anymore to the user. That way the old way of doing it.

> 
>>>> However, given that we cannot then preserve the gpg signature on the
>>>> commit (depending on how the merge goes), maybe indeed we _need_ a dev
>>>> to do the sign-off just to get at least one proper gpg signature on the
>>>> commit.  In that case, maybe the CI can automatically send an e-mail to
>>>> a group of devs that are on sanity-checking + gpg-signing duty.
>>>> 
>>>> Anyway, the CAA issue should be solved prior to any Git write access,
>>>> and the sign off step _may_ be (borderline) acceptable to address the
>>>> GPG signing issue, but it shouldn't be seen or phrased as that this is
>>>> done by the "main" devs. The sign-off should be more more like a
>>>> secretary position for pushing the paperwork along.
>>> 
>>> Well then the whole "open participation" thing is moot anyway and I wonder 
>>> why it comes up all the time here.
>>> If we have a beaurocractic onboarding process including the CAA (which we 
>>> do not have atm btw), then participation is limited and must be done 
>>> through gatekeepers anyway.
> 
> I'm not sure why you say "which we do not have atm btw" -- all the
> Gitolite admins have been told that giving Git (write) access should
> only be done if someone has signed the CAA, and I have a collection of
> CAA sheets here at home. I'm not 100% sure that there isn't one missing
> (some are electronic, I still need to print those), but at least the
> process exists and _should_ be enforced.

Oh of course! A transparent, unbureaucratic and open way for contributor 
onboarding! What can possibly go wrong.
"Git admins" instructed by you on the basis of sheets of paper which have been 
mailed to you. In the year 2019...

Just do whatever you want. I think I will stop bringing myself in this regard 
and just develop in an external mirror repo occasionally rebasing my stuff in 
the main repo. This way, you can even keep gitolite -> win win

> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]