Other open source licenses don't require all portions of a covered work to be under the same license. That's why they don't create such a mess and are not as viral as the GPL. That's hilarious considering that the latest discussions are about what can and can't be done with the BSDL, and what are the requirements for mixing BSDL code in GPL applications, not the other way around. The latest months have made it quite clear that the BSD/ISC/MIT licences are subject to multiple opposing interpretations that can drasticaly changes what you can actually do with the code, which is rather funny given the "freer than thou" mantra I keep hearing. The general feeling is that you are free to use it, just not for GPL projects. To each its own I guess.
As for needing a lawyer, it's of course to be expected in a document produced by lawyers that they say that, and it is logical that they do so: doubts about legal matters are better resolved by lawyers. Like, say, wanting to know if the BSDL requirements need verbatim reproduction of the warranty disclaimer or just a general warranty disclaimer. Or if Theo is right about his view on dual licencing and the requirements of the BSDL that make it void. Or any other of the dozens of different views on why you can or can't use BSDL code in projects without doing a random ammount of things.
Ehe, this looks like a fork from our ongoing debate in a now buried thread. Since more people are reading this one I'll answer it here, maybe someone has something interesting to add (ahahaha, just kidding).
The BSD people you have talked with are correct IMO, and as I said in the other thread that is also my interpretation and the interpretation of the FSF when writing the section. Additional copyright notices and "reasonable legal notices" are regarded as an allowed restriction even if the text is "permissive" (well, especially then, since that is part of the concept of "reasonable legal notices"). The BSDL is basically PD with further restrictions: the beginning says "Permission granted..." but then sets forth a number of restrictions which fall within the ones listed in section 7 of the GPL. Since it is a restriction (several, actually) it can't be removed. If it said "You can do whatever you want with the code" that would be an additional permission: by definition you can always remove it since it doesn't state any objections to you doing so (just like PD code allows for the removal of "This code is in the Publiv Domain"). The BSDL/ISC/MIT do state the need to maintain the copyright notice... that's not an additional permission.
This for GPLv3, of cource. They do mention that since the notices set forth in the BSDL are, in a different but perfectly correspondent language,present in the GPL the case could be made that by using the GPL you are complying with the terms of the BSDL (since you guarantee all the points in the BSDL licence). That is however a different debate, and IANAL.
The "Permission is hereby granted, free of charge, to anyone obtaining a copy of ths software and the accompanying documentation...." constitutes a reasonable legal notice. And the GPLv2 does ensure that the licences are guaranteed downstream, you can't remove restrictions, and that permissions grant is a restriction: more exactly the fact that you must display it.
If I'm not understanding you correctly is likely my fault though... perhaps a further example would be helpful (this is not in jest).
We also discuss Google's super-secret project that may or may not be happening around creating a new open source software licensing model.
Google to Change the World with New Open Source License
* Subhead - We might be making this up
Well, at least they're honest.
Anyway, assuming this is true... I don't see the big difference or importance. In one way everyone is free to choose and create a licence that suits his needs. On the other the creation of yet another licence that means the same than already existing ones isn't really something to be in awe about. If it provides more "legal protection" people will complain it's legalese, if it doesn't then it's no different from dozens of other ones. A "simplified open source license that makes it easier for developers to stay "within the spirit" of the license in addition to the law" doesn't mean anything in concrete terms, and what is worse makes the assumption that current popular free licences somehow make it hard to do the same.
If in the last months so many interpretations were made regarding a licence as simple as the ISC licence I'm not sure any licence in the world is invulnerable to different interpretations. On that note the SFLC has issued a position regarding the GPLv2/GPLv3/BSD licences mixing that have been all the rage.
The SFLC just released their statement on this issues, right here.
It shouldn't take long for the news to propagate, but since you seem interested in this subjects I think you will find it interesting.
I don't take it as "definitive" or anything, appeal to authority as its limits, but since IANAL and they apparently are it's at least something to be taken into account, even if one disagrees.
I continue to disagree, additional permissions and allowed adittional restrictions are clearly enough defined (i.e. defining them more would defeat the purpose).
In any event here is the fresh opinion of SFLC:
(...)he GPL clarifies its copyleft requirement by explicitly prohibiting imposition of "further restrictions" on downstream recipients' exercise of GPL-derived rights. A condition in a non-GPL license covering some incorporated code, however liberal or simple such a license is, is certain to be different from the terms of the GPL in at least a literal sense. However, the meaning of "further restrictions" under GPL version 2 (GPLv2) has not been read in a literalist fashion, but rather has been elaborated over time by the communities developing, distributing, modifying and using code under that license, as a matter of custom. The treatment of notice preservation requirements in non-GPL licenses is a case in point.
The kinds of notice preservation requirements commonly found in permissive licenses are different from counterpart requirements in the GPL, but they are, as a rule, similar in nature and purpose and no more burdensome than the GPL requirements. For example, section 1 of GPLv2 requires that anyone making or distributing a copy of the program "publish on each copy an appropriate copyright notice" and "keep intact all the notices that refer to...the absence of any warranty". The GPL also requires that distributors accompany all copies with the license text. The existence of such requirements in the GPL justifies regarding the comparable requirements in permissive licenses as not being "further" restrictions in relation to the GPL.
Section 7 of GPL version 3 (GPLv3) codifies this GPLv2 interpretive tradition, explicitly allowing contributors to attach "non-permissive additional terms" to the material they contribute if those terms fall within a list of acceptable categories. Such terms supplement the requirements of GPLv3 itself and are not considered "further restrictions". Among those categories are terms "[d]isclaiming warranty or limiting liability differently" from the disclaimers in the GPL and terms "[r]equiring preservation of specified reasonable legal notices or author attributions". (...) They are lawyers, although I'm not of the opinion that one should surrender ones opinion just because of that. It should be taken into account though.
Mangled the quoting a bit and left the other poster comments in the middle, but more importantly left out the link to Opinion on Additional Terms in the FSF site.
ow, this means that if you fork LedgerSMB, you can decide to use the GPL v3 for your license if you can meet the terms of that license (which by my reading would require removing any dependency on BSD-licensed code since the additional permissions cannot be meaningfully removed in accordance with section 7 of the GPL v3). I'm beginning to think that the BSD licence needs to be tried in court, since recently I've heard so many different things I can't do with it.
More seriously I disagree with your view (I have had a good discussion about this and other GPL/BSD issues here, but i'll repeat it). Although not immediately apparent section 7 is actually more compatible with the BSD licence than GPLv2 - at least to those who support the view of the BSD/GPLv2 code sharing incompatibility:
(...)Point 7 of the GPLv3 has *two* different concepts: "aditional permissions" and "aditional requirements". "Aditional permissions" can in fact be removed, this is the situation e.g. in dual-licensing, someone received code under the GPL with aditional permissions that are however removable since they don't afect the fact that the code is under the GPL, only that whomever receives the code can also make use of the aditional permissions. Now, "aditional requirements" are different and that's where the BSDL requirements fall, and they can't be removed as aditional permissions can. The requirements listes cover the general requirements in BSDL/ISC/MIT et. al. and include the possibility of having them as a separate license file or mixed in in a single file.
Now, its probably not illegal to combine the licenses, however, there is a problem with that combination, and it might open you up to other attacks from both downstream users (who might accuse you of misrepresenting the legal rights you had to the software, particularly if they removed the BSD terms and then were sued by the original copyright holder of the BSD-licensed portion), or possibly the copyright holder of the BSD-licensed portion more directly under theories other than copyright violation (perhaps tortious interference with contract.)
I see your concern but as per above I don't think that is the case. As in this article [fsf.org]:
A GPL licensee may place an additional requirement on code for which the licensee has or can give appropriate copyright permission, but only if that requirement falls within the list given in subsection 7b. Placement of any other kind of additional requirement continues to be a violation of the license. Additional requirements that are in the 7b list may not be removed, but if a user receives GPL'd code that purports to include an additional requirement not in the 7b list, the user may remove that requirement. Here we were particularly concerned to address the problem of program authors who purport to license their works in a misleading and possibly self-contradictory fashion, using the GPL together with unacceptable added restrictions that would make those works non-free software.
(...)
The list was made to acommodate licenses which were not compatible, so it wasn't made for the BSDL/MIT/ISC licensed but for others which had other minor requirements that were not restrictive but merely incompatible due to the wording of the GPLv2 (this following the FSF reasoning on the compatibility of the BSDL license with the GPL, which you disagree with). Cheers. So I don't think Section 7 means what some people make of it - thoug part of the fault is in defining two different concepts and naming the section after only one of them.
The GPLv2 and BSD part is such a grey area (you have put forward some good points) and one which such a pervasive possible wrong use (if you're right) that I'll leave it alone. One unfortunate side-effect if you're right is that it doesn't only work against the GPL: I am now very reluncant to relicense my GPL'ed code under a BSD-type license since I could be making it incompatible with the GPL.
About the GPLv3:
The GPLv3 has a problem that I overlooked, in the provision which lets you remove additional permissive terms that are not part of the GPLv3 in downstream distributions, and expressly allows removing such terms even if they are included in a separate license agreement or otherwise phrased as mandatory for redistribution. This is problematic with the BSD, since that would mean you were granting people permission to modify the BSD license in downstream distributions if you included the GPLv3 with the BSD terms. Actually I don't think so. Point 7 of the GPLv3 has *two* different concepts: "aditional permissions" and "aditional requirements". "Aditional permissions" can in fact be removed, this is the situation e.g. in dual-licensing, someone received code under the GPL with aditional permissions that are however removable since they don't afect the fact that the code is under the GPL, only that whomever receives the code can also make use of the aditional permissions. Now, "aditional requirements" are different and that's where the BSDL requirements fall, and they can't be removed as aditional permissions can. The requirements listes cover the general requirements in BSDL/ISC/MIT et. al. and include the possibility of having them as a separate license file or mixed in in a single file.
Now, its probably not illegal to combine the licenses, however, there is a problem with that combination, and it might open you up to other attacks from both downstream users (who might accuse you of misrepresenting the legal rights you had to the software, particularly if they removed the BSD terms and then were sued by the original copyright holder of the BSD-licensed portion), or possibly the copyright holder of the BSD-licensed portion more directly under theories other than copyright violation (perhaps tortious interference with contract.) I see your concern but as per above I don't think that is the case. As in this article:
A GPL licensee may place an additional requirement on code for which the licensee has or can give appropriate copyright permission, but only if that requirement falls within the list given in subsection 7b. Placement of any other kind of additional requirement continues to be a violation of the license. Additional requirements that are in the 7b list may not be removed, but if a user receives GPL'd code that purports to include an additional requirement not in the 7b list, the user may remove that requirement. Here we were particularly concerned to address the problem of program authors who purport to license their works in a misleading and possibly self-contradictory fashion, using the GPL together with unacceptable added restrictions that would make those works non-free software.this article The list was made to acommodate licenses which were not compatible, so it wasn't made for the BSDL/MIT/ISC licensed but for others which had other minor requirements that were not restrictive but merely incompatible due to the wording of the GPLv2 (this following the FSF reasoning on the compatibility of the BSDL license with the GPL, which you disagree with).
Cheers.
That said, while Truecrypt exists for Linux, I'm sure there is a native way to do encryption without additional software. If anyone has more information about that, I'll be glad to hear of it. (Migrating to Ubuntu full-time, so one day I'll need it) Yes, LUKS. Works at block level and is available during the install of Debian etch, and surely others. Easy to create and maintain. Unlike TrueCrypt it doesn't offer that "shadow" volume thing, but that's an extra behyond normal requirements.
Ahahahahah, brilliant. I'm curious enough to risk being offtopic: is that Shelley page some kind of Onion? Or is it for real? This is not a funny question, I'm getting mixed signals from reading it. It looks like something like the Onion by the sheer absurdity and language used, even the comments are brilliantly funny, but one never knows...
which specifically prohibits adding any additional terms to the GPLv2 terms Actually you might have point, I never looked at it that way. I mean, the BSD requirements are also GPL requirements, so I'm not sure they constitute "additional terms", but since the wording is different that perhaps explains why the GPLv3 has a paragraph explicitly stating that such additional requirements are allowed (could be solely to clarify a grey area and not a sign of thinking that the GPLv2 wasn't already compatible).
This is stange since some peoplehave the opinion that GPLv2 is compatible, but GPLv3 isn't, others that both are, and surely others think that none of them are.
I am aware that the FSF considers that to be the case. I am also aware that the FSF has an ideological interest in people relicensing code under the GPL, and is hardly a neutral expert on the matter. Now, I'm not saying that the BSD is definitively incompatible with the GPLv2, but it seems pretty strongly on its face to be. Ideological motives aside nobody to date in any other camp ever hinted at any incompatibility of the BSD license, contrary to what was recognized in the APL or the old BSDL with the advertisement clause, and I can't really see any reason for any such incompatibility. Compatibility in this context means the ability to mix the code, not necessarily the ability to remove the text of the other license. This is what I was refering as "strict", i.e. I was not refering to compatible in the sense of allowing integration by completely removing the license, merely the ability to use the code and distribute derived works.
If you mix GPL and BSD code and distribute derived works, it is a copyright violation of at least one of the upstream works if the two license are not compatible "in a strict licensing context". See above got my usage of "strict". Again, I fail to see any reason for incompatibility between the GPL and the MIT/ISC/BSDL license. *But* if that's something that a large - or at least influential - part of the BSD community believes or wants, and especially if someone with more knowledge of the legal field states, I think it's important to clear in order to inform anyone who develops GPL'ed code the risks in agreeing to relicense parts or the whole of the software as BSDL, since it would make the code unusable in GPL projects.
Yeah, but you'd think Theo would know better than to claim you have to follow both sets of terms. If you do, then the code is, effectively, GPLed. Theo seems to think that he can follow the BSD license when code is dual-licensed, without regard to the GPL. Makes sense to me. Why, then, does he think it's wrong to follow the GPL license? Exactly.I've been asnking the same since this topic appeared, and nobody answers it. If both licenses apply, then the BSD alone can't be used in that code, which means that the code is also and forever under the GPL, which means that BSD is incorporating GPL code in their core distribution. Also, apparently dual-licensed code can't be used for proprietary development since eveyone receiving the binaries must receive the "option" of choosing the GPL, and can demand the code.
Both you and the commentator to whom you reply have missed one crucial fact: The contributions submitted under the dual license terms which remain part of the file are licensed under the dual license terms. Until and unless every contributor has explicitly given permission to re-release the file under novel terms, the dual license still applies. So, any proprietary development of dual-licensed GPL/BSDL code is also bound by the GPL, unless every contributor gives explicit permission? I was under the assumption that dual licensed code was more palatable for the BSD folks since the option of using the BSD license exclusively meant that extra conditions weren't imposed upon anyone else,but is that's not the situation then no dual licensed code can ever enter the core distribution.
For an open source project like this, spending dozens (hundreds?) of hours of time redrawing tiles just because the license is different (yet still open) is really pointless pedantry. Wow, you've really struck a blow for your BSD license preference by wasting a ton of your own time. Congratulations. I assume the game is closed sourced, hence the preference for BSD tiles. I can also understand the frustration, but it's a direct consequanece of the specific whishes of whomever designed the original tiles.
* The FSF's chief legal counsel, Eben Moglen, is "arrogant and unscrupulous" as well as "crafty and cowardly"
* Moglen has a "stated goal" that he's breaking the law by "stealing as much software as possible and putting it under the GPL even when doing so is illegal"
* The FSF is fighting a "war against reality"
* The only reason the FSF exists is to "keep stealing code until they get busted, go to court, and then go back to stealing as much code as possible."
Oh, and the "delusional and deranged" Richard Stallman is leading anyone who uses the GPL to a Jonestown-style koolaid suicide.
Why does anyone bother reading JC Roberts' nuttery? He sounds like he's either 14 years old, off his meds, or both. Hey, that reads like Slashdot in the last months. Either there is some overlap in/. and those lists, or the language is remarkably similar.
I'd have less of a problem with people continually rubbishing Theo if there wasn't so often continual, simultaneous worship of Stallman on the other hand as well. You seem to be a reasonable, open-minded chap (ahahaha, j/k), care to point me to where the parent post even *mentioned* Stallman? Or perhaps any mail from him about this subject? Any other references that connect RMS to the topic at hand?
No? Well, I'm sure he did sent several mails saying "THE WOLD IS MINE, SURRENDER!!!", but an army of Ninja FSF GNU GPL zealots deleted them from the archives .
Completely agree. For me Objective-C and the OPENSTEP API are probably the one reason I have to buy a Mac, and surely the reason I have to love GNUstep. As the parent said GNUstep is explendid for development, even if less "sexy" and/or mainstream than other API's.
The BSD is, from reading the licenses, incompatible with the GPLv2 but not the GPLv3, provided the BSD-required terms are included along with the GPL terms. Just note that the FSF considers just about every BSD/ISC/MIT-type license compatible with both the GPLv2 and 3. I think the difference is that you're using compatible in a strict licensing context while I generally use in in terms of mixing GPL and BSD code, and distrbuting derived works.
But you make good points in terms of the BSD license being not easily "subsetted" in GPLv2. Perhaps this is something that warrants further analysis, behyond what people have come to take for general truths for years now.
No it's not irrelevant. The author grants you Copyright. You do not take it. Yes it is largely irrelevant, for the purpose of what I was discussing which is license *interpretation*. If I release the BSD license to release some code and then, for example, say that some company is breaching the license by not distributing the source code becayse it is the authors interpretation that the BSD license is also copyleft it doesn't follow that the BSD license is copyleft and that the author is right.
Forthermore, you can't strip the BSD license. Yes, I have said that already.
Tt's not so hard to understand. Yeah, I know...reality sucks. GPL zealots [bla bla bla] Yes, yes, right, whatever you want. Everyone else is stupid and you rule, I see that Theo's lack of hability to keep a speech within regular cordiality parameters, without going on a long rant about zealots everybody else stupidity, is something that many within the BSD community try to emulate. If only they opted for his programming qualities instead.
Oh, and just to clarify one point: my personal opinion on including BSD code in a GPl application is that while the "whole" should be viewed and treated as a GPL application (since the GPL included the demands of the BSD license, and adds more) the requirements of the BSD license must be met, namely a '$ strings foo|grep "University of California"' should return something to the screen.
Really? The summary and both articles seem to say that the code was BSD licensed, and the GPL was tacked on after the fact without the knowledge or consent of the original copyright holder. There were *two* different issues, and I'm starting to lose track of them myself. There were some BSD files that got a GPL on top, and then there was the dual-licensed files from which the BSD was removed. As far as the first issue goes I have read different and conflicting reports, that it was a mistake and was reverted, that it wasn't a mistake and that BSD code can be used inside GPL'ed code, that (this is Theo's opinion I think) there is some sort of measurable ammount of modifications one has to make to be able to gain copyright, ad nauseam. *Personally* I always imagined BSD code as passible of being incorporated in GPL projects, keeping the copyright notice *but* covering the aggregate work with the GPL, which in terms of distribution terms ammounts to being covered to the GPL alone, due to it being a superset. But I'm open to more opinions on this.
Unless the original copyright holder agrees to "either or", In the dual-licensed code situation I refered to thw author sent a mail saying exactly that, although I imagine that the authors opinion is only partially relevant: it's written right there that it's "you can choose to be covered by either the GPL or the BSD, at you option", so the authors opinion only serves as an aditional guarantee. I'm saying this because if someone releases a piece of code under the BSD license )or GPL, or any other) he can't complain latter from usages covered by that license by merely saying that his understanding was different.
I don't see how a third party can arbitrarily add a second incompatible license and say you can use whichever one you want. The BSD isn't incompatible with the GPL.
Isn't one of the tennets of the GPL that when you distribute the code, you must confer the same rights onto the next person that you were given with the code? I would argue that includes the option to use the code under the BSD license rather than the GPL (given that GPL is more restrictive). If you fail to include the option to license under BSD in your distribution, you are violating the spirit if not the letter of the GPL by removing freedoms which you previously had been granted. Er, that would basically mean that dual-licensed code can't be part of BSD "core", since using the same "you should give the choice to the next developer" logic would mean that anyone who touches it must also present the GPL as an option, thereby making it impossible to use for any proprietary development. Since dual-licensed code isn't considered as purely GPL code in terms of inclusion the OpenBSD - amongst others - I assume that they know that redristribution and modifications *can* be made *solely* under the BSD licensed *without* having to offer the GPL as an option to the end user.
In this case, it seems that the GPL zealots have failed to comply even with that requirement in their zeal to rebrand the code as GPL. They didn't failed to comply with the BSD licence because they weren't bound by it but by the GPL, since it was a dual-licensed work with a "you can choose which license applies" wording. And this is really the most important issue here, Theo's interpretation of dual licensed software as a kind of "you must comply with both", and this is what warrants further discussion. Saying that "zealots failed to comply" assumes that a regular BSD licensed software was changed, when this is *not* the case.
Slashdot Mirror
As for needing a lawyer, it's of course to be expected in a document produced by lawyers that they say that, and it is logical that they do so: doubts about legal matters are better resolved by lawyers. Like, say, wanting to know if the BSDL requirements need verbatim reproduction of the warranty disclaimer or just a general warranty disclaimer. Or if Theo is right about his view on dual licencing and the requirements of the BSDL that make it void. Or any other of the dozens of different views on why you can or can't use BSDL code in projects without doing a random ammount of things.
Ehe, this looks like a fork from our ongoing debate in a now buried thread. Since more people are reading this one I'll answer it here, maybe someone has something interesting to add (ahahaha, just kidding).
The BSD people you have talked with are correct IMO, and as I said in the other thread that is also my interpretation and the interpretation of the FSF when writing the section. Additional copyright notices and "reasonable legal notices" are regarded as an allowed restriction even if the text is "permissive" (well, especially then, since that is part of the concept of "reasonable legal notices"). The BSDL is basically PD with further restrictions: the beginning says "Permission granted..." but then sets forth a number of restrictions which fall within the ones listed in section 7 of the GPL. Since it is a restriction (several, actually) it can't be removed. If it said "You can do whatever you want with the code" that would be an additional permission: by definition you can always remove it since it doesn't state any objections to you doing so (just like PD code allows for the removal of "This code is in the Publiv Domain"). The BSDL/ISC/MIT do state the need to maintain the copyright notice... that's not an additional permission.
This for GPLv3, of cource. They do mention that since the notices set forth in the BSDL are, in a different but perfectly correspondent language,present in the GPL the case could be made that by using the GPL you are complying with the terms of the BSDL (since you guarantee all the points in the BSDL licence). That is however a different debate, and IANAL.
The "Permission is hereby granted, free of charge, to anyone obtaining a copy of ths software and the accompanying documentation...." constitutes a reasonable legal notice. And the GPLv2 does ensure that the licences are guaranteed downstream, you can't remove restrictions, and that permissions grant is a restriction: more exactly the fact that you must display it.
If I'm not understanding you correctly is likely my fault though... perhaps a further example would be helpful (this is not in jest).
We also discuss Google's super-secret project that may or may not be happening around creating a new open source software licensing model.
Google to Change the World with New Open Source License
* Subhead - We might be making this up
Well, at least they're honest.
Anyway, assuming this is true... I don't see the big difference or importance. In one way everyone is free to choose and create a licence that suits his needs. On the other the creation of yet another licence that means the same than already existing ones isn't really something to be in awe about. If it provides more "legal protection" people will complain it's legalese, if it doesn't then it's no different from dozens of other ones. A "simplified open source license that makes it easier for developers to stay "within the spirit" of the license in addition to the law" doesn't mean anything in concrete terms, and what is worse makes the assumption that current popular free licences somehow make it hard to do the same.
If in the last months so many interpretations were made regarding a licence as simple as the ISC licence I'm not sure any licence in the world is invulnerable to different interpretations. On that note the SFLC has issued a position regarding the GPLv2/GPLv3/BSD licences mixing that have been all the rage.
The SFLC just released their statement on this issues, right here.
It shouldn't take long for the news to propagate, but since you seem interested in this subjects I think you will find it interesting.
I don't take it as "definitive" or anything, appeal to authority as its limits, but since IANAL and they apparently are it's at least something to be taken into account, even if one disagrees.
In any event here is the fresh opinion of SFLC: (...)he GPL clarifies its copyleft requirement by explicitly prohibiting imposition of "further restrictions" on downstream recipients' exercise of GPL-derived rights. A condition in a non-GPL license covering some incorporated code, however liberal or simple such a license is, is certain to be different from the terms of the GPL in at least a literal sense. However, the meaning of "further restrictions" under GPL version 2 (GPLv2) has not been read in a literalist fashion, but rather has been elaborated over time by the communities developing, distributing, modifying and using code under that license, as a matter of custom. The treatment of notice preservation requirements in non-GPL licenses is a case in point.
The kinds of notice preservation requirements commonly found in permissive licenses are different from counterpart requirements in the GPL, but they are, as a rule, similar in nature and purpose and no more burdensome than the GPL requirements. For example, section 1 of GPLv2 requires that anyone making or distributing a copy of the program "publish on each copy an appropriate copyright notice" and "keep intact all the notices that refer to
Section 7 of GPL version 3 (GPLv3) codifies this GPLv2 interpretive tradition, explicitly allowing contributors to attach "non-permissive additional terms" to the material they contribute if those terms fall within a list of acceptable categories. Such terms supplement the requirements of GPLv3 itself and are not considered "further restrictions". Among those categories are terms "[d]isclaiming warranty or limiting liability differently" from the disclaimers in the GPL and terms "[r]equiring preservation of specified reasonable legal notices or author attributions". (...) They are lawyers, although I'm not of the opinion that one should surrender ones opinion just because of that. It should be taken into account though.
Mangled the quoting a bit and left the other poster comments in the middle, but more importantly left out the link to Opinion on Additional Terms in the FSF site.
More seriously I disagree with your view (I have had a good discussion about this and other GPL/BSD issues here, but i'll repeat it). Although not immediately apparent section 7 is actually more compatible with the BSD licence than GPLv2 - at least to those who support the view of the BSD/GPLv2 code sharing incompatibility: (...)Point 7 of the GPLv3 has *two* different concepts: "aditional permissions" and "aditional requirements". "Aditional permissions" can in fact be removed, this is the situation e.g. in dual-licensing, someone received code under the GPL with aditional permissions that are however removable since they don't afect the fact that the code is under the GPL, only that whomever receives the code can also make use of the aditional permissions. Now, "aditional requirements" are different and that's where the BSDL requirements fall, and they can't be removed as aditional permissions can. The requirements listes cover the general requirements in BSDL/ISC/MIT et. al. and include the possibility of having them as a separate license file or mixed in in a single file.
Now, its probably not illegal to combine the licenses, however, there is a problem with that combination, and it might open you up to other attacks from both downstream users (who might accuse you of misrepresenting the legal rights you had to the software, particularly if they removed the BSD terms and then were sued by the original copyright holder of the BSD-licensed portion), or possibly the copyright holder of the BSD-licensed portion more directly under theories other than copyright violation (perhaps tortious interference with contract.) I see your concern but as per above I don't think that is the case. As in this article [fsf.org]: A GPL licensee may place an additional requirement on code for which the licensee has or can give appropriate copyright permission, but only if that requirement falls within the list given in subsection 7b. Placement of any other kind of additional requirement continues to be a violation of the license. Additional requirements that are in the 7b list may not be removed, but if a user receives GPL'd code that purports to include an additional requirement not in the 7b list, the user may remove that requirement. Here we were particularly concerned to address the problem of program authors who purport to license their works in a misleading and possibly self-contradictory fashion, using the GPL together with unacceptable added restrictions that would make those works non-free software.
(...)
The list was made to acommodate licenses which were not compatible, so it wasn't made for the BSDL/MIT/ISC licensed but for others which had other minor requirements that were not restrictive but merely incompatible due to the wording of the GPLv2 (this following the FSF reasoning on the compatibility of the BSDL license with the GPL, which you disagree with). Cheers. So I don't think Section 7 means what some people make of it - thoug part of the fault is in defining two different concepts and naming the section after only one of them.
About the GPLv3: The GPLv3 has a problem that I overlooked, in the provision which lets you remove additional permissive terms that are not part of the GPLv3 in downstream distributions, and expressly allows removing such terms even if they are included in a separate license agreement or otherwise phrased as mandatory for redistribution. This is problematic with the BSD, since that would mean you were granting people permission to modify the BSD license in downstream distributions if you included the GPLv3 with the BSD terms. Actually I don't think so. Point 7 of the GPLv3 has *two* different concepts: "aditional permissions" and "aditional requirements". "Aditional permissions" can in fact be removed, this is the situation e.g. in dual-licensing, someone received code under the GPL with aditional permissions that are however removable since they don't afect the fact that the code is under the GPL, only that whomever receives the code can also make use of the aditional permissions. Now, "aditional requirements" are different and that's where the BSDL requirements fall, and they can't be removed as aditional permissions can. The requirements listes cover the general requirements in BSDL/ISC/MIT et. al. and include the possibility of having them as a separate license file or mixed in in a single file. Now, its probably not illegal to combine the licenses, however, there is a problem with that combination, and it might open you up to other attacks from both downstream users (who might accuse you of misrepresenting the legal rights you had to the software, particularly if they removed the BSD terms and then were sued by the original copyright holder of the BSD-licensed portion), or possibly the copyright holder of the BSD-licensed portion more directly under theories other than copyright violation (perhaps tortious interference with contract.) I see your concern but as per above I don't think that is the case. As in this article: A GPL licensee may place an additional requirement on code for which the licensee has or can give appropriate copyright permission, but only if that requirement falls within the list given in subsection 7b. Placement of any other kind of additional requirement continues to be a violation of the license. Additional requirements that are in the 7b list may not be removed, but if a user receives GPL'd code that purports to include an additional requirement not in the 7b list, the user may remove that requirement. Here we were particularly concerned to address the problem of program authors who purport to license their works in a misleading and possibly self-contradictory fashion, using the GPL together with unacceptable added restrictions that would make those works non-free software.this article The list was made to acommodate licenses which were not compatible, so it wasn't made for the BSDL/MIT/ISC licensed but for others which had other minor requirements that were not restrictive but merely incompatible due to the wording of the GPLv2 (this following the FSF reasoning on the compatibility of the BSDL license with the GPL, which you disagree with). Cheers.
Ahahahahah, brilliant. I'm curious enough to risk being offtopic: is that Shelley page some kind of Onion? Or is it for real? This is not a funny question, I'm getting mixed signals from reading it. It looks like something like the Onion by the sheer absurdity and language used, even the comments are brilliantly funny, but one never knows...
This is stange since some peoplehave the opinion that GPLv2 is compatible, but GPLv3 isn't, others that both are, and surely others think that none of them are.
* Moglen has a "stated goal" that he's breaking the law by "stealing as much software as possible and putting it under the GPL even when doing so is illegal"
* The FSF is fighting a "war against reality"
* The only reason the FSF exists is to "keep stealing code until they get busted, go to court, and then go back to stealing as much code as possible."
Oh, and the "delusional and deranged" Richard Stallman is leading anyone who uses the GPL to a Jonestown-style koolaid suicide.
Why does anyone bother reading JC Roberts' nuttery? He sounds like he's either 14 years old, off his meds, or both. Hey, that reads like Slashdot in the last months. Either there is some overlap in
No? Well, I'm sure he did sent several mails saying "THE WOLD IS MINE, SURRENDER!!!", but an army of Ninja FSF GNU GPL zealots deleted them from the archives .
Completely agree. For me Objective-C and the OPENSTEP API are probably the one reason I have to buy a Mac, and surely the reason I have to love GNUstep. As the parent said GNUstep is explendid for development, even if less "sexy" and/or mainstream than other API's.
But you make good points in terms of the BSD license being not easily "subsetted" in GPLv2. Perhaps this is something that warrants further analysis, behyond what people have come to take for general truths for years now.
Oh, and just to clarify one point: my personal opinion on including BSD code in a GPl application is that while the "whole" should be viewed and treated as a GPL application (since the GPL included the demands of the BSD license, and adds more) the requirements of the BSD license must be met, namely a '$ strings foo|grep "University of California"' should return something to the screen.