The issue with the GPL v3 and both the MIT and X.org licenses (and possibly the MIT license as well) is that section 7, paragraph 2 requires that the license allow the extension of restriction to components added independant of copyright changes (because merely conveying the software doesn;t say anything about copyright ownership). This would seem to require that these licesens allow themselves to be *changed* to the GPL v3 with no additional permissions by anyone who does or does not hold copyrights to changes in those files.
The question is: If you distribute a GPL v3 application containing one X.org file included verbatem, and I redistribute this, does the X.org license allow me to change the license on that file to the GPL v3 without making modifications? I say it does not.
Interestingly this requirement was added in Discussion Draft 2 (Draft 1 required that the permissions were removed by somepne who substantively modified the softwre).
What do you do? Reverse engineer the new function and violate at the very least the dmca, likely trademark if you're not careful and maybe a patent or three? Wrong. See Lexmark vs SCC (IANAL, but this shows that you can't use copyright or the DMCA to lock out add-on products). Trademark and patent laws have similar limitations. In fact the idea of "copyright misuse" is directly derived from patent law.
1) In today's market, one cannot compete with Free. Hence closed source versions are only viable if they are competing with your competitors' closed source products primarily. Note that every proprietary PostgreSQL spinoff has died if its primary goal was to compete with the Free version. The only 2 that have survived are primarily targetting specific markets held by Oracle and DB2. (Arguably, even SunOS wasn;t really aimed at competing with BSD so much as competing with other proprietary UNIXs.)
2) In a BSD-licensed project, you can arbitrarily interfere with closed source versions if they are not contributing back what they should. In fact, you *will* cause them problems if you have enough development momentum. People who don't contribute back to a BSD project tend to be forced to fork and go elsewhere.
Interesting additional points include:
3) The worst punishment to any project (open source or not) which uses your code is to have an incompatible and adequate replacement for their value added features. This drastically increases the cost of maintenance and usually forces them to either contribute or forego future enhancements.
4) Community is all that matters. A strong community will be able to define and coerce wanted contributions while allowing people to sell unwanted portions. For example, nobody in the PostgreSQL community really wants the system to handle NULLs the way Oracle does, so if EnterpriseDB wants to sell that as a feature, great! EnterpriseDB, OTOH, ends up contributing pretty much every generally applicable change back so they don't get hurt though. Same with BizgressMPP and the collation node.
Again, look through my journal for an entry about encouraging contributions via the BSDL for more information.
If you are a troll, I appologise for the lunch but,...
In a nutshell, the GPL v2 states that no further requirements can be placed on use or distribution of the software (legal notices of additional permissions are excluded from this requirement based on any reasonable reading of the license).
The GPL adds further restrictions relating to DRM, Tivoization, redistribution of the corresponding source as a single work, and so forth.
When you dynamically link to a library, the linking process loads both the original file and the linked library into the same protected memory space, but in different portions of that space (i.e. although they share the same protected memory segment, the address spaces are still different). This would not be sufficiently different than if you included two scholarly papers in an anthology, one of which cited the other frequently. Even if certain page numbers, paragraphs, or even sentences were specified, unless one paper reproduced elements of the other, it would not be a derivative work.
Also note that what differences exist would actually make the linking application *less* derivative than the scholarly paper. For example, you could create an application with the same API, and then rerun the linker on it to resolve the symbols and now the original work is no derivative of a different library? I don't think so... Then, does creating a new library with the same API as another alter what works other existing works are derived from? Again, I don't think so.
Furthermore, if you look at cases like Lexmark v. SCC, the court clearly said that copyright does *not* give you a monopoly on controlling add-on components (so SCC prevailed in their copyright misuse defense and could continue to slavishly copyright Lexmark's software).
1) The license is far longer and complex than the GPL v2. I have had marithon arguments about what the GPL v3 requires or does not require, particularly as relates to BSDL compatibility (I have concluded as a result of these arguments that the BSD License is *not* compatible with the GPL v3).
2) The GPL v3 may run into copyright misuse defenses, which could render the restrictions of the license unenforceable and thus allow license violations with impunity. (For a good example of a copyright misuse case, see Lexmark v. SCC, where SCC admitted to slavishly copying Lexmark's software but was not held liable for infringement because this was required for interoperability).
3) The length of the license may pose a problem in certain fields, such as embedded devices.
4) Unclear which licenses are actually compatible with GPL v3, section 7, paragraph 2 (removal of additional permissions). This point was not addressed in the recent SFLC paper on permissive license/GPL v3 issues.
FWIW, I don;t know if the LedgerSMB project is typical or not, but.... Every individual on our core team except one does paid work on the project. We also do unpaid work as well. Most of our contributions also come from people create the work in the course of either employment or consulting contracts. I know that two of our core members (out of six) are employed in positions where development of LedgerSMB is not a duty.
So at least in my experience with one project, I would say that between 80 and 90 percent of contributors are creating contributions in the due course of other paid employement or contracts. Those same contractors may *also* be donating time and effort but that is another matter.
My own view is that the GPL v2 is a good license which balances flexibility with the need to provide some protection to first movers. I.e. a business which releases a new GPL v2 application isn't just subsidizing the competition. I don't think the GPL v3 continues this balance.
Because I am concerned about the future of the GPL v2, I intent to start releasing more code under the X.org license which, by my reading, is incompatible with the GPL v3 but not the GPL v2. I say this because I now understand how to get proper contributions for permissively licensed projects and thus ensure their continued success and freedom without subsidizing the competition.
Personally I suspect that those who do adopt it don't understand the license.
Heck, I don;t think anyone understands the license. The large, nasty surprise is that Paragraph 2 of section 7 pretty much makes the license incompatible with every other license which doesn't have a clause authorizing sublicensing under the exact terms of the GPL v3. It *might* even be the case that GPL v3 + linking exceptions might be incompatible with generic GPL v3...
The GPL v2 required that dependencies have their source available. Because there was no requirement to release the entire corresponding source as a single work, dependencies could have arbitrary licenses provided that the source was redistributed.
The GPL v3 requires that the corresponding source is distributed as a single work, under the GPL v3, which means that all dependencies part of that work (defined in section 1) must be GPL v3 compatible.
Now, the real killer is Section 7, Paragraph 2, which states that one may, in the process of conveying the software, remove any permissions beyond those of the GPL v3. I.e. one can apply all restrictions of the GPL v3 to any portion of the covered work without asserting any copyrights in the matter. This means that if you use a BSDL file, this is only compatible if the BSD License allows changing the license of the file *without* modifying the actual code involved. My own reading of pretty much every BSD-license variant I can find suggests that the license follows the copyright and so this is not permissible.
Hence the BSD license puts further restrictions on the exercise of the rights granted in the GPL 3, section 7, paragraph 2, and is therefore not comp[atible. The BSD license is, however, compatible with the GPL v2, which specifically allows for additional permissions on elements which can be otherwise distributed separately under the terms of those additional permissions.
First, I don't think it was fair to mod you as a troll. If you check my journal, you will see a number of serious concerns I have over the direction of the GPL v3. The major ones center around compatibility with permissive licenses under Section 7, Paragraph 2 (no, the SFLC opinion doesn't address that point).
Secondly, I don;t think that merely dynamically linking to a work creates a derivative. I know that is against the FSF's position (and the SFLC doesn't seem to take a strong stance for this except to suggest it may not be always safe to make that assumption). Hnece I see no reason to move even if dependencies move.
The big issue with the GPL v3 is that it provides licensing requirements that must be met for mere dependencies beyond source availability (the main requirement of the GPL v2 in this area). Hence if there are BSD license compatibility questions, we can't use it for LedgerSMB because we depend on BSD licensed libraries.
The BSD and MIT licenses follow the elements released under those licenses. Yes, you can add elements under other licenses, and thus restrict freedom, but if you are only trying to compete with Free you will lose (case in point: Pervasive PostgreSQL).
There are plenty of reasons to contribute back to BSD/MIT licensed projects, both moral and economic.
Note also that the GPL doesn't guarantee anyone any sort of freedom either. If I set up an enhanced Samba service (an SAAS model), I don't have to provide my enhancements to any third parties. If you want that go with the AGPL or Larry Rosen's OSL. However in these cases, note that the requirement to make the changes available actually undercut the ability for you maintain security released in a central point since everyone who runs a public demo of the software must distribute the code of that demo.
Judges should be able to evaluate the merits and facts of a case, and choose to not grant discovery of an identity in cases where there are not sufficient grounds to win a lawsuit. That seems dangerous to me. After all, you would want the lawsuit tried first and only then have the identity revealed so that court papers could be served. That deprives the defendant of due process rights in my book (IANAL) because his/her view not represented in the trial. Thus such a standard would actually make it easier to go after anonymous bloggers because they would have to abide by a court order based on facts they didn't get a chance to contest.
A better approach to me seems to be to request that the plaintiff state a claim with specificity which meets legal criteria under applicable law, and provide a reasonable level of evientiary support before the identity could be ordered to be revealed and the lawsuit procede.
In my view (IANAL), I think the paintiff should have to show that:
1) If what they say is true, there is cause for action and 2) They have at least some basic evidence of the accusations.
For example, if they can produce a posting which shows that the blog did in fact claim to have received patient records, that would significantly help on showing this. I wouldn't want my medical records being handed to some blogger without my permission.
This is an interesting case because it tests the rights to privacy of a large number of parties. It isn't just about free speech, but security of medical records, and the like. If the hospital has evidence of what they are accusing, this probably should go to court. If not, then it shouldn't.
IANAL, but in my view, I think there ought to be a basic requirement of evidentiary support prior to the outing of an identity. Basically I think that the Plaintiff needs to show the judge that:
1) "If what we say is true, then he should be held legally accountable as a matter of law" and 2) "Here is reason to believe that what we say might be true and why we should be allowed to procede with discovery."
I don't think that anonymous communications should provide cover from slander and libel. However anonymity is not something that should be thrown out just because an accusation is made either.
First, I don't know of *any* circumstance were people are genuinely happy with their computer systems. The clueless users you refer to are *terrified* of them usually, at least in my experience. They key to Linux's past and continuing success is that it *can* do what people want better than any alternative.
Now, there is still a ways to go in providing the sort of consumer experience people want, but I am sure that this issue will eventually go away as well. At the same time, a lot of consumers do find Linux to be the best option.
The fact is-- many businesses going the open source route save money, but many pay more. Those that pay more understand that the money they save on software license fees can go towards making their entire operations more efficient, and they usually will send significantly more on consulting labor in this regard than they saved on software license costs.
Open source software is not the low-cost cheap solution. It is actually the high-end, more expensive solution which provides a great deal more power and flexibility than the truly cheap alternatives.
When I worked at Microsoft, I fell asleep at work on a couple of instances.
When I was working graveyard shift, we would answer tech support calls, and often have 1-2 hours between calls. I didn't want to fall asleep (largely because waking up to the telephone ringing is not exactly pleasant, plus you get cold), but it would happen occasionally in the wee hours of the night. The management didn't care too much about this as everyone really tried to avoid falling asleep.
Then there was the time when I slept overnight in my cube because my car keys fell out of my pocket in some meeting room and I only had about 8 hours before my next shift (I found my keys the next day). So I slept under my cube (no sleeping bag. Just rearranged the furniture to block out the light). The management wasn't happy about this but didn't press the issue. Note that our building had exercise facilities and showers, and the latter came in handy.
Never kissed a coworker though, as much as I might have wanted to kiss a few of the cute ones (they were clearly not interested in me).
I understand that argument. I agree that your position is correct on that limited issue. My issue with compatibility is a different limited issue, and has to do with whether the rights granted under the GPL v3, section 7, paragraph 2 can be meaningfully exercised on BSD-licensed code. I contend that they cannot be, and so the BSD license actually abridges rights granted in the GPL v3.
This is not a notice requirement issue. It is the fact that the fact that the notice effectively prevents excersizing rights granted under the GPL v3, section 7, paragraph 2.
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).
I can't find the thread either.
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.
I am not sure that works. People tend to think of a work-as-a-whole license wrapping around all components used with permission. This is not the case (as pretty much any copyright attourney, including Mr Moglen, will tell you). In essence, just because you use a code excerpt with permission doesn't mean that you can tell people what they can do with that code excerpt when they remove it from your application. Only the copyright owner has that power.
My view is that the BSD License is a permission grant to all people who come into posession of that code. It is a permission grant because the copyright holder is giving permission for the recipient, however they came by the code, to exercise all rights granted by that license. Again, we agree that this can't be arbitrarily abridged for BSDL elements in the code (including but not limited to copyright-worthy code fragments) without asserting copyright in the process.
However, the problem is that the GPL v3 requires the ability to remove these "additional permissions" from "any part of" the covered work, not when you modify that part (where you would arguably have copyrights to your changes) but where you merely "convey" the source code. Thus by my reading, the BSDL would only be compatible with the GPL v3 if I, as a distributor, could unilaterally change the rights granted to downstream users to the GPL v3 without asserting any of my own copyrights in the process.
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.
Ok, in the GPL v2, you can use works under other licenses provided that it is possible to meet the requirements of both licenses simultaneously. This generally means that licenses which don't provide additional copyright, patent, or use restrictions are generally compatible with the GPL v2 provided that one license does not require that you violate the other. Hence most (but not all) permissive licenses are compatible (Apache 2.0, MS-PL, and Old BSD are not for various reasons.
For example, take a look at the ICU license, copied almost verbatim from the X.org license but ammended to make more like the BSDL: "Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/o
Interestingly, the SFLC link you provide doesn't answer to my main concern about GPL v3/BSDL compatibility.
They state "From the beginnings of their use, however, the permissive licenses have been understood by their licensors and licensees alike to permit the code they cover to be incorporated within larger works covered as a whole by more restrictive terms, including more restrictive FOSS licenses like the GPL as well as, indeed, by proprietary licenses. This understanding represents the uninterrupted, longstanding practice and expectation of the global information technology industry, including both its free and proprietary divisions, with vast commercial reliance on the result. As such, disruption of the established interpretation of the permissive licenses is neither likely nor desirable."
The concern I have with the GPL 3 is not the question of whether the larger work can have additional restrictions added (clearly this is allowed), but rather whether the BSD License allows restrictions to be removed from BSDL components absent copyrighted additions. This is in relation to section 7, paragraph 2, which allows anyone who merely conveys the software to remove additional permissions, not just from the "work as a whole" but additionally from "any part of" the covered work. The BSD-licensed projects I have talked with suggest that excersizing this right would violate the license since one cannot merely declare the BSD license grant to be void in the process of distributing the software.
I think that if and when Chris Dibona proposes this on the OSI license-discuss list, he is going to be put in the hotseat perhaps in the same way as Microsoft. The basic issue is that he has been really arguing loudly for the idea that OSI should only approve new licenses when depricating an old one. It seems that license proliferation argumenst are likely to come back against such a proposal.
Slashdot Mirror
The issue with the GPL v3 and both the MIT and X.org licenses (and possibly the MIT license as well) is that section 7, paragraph 2 requires that the license allow the extension of restriction to components added independant of copyright changes (because merely conveying the software doesn;t say anything about copyright ownership). This would seem to require that these licesens allow themselves to be *changed* to the GPL v3 with no additional permissions by anyone who does or does not hold copyrights to changes in those files.
The question is: If you distribute a GPL v3 application containing one X.org file included verbatem, and I redistribute this, does the X.org license allow me to change the license on that file to the GPL v3 without making modifications? I say it does not.
Interestingly this requirement was added in Discussion Draft 2 (Draft 1 required that the permissions were removed by somepne who substantively modified the softwre).
(I am not keeping anything secret.)
However, there are two basic premises:
1) In today's market, one cannot compete with Free. Hence closed source versions are only viable if they are competing with your competitors' closed source products primarily. Note that every proprietary PostgreSQL spinoff has died if its primary goal was to compete with the Free version. The only 2 that have survived are primarily targetting specific markets held by Oracle and DB2. (Arguably, even SunOS wasn;t really aimed at competing with BSD so much as competing with other proprietary UNIXs.)
2) In a BSD-licensed project, you can arbitrarily interfere with closed source versions if they are not contributing back what they should. In fact, you *will* cause them problems if you have enough development momentum. People who don't contribute back to a BSD project tend to be forced to fork and go elsewhere.
Interesting additional points include:
3) The worst punishment to any project (open source or not) which uses your code is to have an incompatible and adequate replacement for their value added features. This drastically increases the cost of maintenance and usually forces them to either contribute or forego future enhancements.
4) Community is all that matters. A strong community will be able to define and coerce wanted contributions while allowing people to sell unwanted portions. For example, nobody in the PostgreSQL community really wants the system to handle NULLs the way Oracle does, so if EnterpriseDB wants to sell that as a feature, great! EnterpriseDB, OTOH, ends up contributing pretty much every generally applicable change back so they don't get hurt though. Same with BizgressMPP and the collation node.
Again, look through my journal for an entry about encouraging contributions via the BSDL for more information.
If you are a troll, I appologise for the lunch but,...
In a nutshell, the GPL v2 states that no further requirements can be placed on use or distribution of the software (legal notices of additional permissions are excluded from this requirement based on any reasonable reading of the license).
The GPL adds further restrictions relating to DRM, Tivoization, redistribution of the corresponding source as a single work, and so forth.
(IANAL)
When you dynamically link to a library, the linking process loads both the original file and the linked library into the same protected memory space, but in different portions of that space (i.e. although they share the same protected memory segment, the address spaces are still different). This would not be sufficiently different than if you included two scholarly papers in an anthology, one of which cited the other frequently. Even if certain page numbers, paragraphs, or even sentences were specified, unless one paper reproduced elements of the other, it would not be a derivative work.
Also note that what differences exist would actually make the linking application *less* derivative than the scholarly paper. For example, you could create an application with the same API, and then rerun the linker on it to resolve the symbols and now the original work is no derivative of a different library? I don't think so... Then, does creating a new library with the same API as another alter what works other existing works are derived from? Again, I don't think so.
Furthermore, if you look at cases like Lexmark v. SCC, the court clearly said that copyright does *not* give you a monopoly on controlling add-on components (so SCC prevailed in their copyright misuse defense and could continue to slavishly copyright Lexmark's software).
1) The license is far longer and complex than the GPL v2. I have had marithon arguments about what the GPL v3 requires or does not require, particularly as relates to BSDL compatibility (I have concluded as a result of these arguments that the BSD License is *not* compatible with the GPL v3).
2) The GPL v3 may run into copyright misuse defenses, which could render the restrictions of the license unenforceable and thus allow license violations with impunity. (For a good example of a copyright misuse case, see Lexmark v. SCC, where SCC admitted to slavishly copying Lexmark's software but was not held liable for infringement because this was required for interoperability).
3) The length of the license may pose a problem in certain fields, such as embedded devices.
4) Unclear which licenses are actually compatible with GPL v3, section 7, paragraph 2 (removal of additional permissions). This point was not addressed in the recent SFLC paper on permissive license/GPL v3 issues.
FWIW, I don;t know if the LedgerSMB project is typical or not, but....
Every individual on our core team except one does paid work on the project. We also do unpaid work as well. Most of our contributions also come from people create the work in the course of either employment or consulting contracts. I know that two of our core members (out of six) are employed in positions where development of LedgerSMB is not a duty.
So at least in my experience with one project, I would say that between 80 and 90 percent of contributors are creating contributions in the due course of other paid employement or contracts. Those same contractors may *also* be donating time and effort but that is another matter.
My own view is that the GPL v2 is a good license which balances flexibility with the need to provide some protection to first movers. I.e. a business which releases a new GPL v2 application isn't just subsidizing the competition. I don't think the GPL v3 continues this balance.
Because I am concerned about the future of the GPL v2, I intent to start releasing more code under the X.org license which, by my reading, is incompatible with the GPL v3 but not the GPL v2. I say this because I now understand how to get proper contributions for permissively licensed projects and thus ensure their continued success and freedom without subsidizing the competition.
Personally I suspect that those who do adopt it don't understand the license.
Heck, I don;t think anyone understands the license. The large, nasty surprise is that Paragraph 2 of section 7 pretty much makes the license incompatible with every other license which doesn't have a clause authorizing sublicensing under the exact terms of the GPL v3. It *might* even be the case that GPL v3 + linking exceptions might be incompatible with generic GPL v3...
What do you bet that when HURD 1.0 is released, we will see a GPL v4 which requires that the kernel is licensed under the same license too?
Of course, when HURD 1.0 is released, we will also have to revise the FreeBSD mascot to add a pair of ice skates...
The GPL v2 required that dependencies have their source available. Because there was no requirement to release the entire corresponding source as a single work, dependencies could have arbitrary licenses provided that the source was redistributed.
The GPL v3 requires that the corresponding source is distributed as a single work, under the GPL v3, which means that all dependencies part of that work (defined in section 1) must be GPL v3 compatible.
Now, the real killer is Section 7, Paragraph 2, which states that one may, in the process of conveying the software, remove any permissions beyond those of the GPL v3. I.e. one can apply all restrictions of the GPL v3 to any portion of the covered work without asserting any copyrights in the matter. This means that if you use a BSDL file, this is only compatible if the BSD License allows changing the license of the file *without* modifying the actual code involved. My own reading of pretty much every BSD-license variant I can find suggests that the license follows the copyright and so this is not permissible.
Hence the BSD license puts further restrictions on the exercise of the rights granted in the GPL 3, section 7, paragraph 2, and is therefore not comp[atible. The BSD license is, however, compatible with the GPL v2, which specifically allows for additional permissions on elements which can be otherwise distributed separately under the terms of those additional permissions.
First, I don't think it was fair to mod you as a troll. If you check my journal, you will see a number of serious concerns I have over the direction of the GPL v3. The major ones center around compatibility with permissive licenses under Section 7, Paragraph 2 (no, the SFLC opinion doesn't address that point).
Secondly, I don;t think that merely dynamically linking to a work creates a derivative. I know that is against the FSF's position (and the SFLC doesn't seem to take a strong stance for this except to suggest it may not be always safe to make that assumption). Hnece I see no reason to move even if dependencies move.
The big issue with the GPL v3 is that it provides licensing requirements that must be met for mere dependencies beyond source availability (the main requirement of the GPL v2 in this area). Hence if there are BSD license compatibility questions, we can't use it for LedgerSMB because we depend on BSD licensed libraries.
So it really cuts both ways.
The BSD and MIT licenses follow the elements released under those licenses. Yes, you can add elements under other licenses, and thus restrict freedom, but if you are only trying to compete with Free you will lose (case in point: Pervasive PostgreSQL).
There are plenty of reasons to contribute back to BSD/MIT licensed projects, both moral and economic.
Note also that the GPL doesn't guarantee anyone any sort of freedom either. If I set up an enhanced Samba service (an SAAS model), I don't have to provide my enhancements to any third parties. If you want that go with the AGPL or Larry Rosen's OSL. However in these cases, note that the requirement to make the changes available actually undercut the ability for you maintain security released in a central point since everyone who runs a public demo of the software must distribute the code of that demo.
A better approach to me seems to be to request that the plaintiff state a claim with specificity which meets legal criteria under applicable law, and provide a reasonable level of evientiary support before the identity could be ordered to be revealed and the lawsuit procede.
In my view (IANAL), I think the paintiff should have to show that:
1) If what they say is true, there is cause for action and
2) They have at least some basic evidence of the accusations.
For example, if they can produce a posting which shows that the blog did in fact claim to have received patient records, that would significantly help on showing this. I wouldn't want my medical records being handed to some blogger without my permission.
This is an interesting case because it tests the rights to privacy of a large number of parties. It isn't just about free speech, but security of medical records, and the like. If the hospital has evidence of what they are accusing, this probably should go to court. If not, then it shouldn't.
IANAL, but in my view, I think there ought to be a basic requirement of evidentiary support prior to the outing of an identity. Basically I think that the Plaintiff needs to show the judge that:
1) "If what we say is true, then he should be held legally accountable as a matter of law" and
2) "Here is reason to believe that what we say might be true and why we should be allowed to procede with discovery."
I don't think that anonymous communications should provide cover from slander and libel. However anonymity is not something that should be thrown out just because an accusation is made either.
First, I don't know of *any* circumstance were people are genuinely happy with their computer systems. The clueless users you refer to are *terrified* of them usually, at least in my experience. They key to Linux's past and continuing success is that it *can* do what people want better than any alternative.
Now, there is still a ways to go in providing the sort of consumer experience people want, but I am sure that this issue will eventually go away as well. At the same time, a lot of consumers do find Linux to be the best option.
matter that much either.
The fact is-- many businesses going the open source route save money, but many pay more. Those that pay more understand that the money they save on software license fees can go towards making their entire operations more efficient, and they usually will send significantly more on consulting labor in this regard than they saved on software license costs.
Open source software is not the low-cost cheap solution. It is actually the high-end, more expensive solution which provides a great deal more power and flexibility than the truly cheap alternatives.
I mean, how many books would the British have to burn to generate this much energy?
When I worked at Microsoft, I fell asleep at work on a couple of instances.
When I was working graveyard shift, we would answer tech support calls, and often have 1-2 hours between calls. I didn't want to fall asleep (largely because waking up to the telephone ringing is not exactly pleasant, plus you get cold), but it would happen occasionally in the wee hours of the night. The management didn't care too much about this as everyone really tried to avoid falling asleep.
Then there was the time when I slept overnight in my cube because my car keys fell out of my pocket in some meeting room and I only had about 8 hours before my next shift (I found my keys the next day). So I slept under my cube (no sleeping bag. Just rearranged the furniture to block out the light). The management wasn't happy about this but didn't press the issue. Note that our building had exercise facilities and showers, and the latter came in handy.
Never kissed a coworker though, as much as I might have wanted to kiss a few of the cute ones (they were clearly not interested in me).
I think we can put the rumors to rest now.
I understand that argument. I agree that your position is correct on that limited issue. My issue with compatibility is a different limited issue, and has to do with whether the rights granted under the GPL v3, section 7, paragraph 2 can be meaningfully exercised on BSD-licensed code. I contend that they cannot be, and so the BSD license actually abridges rights granted in the GPL v3.
This is not a notice requirement issue. It is the fact that the fact that the notice effectively prevents excersizing rights granted under the GPL v3, section 7, paragraph 2.
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).
I can't find the thread either.
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.
I am not sure that works. People tend to think of a work-as-a-whole license wrapping around all components used with permission. This is not the case (as pretty much any copyright attourney, including Mr Moglen, will tell you). In essence, just because you use a code excerpt with permission doesn't mean that you can tell people what they can do with that code excerpt when they remove it from your application. Only the copyright owner has that power.
My view is that the BSD License is a permission grant to all people who come into posession of that code. It is a permission grant because the copyright holder is giving permission for the recipient, however they came by the code, to exercise all rights granted by that license. Again, we agree that this can't be arbitrarily abridged for BSDL elements in the code (including but not limited to copyright-worthy code fragments) without asserting copyright in the process.
However, the problem is that the GPL v3 requires the ability to remove these "additional permissions" from "any part of" the covered work, not when you modify that part (where you would arguably have copyrights to your changes) but where you merely "convey" the source code. Thus by my reading, the BSDL would only be compatible with the GPL v3 if I, as a distributor, could unilaterally change the rights granted to downstream users to the GPL v3 without asserting any of my own copyrights in the process.
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.
Ok, in the GPL v2, you can use works under other licenses provided that it is possible to meet the requirements of both licenses simultaneously. This generally means that licenses which don't provide additional copyright, patent, or use restrictions are generally compatible with the GPL v2 provided that one license does not require that you violate the other. Hence most (but not all) permissive licenses are compatible (Apache 2.0, MS-PL, and Old BSD are not for various reasons.
For example, take a look at the ICU license, copied almost verbatim from the X.org license but ammended to make more like the BSDL:
"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/o
Interestingly, the SFLC link you provide doesn't answer to my main concern about GPL v3/BSDL compatibility.
They state "From the beginnings of their use, however, the permissive licenses have been understood by their licensors and licensees alike to permit the code they cover to be incorporated within larger works covered as a whole by more restrictive terms, including more restrictive FOSS licenses like the GPL as well as, indeed, by proprietary licenses. This understanding represents the uninterrupted, longstanding practice and expectation of the global information technology industry, including both its free and proprietary divisions, with vast commercial reliance on the result. As such, disruption of the established interpretation of the permissive licenses is neither likely nor desirable."
The concern I have with the GPL 3 is not the question of whether the larger work can have additional restrictions added (clearly this is allowed), but rather whether the BSD License allows restrictions to be removed from BSDL components absent copyrighted additions. This is in relation to section 7, paragraph 2, which allows anyone who merely conveys the software to remove additional permissions, not just from the "work as a whole" but additionally from "any part of" the covered work. The BSD-licensed projects I have talked with suggest that excersizing this right would violate the license since one cannot merely declare the BSD license grant to be void in the process of distributing the software.
I think that if and when Chris Dibona proposes this on the OSI license-discuss list, he is going to be put in the hotseat perhaps in the same way as Microsoft. The basic issue is that he has been really arguing loudly for the idea that OSI should only approve new licenses when depricating an old one. It seems that license proliferation argumenst are likely to come back against such a proposal.