Post a Comment
Branching means to seperate, ie: forking. You take what you can from the original project and move forward in your own direction.
Merging mean to join, when two projects have similar goals and fairly compatible code bases they can merge and work together on one project instead of two seperate ones.
BSD encourage 'branching' [forking] and GPL2 encourage 'merging' ?
So why there are thousands of Linux Distributions [forks] and only several BSD Distributions?
In what way BSD encourages forking? Because it is more free then GPL2?
GPL2 oriented projects love to fork, all those media players, beryl/compiz, window managers and many many many more.
Is it only me see that that way?
Yes. Because once you have forked and released your modification under a new incompatible license, there is no way to merge your modification back.
That is only the fault of the person that changes the license, not the BSD licence itself, it allows you to do that which gives you more freedom but its your fault if you changed license and now your code cannot be merged back.
Consequence.
There are hundreds of Linux because people differ on what parts should be present by default, what VERSION of the kernel should be in use, how the initialization should be handled, what patches must be applied, how upgrades must be handled and finally what is the best "layout" of the fs. You can think this is a fork but the basic components are all the same: Linux kernel and GNU userland tools (gcc, glibc, and so on).
That is different from *BSD side as there are different kernels playing there.
Note that I'm not counting different kernel versions as different kernels (what have their own counterpart on *BSDs too).
So, if you ask me if GPL tend more to merging than to branching I would say YES, there is just one kernel and mainly one userland on Linux camp if you care to inspect (in the sense I said).
If you really want to compare *BSD to what we call linux, do it the right way and compare it to a particular one, like RedHat, SuSE, Debian or (even) *buntu.
I don't want to start a flame war here but, the way I look at things, there is a fundamental difference between GPL and BSD licenses and they are not related to how it affect final users but, instead, who would want to contribute to the projects. Hardware and service companies where software are addendum or cost tend to choose GPL as any contribution/improvement will come back. But if the software is very important (main differential) in their products they probably will develop their own version or grab parts under BSD license with little chance to come back to the community. That is why you see big companies putting a lot of money on Linux and not that amount on *BSD: every penny allocated on Linux will show up, on BSD we just don't know (even if was more money).
Also, I mostly side with Linus. There are conjectural politics on one side and real politics and real world on the other. I have a high respect to RMS, GNU and FSF but try to be a bit more linked to reality where I think any cooperation is better than total isolation. This way we can change the world a bit every time, instead of try to create a new one. The history had showed that the former approach is the one that works as at any time there are always disagreements.
Last, I have been using FreeBSD since 4.3, Slackware since 8 and RedHat since 5, promoting and loving them all.
I'd not say it's about licence, and branching/merging can happen under any compatible licence - and is a merely technical operation.
Under this respect GPL is even more restrictive, as it is compatible with GPL only, admitting that you redistribute the program.
The fact that gnu/linux has more variety in distribution depends on it's "frankenstein" nature, compared to BSDs. Linux is a kernel, then you have to choose a userland - no real standards here, and many different choices / preferences. BSDs instead have a longer tradition and are more standardized in this respect - userland included.
Wether you like it or not, it's about taste
But not about the licence itself, imho.
And to be back on-topic, I agree with Mr. Torvalds : I do not like a software licence that prescribes something about hardware.
Edit: rearranged a bit the text
Edited 2007-06-19 09:01
it's just the oposit. You create two branches of a project, by forking them. Like we have ProjectA and you don't like something, you create ProjectA+ that is a fork of my ProjectA.
Merging, would be when i take the modifications you did to ProjectA+ that i like, and merge them back to ProjectA, or viceversa.
versions evolve in a tree-like structure. however, unlike tree-ish structures, often one or more branches might blend together into a single branch.
a branch is an active line of development. there might be several of them.
to merge is to bring the contents of another branch into the current branch.
http://www.kernel.org/pub/software/scm/git/docs/glossary.html
RE: Branching vs. Merging
In order to distribute someone else's code under GPLv2, you must provide a royalty-free license for any of your patents which affect that code.
For example, I release some code under the GPLv2. You use my code and modify it in a way that makes it subject to your patent. You only have my permission to distribute *your* code, which includes *my* code, if you conform to the terms of the GPLv2. Those terms include granting the free use of your patent to anyone who obtains your code under the GPLv2. If you want to charge royalties for your patent, then you can't distribute my code. If you want to charge royalties to people who aren't using the GPLv2 code, go right ahead.
DRM is a broad subject. Using crypto techniques to control what may execute on a computer is a useful technique. The problem is who decides what's allowed. My belief is that DRM is good when controled by the owner of the computer, and bad when it takes control away from the owner and gives it to someone else. The RIAA/MPAA want that control. Once more, control isn't the problem, it's who has control.
Nothing about DRM prevents merging branches back together. It may prevent *running* the merged code on a particular piece of hardware. But the code is available to everyone, and may be used elsewhere. That's what Linus cares about - changes to the code are available to anyone who wants them. If you buy hardware that won't run certain code, that's an issue with the hardware, not the license of the software. If you don't like closed hardware, and I don't, then don't buy closed hardware. But closed hardware does not prevent the software from evolving, which is the most useful feature of the GPLv2.
Torvalds believes in share and share alike code: Here is my code, if you want to distribute copies of it, you should also contribute your modifications. He believes that the GPLv2 is good enough to ensure this. Why does he need to agree with what the FSF says about software morality? If an entity is offering something that is perfect for your requirements, the only reason to reject the offering is to make some sort of statement to that entity. Torvalds doesn't need to accept the FSF's philosophy to accept the terms of GPLv2.
>Torvalds believes in share and share alike code: Here is my code, if you want to distribute copies of it, you should also contribute your modifications.
No problem beside that the GPL doesn't require to give back modifications.
>He believes that the GPLv2 is good enough to ensure this.
That's OK, too.
>Why does he need to agree with what the FSF says about software morality?
He doesn't have to agree.
The problem is, that Linus interpret the spirit of the GPL by reading the GPLv2 legal text and map it to todays situation. And than claim that his interpretation is the spirit of the GPL.
But to understand the spirit of the GPL you have (a) listen to FSF because they are the author of the license (that doesn't mean that you have to agree) (b) read the preamble of the GPL (c) interpret the GPL in the context when it was written and not in todays context because todays world is different.
If you do this you will see that GPLv3 makes perfectly sense. That doesn't mean that you have to like it or to support it. But you have to admit that GPLv3 and their author keep the spirit known from the beginning.
It's basically the same if i would read an essay from Linus Torvalds and than try to convince him that my interpretation of his essay must be his intention to write the essay. The only way to understand his intention to write the essay is to listen to him. I don't have to agree and i can still have my own interpretation but i can't tell Linus what was his intention. But this is exactly was Linus tries to do.
>Torvalds doesn't need to accept the FSF's philosophy to accept the terms of GPLv2.
Right.
Edited 2007-06-16 15:24
I find Linus' arguments about the BSD license vs. the GPL to be a little misleading. How many people are running a "vanilla" official Linux kernel without some sort of patching? If you're running *buntu, (open)SuSE, Red Hat, or Fedora, you can put your hands down now. That's just the kernel, I am not counting distributions. I consider this to be "branching".
Now, it is true that on the BSD side of things we have FreeBSD (PC-BSD, DesktopBSD), NetBSD, OpenBSD, Darwin (Mac OS X). However, there is an immense amount of code sharing and cooperation between the members of the BSD family. For example, various wireless network drivers written for OpenBSD (easily the best wireless support in the open source world) have been ported to FreeBSD and NetBSD with relative ease. This would be a great example of "merging".
Frankly, I don't think the differences between GPLv2 and the BSD license really affect the likelihood of branching and merging very much at all in real life.
...various wireless network drivers written for OpenBSD (easily the best wireless support in the open source world) have been ported ...
Best?! Well, not if you talk to OpenBSD developers, it isn't. Is WPA even supported? Yes, I know that OpenBSD people does not believe in encrypting Wireless stuff since they think VPN is the way to go. Apparently the rest of the people disagrees by their actions. While that works nicely when you are using you own setup, it gives you immense problems accessing other open access points.
On BSD, I find Linus strange. While he agrees that sharing is the way to go, he feels that he needs to tell people what to do by forcing them (through GPL). Luckily, people that believe in the BSD principle, share without restrictions, does not and the OS-world is a much better place than it would've been without BSD. I see no shortage of code merging into FreeBSD so obviously people act differently from what Linus fears. It is a bit like freedom of speech, it is the right to speak those words you disapprove of that needs to be protected, not the opinions you agree with. I believe in completely free and open software so I will defend your right to freely branch and modify it. I will of course encourage you to share the modifications but I will not force you to do so as it is your code (only the modifications, the original source is as free as before, an incredibly common misunderstanding by some "GPL-only" pundits). I do see a place for GPL software, but for me it is an extremely poor choice for an OS-license. Feel free to disagree
Edited 2007-06-16 00:17
And what's the problem with that?
The problem is you end up with umpteen different, incompatible versions of something.
Pick the license that suits your needs.
I think most people need to ensure that their work won't be taken advantage of by other people without those other people giving back. Thus, the popularity of GPL and Linux.
"""
On BSD, I find Linus strange. While he agrees that sharing is the way to go, he feels that he needs to tell people what to do by forcing them (through GPL). Luckily, people that believe in the BSD principle, share without restrictions, does not and the OS-world is a much better place than it would've been without BSD.
"""
Linus is not strange about BSD. He feels that if one makes their hard work available for others to use, he has the right to expect "tit for tat".
I sometimes find Theo a bit strange about BSD because he gives people the freedom not to give back and moans when some choose not to.
But don't take that as a criticism of BSD. Because copyleft licenses have the nasty side effect of sucking up OSS code from other free projects without giving back.
"Compatibility" in the GPL world, means "we can take from them". Usually, they cannot take from us. But few people of the copyleft mentality seem to seem a problem with that.
In the insterest of full disclosure, I should say that I like copyleft. I even like the new extensions that come with the GPLv3. (Though, as always, I'm more concerned with the GPLv3's divisive aspects than I am with the refinements in it.)
But I do respect the BSD philosophy, even if I do sometimes call it the "rape me" license.
In the end, I think that we are stronger for having different classes of licenses available. And note that I say "classes of licenses". I do not think that rampant license fragmentation is good. But BSD and Copyleft represent two substantively different views of freedom. And I believe that we are stronger for having a choice at that level.
But I do respect the BSD philosophy, even if I do sometimes call it the "rape me" license.
A better way to think about it is the giving license. You give to others instead of expecting money or source code in return. You can still hope others will share back. That is not hypocritical. BSD is the soup kitchen of licenses. 
I find Linus' arguments about the BSD license vs. the GPL to be a little misleading. How many people are running a "vanilla" official Linux kernel without some sort of patching? [...] I consider this to be "branching".
Linus explicitly states that branching is a prerequisite for merging. He never claims that branching is undesirable. He merely suggests that merging is more interesting and more productive than branching.
Frankly, I don't think the differences between GPLv2 and the BSD license really affect the likelihood of branching and merging very much at all in real life.
The reason why developers and projects use branching is to take existing code in a different direction. With BSD code, the possibilities are almost endless. But with GPL code, there are rules for what you can do with the code. This makes branching less attractive in the GPL world than in the BSD world.
That's not true. There is no rules in GPL in regard to what you can do with the code.
You can do anything you want. Even use it in proprietary products. The rules only kick in in regard to distribution, but that is irrelevant in regard to what you can do with the code.
From a philosophical point of view I prefer the BSD- or MIT-license - from a pragmatic view I prefer GPL. The latter one is a requirement as long as fundamental rights are not protected.
There is no rules in GPL in regard to what you can do with the code.
The rules only kick in in regard to distribution, but that is irrelevant in regard to what you can do with the code.
That doesn't make sense. Distributing the code is doing something. Unless you meant that distribution was the exception.
>That doesn't make sense. Distributing the code is doing something. Unless you meant that distribution was the exception.
Read "what you can do with the code" as "the freedom to run the program for any purpose" which is freedom 0. This is what you do with your copy on your devices. Distributing is something different that's also why we have different words for it in our language. You can do with your copy what you want but you can only distribute copies if you can give your recipients the same freedom you had. If you don't want to give your recipient the same freedom than you can't distribute the software. That's copyleft.
Edited 2007-06-17 21:10
Distributing the code is not doing something with the code.
Doing something with the code is using and modifying it. Distributing the code has nothing to do with what you can do with the code.
It is possible to distribute the code without doing anything with the code and it is possible to do something with the code without distributing it.
[i]Frankly, I don't think the differences between GPLv2 and the BSD license really affect the likelihood of branching and merging very much at all in real life.[i]
With GPL2 you must make your improvements available if you distribute your code, whereas with the BSD license you need not (although you certainly may)
I don't typically take the RMS/FSF side of things (at least completely), but Linus really comes off as an uninformed (or paid off by Tivo) asshat in that thread. Seriously, how many times did he trot out the "They can do as they like with *their* hardware" shit, before someone had to point out that it became the consumer's hardware the minute they bought and paid for it?
He clarified that. The *design* of the hardware belongs to TiVo, and is not under the GPL. Some of the software included with the product is under the GPL, some is under other licenses.
The fact that GPL software is included does not put the other software or the design of the hardware under the GPL. RMS may want all software to be under the GPL, but copyright law doesn't work that way. It is perfectly legal to include (aggregate) GPL and non-GPL software on the same system.
If you buy a TiVo, you own it. You can get the source for the kernel. You can modify the kernel. Run that kernel on your own hardware design, or hack your TiVo so that it will run unsigned code. But TiVo is NOT obligated to provide you with the source for the hardware design, or the other code, or anything else.
I don't own a TiVo, because I dislike closed hardware. That's why I use MythTV. But Linus is right when he points out that RMS is trying to extend a software license to cover hardware. That's not right, and it's likely to create problems.
GPLv3 uses a software license to impose conditions on the hardware that the software runs on. Sony used a rootkit to impose conditions on computers that audio CDs were played on. In both cases, the copyright for one element is being abused to control the behavior of systems which are NOT under that copyright. The copyright on the music on a CD should not have ANY effect on the system it is played on, and the copyright on a program should not have ANY effect on hardware it runs on.
Tivo distributes modified GPL software when selling their devices. You cannot modify and run that software on the device. The GPL intends to make sure GPL-ed software can be modified and run. The only way it can be run now is to have a modified Tivo-device without the locking. It cannot be run on the Tivo device as bought. Linus thinks that is OK, the FSF thinks it's not, and they are authoring the license, so they wrote v3. The GPLv3 would protect software better from a user's point of view, so I am all for it.
Tne author of the GPL intends this ability to modify software in place, but clearly the license does not require this and the author of the GPLed software (well, at least the bulk of it) does not believe in this. Seeing how the copyright holder has more rights over the kernel than the owner of the license, I think Linus has every right to choose a different philosophy for how his code is used.
Frankly, the FSF should just get a new kernel if they're in so much pain of Linus' decision. I, for one, would love to see them choose a GPL3 Solaris... competition of the kernel crown in the FOSS world will probably cure some of the Linux follies.
As long as they follow the GPL for the software they are using, I don't see what the operation of their hardware has to do with it. Using a software license to regulate hardware IS a bit crazy talk.
What happens if someone uses a ROM so it's electronically impossible to change the software? Does the FSF sue? 
But Linus is right when he points out that RMS is trying to extend a software license to cover hardware. That's not right, and it's likely to create problems.
Distribution has always been a central concern of the GPL. The Tivo device is a means of distribution. Thus, it is entirely appropriate that if Tivo wants to distribute someone else's GPLv3 software, Tivo must agree to the distribution terms or just not distribute the software. What's not right about that? "Creating problems" does not mean much. Many good things are done that end up creating problems. I may sign up for a tough class that will create problems for myself, but that fact alone does not at all throw my decision into doubt.
GPLv3 uses a software license to impose conditions on the hardware that the software runs on. Sony used a rootkit to impose conditions on computers that audio CDs were played on. In both cases, the copyright for one element is being abused to control the behavior of systems which are NOT under that copyright.
This is too simplistic an attempt at associating the GPLv3 with a notorious event by finding something in common. It's easy to come up with such arguments. E.g., the U.S. used power to defeat the Axis powers. Japan used power to commit genocide in China. In both cases, the laws of one nation are being used to control the behavior of nations which are not under their laws. The laws of one country should not have ANY effect on the behavior of other nations.
Is hardware somehow more sacred than nations?
We also could as easily find all the ways that the rootkit is worse. It relied upon deception, done on a machine having absolutely no pre-planned connection to the rootkit (unlike the means of distribution that a Tivo device is), etc.
We are probably ignoring some other important cases where copyright influences hardware behavior. Perhaps those who are more familiar with proprietary systems than I am can recall some examples. In any case, I don't see how the GPLv3 is anything special in this way, and, again, it is merely a choice that anyone, of course, is entirely free to ignore.
Moreover, there are the four freedoms that any GPL is designed to promote. Why must they be sacrificed in order to placate some manufacturer? The FSF would fail in its mission if it had not responded to Tivoization by banning at least some (but not all, it turns out) forms of it in the GPLv3.
TiVo has agreed to, and obeys, the terms of the GPL for all of the software they distribute using that license. It is not right to apply those terms to the other software, under different licenses, which they also distribute in the same box. Copyright law distinguishes aggregation from derived works.
TiVo distributes the Linux kernel under the GPL. Because the GPL applies to the kernel, they also license the drivers that they wrote under the GPL. The drivers are linked, making them derived works of the kernel.
Other software is included in the box. That software is not licensed under the GPL. I would like it to be, but there is no legal obligation for TiVo to license separate programs under the GPL because they happen to run under Linux. Those programs are merely aggregated with the kernel, which does not make them derived works.
It would be counter-productive to require all software on a computer running Linux to use the GPL. No current Linux distribution would qualify. My Debian systems may run only freely-licensed software, but the GPL is not the only free license. Such a requirement would also fail in court. Copyright law understands derivation, not contagion.
The ends do not justify the means. Coercion is bad when Sony does it, and when the FSF does it. Version 2 of the GPL does not coerce, because it applies only to the software that the license is attached to. Accept or decline the license, and it only affects the program itself, not system it runs on. Sony's copyright on some music does not give them the right to dictate the operation of the device I play the music on. The FSF's copyright on gcc does not give them the right dictate how I manage keys on my hardware. The copyright on the music applies ONLY to the music, and not the player. The copyright on a program applies ONLY to the program, and not the hardware it runs on.
I agree with the goals of the FSF, but think that they've made a tactical blunder with the DRM portion of GPLv3. The other changes are worthwhile improvements.
Using a license to promote the freedom of the licensed object is great. Using a license to promote freedom of other things which come in contact with the licensed object steps over the line. Version 2 of the GPL stays firmly on the right side of the line, and recognizes that while world peace and ending hunger are worthwhile goals, restricting the USE of software in fact reduces freedom. It covers only distribution, not use. There are better ways to end hunger, and better ways to promote open hardware.
It would be counter-productive to require all software on a computer running Linux to use the GPL. No current Linux distribution would qualify. My Debian systems may run only freely-licensed software, but the GPL is not the only free license. Such a requirement would also fail in court. Copyright law understands derivation, not contagion.
You have got the wrong end of the stick here, entirely.
The point of "anti-tivoisation" clauses in GPL3 has nothing to do with non-GPL software on the TiVo. There is no requirement at all to make "all software on a computer running Linux to use the GPL".
The "anti-tivoisation" clauses in GPL3 simply mean that it is not permissible for a vendor such as TiVo to distribute any software which IS GPLv3 software in such a way that the end user may not change it.
The ability of the end user to alter the GPLv3 software is one of the four freedoms. If TiVo want to use some GPLv3 software elements as part of their product, then they are distributing those GPLv3 software elements, and so then TiVo have no right under the GPLv3 license to remove that freedom of the end user (aka as the downstream recipient) which is granted by the license.
Remember, the GPL software in the TiVo is not TiVo's software, it is GPL software. We are talking here only about the bits of software in the TiVo which are GPL software, and we are not talking about any of TiVo's own software.
Please bear in mind that the GPLv3 license applies only to software which is distributed (by the original author) as GPLv3 software. The GPLv3 license is intended to preserve the freedoms of the license for all recipients of that software. The GPLv3 license does not apply to any other software bundled together in a product, it applies only to the GPLv3 software.
Why, exactly? What exactly is wrong with the DRM portion of GPLv3?
The DRM portion of GPLv3 says only that one may not apply DRM provisions to software that is GPLv3 software, so that the end user loses rights to the GPLv3 software.
GPLv3 software does not prevent DRM per se, and GPLv3 is entirely silent on what anyone does with software that is not GPLv3 software.
Edited 2007-06-16 06:49
Where does the GPLv3 ever mention anything that is NOT GPLv3 software? There is no coercion involved. If you want to use GPLv3 software, you may not use (harware or software) DRM to apply to that bit of software. That is it, period. There is no coercion involved, if you want to apply DRM to a complete system, then go ahead ... just don't use any GPLv3 software as part of that system. If you want to apply DRM to music on a system that in part uses GPL software, then go ahead, just don't apply the DRM to the GPL software itself.
Of course not. The FSF does have the right, however, to say that you cannot distribute FSF's software with DRM applied so that downstream recipient's cannot change the FSF's software.
I would point out to you that TiVo's right to make hardware and DRM systems does not extend to TiVo applying that DRM to FSF's software.
Correct. The copyright to FSF's software belongs to the FSF. Hence the FSF then get to say what the terms are for distribution of FSF's software. Their terms are that you may not apply DRM to their software, so that downstream receipient's of the FSF's software cannot further change it. The FSF say nothing at all about anything belonging to anyone esle.
Please point out where there is any coercion at all in the GPLv3 license. There is no such coercion. No-one is forced to do anything. The GPLv3 license gives recipients of GPLv3 software permissions to use the software covered by the license in certain ways (if they want to), and it sets out certain restrictions on that use. One of the restrictions is that you may not distribute the software you receive under the GPLv3 to downstream users in such a way the the downstream user has more restrictions than you have.
Edited 2007-06-16 07:54
something as trivial as software
I haven't read what you respond to, but trivial? Software runs almost any infrastructure our civilization builds on. In no way is it trivial. If we don't have a democratic control over our software our civilization will once again lose control to a small owner class.
I'd say the FSF guy comes off as a doofus. Especially when he tries to push the old 'fair use' chestnut. The doctrine of fair use says that, IF you happen to be able to do the following things, they cannot be considered breach of copyright. It doesn't say _anywhere_ that content providers or hardware manufacturers are obliged to make these things possible, or even that they are obliged not to intentionally attempt to stop you doing them. The FSF guy's argument is clearly specious in this area.
From Linus:
There is *NOTHING* stopping you from doing whatever you want with the code that runs on a TiVO (or any similar device). You (and everyone that thinks like you) are confusing a want to use the *HARDWARE* however you want with your GPL granted "right" to do what you want with the *SOFTWARE*.
and
And that's my opinion. THINK about that for a moment. THINK about the fact that I am the original copyright holder in the main software project they used, and that I state that as neither having ever gotten paid _or_ owning any stock what-so-ever in Tivo.
Dammit, if I cannot say that I think what they did was fine, who can?
This argument should just die. RMS is against Tivoisation, so the FSF is free to do whatever they want with v3. Linus supports Tivoisation, so he's free to choose the license that best represents his objectives.
Anybody that disagrees with Linus and the kernel devs about the Tivoisation issue should start learning to code and start working on Hurd. The sad part is that this thread started with Linus coming as close as ever to a concilliatory attitude towards v3, but then the FSF proponents managed to remind him of why he dislikes them so much.
Anybody that disagrees with Linus and the kernel devs about the Tivoisation issue should start learning to code and start working on Hurd. The sad part is that this thread started with Linus coming as close as ever to a concilliatory attitude towards v3, but then the FSF proponents managed to remind him of why he dislikes them so much.
That's just disrespectful toward contributors to the kernel who simply do not agree with Linus about v3. Some of these contributors may not particularly like the FSF but still may appreciate seeing their concerns addressed in a way that Linus seems to dismiss.
Linus is full enough of himself so as to regularly insist that he has his own mind while suggesting that his skeptics do not (e.g., "FSF follower people") when their opinion happens to coincide with that of the FSF. His disclaimer is that he is a blunt a**hole, but that cute self-deprecation works only to a point. Frankly, it's just a stupid and tiresome distraction.
Fortunately, Linus does a lot of good when it comes to technical issues. He also seems to be an entertaining writer if you overlook all of his silly abuse. However, there needs to be a counterweight to his abusive and sloppy-to-the-point-of-perhaps-deceitful rhetoric.
Anybody that disagrees with Linus and the kernel devs about the Tivoisation issue should start learning to code and start working on Hurd. The sad part is that this thread started with Linus coming as close as ever to a concilliatory attitude towards v3, but then the FSF proponents managed to remind him of why he dislikes them so much.
That's just disrespectful toward contributors to the kernel who simply do not agree with Linus about v3. Some of these contributors may not particularly like the FSF but still may appreciate seeing their concerns addressed in a way that Linus seems to dismiss.
Not really. It's their choice to contribute to Linux, to Hurd, to BSD, or to any other project. Linus has made it very clear where he stands. You're free to contribute under that understanding, or not.
You can even take a BSD kernel, make you own changes, and release it under a totally different license of your own creation, if you like, to address those concerns you have.
I find myself pretty put off by Linus' lack of social skills, but I also have to agree with his basic argument. He knows what he's doing, he knows what he wants, and he knows what works for him. You can join him, or not.
I also like the idea that his approach is not us vs them. That's what I don't like about rms.
That said, I think GPLv3 is probably the better license, and I am not as blase' about Tivoization as Linus is. It'll be interesting to see how Solaris develops under GPLv3.
Not really. It's their choice to contribute to Linux, to Hurd, to BSD, or to any other project. Linus has made it very clear where he stands. You're free to contribute under that understanding, or not.
True. However, this does not at all rule out the justification for the understandable concerns that are raised on the list. Linus or anyone else, of course, is entirely free to ignore those concerns.
I also like the idea that his approach is not us vs them. That's what I don't like about rms.
That depends on who "us" and "them" are. Moreover, there is nothing inherently virtuous about such accommodation--we need only look at history.
Indeed, the differing approaches are nothing more than logical consequences of two different philosophies with different goals: (1) Linus and open source and (2) RMS and free software. (1) leans more to marketshare, whereas (2) leans more to freedom. Although (1) and (2) are mostly on the same side, there are inevitable conflicts, and we should all realize that siding with one or the other entails a preference for one goal at the expense of the other.
We could replace Linus and RMS and the "us vs them" difference would necessarily remain, regardless of who replaced them. That being said, I am put off by both in their lack of social skills, but there are certainly bigger issues.
You can even take a BSD kernel, make you own changes, and release it under a totally different license of your own creation, if you like, to address those concerns you have.
Hold your horses buddy. You can't relicense BSD licensed code!
Copyright (C) 1992-2007 The FreeBSD Project. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
You can even take a BSD kernel, make you own changes, and release it under a totally different license of your own creation, if you like, to address those concerns you have.
Just to clarify, only the MODIFICATIONS will have that new license. The code you used that was under BSD-license will still be under the BSD license.
No you may not. You can use it as part of another project as is, and make modifications to it and not have to distribute them, but you must license the original bits as BSD.
Edited 2007-06-16 12:57
Given the controversy and debate surrounding v3, do you think the FSF will respectfully consider dual-licensing the GNU projects to maintain v2 compatibility when v3 is released?
No? Why not? Oh, I see. The primary maintainers/copyright holder of the projects, that being the FSF, has their own objectives with their code and will select the best license for meeting their objectives, regardless of how the developer community at large feels. Is that wrong? Are they being disrespectful to developers that question RMS? Of course not, the FSF has stated all along that the goals for the GNU projects were to promote their interpretation of Free Software via the four freedoms.
Why should Linus be held to a different standard? He never pretended or inferred that his choice of the GPL was for any reason other than ensuring source code is always available. Anybody that thought otherwise should have considered that before submitting code, just as anybody having submitted code the GNU projects cannot really dictate how the FSF should license their code now.
Given the controversy and debate surrounding v3, do you think the FSF will respectfully consider dual-licensing the GNU projects to maintain v2 compatibility when v3 is released?
Where I differed with you was not with what the responsibility of the copyright holder should be but what is appropriate for the community around the project.
If I recall correctly, you suggested that the GPLv3 proponents should shut up and write code for something else, and I reject this type of advice. It sounds like when someone (not saying you) says shut up about U.S. policies or move to Canada.
Edited 2007-06-17 01:21
Yes...he dislikes THEM and that is why he is against v3 as much as anything. That is the part I cant stand. He isn't level-headed IMO.
He had no problems choosing v2 and it was the same people, the same ideals, the same four freedoms, the same hippy then as it is now...
If merging is important, well, I wonder how much code from novell/xandros/linspire will be *merged* now?
>>He had no





