On Fri, Feb 10, 2012 at 10:16:06PM +0200, Felipe Contreras wrote: > We don't care about compliance, compliance is almost useless. What we > need is for them to become members of the community, and that can only > happen within, by a change in culture, understanding how open source > works.
It would work just as well for them to give the competitive advantage to companies that are complying. You have to think about global effects on the software ecosystem, not just a single company. > Google's Android team opens their code (eventually), but most of that > code has not been merged to the Linux kernel, therefore, it's > basically useless to developers. I hope I don't have to tell you that > many people are angry about this, and have called Android a fork. How > are you going to solve this? Suing? If developers care about its utility to them, they can read and merge the code. What matters a lot more is utility to users who have received Android devices, who want to be able to use their hardware without the encumbrance of the vendor-shipped crapware. The fact that the source code is public and free makes a huge difference to them. > Enforcement only ensures that we would get the bare minimum (legal) > from the company, and IMO that doesn't help much. Enforcement creates a cost for companies that take advantage of free software and refuse to play by the rules. This in turn helps give competitive advantage to the ones who do play by the rules, and creates an incentive for the ones who are infringing to change their behavior. > > Otherwise, many companies merely ignore the GPL. > > GPL is not important; it's just a tool. What is important for > developers is to get contributions back. > > In the case of Sony, this tool is doing the opposite; not only is it > taking potential contributions from Sony away, but it's encouraging > other people to do the same (since toybox is also open source). Toybox has little to do with Sony. Rob can be abrasive, but I've known him a long time, and his main interest in Toybox is frustration with all the hideous hacks, obfuscation, and microoptimization all over Busybox that make the code difficult to read, fix, and improve, all for the sake of saving a few worthless bytes here and there. The basic principle, which I fully agree with and also adopted as a core design principle in musl, is that near-optimality in size and performance stem naturally from simple, clean design, and that complexity should be introduced only in cases where the simple solution is pathologically slow or bloated. > Perhaps it's time to write a special clause that says that the scope > of busybox enforcement should be restricted to busybox (not used as a > proxy). Why? I would hope many developers would be against such a policy. The most useful part of Busybox enforcement is as a proxy. Nobody actually cares about the modifications to Busybox (if any); they care about the kernel patches and other stuff that's essential to using the hardware Busybox is distributed on. Rich _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
