Hi, On Tue, 3 Dec 2019 at 16:29, Hans Dedecker <dedec...@gmail.com> wrote: > > On Tue, Dec 3, 2019 at 3:59 PM Uwe Kleine-König <u...@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 <u...@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 > > >>> <u...@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
I have to agree with everyone, so please don't add SoBs for *anyone* except yourself. This is basically similar to forging a signature (just without the direct legal consequences of that). > 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 Indeed, so patches without one, or a broken one need to be fixed by the submitter/author. This cannot be fixed up by the maintainer (except maybe with an explicit permission of the author). Regards Jonas _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel