GNU versus BSD

[zenten]

Ok, I'm going to start this off being reasonable *gasp*.

I like the BSD license, in theory. I would generally be inclined to use that license, if I were to make things open.

That being said, I've noticed that most of the software I use, especially larger scale software (instead of just small pieces) is under the GNU license. And that software is also the most popular.

[davean]

I've generally found the BSD kernels to be higher quality then the Linux kernel. And a lot more reliable.

I'm a fan of one firm step forward at a time instead of Linux's "Oh, we broke everything" methodology, and by broke I mean it never fully functioned to begin with.

[zenten]

I've generally found the BSD kernels to be higher quality then the Linux kernel. And a lot more reliable.

I'm a fan of one firm step forward at a time instead of Linux's "Oh, we broke everything" methodology, and by broke I mean it never fully functioned to begin with.

But that could easily be about the monolithic versus microkernel split, instead of being about GNU versus BSD.

[Anpheus]

It's ideological and that's all. BSD people believe their code should be free to be used by anyone, for any reason. GPL people feel that their code should be free to be used by anyone, for some reasons, and you need to package the license and the source with the binary always.

GPL people tend to be really silly about this though, in that if a library is released GPL, they want you to either dynamically link it, or if you statically link, you have to release the whole thing's source. That is, the difference between having to release your program's source code and being able to keep it closed is... a compiler option.

[Ghorthas]

Well it depends on the license there are different kinds of GPL licenses. Not all of them require the same things with libraries. I personally feel that if I spent my free time on software, why should it be made available to a company to just repackage it and make money off of all my work. Whether we want to admit it or not this happens, legally, and illegally. I am not one of those guys who just codes for fun. I have a lot of things on my plate, if I work on some application and a company uses it I want to be compensated for my work. This is why I choose the GPL. I don't have to worry about some company just repacking my software, and if it does happen i can at least have some legal muscle behind my work protecting me. BSD would be better if it didn't lag behind so far on hardware. Also most of the main packages I use in BSD are linux ports anyways. There used to be a large difference in performance. Especially with servers. However, I think that gap has closed to a point where it is only a narrow crevasse.

The license, and the lack of hardware support keep me from using BSD. Fairly antiquated hard ware that I can get working with linux, does not work with BSD. I like BSD, I like the BSD system style much much more than SysV, but the license is too much for me to get around. I'm not willing to have my code used for commercial purposes without compensation. Right now with school, and everything else, I could use all the streams of income I can get.

[EvanED]

GPL people tend to be really silly about this though, in that if a library is released GPL, they want you to either dynamically link it, or if you statically link, you have to release the whole thing's source. That is, the difference between having to release your program's source code and being able to keep it closed is... a compiler option.

The FSF's position is that dynamic linking is enough to require your program to be GPL'd.

Edit: s/GNU/The FSF/. (Hey, at least I caught it before someone else pointed it out. )

[Rysto]

GPL people tend to be really silly about this though, in that if a library is released GPL, they want you to either dynamically link it, or if you statically link, you have to release the whole thing's source. That is, the difference between having to release your program's source code and being able to keep it closed is... a compiler option.

You are skirting a very fine line if you try and release proprietary software that dynamically links against a library that is only distributed under the GPL. In fact I'd go as far as to say that if you do this you're in violation of the GPL: your software is definitely a derived work of the library and therefore can only be distributed under the GPL.

[zenten]

GPL people tend to be really silly about this though, in that if a library is released GPL, they want you to either dynamically link it, or if you statically link, you have to release the whole thing's source. That is, the difference between having to release your program's source code and being able to keep it closed is... a compiler option.

You are skirting a very fine line if you try and release proprietary software that dynamically links against a library that is only distributed under the GPL. In fact I'd go as far as to say that if you do this you're in violation of the GPL: your software is definitely a derived work of the library and therefore can only be distributed under the GPL.

Unless you use the version of the GPL that allows it.

[Rysto]

Are you trying to say that if the library is licensed with the LGPL, then you're ok? The LGPL is a completely different license so bringing it up in a discussion of the GPL is rather a non-sequitor.

[d3adf001]

imo Creative Commons Attribution-Noncommercial-Share Alike is the best because it keeps it from going closed source and stops closed source from using it and stops people that didnt do shit for it from making money from it. free riders ftl.

[pieaholicx]

imo Creative Commons Attribution-Noncommercial-Share Alike is the best because it keeps it from going closed source and stops closed source from using it and stops people that didnt do shit for it from making money from it. free riders ftl.

It never stops it from going closed source. A No Derivatives CC license would stop it from becoming closed source (as long as yours was open, but what's the point then?), but you can put out work under the by-nc-sa that can become closed source, as long as they don't sell it, say you made part of it, and placed their work under the by-nc-sa. However, trying to adapt CC for programs is a tricky road since it was designed as a non-specific license, instead of a software specific license.

[Rysto]

imo Creative Commons Attribution-Noncommercial-Share Alike is the best because it keeps it from going closed source and stops closed source from using it and stops people that didnt do shit for it from making money from it. free riders ftl.

Noncommercial licenses are a death knell for any free software*. If Linux were non-commercial, nobody could use it for anything interesting and thus it never would have seen the development effort it does now. If gcc were non-commercial it couldn't be used to compile for as many architectures as it is now. If MySQL were non-commercial nobody would use it.

Ok, that last one was a bad example.


* Note for the pedants: yes, I know that non-commercial software does not meet the free software guidelines. You know what I'm trying to say here so don't bother nitpicking; I am arguing for your side anyway.

[d3adf001]

imo Creative Commons Attribution-Noncommercial-Share Alike is the best because it keeps it from going closed source and stops closed source from using it and stops people that didnt do shit for it from making money from it. free riders ftl.

It never stops it from going closed source. A No Derivatives CC license would stop it from becoming closed source (as long as yours was open, but what's the point then?), but you can put out work under the by-nc-sa that can become closed source, as long as they don't sell it, say you made part of it, and placed their work under the by-nc-sa. However, trying to adapt CC for programs is a tricky road since it was designed as a non-specific license, instead of a software specific license.

the share alike means that derivate work has to have the same license from what i understand.

[pieaholicx]

imo Creative Commons Attribution-Noncommercial-Share Alike is the best because it keeps it from going closed source and stops closed source from using it and stops people that didnt do shit for it from making money from it. free riders ftl.

It never stops it from going closed source. A No Derivatives CC license would stop it from becoming closed source (as long as yours was open, but what's the point then?), but you can put out work under the by-nc-sa that can become closed source, as long as they don't sell it, say you made part of it, and placed their work under the by-nc-sa. However, trying to adapt CC for programs is a tricky road since it was designed as a non-specific license, instead of a software specific license.

the share alike means that derivate work has to have the same license from what i understand.

Yes, it does. It means they need to put it under the by-nc-sa, but the by-nc-sa never states that you have to share your software source.

[d3adf001]

Yes, it does. It means they need to put it under the by-nc-sa, but the by-nc-sa never states that you have to share your software source.

i fail to see what you can do with the binary alone.

[EvanED]

Yes, it does. It means they need to put it under the by-nc-sa, but the by-nc-sa never states that you have to share your software source.

i fail to see what you can do with the binary alone.

The point is that the following is probably allowed under by-sa and by-nc-sa:
* Person A writes some software, releases source and binary under by-sa
* Person B adapts said software, releases only the modified binary under by-sa
* Person A doesn't get source back

Obviously this is worse if you don't have the NC clause, because it becomes a lot more likely that it'll happen. It still forces more than the BSD license does, but if you are of the mindset where you don't like BSD, by-nc-sa very possibly doesn't provide the protections you want either.

[d3adf001]

well the way i would want is is that noone can make money off of it or works derived from it. i have no problem someone selling a patch to it tho. but i pretty much want to stop people from pulling a redhat (take gpl code and sell "support") or apple or microsoft (take bsd and close the source and sell it in their products)

[Rysto]

well the way i would want is is that noone can make money off of it or works derived from it. i have no problem someone selling a patch to it tho. but i pretty much want to stop people from pulling a redhat (take gpl code and sell "support") or apple or microsoft (take bsd and close the source and sell it in their products)

Well, I'll defend your right to do that, but I believe that to be counter-productive. People won't use your software if it can't be used commercially.

[Anpheus]

It's kind of silly to accuse Red Hat of 'selling GPL code' when in fact it is freely available. Don't want to pay for support? Download Fedora Core.

Believe it or not, the 'selling support' model not only works, but manages to produce valuable contributions to the linux kernel and associated projects.

And saying Apple or Microsoft is doing something wrong by including formerly BSD-licensed code is silly too, the license expressly permits that.

So, what's wrong with what the three companies I mentioned? What are they doing wrong? The license permits it, they're following the law, the people who wrote the code had the option to use that license. They wanted to use that license.

[d3adf001]

It's kind of silly to accuse Red Hat of 'selling GPL code' when in fact it is freely available. Don't want to pay for support? Download Fedora Core.

Believe it or not, the 'selling support' model not only works, but manages to produce valuable contributions to the linux kernel and associated projects.

And saying Apple or Microsoft is doing something wrong by including formerly BSD-licensed code is silly too, the license expressly permits that.

So, what's wrong with what the three companies I mentioned? What are they doing wrong? The license permits it, they're following the law, the people who wrote the code had the option to use that license. They wanted to use that license.

that is true but i just have something against people making money off of stuff that they got for free. well i guess that red hat does contribute to linux so its not as bad as what MS did with tcp/ip stacks and apple contributes to darwin even tho noone uses it

[Anpheus]

But the people who wrote the BSD code chose to license it as BSD, because especially under BSD, you can change the license to whatever you want. Moreso than say, people who develop GPL code possibly because they are compelled to for legal reasons.

There is no legal compulsion to release code under BSD, whereas under GPL, it can encourage lawsuits. Statically linking GPL code with non-GPL code right out of the question, and contrary to the beliefs of some people who have posted here, dynamic linking may or may not be legal, a matter which has not stood before a court and the illegality of it was questioned the moment the FSF suggested it was.

Personally, I think the GPL's viral nature is reprehensible, although I understand that result to be unintentional and do not place any blame on the FSF or the individuals who drafted it. I understand why GPLv3 was created and why the Linux kernel can never be GPLv3, but that is not my bone to pick with GPL. My problem with GPL is one line in particular that the FSF puts in their official copy:

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 1, or (at your option)
any later version.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

If v4.0 is the BSD license, you're fucked. While I don't think it's likely, I think you're a fool to include those lines with your headers and in the license (many projects remove it.)

Basically, if Microsoft bought the FSF, which is incredibly unlikely, they would be able to make version 4.0 of the license allow them to not have to distribute source code and to change the license. Because version 4.0 would not restrict the rights of the distributor (which is only permitted if the copyright holder and distributor permit those restrictions,) they would therefore be permitted to take any and all code they wanted against the original author's intentions and distribute it in closed source forks of their own.

The GPL contains within it the tool of its own destruction, and that's why I find it extremely silly. Even if it's beyond unlikely, I find it odd that they believe themselves to be of such impeccable moral stature that their license includes a provision that any future license can be applied instead.

[EvanED]

Personally, I think the GPL's viral nature is reprehensible, although I understand that result to be unintentional and do not place any blame on the FSF or the individuals who drafted it.

What? The "viral nature" is very intentional, and is in fact the whole point of why you would release under the GPL.

The GPL contains within it the tool of its own destruction, and that's why I find it extremely silly. Even if it's beyond unlikely, I find it odd that they believe themselves to be of such impeccable moral stature that their license includes a provision that any future license can be applied instead.

Note that the line you quote isn't actually part of the license itself, but part of the boilerplate text they suggest including in other files to say what license said file is released under.

Anyway, if you don't trust the FSF, don't use it. I think you're way overblowing this. At any rate, I don't think that clause could really result in anything worse then your code being effectively BSD-licensed. I doubt that the FSF saying something like "all your copyrights now belong to MS" would stand up in court.

It's entirely reasonable to say that the benefits of increased interoperability (your code can be compiled with both GPL 2 and GPL 3 code) is worth the risk that someone will co-opt the FSF.

[Anpheus]

Is there an echo in here? I know you can remove that from the boilerplate, and there's another line, in the license that also has a removable future version clause. I kind of pointed that out in my post.

I appreciate your zealotry, but the GPL's viral nature wasn't exactly intended way back in the day, and the result is that it's really, truly impossible to fork the Linux kernel over to another license. In fact, it's impossible to move it to any other license as a result of the GPL. And any driver for linux that you want to 'go fast' has to statically link, which means it needs to be GPL... it's insane. (And stupid.)

However, the "Future version" clause does exist in the draft they publish, and it is therefore a risk to any author that includes that license.

[Rysto]

I appreciate your zealotry, but the GPL's viral nature wasn't exactly intended way back in the day, and the result is that it's really, truly impossible to fork the Linux kernel over to another license. In fact, it's impossible to move it to any other license as a result of the GPL. And any driver for linux that you want to 'go fast' has to statically link, which means it needs to be GPL... it's insane. (And stupid.)

That's a feature, not a bug. Ever notice how much better Linux's hardware support is then any of the BSD's?

[EvanED]

Is there an echo in here? I know you can remove that from the boilerplate, and there's another line, in the license that also has a removable future version clause. I kind of pointed that out in my post.

Yes, but it's inactive. The first and second occurrences doesn't apply if the "or a later version" isn't applied to your code. The third is just saying how to apply the GPL to your code.

I appreciate your zealotry, but the GPL's viral nature wasn't exactly intended way back in the day, and the result is that it's really, truly impossible to fork the Linux kernel over to another license.

No, it was intended. The whole point of using the GPL is to make sure that anything someone links against your program is also GPL.

Now, it may be that some of the consequences of the viral nature aren't intended. For instance, the sentence above ends "is also GPL", but really they want "also Free". It's just that "also Free" is somewhat hard to enforce, and "also GPL" ensures that.

And any driver for linux that you want to 'go fast' has to statically link, which means it needs to be GPL... it's insane. (And stupid.)

nVidia manages to get by with a mostly closed driver that goes fast.

However, the "Future version" clause does exist in the draft they publish, and it is therefore a risk to any author that includes that license.

Again, the only times this is used in the license are inactive if you don't include the "later version" part in your own license grant. The only thing that it being in the license risks is someone pulling the boilerplate text from the license and putting it, without modification, into a source file, or if you are contributing to a project that uses the "later version" clause and you don't remove it.

[Anpheus]

Mostly closed driver that requires a hacked-on GPL 'driver' which then outsources all of its actual work to a binary blob. Which just goes to show how silly the static/dynamic linking argument really is.

"Yes, but it's inactive. The first and second occurrences doesn't apply if the "or a later version" isn't applied to your code. The third is just saying how to apply the GPL to your code."

But the "or a later version" bit is part of what they tell you to use, and as a consequence, thousands of people use it without even realizing it. If tomorrow the FSF came out with GPL v4, BSD edition, then I could go pillage me some code!

It's a display of extreme hubris to have the "or later version" in the GPL at all. It's a way of saying "we know we're better than you, and always will be, so let us do what we know is best for you by writing future versions of your code's license." The FSF may not have copyright ownership of these varied projects, but they certainly have the ability to put a whole fucking lot of GPL code into the public domain at will.

[EvanED]

But the "or a later version" bit is part of what they tell you to use, and as a consequence, thousands of people use it without even realizing it.

That's their own problem. I can understand complaints about EULAs and such that have ridiculous terms, because they really are hard to read and no one does. But if you're doing something major? If you buy a house and don't read the contract? If you contribute enough to a software project that you would care if it goes BSD, and don't understand the terms under which you do so? I have no sympathy.

It's a display of extreme hubris to have the "or later version" in the GPL at all. It's a way of saying "we know we're better than you, and always will be, so let us do what we know is best for you by writing future versions of your code's license."

I really do think it's more of a "we think that we are good enough that the risk posed by this clause is smaller than the benefits of being able to use existing code that would otherwise be under an incompatible license only through a technicality."

I'm not trying to be an FSF zealot or anything. I would usually be more inclined to choose the BSD license for my code, though there is a project in the back of my mind where this might not be true.

[pieaholicx]

I appreciate your zealotry, but the GPL's viral nature wasn't exactly intended way back in the day, and the result is that it's really, truly impossible to fork the Linux kernel over to another license. In fact, it's impossible to move it to any other license as a result of the GPL. And any driver for linux that you want to 'go fast' has to statically link, which means it needs to be GPL... it's insane. (And stupid.)

That's a feature, not a bug. Ever notice how much better Linux's hardware support is then any of the BSD's?

Somebody correct me if I'm wrong here, but isn't this a discussion about licenses and not hardware support? If that is the case, then exactly what does your statement about hardware support have to do with the differences between the GPL and the BSD License? The original statement was saying that as a result of the GPL, all drivers that want to be fast have to be statically linked into the kernel, and thus placed under the GPL, even if the writer of the driver does not want it to be under the GPL.

[EvanED]

Somebody correct me if I'm wrong here, but isn't this a discussion about licenses and not hardware support? If that is the case, then exactly what does your statement about hardware support have to do with the differences between the GPL and the BSD License? The original statement was saying that as a result of the GPL, all drivers that want to be fast have to be statically linked into the kernel, and thus placed under the GPL, even if the writer of the driver does not want it to be under the GPL.

I think he was trying to say that the license differences helped lead to the increased HW support. This may or may not be true.

[Hammer]

That's a feature, not a bug. Ever notice how much better Linux's hardware support is then any of the BSD's?

Yes, that's obviously why the Linux kernel now includes a lot of drivers that are BSD drivers relicensed and patched for the different kernel.

The irony is that this now poses a problem for people who want to contribute to both projects or keep the drivers the same on both. If someone contributes to the Linux kernel, it's GPL licensed, if somebody contributes to the BSD kernel, it's BSD licensed. The problem is, person A wants to use a BSD driver on Linux, he patches it to work with the Linux kernel and relicenses it as dual-GPL/BSD. He rolls his own kernel to test it, and after getting it to work, he submits a contribution to the kernel tree that is eventually approved. Person A's driver only works for say, Wireless Card v1xx, but not Wireless Card v2xx. Person B contributes a patch to get Wireless Card v2xx working under Linux, under the GPL. Person B doesn't explicitly declare his contribution as being dual-licensed. Person A looks at this code and wants to bring it back to his distribution of choice for BSD, OpenBSD.

Can person A do that? No. He'd have to personally contact every contributor to that driver since he submitted it to ensure that they all approved the modified licensing to put it in the BSD kernel. Because the GPL contaminates anything it is associated with, it is extremely difficult and time-consuming, if not wholly impossible, to change the license of a GPL project. If a contributor has died it's a legal nightmare: technically their code is copyright them under whatever license they submitted for one hundred years after their death. Not only that, Person A would technically be violating the law if he were to look at Person B, C, etc's code changes to his driver, and then institute those changes into the BSD driver, because he can't prove that he's not infringing upon the other individual's copyright. The only way he could do it is if he clean-roomed it, a laborious and expensive process which is only made necessary because of GPL licensing requirements.


The GPL is an infection, essentially. You introduce GPL code into an important project, and it snowballs. The result is that eventually everything closely associated with that project has to be GPL licensed or you have to use loopholes to link binaries together (as in the case of nVidia's binary blob.)

[EvanED]

That's a feature, not a bug. Ever notice how much better Linux's hardware support is then any of the BSD's?

Yes, that's obviously why the Linux kernel now includes a lot of drivers that are BSD drivers relicensed and patched for the different kernel.

The irony is that this now poses a problem for people who want to contribute to both projects or keep the drivers the same on both. If someone contributes to the Linux kernel, it's GPL licensed, if somebody contributes to the BSD kernel, it's BSD licensed. The problem is, person A wants to use a BSD driver on Linux, he patches it to work with the Linux kernel and relicenses it as dual-GPL/BSD. He rolls his own kernel to test it, and after getting it to work, he submits a contribution to the kernel tree that is eventually approved. Person A's driver only works for say, Wireless Card v1xx, but not Wireless Card v2xx. Person B contributes a patch to get Wireless Card v2xx working under Linux, under the GPL. Person B doesn't explicitly declare his contribution as being dual-licensed. Person A looks at this code and wants to bring it back to his distribution of choice for BSD, OpenBSD.

Which is an unfortunate consequence, but again, I have no sympathy.

The original author of the driver (let's say person A wrote it for BSD originally) understood that, by including it with OpenBSD, a third party could use it and not return their contributions. Microsoft could take it, distribute it in Windows, not give it back at all, and it would be fine. Person A would say that he understands that could happen, and is okay with it. (Or at least okay with it that he's willing to contribute to OpenBSD.)

The only difference here is that "Microsoft" is replaced by "Person B", and "not give it back at all" is replaced by "not give it back under an acceptable license". Otherwise the situation is the same.

I can turn this argument around to argue against your point. You assert that the Linux situation is bad, therefore I think you must also assert that the analogous situation with Microsoft is bad, and you wouldn't want Microsoft to be able to do that. Then you should release your code under a copyleft license such as the GPL so that it can't.

If a contributor has died it's a legal nightmare: technically their code is copyright them under whatever license they submitted for one hundred years after their death.

I don't know where you are, but it the US, it's 70 years. Still absurd though.

Not only that, Person A would technically be violating the law if he were to look at Person B, C, etc's code changes to his driver, and then institute those changes into the BSD driver, because he can't prove that he's not infringing upon the other individual's copyright.

No, he wouldn't be violating the law. It would be harder to establish that he wasn't, but there is nothing innate that says that if you see something and then create something that does a similar thing, that your violating copyright.

The only way he could do it is if he clean-roomed it, a laborious and expensive process which is only made necessary because of GPL licensing requirements.

But again, the same thing applies if Microsoft takes the code and uses it, which the original author is okay with.

[Anpheus]

I'm confused by your edit, Hammer, I don't think Linux has better hardware support for everything compared to BSD. While I believe Linux rivals BSD (partly due to the adoption of BSD drivers converted to the GPL license) I don't think it's at all true that one is necessarily better than the other, or 'across the board' better than the other.
Apologies for the mistranslation. Edit removed.


Edit: To EvenED, my point was not made very clearly and I apologize. I should have emphasized much better that after looking at the GPL code, he cannot legally put that into a BSD driver. Simply looking at that GPL code is enough to contaminate him legally, which means he could not legally take those modifications and put them back into OpenBSD. This makes GPL extremely one-way. You can contribute to GPL, but you cannot take from it without expensive and laborious clean-room procedure that involves lawyers and isolation of knowledge, it's very annoying. As a consequence, anyone who even looks at GPL code relevant to their own project has a possibility of contaminating their project. While the same is absolutely true for closed source (if you were able to acquire the Windows source code again, it would contaminate any contributions related to what you had read) the fact that GPL requires source code distribution ensures as many devs as possible are contaminated by reading GPL'ed source. I digress though, it's extremely important to note that once Person A views the contributions of Person B, C, D, etc., because implementing a driver is basically a 'there is only one way to do it right' process, Person A cannot contribute those changes back into the BSD kernel. Doing so would violate the copyright of B, C, and D.

[EvanED]

I should have emphasized much better that after looking at the GPL code, he cannot legally put that into a BSD driver. Simply looking at that GPL code is enough to contaminate him legally, which means he could not legally take those modifications and put them back into OpenBSD.

Yes, I know. You said it fine the first time.

Again, my point stands. It's easy to argue you couldn't have copied something if you can honestly say you've never looked at it. It may even be very hard to come up with a way of doing it that doesn't use what you saw.

However, it's not absolutely necessary unless the project you're working on requires it. If you know another way of doing it, fine.

While the same is absolutely true for closed source (if you were able to acquire the Windows source code again, it would contaminate any contributions related to what you had read) the fact that GPL requires source code distribution ensures as many devs as possible are contaminated by reading GPL'ed source.

Then someone working on BSD would just not want to look at the Linux SRC. Again, it's no worse than MS except that the dev has to know what he's doing.

[Anpheus]

You like to skate around the issue that the moment he looks at the changes necessary to get the driver to work with the new device models, he can't rewrite that back into BSD. He can't even look at it and write it in a different way, he has to not look at it all, ever. Which would make it extremely hard for him to incorporate those changes at all.

The BSD-Linux problem is more difficult because the availability of the source means it's very easy for any one contributor to Linux to claim a copyright violation in another open source project. Because there is no contractual assignment of copyright to the Linux foundation or Linus (with perhaps a set of provisions, such as the source must always be available free to download and modify,) then there are a huge number of individuals who could sue for copyright infringement if someone takes code from BSD.* In addition to that, any one individual who cannot be found would prohibit the conversion of code changes back.

The GPL's one-way, our definition of 'free and open source is better than yours' mentality combined with the lack of copyright assignment to or arbitration by a single legal entity means that the Linux kernel is a code sink, a black hole into which code can be taken into but never given back to other, possibly superior licenses. People are compelled to contribute code under the GPL regardless of whether or not they like all of its terms because adding or removing any clause will make it incompatible with the GPL code it will be linked against. It's extremely self-centered and while I don't think the writers of the GPL were thinking about the genius of their idea to take over the coding world with one license to rule them all, the result was that there is only one license to rule them all.

*) Scary fact: if Microsoft were to contribute to the Linux project, even make only minor contributions across several different pieces of code that are regularly adapted into other projects that are non-GPL because there is implied consent, they could then sue the receiving party for converting their license from the GPL. It would be a ridiculous legal fight and I'm sure many a slashdot post would lambaste them, and PJ from Groklaw would be overjoyed to have a new legal battle to watch, but that is one possible scenario. All it takes to make it utterly impossible to go BSD->GPL->BSD is one individual who refuses to relicense, one individual who insists that the developer was contaminated by GPL code, or one dead person.

[d3adf001]

so you drop it from the kernel and make it yourself

[EvanED]

You like to skate around the issue that the moment he looks at the changes necessary to get the driver to work with the new device models, he can't rewrite that back into BSD. He can't even look at it and write it in a different way, he has to not look at it all, ever. Which would make it extremely hard for him to incorporate those changes at all.

And you like to skate around the issue that I said that no he doesn't. He can rewrite it another way as long as the particular project doesn't prohibit it.

The GPL's one-way, our definition of 'free and open source is better than yours' mentality combined with the lack of copyright assignment to or arbitration by a single legal entity means that the Linux kernel is a code sink, a black hole into which code can be taken into but never given back to other, possibly superior licenses.

In some sense, the GPL is like that, yes. I could also say "The BSD's unrestrictive, our definition of 'free and open source is better than yours' mentality combined means that BSD can be treated as a code source, a white hole from which code can be taken without giving back to the authors who wrote it, or even acknowledging that they helped in any meaningful way."

It's extremely self-centered

I don't think it's self-centered to require that, "hey, you use my code, you let me use my changes. I scratch your ear, you scratch mine."

Scary fact: if Microsoft were to contribute to the Linux project, even make only minor contributions across several different pieces of code that are regularly adapted into other projects that are non-GPL because there is implied consent, they could then sue the receiving party for converting their license from the GPL.

"Implied consent" is somewhat a misnomer; legally speaking, implied consent should be treated as no consent. But otherwise, yes, this is true.

In all this, I've overlooking one additional issue, which I just thought of and is actually pretty important: I would argue that you could also blame the BSD people equally. After all, they are perfectly able to incorporate GPL'd code into OpenBSD. This won't work if you want to import code from two viral licenses (say the GPL and CDDL), but there could be flow from Linux -> BSD if they didn't take their own sort of "our definition of 'free and open source is better than yours' mentality." The people working on the BSDs are just as insistent on using a specific license as the Linux people. In the case of the BSDs it's their own conventions that say that they want only code under the BSD license, while in the case of Linux it's the license that requires it. Same result in the end though.

Again, the fact that you can't incorporate GPL code into a BSD project on your license terms is an unfortunate consequence. However, if you take the point of view that if you contribute code to someone else they should contribute back, it's a drawback worth the cost. And, as I've said, I think this is a perfectly reasonable attitude to take.

[Anpheus]

No you can't incorporate GPL code into BSD, try and remove yourself from that notion as much as possible. If people want to compile that at home, it's fine, but distribution wise, if you link two pieces of code together, the GPL takes the high horse that any code is derived from it.

There is a lot of argument about whether or not dynamic linking counts, but the GPL insists that if you link the GPL with something not-GPL, the not-GPL code is a derivative and has to become GPLed. Dismiss this notion as much as you can, because it is blatantly wrong. It is as impossible to take GPL code from Linux and use it to any useful end in any other Free/Open Source license as it is to change the license of the Linux kernel itself. It involves contacting a lot of people who may not even be alive anymore. That's obviously a bit of a problem.

And it only takes one person to be an ass and ruin the open source spirit of communal achievement.

[btilly]

Short version. Jackbooted proprietary thugs really like the BSD license. People who are inclined to see jackbooted proprietary thugs everywhere really like the GPL license. Most programmers don't actually care too much one way or the other.

To davean: I don't see a connection between the licensing and purported quality differences between Linux and FreeBSD.

To pieaholicx: The connection between hardware support and licensing is very complicated. Supporters of the GPL often claim that their pushing licensing issues make companies more willing to just give competent people access to the specs, which results in higher quality drivers. BSD fans might be inclined to say that Linux has better hardware support because it can use both drivers that were originally developed for Linux and for FreeBSD, while FreeBSD cannot use drivers that were written for Linux.

To Anpheus: popular impressions overstate how hard it is to relicense software projects. See http://catb.org/~esr/Licensing-HOWTO.html for legal background (researched by his wife, who is an intellectual property lawyer) and when and how software can be relicensed without having to get explicit permission from everyone involved. That said one major contributer really can say that the code they've contributed to shall not move away from a GPL license, and they can make it stick.

To everyone, popular impressions of copyright derivatives and linking massively oversimplify the real legal relationship. On a related note there are widespread misunderstandings about a "binary exception" from Linus Torvalds for binary modules to link into the Linux kernel. The truth is both simpler and more complex than that.

The truth is that you have to worry about a copyright license if you're a derivative under copyright law. To really determine whether that is the case you need to know a whole lot about copyright law, various precedents, and be able to back it up with a good lawyer who can convince a judge.

So how does this relate to linking? Static linking is simple. A statically linked binary is a copyrightable work that very, very clearly derives both from the code for the program, and from whatever libraries have been linked with that. Dynamic linking is much more complex. A dynamically linked binary in memory has the same issues as a statically linked binary, but it is irrelevant since we usually don't copy them around and so don't violate copyright law. (I expect that some day we'll have an interesting lawsuit about copying a virtual machine with dynamically linked binaries in it.) But what about the unlinked binary? Well just by using enough of someone else's words, patterns and idioms, you can become a derivative of their work under copyright law. For instance a story about a pair of mice named Mickey and Minnie is probably going to be derivative of Disney's copyrights on Mickey Mouse. But in using someone else's library you inevitably use their words, patterns and idioms. When is this a copyright violation? There is a huge gray area. Talk to a good lawyer if it matters to you.

Now what about binary modules linking into the Linux kernel? That one is interesting. Linus is not a lawyer. However he has learned some basics, and he made a judgment call. Early on the kernel module interface was very limited, so at that point his call was that anything implemented as a module used only a limited subset of the standard Unix API and so wasn't derivative of Linux. But times change. Now the kernel module interface is very rich. So while it is still possible to link and be OK, it is very easy to write something that is derivative. For some snapshots of his changing opinions over time, see http://linuxmafia.com/faq/Kernel/propri ... dules.html. (What I find interesting is that he's using the same principles and same criteria and coming up with different answers. Why? Because the facts have changed!)

[Anpheus]

See, this sort of nonsense about linking is what really gets me. It's all data that gets copied around on someone's computer. In the case of open source, GPLed libraries, there's no end-result difference between asking the user to download it and compile it, link it themselves and packaging it and the source code of the library with the binary. The only difference is in distribution, in which case, one is illegal only... just because, and the other is legal because the license permits it.

I think a lot of this is an unfortunate consequence of the law being unable to deal with the digital age. The only reason I'm even allowed to copy and paste executables on my hard drive, legally, is because of fair use, but am I allowed to send someone else a fixed executable or DLL if theirs is corrupt? Even if said DLL is freely available?

The really ridiculous part of all of this would be that instead of distributing libraries or sources, if I can get the enough distro's build chains to build my code from start to finish without problem, I could just ship my code or even an unfinished binary to be statically linked on a user's computer so long as I didn't distribute it myself. (The user's computer would statically link it under fair use.)

Am I correct so far with this? It seems to me that a lot of this copyright BS is semantics that only really work for things like books, poems, and movies. When you start including things like bits and bytes, I have to exercise fair use just to copy a file from one part of my hard drive to the other, and to me that sounds like it's perhaps the law that has the issue, and not society.

[Pobega]

As an operating system:

I find GNU/Linux far superior to BSD; In most aspects GNU/Linux is far beyond that of FreeBSD (Hardware support, userbase, etc.), but in other ways BSD is better (Centralized community of developers, very strong support).

Both are Unixes so they operate very similar, except that GNU/Linux has a far broader choice of package management tools, while most BSD derivatives just have pkg_add and/or Ports. And personally, I don't like either of the BSD package managers.

(Note: I may be wrong when it comes to BSD, I've had limited use of BSD, and even that was only FreeBSD.)

As a license:

Again, GNU wins out. The BSD license is good for certain, smaller projects that I'd like to just see used, but the GNU GPL is better in sheer terms of protectedness. While using the GPL on my projects I feel like I won't be robbed by a money-hungry company who plans on patenting my ideas.