On Sat, 28 Jun 2025 at 19:30, Roberto A. Foglietta <[email protected]> wrote:
> > https://github.com/robang74/tinycore-editor/tree/main/busybox/patches > > Before entering into judgemental mode, I suggest to take a look to the > description "TinyCore Editor - Building suite for a > non-certifiable-by-design PoC Linux embedded system - Teaching tool > about dealing with legacy systems" because a PoC is a PoC as long as > it cannot be a product, otherwise it is a product into its early stage > of developing but as Microsoft teaches, as long as something run and > people use it, then it is a commercial product! LOL > For sake of completeness for the few that did not get in full the point of a PoC as a system "non-certifiable-by-design" a) whatever is the conditions of the contract or employment nobody can -- without an extra and VERY important payment on the top of a standard-to-the-market price/salary - grant itself a NDA about technologies that the consultant/employee had mastered in the past, or exclusivity over code that by its nature is copylefted, especially for those who are fulfilling a GNU/Linux role. In fact, no company made an attempt to challenge this obvious statement of law because the consequences for the whole market could be HUGE. At least, in Europe. b) as long as I created the "non-certifiable-by-design" PoC, I am also capable of applying a procedure that it grants to be certifiable (as a general product) and/or be suitable for a professional use by those who knows the Tinycore system and the target system. In this second case, the business model is something like a maintenance or reparation service. For which the certification chain starts from the producer (company) towards the employee in specific role/skills and down to the consultants/external due to their role/skills. Finally, the certification of the target system happens within the technical testing framework. Both of these points are in place to strongly sustain the "Humans as Capital" principle rather than "Humans as Resources" (hence copyright as intangible asset aka "intellectual property") model. Both of these points are completely aligned with the copyleft principle in which the code is available under certains terms also to third parties and the value (business opportunity) is about the skills. Please, note that THIS is pretty different from "knowledge retention" which can be limiting for the business and the people (short-term tactic) but it is "knowledge first" which means not being replaced by people that click buttons without any awareness about what they are doing. Which is an approach that kills every risk mitigation plan or strategy. Moreover, a brief reminder that security by obscurity is an approach (or a tactic) doomed to fail in the middle-terms even if it can provide a kind of advantage in the short-terms. Which is the reason because white-hat security hackers grant to companies a grace period before publicly disclosing vulnerabilities or defects. It is worth noticing that "security" is a broad social value, not just a private matter. Many jurisdictions like Roman law and Common law provide a principles-set framework which is strongly oriented to the good of many. For example copyright and patents are two examples, in which the private receive some advantages (exclusivity) in such a way society can benefit from the externalities (business and knowledge securing). Finally, this is NOT politics, in strict terms. In broad terms, it might be a political view (HC vs HR, Copyleft vs Copyright) but in this broader view, also buying apples rather than pears is a political choice depending on the awareness of those who are paying the price. For those who support the idea that everything is politics, they would take notice that on the other hand, everything is about awareness while some specific actions are about politics. I will avoid linking here two articles about "Emancipate SW libre from its politica roots" and "Politics and democracy for dummies" but I am pretty sure that those who are looking for them will find those two articles. Is this OT for the Busybox ML? Well, it is quite a bit. However, once a debate sparks, it is worth sharing that information that can be useful for those who are working in the same field. Those who are considering this kind of e-mail as OT, are suggested to not answer this e-mail in order to adhere to the classic "do not feed the troll" policy, which is coherence, first of all. LOL Best regards, R- _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
