[OpenWrt-Devel] The meaning of Signed-off-by for netifd [Was: Re: [PATCH netifd] interface: warn if ip6hint is truncated]

[Daniel Golle]

On Tue, Dec 03, 2019 at 08:56:46PM +0100, Uwe Kleine-König wrote:
> On 12/3/19 4:28 PM, Hans Dedecker wrote:
> > On Tue, Dec 3, 2019 at 3:59 PM Uwe Kleine-König <uwe at kleine-koenig.org> wrote:
> >>
> >> Hello Hans,
> >>
> >> On 12/3/19 8:50 AM, Hans Dedecker wrote:
> >>> On Fri, Nov 29, 2019 at 9:29 PM Uwe Kleine-König <uwe at kleine-koenig.org> wrote:
> >>>>
> >>>> On 11/29/19 8:50 PM, Hans Dedecker wrote:
> >>>>> On Wed, Nov 20, 2019 at 7:11 PM Uwe Kleine-König <uwe at kleine-koenig.org> wrote:
> >>>>>>
> >>>>>> When for example a /60 is assigned to a network the last 4 bits of the
> >>>>>> ip6hint are unused. Emit a warning if any of these unused bits is set as
> >>>>>> it indicates that someone didn't understand how the hint is used. (As I
> >>>>>> did earlier today resulting in spending some time understanding the
> >>>>>> code.)
> >>>>> Patch applied with some minor tweaks
> >>>>> (https://git.openwrt.org/?p=project/netifd.git;a=commit;h=e45b1408284c05984b38a910a1f0a07d6c761397);
> >>>>
> >>>> The updated warning message is fine.
> >>>>
> >>>>> I added your SoB as this was missing in the patch
> >>>>
> >>>> I wonder what the significance of the SoB is given that a) it's not
> >>>> documented (at least in the netifd sources) and b) it seems to be ok to
> >>>> "fake" someone else's SoB and c) there are several commits in the newer
> >>>> history of netifd that don't have a SoB of either Author or Committer
> >>>> (or both).
> >>> For details why a SoB is required; see
> >>> https://openwrt.org/submitting-patches#sign_your_work.
> >>> If there're any commits in the netifd repo which don't have a SoB this
> >>> must rather stay an exception than becoming a general rule.
> >>
> >> ok, so you claim my SoB means that *I* confirmed that my change is
> >> compatible to the netifd's license. I didn't do that though.
> >>
> >> Even if it was me who added that line I doubt is has any relevance for
> >> netifd because nothing in the netifd sources explains what an SoB means.
> >> And the link you sent applies only to patches for openwrt, not netifd.
> >> (Also if this is the only place for openwrt where the significance of an
> >> SoB is described I wonder if this is relevant given that from the POV of
> >> openwrt.git the wiki is an external resource that can be modified by
> >> anyone. What if someone removes item (d) from the wiki or introduces an
> >> (e)?)
> >>
> >> Don't get me wrong, my patch is compatible to netifd's license. But if
> >> you want that netifd's license situation stays reasonably safe and
> >> clean, it IMHO cannot be that you add a SoB for someone else, and give
> >> that SoB a meaning that isn't documented for your project and assumes
> >> things about that someone else that you cannot know for sure. So if you
> >> require a formalism, please formalize it properly. (Of course INAL, but
> >> that's my understanding of how open source licensing works.)
> > I won't waste further my time and energy on this ...
> > I acted in good faith and next time if I find a patch from you without
> > SoB I will just simply reject it to avoid contra productive
> > discussions

Yes, and please do so as well for anyone else who doesn't add SoB
herself.

> 
> I would have expected that the discussion is in your interest because
> not being strict with licenses is something that really hurts when it
> goes wrong. My intention is not to drain your energy but to highlight
> the necessity[1] to be stricter with license stuff than the way my patch
> was handled.

I definitely agree, adding SoB on behalf of someone else should not
happen and I haven't seen it happening before this occasion.

> 
> > Patches delivered for all projects (netifd/libubox/ubus/...)
> > maintained by OpenWrt must have a SoB in line what is described on the
> > Wiki; this does not solely apply to the OpenWrt repo
> > 
> > This closes the discussion for me
> 
> Fine for me, I won't press the matter any further. I wish you that this
> problem won't backfire.

I hope as well...

> 
> Bye
> Uwe
> 
> [1] well, or at least what I consider to be necessary
> 

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel