Your statement could be true and would suggest that a scholar of the related tradition of the Rig Veda should be qualified to speak as to matters of modern law.
In case you are wondering, most European legal systems are in part derived from the Roman legal system. The Roman legal system and its legalese is actually structurally based on older liturgical structures which had died out in Rome (but were otherwise known throughout the Indo-European and even the Italic world). This tradition also gave rise to proto-Hinduism, the Rig Vedas, the Druids, the Eddas, and the like. Hence if we are going by origins, Hindu scholars ought to be qualified as lawyers, the whole lot of them.
On the latter paper, the SFLC didn;t answer a key question on GPL v3/BSDL compatibility. The basic question surrounds whether and how the permissions granted by the GPL v3, section 7, paragraph 2 could be meaingfully applied to BSDL software.
This paragraph requires that GPL v3 compatible licenses be written in such a way that they can be reduced to the GPL v3 by anyone who merely distributes the softwre, adding no copyrights of his/her own Since the GPL v3 applies to the Corresponding Source as well, this means that any GPL v3 application that uses PostgreSQL could only do so without license modifications if the distributors could take the Libpq source and change the license without otherwise changing the code. I don;t believe it is possible, and the SFLC seems to advise not going this route.
I see no reason you can't have BSD files in a GPL v2 application, or a GPL v2 application which depends on BSDL components. After the GPL2 does not appear either grant rights not granted by the BSDL, nor does it require that you violate the BSDL.
The GPL v3 is a far more interesting question. The key questions involve applicability of Section 7, Paragraph 2 to BSDL portions of the application. What does it mean to remove additional permissions from these portions? And is that a right that the BSDL gives absent the enforcement of additional copyrights? If the BSDL does not allow you to change the license when you have not added copyrights, and if the GPL3 means what it says in this section, then I would answer "no" in terms of a single copyrighted work. Mere aggregation would be a different question (i.e. only applies tothe single atomic copyrighted work, not to the larger distro where these could be mixed).
First, I am glad that this came to a reasonable resolution that benefits all parties. Nothing is really to be gained by splitting effort in the way things were going.
However, I think that this does go to show that there are real questions whether the BSD license actually does follow the copyrights of the code in question, and if it does, then it would seem to limit what one could do to included pieces under the GPL v3, section 7, paragraph 2 (removal of additional permissions). This might make the BSDL incompatible with the GPL v3. If that section of the GPL means what it says, then it is a real shame because it means that more of these issues will come up in the future.
We ought to remember that our greatest strength lies in not forcing everyone to reinvent the wheel over and over. If we band together and stop fighting over whether the BSDL is helping commercial competitors, etc. we can beat everyone. Together. BSD, Linux, and the like.
And the answer is: solely because of legal shenanigans. In particular, the question of "when do you have to use the GPL?"
I would argue that the use of Readline by an application does not require the author of the application to license the application under the GPL because:
1) Interop is protected. Therefore mere facts (like function definitions) in a header to not cause the app to be a derivative work.
2) If you start writing your header files to control the downstream licensing of applications outside the scope of your own copyright, then that is copyright misuse, and people can ignore what you say.
I also don't see any specific argument that could be made tht the GPL doesn't force people to grant patent licenses under either version unless they are explicitly licensing for a specific work. Again, IANAL.
For example, suppose I have three patents, A, B, and C. I create code based on patent A which I contribute to a GPL v2 application that infringes on neither of my other patents.
I then contribute code based on patent B to a GPL v3 application which infringes otherwise on patent A. If I new about the infringement on patent A, this might be an implied license.
You take my patent B code and include it in an application that infringes on my patent C, but that application us under the GPL v3. This is not an implied license. And I don't use or distribute that application.
Hence in the third example, I can sue users of the application for patent infringemnet, I believe (IANAL).
Does section 7, paragraph 2 provide the right to change the license to arbitrary portions of the code? Seems to me the answer is "yes." AFAICS, Moglen's writings and the rationale documents agree.
Does this require one to add copyrights on portions where the license changes? Certainly not. Everyone agrees here.
Does the BSD license permit the changing of the license without modifying the code? Nobody can agree here. However the SFLC did out out guidelines where they suggested that the workaround was not to change the license. This would suggest that there is at least a good chance that the answer is "no."
Is this an enforceable license incompatibility? I really have no idea. I.e. if you take my BSD-licensed code, distribute it as part of your GPL v3 appication, can I stop you? I don't know. If a downstream distributor changes the lciense on the file as allowed by the GPL v3, can I stop him? Probably. Can he come after you? There is the question....
First, my reading of BSD-style licenses is that tehy follow the copyrights. I.e. you can't include BSDL code in your GPL v2 or V3 application and pretend that the restrictions of the GPL apply to that code. Or rather you can pretend to but it may lead to troublesome legal and/or political disputes.
Secondly, although this is not "passing your work off as my own," nothing in copyright law prevents clean-room reimplementation. For example, you could have 2 people read through my code, document the algorythms, etc. and hand their notes off to two programmers which implement similar solutions to the problems.
Is MinGW a derivative work of Microsoft Windows? Does anyone really believe that?
The dependency on KDE of a client app would be real since you are using their copyrighted images in widgets. But the merely functional libraries of OpenChange would seem to be another matter. I don;t see why you couldn't release a KDE client for OpenChange using their libraries under the GPL v2.
the GPL v3 prevents the following form of Tivoization:
An embedded device with a hypervisor running GPL'd software in one VM, with other VM's that handle access to specific hardware. The main VM hosting the GPL'd software only talks to the hardware through other software that is effectively on the other sides of pipes managed by the hypervisor.
I allow you to create your own main VM image, but when you install it, it wipes out all the other VMs, thus althoug nothing is interfering with your binary, your binary isn't able to do anything interesting because nothing is on the other side of the pipes.
Who ever releases something GPLv3 now, even if it is moving a license from GPLv2 or later to GPLv3 takes on the liability of claiming we have the right to use any patent related materials. That is not my reading at all. The GPL basically says you can't distribute the software unless you can ensure protection from restrictions to those rights granted to those you distribute the software to, and their downstream recipients, whether by patent, or otherwise (you are, however, not liable for their behavior). This means that if you distribute the software, you are basically saying you don;t know of any patents that could affect the software that you are not licensing.
Note that the ASL code cannot coexist int he same work with GPL v2 code because of the patent termination clause. The GPL v2 does not allow patent licensess to be terminated just because someone initiates a patent lawsuit, while the GPL v3 does this (and is by my reading incompatible with the ASL on other grounds, namely that Section 7, Paragraph 2 permission to change the license to the stock GPL v3 cannot be meaningfully extended to ASL code).
Hence if you distribute code under the GPL v2 or later, you can't later claim your patents allow you to sue people who violate the GPL v3 because the GPL v2 doesn't allow for this sort of patent license termination. IANAL though.
The FSF's position has been that if you ship GPL v2 software, you are giving an implied patent license covering any of your patents in that software. Although I disagree witht he FSF in most areas, I agree with them here (IANAL).
So now, the patent protections are not new. They are, however, different. The GPL v3 is actually quite a bit less strict about what patent protections are granted (in that they are effectively revoked for any license violation).
but it stems from the idea that we need to legislate everything into the license.
The fact is, however, that technology can always be used to restrict what a modified system can do unless you start restricting any interference with the user rather than the program.
My reading of the GPL v3 would allow tivoization via hypervisors provided that the modified application is not interfered with or treated differently by the hypervisor or hardware. This doesn't mean that other aggregated components running in different VM's have to survive the OS update.
(Yes, the system runs and the existing components treat it just as if it were an unmodified version, but the components that do interesting things are now gone, so the box is now a paperweight.)
The copyrights only extend control of your own elements. If a given work is distributed as allowed by a license but the compiled work mixes incompatible licenses, I don;t see that as a problem as long as it is possible to follow all licenses at the same time.
What could be a problem here (IANAL) is that any KDE-based application is going to be using images copyrighted by either the KDE authors, Trolltech, or the like if it has a GUI interface. Thus irrespective of the linking issue, there may be other reasons to be worried.
I could imagine situations where two processes running on different computers could create derivative screen output, so I think the GPL v2 would be the only safe license to use, but if you had to, you could add a linking exception to the GPL v3 library (since linking by itself does not indicate derivation, but again, IANAL).
Actually the main reason i dislike v3 is that is easily understood for a non-"OS-Freak". I don;t think anybody understands the GPL v3 inside or outside the open source community. Heck, I need a secred mind-reading decoder ring to get proper information out of the SFLC and FSF sites on this matter.
As long as the GPL allows mere aggregation with other components on the same media, it will be possible to Tivoize the package. All the GPL v3 does is prevent you from interfering with the actual execution of the binary. It does not tell you what the package as a whole has to be capable of doing.
Suppose I use a hypervisor and a hypothetical GPL v3 version of HURD. I want to Tivoize it, but I must treat a modified HURD as the same as an unmodified one by the hypervisor and hardware. So I provide the hypervisor as a separate download, and include all information necessary (including necessary encryption keys) to get modified HURD kernels actually running on the hardware.
However, I also release my updates in a way which cause the entire hypervisor and OS component image to be rewritten on every update. This includes other components in VM's which do things like DRM, HDTV reception, and the like. These components really are separate (in fact they are separate OS instances) and communicate with HURD via pipes.
So when you modify HURD and plop it on the device, HURD runs, but it cant do much because it doesn;t have anything to talk to.
Now you could use a similar system to create DRM where the OS wasn't trusted (even allowing a modified OS to run) and hence wasn't interfered with by the GPL v3, or the like.
These provisions in the GPL v3 have no impact. They are easy to circumvent if you want to, and they do not do what RMS promised.
The ASL is only compatible with the GPL v3 if it allows the license to be changed to the GPL v3 without asserting any new copyrights (see GPL v3, section 7, paragraph 2).
I remain unconvinced that these licenses are in fact compatible. The ASL may in fact impose restrictions on excersizing the grant of permissions to change the license in section 7, paragraph 2 of the GPL3 and thus be incompatible.
As for ASL/GPL2 compatible, there is at least limited compatibility. Nothing in the GPL v2 prevents you from using an ASL component as a dependency and distributing the source separate from the source of your application. The GPL v3 does not afford you this "loophole" and so there is no such thing as limited compatibility.
It depends on who you ask. The FSF generally will tell you that linking creates derivative works. IANAL, but from my research, I don't buy that line. It is even less derivative than if I were to create an anthology of, say, physics papers where one paper references specific paragraphs from another (see article such-and-such, section 2, paragaph 3). Such specific references do not make one article derivative of the other.
However, the case with libraries is actually less likely to be derivative even than that. In the scholarly article, there is no possibility of substitution of the referenced article because it is what the author is citing or referencing. In a software library, we can create a library with an identical API, and then rerun the linker to generate the references. Hence the application and its library are even more loosely coupled than the articles are in the anthology I mentioned.
However, the fact is, your GUI application probably uses copyrighted images from the GUI framework. In this case, your screen output may be a derivative work of that framework.
While I would not try this without getting clear and impartial legal advice, I think one could probably create a GPL v2 application which would link to the OpenCHange libraries.
If it was the former, the second person software will always be behind the first person software, and he/she has to fight potential interference made by the first person that will conflict with the enhancements made by the second person. Yes, but when the first person does fight, the second person is in trouble.
Basically, when the first person makes a similar change to that which the second person made, the second person's code maintenance complexity just increased. If the change is better than the second person's then the second person loses their investment n R&D. However, if it is not as good, it is even worse for the second person because now the decision has to be made whether to move to an inferior version or deal with an increasingly expensive process of maintaining the changeset.
Now, this gets far more interesting when it is a large community and a few closed source companies. In essence the companies have a marked disadvantage.
If I am correct (IANAL), then linking is hardly sufficient to argue derivation and you would need to argue more than that. Of course, in the case of widgets like QT where the use of the artistic components of the widgets would likely make a work derivative on those cases (essentially copyrighted images enbedded in the UI of another application and thus creating screen output derivative of Trolltech's copyrights). Note that this could be the case whether the library was used in process, whether it was automated from another process, or whether it was automated from another machine.
A second important issue, however, is that the GPL v3 requires you to license nearly all your dependencies under licenses compatible with it (see definition of Corresponding Source in section 1, and requirements for binary distribution). Note that the GPL v2 does not make such a requirement and components whose source is redistributable if they are distributed as separate works.
So my view is that if I were to make a KDE application using OpenChange libraries, I could probably do this under the GPL v2 since the screen output is derivative of KDE, but the application is a collected rather than derivative work in memory including the OpenChange libraries. I could not do so under the GPL v3 due to the requirement to extend the license to KDE, and the question of derivative screen output.
The third person is not stranded. They can always get the BSD version from you, and the closed source ersion can only really charge for their value adds, not for your own work if they are competing with you which is a problem for them if you can maintain a good pace of development.
I have been around the PostgreSQL project for some time. I have watched every closed source version that wanted to compete with the open version die. The two which have survived have done so by contributing everything back they can (i.e. everything that the community wants). They can then give customers what they want without being told what business model they need to have, while the project gets what they want out of it. It is a good situation for everyone.
Where the GPL really makes a difference though is in the initial source release. If you have a proprietary application you want to open source, you may have competitors which would like to initially use this to subsidize their own R&D, so you may want to choose the GPL instead. Note, however, that this doesn't prevent such a subsidizing of the competition (they can always clean room re-engineer), it just makes it a little more costly to do so.
If I want to suggest that I have made the ultimate successor to the GNU GPL, and I take it, write my own different preamble, modify the license on other ways, and call it the GXI GPL is that prohibited? Or is this a reference to GNU? (XI is the Greek letter after NU).
Suppose my license is so great I skip an extra letter and call it the GOmicron GPL (or Go GPL for short)?
I think there are a couple of major reasons why people choose the GPL over other licenses (note only one reason may apply to any developer and these are not in any particular order):
1) They are fanatical followers of RMS. Anytime I get flamed for suggesting that I intend to do more under permissive licenses, this comes to mind.
2) They don't understand how to leverage the BSDL to encourage competition from both open and closed source partners.
3) They have a mature codebase and want to release it without having to worry about their competition using as free R&D. Note that the BSDL offers similar protections over time, but only in purportion to the community, so it is scary to release one's own code under the BSD license if you don't already have a strong community behind it.
In other words, they are either fanatical, ignorant, or have legitimate reasons for doing so:-)
IANAL, but I have read a fair bit of legal analysis over the linking vs derivation argument. In general the concensus (outside the FSF) seems to be that linking is insufficient to show derivation, and that one can have derivative works even if they are loosely coupled (for example, by incorporating artistic elements from another program, particularly a video game, in a fixed way).
I would add a few things: I would argue that use of CPP macros are also insufficient to argue derivation for two reasons:
1) They are usually insubstantial and 2) Their use does not necessarily make a creative combination worthy of copyright.
Same with pretty much everything else in the header file.
Now this doesn't preclude you from running into problems. It just means that every possible case would need to be evaluated on a case by case basis. For example, nothing prevents a CPP macro from creating a derivative work when used just as nothing says that it always does.
Slashdot Mirror
Your statement could be true and would suggest that a scholar of the related tradition of the Rig Veda should be qualified to speak as to matters of modern law.
In case you are wondering, most European legal systems are in part derived from the Roman legal system. The Roman legal system and its legalese is actually structurally based on older liturgical structures which had died out in Rome (but were otherwise known throughout the Indo-European and even the Italic world). This tradition also gave rise to proto-Hinduism, the Rig Vedas, the Druids, the Eddas, and the like. Hence if we are going by origins, Hindu scholars ought to be qualified as lawyers, the whole lot of them.
On the latter paper, the SFLC didn;t answer a key question on GPL v3/BSDL compatibility. The basic question surrounds whether and how the permissions granted by the GPL v3, section 7, paragraph 2 could be meaingfully applied to BSDL software.
This paragraph requires that GPL v3 compatible licenses be written in such a way that they can be reduced to the GPL v3 by anyone who merely distributes the softwre, adding no copyrights of his/her own Since the GPL v3 applies to the Corresponding Source as well, this means that any GPL v3 application that uses PostgreSQL could only do so without license modifications if the distributors could take the Libpq source and change the license without otherwise changing the code. I don;t believe it is possible, and the SFLC seems to advise not going this route.
IANAL, etc.
I see no reason you can't have BSD files in a GPL v2 application, or a GPL v2 application which depends on BSDL components. After the GPL2 does not appear either grant rights not granted by the BSDL, nor does it require that you violate the BSDL.
The GPL v3 is a far more interesting question. The key questions involve applicability of Section 7, Paragraph 2 to BSDL portions of the application. What does it mean to remove additional permissions from these portions? And is that a right that the BSDL gives absent the enforcement of additional copyrights? If the BSDL does not allow you to change the license when you have not added copyrights, and if the GPL3 means what it says in this section, then I would answer "no" in terms of a single copyrighted work. Mere aggregation would be a different question (i.e. only applies tothe single atomic copyrighted work, not to the larger distro where these could be mixed).
First, I am glad that this came to a reasonable resolution that benefits all parties. Nothing is really to be gained by splitting effort in the way things were going.
However, I think that this does go to show that there are real questions whether the BSD license actually does follow the copyrights of the code in question, and if it does, then it would seem to limit what one could do to included pieces under the GPL v3, section 7, paragraph 2 (removal of additional permissions). This might make the BSDL incompatible with the GPL v3. If that section of the GPL means what it says, then it is a real shame because it means that more of these issues will come up in the future.
We ought to remember that our greatest strength lies in not forcing everyone to reinvent the wheel over and over. If we band together and stop fighting over whether the BSDL is helping commercial competitors, etc. we can beat everyone. Together. BSD, Linux, and the like.
Sometimes, I think that the only way to understand every aspect of the GPL v3 is to argue about it for weeks or months :-)
:-)
Thanks for the corrections
I would argue that the use of Readline by an application does not require the author of the application to license the application under the GPL because:
1) Interop is protected. Therefore mere facts (like function definitions) in a header to not cause the app to be a derivative work.
2) If you start writing your header files to control the downstream licensing of applications outside the scope of your own copyright, then that is copyright misuse, and people can ignore what you say.
IANAL, TINLA, etc.
I also don't see any specific argument that could be made tht the GPL doesn't force people to grant patent licenses under either version unless they are explicitly licensing for a specific work. Again, IANAL.
For example, suppose I have three patents, A, B, and C. I create code based on patent A which I contribute to a GPL v2 application that infringes on neither of my other patents.
I then contribute code based on patent B to a GPL v3 application which infringes otherwise on patent A. If I new about the infringement on patent A, this might be an implied license.
You take my patent B code and include it in an application that infringes on my patent C, but that application us under the GPL v3. This is not an implied license. And I don't use or distribute that application.
Hence in the third example, I can sue users of the application for patent infringemnet, I believe (IANAL).
Questions:
Does section 7, paragraph 2 provide the right to change the license to arbitrary portions of the code? Seems to me the answer is "yes." AFAICS, Moglen's writings and the rationale documents agree.
Does this require one to add copyrights on portions where the license changes? Certainly not. Everyone agrees here.
Does the BSD license permit the changing of the license without modifying the code? Nobody can agree here. However the SFLC did out out guidelines where they suggested that the workaround was not to change the license. This would suggest that there is at least a good chance that the answer is "no."
Is this an enforceable license incompatibility? I really have no idea. I.e. if you take my BSD-licensed code, distribute it as part of your GPL v3 appication, can I stop you? I don't know. If a downstream distributor changes the lciense on the file as allowed by the GPL v3, can I stop him? Probably. Can he come after you? There is the question....
First, my reading of BSD-style licenses is that tehy follow the copyrights. I.e. you can't include BSDL code in your GPL v2 or V3 application and pretend that the restrictions of the GPL apply to that code. Or rather you can pretend to but it may lead to troublesome legal and/or political disputes.
Secondly, although this is not "passing your work off as my own," nothing in copyright law prevents clean-room reimplementation. For example, you could have 2 people read through my code, document the algorythms, etc. and hand their notes off to two programmers which implement similar solutions to the problems.
Since when does dependency == derivation? (IANAL)
Is MinGW a derivative work of Microsoft Windows? Does anyone really believe that?
The dependency on KDE of a client app would be real since you are using their copyrighted images in widgets. But the merely functional libraries of OpenChange would seem to be another matter. I don;t see why you couldn't release a KDE client for OpenChange using their libraries under the GPL v2.
the GPL v3 prevents the following form of Tivoization:
An embedded device with a hypervisor running GPL'd software in one VM, with other VM's that handle access to specific hardware. The main VM hosting the GPL'd software only talks to the hardware through other software that is effectively on the other sides of pipes managed by the hypervisor.
I allow you to create your own main VM image, but when you install it, it wipes out all the other VMs, thus althoug nothing is interfering with your binary, your binary isn't able to do anything interesting because nothing is on the other side of the pipes.
Note that the ASL code cannot coexist int he same work with GPL v2 code because of the patent termination clause. The GPL v2 does not allow patent licensess to be terminated just because someone initiates a patent lawsuit, while the GPL v3 does this (and is by my reading incompatible with the ASL on other grounds, namely that Section 7, Paragraph 2 permission to change the license to the stock GPL v3 cannot be meaningfully extended to ASL code).
Hence if you distribute code under the GPL v2 or later, you can't later claim your patents allow you to sue people who violate the GPL v3 because the GPL v2 doesn't allow for this sort of patent license termination. IANAL though.
The FSF's position has been that if you ship GPL v2 software, you are giving an implied patent license covering any of your patents in that software. Although I disagree witht he FSF in most areas, I agree with them here (IANAL).
So now, the patent protections are not new. They are, however, different. The GPL v3 is actually quite a bit less strict about what patent protections are granted (in that they are effectively revoked for any license violation).
but it stems from the idea that we need to legislate everything into the license.
The fact is, however, that technology can always be used to restrict what a modified system can do unless you start restricting any interference with the user rather than the program.
My reading of the GPL v3 would allow tivoization via hypervisors provided that the modified application is not interfered with or treated differently by the hypervisor or hardware. This doesn't mean that other aggregated components running in different VM's have to survive the OS update.
(Yes, the system runs and the existing components treat it just as if it were an unmodified version, but the components that do interesting things are now gone, so the box is now a paperweight.)
The copyrights only extend control of your own elements. If a given work is distributed as allowed by a license but the compiled work mixes incompatible licenses, I don;t see that as a problem as long as it is possible to follow all licenses at the same time.
What could be a problem here (IANAL) is that any KDE-based application is going to be using images copyrighted by either the KDE authors, Trolltech, or the like if it has a GUI interface. Thus irrespective of the linking issue, there may be other reasons to be worried.
I could imagine situations where two processes running on different computers could create derivative screen output, so I think the GPL v2 would be the only safe license to use, but if you had to, you could add a linking exception to the GPL v3 library (since linking by itself does not indicate derivation, but again, IANAL).
As long as the GPL allows mere aggregation with other components on the same media, it will be possible to Tivoize the package. All the GPL v3 does is prevent you from interfering with the actual execution of the binary. It does not tell you what the package as a whole has to be capable of doing.
Suppose I use a hypervisor and a hypothetical GPL v3 version of HURD. I want to Tivoize it, but I must treat a modified HURD as the same as an unmodified one by the hypervisor and hardware. So I provide the hypervisor as a separate download, and include all information necessary (including necessary encryption keys) to get modified HURD kernels actually running on the hardware.
However, I also release my updates in a way which cause the entire hypervisor and OS component image to be rewritten on every update. This includes other components in VM's which do things like DRM, HDTV reception, and the like. These components really are separate (in fact they are separate OS instances) and communicate with HURD via pipes.
So when you modify HURD and plop it on the device, HURD runs, but it cant do much because it doesn;t have anything to talk to.
Now you could use a similar system to create DRM where the OS wasn't trusted (even allowing a modified OS to run) and hence wasn't interfered with by the GPL v3, or the like.
These provisions in the GPL v3 have no impact. They are easy to circumvent if you want to, and they do not do what RMS promised.
The ASL is only compatible with the GPL v3 if it allows the license to be changed to the GPL v3 without asserting any new copyrights (see GPL v3, section 7, paragraph 2).
I remain unconvinced that these licenses are in fact compatible. The ASL may in fact impose restrictions on excersizing the grant of permissions to change the license in section 7, paragraph 2 of the GPL3 and thus be incompatible.
As for ASL/GPL2 compatible, there is at least limited compatibility. Nothing in the GPL v2 prevents you from using an ASL component as a dependency and distributing the source separate from the source of your application. The GPL v3 does not afford you this "loophole" and so there is no such thing as limited compatibility.
It depends on who you ask. The FSF generally will tell you that linking creates derivative works. IANAL, but from my research, I don't buy that line. It is even less derivative than if I were to create an anthology of, say, physics papers where one paper references specific paragraphs from another (see article such-and-such, section 2, paragaph 3). Such specific references do not make one article derivative of the other.
However, the case with libraries is actually less likely to be derivative even than that. In the scholarly article, there is no possibility of substitution of the referenced article because it is what the author is citing or referencing. In a software library, we can create a library with an identical API, and then rerun the linker to generate the references. Hence the application and its library are even more loosely coupled than the articles are in the anthology I mentioned.
However, the fact is, your GUI application probably uses copyrighted images from the GUI framework. In this case, your screen output may be a derivative work of that framework.
While I would not try this without getting clear and impartial legal advice, I think one could probably create a GPL v2 application which would link to the OpenCHange libraries.
Basically, when the first person makes a similar change to that which the second person made, the second person's code maintenance complexity just increased. If the change is better than the second person's then the second person loses their investment n R&D. However, if it is not as good, it is even worse for the second person because now the decision has to be made whether to move to an inferior version or deal with an increasingly expensive process of maintaining the changeset.
Now, this gets far more interesting when it is a large community and a few closed source companies. In essence the companies have a marked disadvantage.
If I am correct (IANAL), then linking is hardly sufficient to argue derivation and you would need to argue more than that. Of course, in the case of widgets like QT where the use of the artistic components of the widgets would likely make a work derivative on those cases (essentially copyrighted images enbedded in the UI of another application and thus creating screen output derivative of Trolltech's copyrights). Note that this could be the case whether the library was used in process, whether it was automated from another process, or whether it was automated from another machine.
A second important issue, however, is that the GPL v3 requires you to license nearly all your dependencies under licenses compatible with it (see definition of Corresponding Source in section 1, and requirements for binary distribution). Note that the GPL v2 does not make such a requirement and components whose source is redistributable if they are distributed as separate works.
So my view is that if I were to make a KDE application using OpenChange libraries, I could probably do this under the GPL v2 since the screen output is derivative of KDE, but the application is a collected rather than derivative work in memory including the OpenChange libraries. I could not do so under the GPL v3 due to the requirement to extend the license to KDE, and the question of derivative screen output.
The third person is not stranded. They can always get the BSD version from you, and the closed source ersion can only really charge for their value adds, not for your own work if they are competing with you which is a problem for them if you can maintain a good pace of development.
I have been around the PostgreSQL project for some time. I have watched every closed source version that wanted to compete with the open version die. The two which have survived have done so by contributing everything back they can (i.e. everything that the community wants). They can then give customers what they want without being told what business model they need to have, while the project gets what they want out of it. It is a good situation for everyone.
Where the GPL really makes a difference though is in the initial source release. If you have a proprietary application you want to open source, you may have competitors which would like to initially use this to subsidize their own R&D, so you may want to choose the GPL instead. Note, however, that this doesn't prevent such a subsidizing of the competition (they can always clean room re-engineer), it just makes it a little more costly to do so.
If I want to suggest that I have made the ultimate successor to the GNU GPL, and I take it, write my own different preamble, modify the license on other ways, and call it the GXI GPL is that prohibited? Or is this a reference to GNU? (XI is the Greek letter after NU).
Suppose my license is so great I skip an extra letter and call it the GOmicron GPL (or Go GPL for short)?
I think there are a couple of major reasons why people choose the GPL over other licenses (note only one reason may apply to any developer and these are not in any particular order):
:-)
1) They are fanatical followers of RMS. Anytime I get flamed for suggesting that I intend to do more under permissive licenses, this comes to mind.
2) They don't understand how to leverage the BSDL to encourage competition from both open and closed source partners.
3) They have a mature codebase and want to release it without having to worry about their competition using as free R&D. Note that the BSDL offers similar protections over time, but only in purportion to the community, so it is scary to release one's own code under the BSD license if you don't already have a strong community behind it.
In other words, they are either fanatical, ignorant, or have legitimate reasons for doing so
IANAL, but I have read a fair bit of legal analysis over the linking vs derivation argument. In general the concensus (outside the FSF) seems to be that linking is insufficient to show derivation, and that one can have derivative works even if they are loosely coupled (for example, by incorporating artistic elements from another program, particularly a video game, in a fixed way).
I would add a few things: I would argue that use of CPP macros are also insufficient to argue derivation for two reasons:
1) They are usually insubstantial and
2) Their use does not necessarily make a creative combination worthy of copyright.
Same with pretty much everything else in the header file.
Now this doesn't preclude you from running into problems. It just means that every possible case would need to be evaluated on a case by case basis. For example, nothing prevents a CPP macro from creating a derivative work when used just as nothing says that it always does.