It's pretty strange that the talking notes linked below say that one of the biggest threats to computing is locked down embedded devices. The author's fix is to then implement a replacement that would allow vendors to completely lock down embedded devices.
Huh? The author's fix is to help develop embedded systems by freely distributing an unencumbered tool set with:
1) A smaller attack surface
2) Correctness as a focus with regard to code
3) Conciseness as a focus with regard to tools
4) Improved speed
5) Clear documentation (In TODO)
I was replying to the parent's assertion the "author's fix is to then implement a replacement that would allow vendors to completely lock down embedded devices."
This is an entirely a false premise used to attack the author for his license choice; rather unfortunate since it belittles the entire project. It implies that only corporate entities with closed source licenses can improve the code/hardware... which they will dastardly keep close to their hearts, bless 'em. Meanwhile, a vast number of others will take the code and do improvements themselves. Some portion of them (not all, obviously, and this seems to be the grating point for GPL proponents) will willingly contribute code back as has happened to the countless other BSD/ISC/PD projects floating around. And they will be better off for it since contributed code wasn't due to some license prerequisite, but by willing choice.
>This is an entirely a false premise used to attack the author for his license choice
Well the author made a big deal of the licencing himself as a reason for the project.
>And they will be better off for it since contributed code wasn't due to some license prerequisite, but by willing choice.
I don't see how they are 'better off', if I release a program and say to people that you can pay me if you want to and no one or extremely few do, am I 'better off'? It's the code/money coming back to me that decides whether I'm 'better off' in my book.
Personally I'd rather take the code even if given 'because they legally must', then not have the code at all, if I am really interested in code contributions at all that is. If I'm not then permissive licencing is my preference.
There are many types of projects out there were code contributions are appreciated but not really sought, and there are many projects out there were contributions and cooperative development is important for it to bear fruit.
I personally think permissive licences typically lends itself best to the former and copyleft licences to the latter. The reason for this is that I think copyleft creates a level playing field for contributors, each participant are legally bound to offer their enhancements in source form which can be incorporated back into the project.
But of course there's no clear rule, and the nature of the project itself most likely has a huge impact, like if the project is meant to be a component to be used in other projects then permissive licencing is likely used regardless of the level of cooperative development.
Meanwhile if the project is 'stand-alone', copyleft is in my experience the widely chosen licence, this seems to be extremely typical for open source desktop software, regardless of platform.
They're better off for getting code willingly contributed as opposed to forced due to a license provision. I'm not sure how I would explain the benefits of altruism by choice vs. by law (which isn't really altruism, but a completion of a legal obligation).
"...and there are many projects out there were contributions and cooperative development is important for it to bear fruit."
Struggling to come up with a single category of software where this would merit derivatives include source sharing provisions in the license.
>I'm not sure how I would explain the benefits of altruism by choice vs. by law
This is the 'perfect world' scenario where everyone does 'the right thing', of course in such a world we wouldn't need any laws or any written contracts at all.
In reality though, I make sure that I have a written agreement with my employer which legally binds him to pay me a specified salary at the end of each month, because when push comes to shove I don't blindingly trust that he pay me my salary just because it's the 'right thing'.
Nor do I only want my specified salary if he 'wants to give it to me instead of being legally bound to do so', if he owes me salary I want it even if he doesn't want to give it to me.
In my opinion when it comes to companies in particular (which is generally the equivalent of an extremely selfish person), the typical course of action is to only contribute back if they legally have to, or if they see a practical benefit in doing so that outweighs the potential advantage they could have by keeping their changes to themselves, color me cynical.
I also think this is what makes copyleft a good base for cooperative development between said companies, as they are all legally bound to contribute their changes back which is something I believe comes across better in the board room as opposed to relying on other companies returning the favour because it's the 'right thing' to do.
>Struggling to come up with a single category of software where this would merit derivatives include source sharing provisions in the license.
Any project where you want to be able to benefit from any enhancements made to the code of the original project, including any derivatives/forks.
They're not totally unrelated to the license - all the good code is GPL, and hardware manufacturers sometimes would rather create an insecure software solution than use GPL code. If somewhat good BSD code is available, manufacturers will use it instead, and it will reduce the attack surface of many embedded systems.
Yeah, like the Apache web server, OpenBSD, OpenSSH, most of the software released by the Internet Software Consortium, LLVM, SDL, Ogre3D, Xorg, Python, Perl, Django, V8, Lua, Mesa, CEGUI, JQuery, CURL, Sass, Groovy, and LESS among others.
You're right, all of the good code is GPL -- oh wait, none of those are. I guess that code's no good.
Do you know any such example of manufacturer reimplementing POSIX userspace from scratch instead of using GNU coreutils or Busybox?
Sometimes vendors do not use POSIX userspace altogether by providing big-proprietary-init blob (LG TVs do), but that's irrelevant to Busybox vs Toybox debate.
