However, the individualist in me really likes being able to install my own software on my own hardware. The GPL license, specifically in the areas of a system needed to boot and minimally run, has successfully helped me do this several times in the past, by pushing vendors to deliver source for something that they probably wouldn't have otherwise. It doesn't always work, and it isn't perfect, but it has worked in some cases where seemingly nothing else would have.
As long as this continues to be the case, I won't celebrate the replacement of busybox for licensing purposes.
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)
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.
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.
"...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.
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.
all the good code is GPL
You're right, all of the good code is GPL -- oh wait, none of those are. I guess that code's no good.
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.
Nevermind, found it here:
I'm very curious how it will turn out as I favor BSD/ISC over GPL for the same basic reason as well :
In the absence of universal receiver, go to universal donor (BSD/PD)
My perspective is that of a donor; not a receiver. I want to ensure that what I create has as few hindrances as possible in terms of adoptability and the last thing I need is the license (which has no bearing whatsoever on the actual functionality of the work to begin with) to get in the way. And I've seen it get in the way of plenty of other past projects.
Now if someone takes your permissively licensed code and makes it proprietary, THAT is a real hindrance to users of that software, and while it may not be your fault directly, you had the power to stop it because you are the copyright holder and could have copylefted it. So permissively licensed software actually has more potential than copyrighted software in allowing a license to "get in the way."
'Do as you please and leave the copyright' vs. 'Do as you please, leave copyright, distribution requires sources etc...' Which is more permissive? "Permissive" in your sense of the word is entirely a misnomer since it's effectively a permission whitelist not a blacklist.
This is getting to be entirely repetitious since I've had this discussion many times before. I'll let an old post explain why I can never in good conscience put GPL on anything I do : http://eksith.wordpress.com/2008/11/24/gpl-vs-bsd
I'm sure you have your reasons for disliking the GPL. Many of us love it for those very same reasons, and for the freedom it grants to everyone, not just the immediate recipient.
Unfortunately management doesn't care about this aspect of their business, and has to be dragged kicking and screaming to a world of user-upgradeable software.
Proprietary software has many advantages over Free - heavier corporate investment creates more consistent and polished results. But that doesn't imply that it's better for all purposes, or that a new project is better off choosing a license that makes easy to incorporate into proprietary products.
However, compared to BSD licenses, the GPL gives fewer rights to those 3rd party developers. It also gives users of the software those developers write rights. BSD licenses, on the other hand, leave it to those developers to decide what they want to give their users.
So yes, the GPL isn't about control in the way proprietary licenses are, but it is about control.
This "the GPL gives developers power" is pure FUD that showed up in the 90's as part of the reactionary trantrums throw down by some BSD groupies and by ESR and his gun-toting friends who wanted to sell Free Software to the corporate world, so they corrupted the term and invented Open Source. It just so happens that developers are users too.
So, if you want to strike it rich with open core, sure, you choose a lax license, say MIT or Apache, or even better BSD 2-clause, and when the suckers have implemented all the features and ironed out the bugs, you run away with the code, sell your startup and more power to your bank account in the Caiman's. Right?
So, no. The reason why the corporate world uses the GPL instead of the BSD license for the really important stuff is because it creates a level-playing field. It is the same situation as the Cold War (perhaps you are too young to remember its lessons?): "If you and I can blow each other to bits and take everybody else with us in the process, let's stop and rather do some conquering and plundering together, shall we?" And that's exactly why the mobile space is a nasty, miserable world of patent lawsuits: There are no mutual assurances of total, generalized annihilation if someone doesn't want to play by the rules. Patents are just not it; ask the Chinese.
I won't comment on paragraphs 2 and 3, because they, to me, look more like opinions than factual discussion.
The last paragraph, similarly, IMO is not built on facts. "The corporate world uses the GPL" certainly isn't uniformly true. To mention one example: from what I can see, a C compiler is part of the "really important stuff" and clang is more popular than gcc for new developments.
Copyright holders retain all of the power granted by copyright. The GPL grants only some of that power to licensees. A BSD license grants almost all of it.
- Only the copyright holder can effectively enforce the license on a particular piece of software
- They are in a better position to enforce the GPL than most users
And yes, the reason for the existence of copyleft is specifically to disable the powers granted by copyright that can be used to attack the users' freedoms.
The point is simply that there is a power discrepancy between copyright holders and everyone else, and that by limiting power the copyright holders are exerting control over what happens to their creative expression.
I don't really understand why this is contentious, I just see it as a fact about the GPL. The FSF routinely refers to BSD-style licenses as permissive, which means the GPL is restrictive in comparison. "Restrictive" is another way of saying "controlling".
In this context we don't consider "restrictive" as the opposite of "permissive." The ones who are trying to restrict users are the proprietary software companies. We need to use certain language to draw attention to this because proprietary software developers are trying to downplay the fact that they are restricting their users. The only reason the GPL is not "permissive" is because it does not permit them to restrict users.
I look at it as decent screening process. If the only reason the person / company is returning the changes is the license, then it is very probable that I don't really want those changes or to work with them.
Its also a really poor business decision on their part (yet another good reason to not deal with them). They will spend time on their fork and have no influence over the direction of the code.
You don't need to work with anyone that you don't want to. The GPL doesn't have a requirement that you need to submit pull requests. All it requires is that if you distribute binaries, you must also distribute source code to anyone who asks, so that the users can have freedom. And if the users have freedom, then anyone can have as much influence on the direction of the code as they want.
Landley speaks to this in his Toybox presentation, noting that the forced source code contributions resulting from the Busybox lawsuits were absolutely worthless.
They also haven't solved that LibreDWG issue yet, even though they hold all the cards and it would be of literally no effort on their part to fix this mess.
It seems like with qcc he's focused on self-hosting toybox rather than the system upon which it runs... (also linking big projects like WebKit takes a lot of address space; last time I tried I was unable to link a debug WebKit on a 32bit machine...).
(I think I'd like to see better communication between devices, with the expectation that a real Linux development machine will be trivially cheap from here on out.)