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.) Best regards Uwe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
