I am sympathetic to people who prefer BSD-style licenses for many reasons, including simplicity, GPLv3 overreach avoidance, and even just declining to give attention to a certain obnoxious man (regardless of what you think of the politics).
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.
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.
That analogy is a bit flawed. People who can't legally combine the GPL with other projects had to make the conscious decision of choosing an incompatible license. If you acknowledge the idea that there are no non-universal recipients or donors in software, then it makes more sense to use copyleft.
I'm not too sure what you're trying to say here. "If you acknowledge the idea that there are no non-universal recipients or donors in software..." ?
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.
If you release your software under copyleft, and someone else can't use that in another project because they chose an incompatible license, the "hindrance" is entirely their fault, not yours.
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
One persons restriction on what developers can do is another persons "Never able to access the source to devices I own"
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.
The GPL and proprietary licenses are both about controlling what other people can do, just in opposite ways. They each address the fear that other people won't play nice. The BSD license sits in the middle and is about trusting people to make good decisions. The trust extends so far that BSD code can be converted to the GPL or a proprietary license.
Do embedded device vendors deserve our trust to make good decisions ? They don't display outright malice, but they are institutionally set up to abandon software after a few years, as software maintenance is only ever a cost center.
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.
Are you actually comparing Darwin vs Linux, or OSX vs GNU?
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.
Darwin is an OS (the kernel is called XNU), so I was comparing it to Linux-based OS's. Darwin is the basis of both OS X and iOS. I agree that whether or not proprietary or copyleft is better or worse for a given situation is hard to say. A BSD license simply leaves the door open.
GPL isn't about control in the way proprietary licenses are, since it grants rights beyond what you would get with no license at all, while proprietary licenses take away rights you would normally have under copyright.
Both the GPL and BSD licenses give developers that want to build on software others wrote rights that they do not have by default.
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.
No. The GPL is about the users. It empowers those who use the software to have access to the source and in case they are so inclined (say, the developers are a bunch of tools that don't listen to the needs of the users), to be able to run away with the code and continue with real user oriented development. That is, a fork.
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 agree with that first paragraph. My main disagreement is about your use of 'No'. I don't see how what you say contradicts what I said. Care to explain?
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.
The GPL is not about control, it's about freedom. It gives you all the rights necessary to preserve the four freedoms. The only thing the GPL limits is power; it does not give you the power to take those freedoms away from anyone else.
Because the limitations on power apply to everyone. If neither you or I have power, then neither of us have control over the other. We both stand on the same ground.
If the copyright holder has the same amount of power as the licensee, why does the FSF require copyright assignment for GNU projects?
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.
So your language here is the language of control: "enforce", "disable", and "attack" prevention.
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".
The view of the FSF is that, in the case of software, that power discrepancy is morally wrong. So copyleft was established as a method to disable it.
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.
Sure, the GPL is more permissive than simple copyright, but it's much more restrictive than BSD-style licenses. The GPL is controlling (compared to a BSD license) in that it seeks to ensure freedom, a proprietary license is controlling (compared to a BSD license) in that it seeks to ensure profit.
> Now if someone takes your permissively licensed code and makes it proprietary, THAT is a real hindrance to users of that software
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.
If a proprietary company decides to modify and distribute GPLed software, then I would say they have been persuaded into a good business decision, because their users will have freedom with that software.
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.
By that logic, the FSF created a pseudo-proprietary environment where code from several notable projects including the Linux Kernel, have no way of using code or even migrating to the GPLv3.
I don't blame anyone except the FSF for this massive oversight in license compatibility.
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.
What oversight? They recommend licensing as GPLv2 "or later", but the Linux project didn't accept that, since Linus doesn't like the GPLv3. How is it the FSF fault?
No, but the GPL already included a "or any later version" clause if the copyright holder wanted to make use of it. Were they supposed to force people to accept it to use the GPL? If not, how is it their fault?
I like that self-hosting is a focus; I'd love for Android to become self-hosting and have some good development tools (and I believe that good tools would be much easier if Android ran regular java code and didn't require dexing -- incremental compilation is made much harder by this [over] optimization).
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...).
Funny how this project with the BSD license is so anti-BSD (yeah, BSD users are 'busybox-envious', amongst other things). Fails to notice the presence of a large number of BSD-licensed userland tools, in the BSDs, while denigrating as many similar projects as possible (linking to inaccurate, flame-bait anti-Perl articles as a bonus).
I got to know Landley fairly well on IRC over a course of a few months, he was a really clever fellow. At the time Toybox was just in it's infancy, glad to see it maturing.
There use to be a little DOS GUI program called ToyBox. My dad installed it to allow easier access to stuff installed on our computer for my siblings and I.
I only watched a bit, but isn't the idea that "phones become disruptive" contrary to other expectation, of ubiquitous computing? Needing "your device" to be self supporting seems to hearken back to rare computing.
(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.)
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.