Bit-baking with soda

The 'a' in compliance stands for abstract things, that most developer try to avoid artificial created rules (as it's the nature of laws to be sometimes illogical;-)) an absolute must-have if you're working with open-source software. for me it additionally stand for automation potential Introducing the issue Just think of the following situation: a random guy, you never worked with before (and you don't know personally) tries to contribute a bitbake recipe for a new component. As we all know each recipe has a LICENSE entry, which offers a SPDX compatible representation of a LICENSE (or multiple licenses) applied to the source code, that the recipe offers build information for. So how can you be sure, that this setting is correct? Well you can scan the source code all by yourself and try to figure out under what license the source code is provided. For a single source repository, I guess that's  fairly easy, but time consuming. B

What's the story? I guess most of you are familiar with the concept of merge or pull requests, so I won't go into details on these - but in case you missed it,  here is a brief description what GitLab thinks it is. There are basically two side involved into a merge request (or MR as the cool kids would say;-)) the one who actually provides the code change, lets call them devs the one who's maintaining the repository, where the change should be applied Both sides might have different objectives. The dev wants the code, she/he already wrote (hopefully tested) and streamlined, to be part of the repo upstream - as otherwise she/he could skipped all that work and enjoyed life (something we should all do from time to time). The maintainer usually lacks some implementation detail and is more keen on having the contributed code to be written according to the project style, the code being regression tested, covered by unit tests, so she/he can be sure that the fresh con