The license text notice of the MIT License, the BSD License, and the ISC License all provide language offering a grant of certain copyrights. Excersize of section 7(2) restricts those rights which are granted by removing those permissions beyond the scope of the GPL v3.
Note that dependencies can only be used if they are compatible with the GPL v3 by allowing such relicensing provided that binary distribution is done (because when this happens, the dependencies' source must be part of the Corresponding Source and that work must be under the GPL v3.
EIther the BST, MIT, and ISC licenses allow you to change the license on the entire work (for example MIT Kerberos, BIND, PostgreSQL or similar) without adding any copyright-protected elements to the work and hence they are compatible, or the licenses restrict excersize of the grant to remove those additional permissions.
Interestingly, the GPL v2 has no linking clause as the GPL v3 does. Hence I see no reason why a GPL v2 program can't link to a GPL v3 program (this seems safer than getting into arguments about what permission removal means for BSDL dependnecies).
Ok, in my example, the Corresponding Source must be released under the GPL v3, correct?
The MIT Kerberos implemntation is part of the Corresponding Source, correct?
By including it in the Corresponding Source, the license must be GPL-compatible, correct? This means that it must be possible to convert the MIT License into the GPL with allowed additional restrictions (such as 7b legal notices) only. Even if the library code remains unchanged, correct?
The MIT License addresses *all* downstream recipients, correct?
Thus additional permissions cannot be removed from those libraries prior to alteration. Hence it limits the exercise of 7(2) rights to remove additional permissions.
Paragraph 2:
When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission. Final paragraph:
Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way. Does this make my position clearer now?
For better or worse I don't have the same level of trust. Furthermore, athough the FSF likes to pretend that Free Software is analogous to Free Speech, the fact is that their vision of free speech allows for a form of forced advocacy (given the history of the GFDL). See my latest journal entry for details.
This relates to the GPLv3 and section 7 how? This is another discussion, the one about taking non-copyleft code and stripping the licence away since it's "allowed". I don't think that it's allowed - but I'm open to different views- but this doesn't relate to the GPLv3 since the same doubt occurs with the GPLv2. Ok, assuming that Kerberos is not classified as a Major Component, then if I release a GPL v3 application which I distribute in binary form (as well as with the Corresponding Source) then I can only do it if and only if the Kerberos that I distribute with it (in this case MIT Kerberos) can have its license *changed* to the GPL v3 since it is now a portion of the Corresponding Source.
No, not exactly, I said that what *could* be unreasonable is the direct targeting of the licence under which exception you are adding the adittional restrictions under the "reasonable legal notices" umbrella. It wouldn't, as I said, make much difference in pratical terms since the exception is there to allow the MIT licence to be aggregated, as an extra file or with other licences, with the GPlv3 code and make it remain so since nobody can remove it. Would not any legal notice which includes a permission grant such as ".... are permitted providing...." or "Permission is hereby granted" add a restriction on the excersize of Section 7, paragraph 2? For example, until the functions are actually modified sufficiently to qualify as something other than nonliteral copies for the purpose of copyright law, I fail to see how these are actually different.
So, you must think that if I take, say, MIT Kerberos and change nothing but the license, that this is permissible under the terms of the MITL? So far I have not heard anyone make that argument seriously outside the FSF and Mr Moglen (in fact the SFLC specifically advises against it).
The only thing that would make you example "unreasonable" is the fact that it directly tries to undermine an entire section of the licence: even if the effects of not using that would be the same, I don't see that as "reasonable" since you could also say "without regard to the entire GPL you can make what you wish with the code in those functions, the code that uses those functions and any code that shared disk space with the files of those functions". Isn't that exactly what the MIT License does when it says that "Permission is hereby granted, free of charge, to any who receive..." The implied bit is that is without regard to any other licenses or sublicenses (hence in effect MIT License allows sublicensing as a form of legal relationship provided that the sublicense provides terms identical to the MITL itself).
Again, the difference here is that the MIT and BSD licenses only apply to specifically licensed copyrights for certain elements of the software where my example breaks things down on a functional level. This is the only difference.
Actually, on further research, I think your lawyers are right.
If someone downloads a copy of the GCC and puts it on a file share, so everyone on the team can use it, that is conveying under the GPL v3, and would seem to imply a grant of patent license.
("If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.")
I believe the intent of the paragraph cited above was to prevent internal distribution from qualifying, but the fact is, that if your team manager asks you to put it on a file share, that seems to me to be an arrangement which grants an implied patent license.
The GP's lawyers are doing what they are paid to do-- prevent the company from going near anything which could even possibly be used to argue things at odds with the company.
The key question is this:
If I download the GCC and put it on a file share, and someone else at the same company installs it from my file share, is that distribution? Does that trigger the patent license grants?
IANAL, but if I read the language closely, the answers would seem to be "yes" and "yes" when one disregards the intent of the license.
However, the problem that you get is that it is the intents of the licensors and licensees that matter, not the intent of the license authors.
If you distribute GPL v2 software and then sue for patent infrignement while you still are distributing the software, you are violating the authors' copyrights.
Furthermore, under the GPL v3 I can do a lot of things I couldn't under the GPL v2: 1) Release beta versions of software under NDA's provided that the contract also stipulates that they are receiving the software solely for the purpose of providing QA services for me by testing their own software against mine.
2) Use hypervisors and aggregated updates (for components in other VM's) to prevent updated software from doing anything (the software isn't interfered with in any way, but everything that it needs to talk to is missing if you provide your own update!)
3) Use hypervisors and other VMs to create DRM which can't be circumvented by accessing the source code of the kernel (because the decryption/hardware interfaces occur in another VM).
Seems like a lot of work to go to for not a lot more freedom of the end user.....
THe logic appears to be that if someone removes the "additional permissions" afforded by the BSDL, until they have their own valid copyrights in the work they don't have standing to sue for copyright infringement.
IANAL, but the problem I see here is that licenses are interpreted by the courts as contracts. This leaves open a large number of questions on contract theory which I would rather not ask a court.
Heck, I would rather keep my software under the GPL v2 when required libraries move (and hence that libraries are no different than referenced sources in an anthology and hence the use of libraries constitutes a collective work rather than a derivative one) than I would get into those questions.
It states that you can remove additional permissions when you *convey* the software. Conveyance doesn't add copyrights but it requries copyright permission.
The problem is that many of us believe that this is not allowed by permissive licenses in general-- that the permissive license always follows those specific copyrights which are licensed under it and that this is passed on to downstream users. This isn't an issue with the GPL v2 because when you create a derivative work, you add your own copyrights which can be licensed under the GPL v2 (and hence the work as a whole is licensed under the GPL v2 even if certain things could be extracted and used under the BSDL). Same with Microsoft's use of BSDL code-- they haven't changed the license on those specific copyrights, they have only enforced their own copyrights under different terms.
Suppose I license a program under the GPL v3 but also include a 7(b) legal notice which states:
"The author of this software hereby provides permission to all downstream recipients, without regard to the excersize of section 7, paragraph 2 removal of additional permissions, the right to extract the code from the following functions and use in any works under any other licenses provided that this notice is maintained."
Is that a valid section 7(b) legal notice? Is it an additional permission which can be removed? Is it an additional restriction which can be ignored? I believe that the BSDL, MITL, and similar licenses are of a similar nature.
For example, the inclusion of such clauses by the Apache Software License does not seem to make businesses less eager to donate code there....
However, the general argument still stands. In particular, there are sections in the GPL v3 which seem to me to be lawyerbombs or litigation magnets in that they appear to any reasonable reading to make license compatibility an open question, In particular, go read section 7, paragraph 2 of the GPL v3 and ask yourself if it can be applied to BSD-licensed software where the license grant must be reproduced exactly for covered copyrights (BSDL is not copyleft because it *only* follows copyrights licensed under that license and does not provide restrictions on licensing other copyrights added for derivative works).
I would argue that the MIT license is incompatible for the same reason. Namely because one cannot take BSD or MIT-licensed copyrights and change the terms on them later because the author grants these rights to all downstream users. The only answers that I have been able to get from Mr Moglen seem to be that it doesn't matter because you could get such a suit dismissed for reasons of standing, but that ought to make people nervous.
The FSF addresses the ability to remove additional permissions and distribute under a more restrictive license. The GPL v3 is written as if this can be done for any piece of a covered work and does *not* suggest that the license reverts when that piece is later extracted. This has lead me to conclude that the GPL v3 is incompatible with permissive licenses such as the BSDL because:
1) The BSDL addresses *all* downstream recipients of covered copyrights and 2) The BSDL itself is an invariant license which follows those covered copyrights.
Thus I argue that these permissive licenses essentially limit the ways in which section 7 paragraph 2 can be meaningfully excersized. One cannot just take some BSD files include them verbatem, and change the license as one desires to do.
What does going with a relational system as opposed to a simple object persistance mechanism give you in this case?
In an accounting system, we have to do a lot of aggregates and are dealing generally with complex ways of presetning relational data. Yes, this could be abstracted away but you would lose the ability to do certain types of data enforcement unless you put it in stored procedures (for example, the fact that each transaction must have an equal number of debits and credits).
If all you are doing is storing and retriving object data and meta-data, why use a relational system at all? Why not program to the interfaces with BDB, the equivalent from GNU, or the like?
Of course, if you are (like me) creating an accounting/ERP system, then the relational needs are a lot heavier and hence we need to keep quite a bit closer to the db.
If course they have some UNIX IP. Just not the source for SVRX. For example, I am pretty sure that the source code for every version of Xenix/OpenUnix, etc. is going to be copyrighted by them. That may be sorth something. Part of the issue though is that IBM's patent counterclaims basically can be used to ensure that IBM has control over the use of certain technologies marketed in the past by Caldera/SCO.
When I built HERMES, I took the approach of wrapping various forms of database behavior in abstraction layers. Eventually I dropped MySQL because there were some things I needed subqueries for and MySQL didn't support them at the time. I had by that time emulated role-based security on MySQL 3.x which required a *lot* of code.
Later I have looked at ORMs and the like. I have concluded that there is no good answer to the ORM problem on a math level (though I am slowly reconsidering that perspective, it is clear that nearly all ORM's suck from a relational perspective).
Also, if all you want is a data bucket, why use MySQL at all? Why not use BDB?
They still have copyrights of their own and UNIX license revenue.
The big issue is that unless the lawsuits are stupped, IBM will more or less destroy what UNIX IP SCO does have via patent infringement lawsuits.
There may be other assets here too, MWouldn't it be funny of Microsoft purchased the SCO OpenUNIX source code copyrights (full circle since the original SCO got their UNIX division started by buying Xenix from Microsoft).
IBM has patent counterclaims which would follow the UNIX IP. If YCM takes over the UNIX IP, and they let SCO take on the current liability, then IBM's counterclaims could still make their IP worthless.
Am I missing something? This is not a no-risk deal for YCM.
This whole thing smells of back-room deals. It basicaly means that you only have two possibilities:
1) Deals have already been made to end the lawsuits (remember IBM's patent counterclaims? Those go with the UNIX business!) 2) There is an honest belief that there is sufficient reward to continue with the suits. In which case YCM will get buried along with SCO.
I certainly hope it is the former. But corporations can be stupid sometimes (remember MS Bob? this could be the same sort of thing but with far greater consequence.)
Given how different the internals of the software are, I am not sure there would be any derivation of the PostgreSQL patches from the original code.
Furthermore, nothing prevents Google from licensing their code with more permissions than the GPL. Hence the BSDL could be used on the patch as well, though again, I very much doubt that it would be helpful to PostgreSQL.
The license text notice of the MIT License, the BSD License, and the ISC License all provide language offering a grant of certain copyrights. Excersize of section 7(2) restricts those rights which are granted by removing those permissions beyond the scope of the GPL v3.
Note that dependencies can only be used if they are compatible with the GPL v3 by allowing such relicensing provided that binary distribution is done (because when this happens, the dependencies' source must be part of the Corresponding Source and that work must be under the GPL v3.
EIther the BST, MIT, and ISC licenses allow you to change the license on the entire work (for example MIT Kerberos, BIND, PostgreSQL or similar) without adding any copyright-protected elements to the work and hence they are compatible, or the licenses restrict excersize of the grant to remove those additional permissions.
Interestingly, the GPL v2 has no linking clause as the GPL v3 does. Hence I see no reason why a GPL v2 program can't link to a GPL v3 program (this seems safer than getting into arguments about what permission removal means for BSDL dependnecies).
Ok, in my example, the Corresponding Source must be released under the GPL v3, correct?
The MIT Kerberos implemntation is part of the Corresponding Source, correct?
By including it in the Corresponding Source, the license must be GPL-compatible, correct? This means that it must be possible to convert the MIT License into the GPL with allowed additional restrictions (such as 7b legal notices) only. Even if the library code remains unchanged, correct?
The MIT License addresses *all* downstream recipients, correct?
Thus additional permissions cannot be removed from those libraries prior to alteration. Hence it limits the exercise of 7(2) rights to remove additional permissions.
Paragraph 2: When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission. Final paragraph: Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way. Does this make my position clearer now?
For better or worse I don't have the same level of trust. Furthermore, athough the FSF likes to pretend that Free Software is analogous to Free Speech, the fact is that their vision of free speech allows for a form of forced advocacy (given the history of the GFDL). See my latest journal entry for details.
if you stop conveying the software, can you retract your patent license to those whom you conveyed the software too?
So, you must think that if I take, say, MIT Kerberos and change nothing but the license, that this is permissible under the terms of the MITL? So far I have not heard anyone make that argument seriously outside the FSF and Mr Moglen (in fact the SFLC specifically advises against it). The only thing that would make you example "unreasonable" is the fact that it directly tries to undermine an entire section of the licence: even if the effects of not using that would be the same, I don't see that as "reasonable" since you could also say "without regard to the entire GPL you can make what you wish with the code in those functions, the code that uses those functions and any code that shared disk space with the files of those functions". Isn't that exactly what the MIT License does when it says that "Permission is hereby granted, free of charge, to any who receive..." The implied bit is that is without regard to any other licenses or sublicenses (hence in effect MIT License allows sublicensing as a form of legal relationship provided that the sublicense provides terms identical to the MITL itself).
Again, the difference here is that the MIT and BSD licenses only apply to specifically licensed copyrights for certain elements of the software where my example breaks things down on a functional level. This is the only difference.
Actually, on further research, I think your lawyers are right.
If someone downloads a copy of the GCC and puts it on a file share, so everyone on the team can use it, that is conveying under the GPL v3, and would seem to imply a grant of patent license.
("If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.")
I believe the intent of the paragraph cited above was to prevent internal distribution from qualifying, but the fact is, that if your team manager asks you to put it on a file share, that seems to me to be an arrangement which grants an implied patent license.
The GP's lawyers are doing what they are paid to do-- prevent the company from going near anything which could even possibly be used to argue things at odds with the company.
The key question is this:
If I download the GCC and put it on a file share, and someone else at the same company installs it from my file share, is that distribution? Does that trigger the patent license grants?
IANAL, but if I read the language closely, the answers would seem to be "yes" and "yes" when one disregards the intent of the license.
However, the problem that you get is that it is the intents of the licensors and licensees that matter, not the intent of the license authors.
If you distribute GPL v2 software and then sue for patent infrignement while you still are distributing the software, you are violating the authors' copyrights.
Furthermore, under the GPL v3 I can do a lot of things I couldn't under the GPL v2:
1) Release beta versions of software under NDA's provided that the contract also stipulates that they are receiving the software solely for the purpose of providing QA services for me by testing their own software against mine.
2) Use hypervisors and aggregated updates (for components in other VM's) to prevent updated software from doing anything (the software isn't interfered with in any way, but everything that it needs to talk to is missing if you provide your own update!)
3) Use hypervisors and other VMs to create DRM which can't be circumvented by accessing the source code of the kernel (because the decryption/hardware interfaces occur in another VM).
Seems like a lot of work to go to for not a lot more freedom of the end user.....
if he is a licensed practitioner of law and this is a cosmetic change of name or if I am as competent to speak on these matters as he is.
THe logic appears to be that if someone removes the "additional permissions" afforded by the BSDL, until they have their own valid copyrights in the work they don't have standing to sue for copyright infringement.
IANAL, but the problem I see here is that licenses are interpreted by the courts as contracts. This leaves open a large number of questions on contract theory which I would rather not ask a court.
Heck, I would rather keep my software under the GPL v2 when required libraries move (and hence that libraries are no different than referenced sources in an anthology and hence the use of libraries constitutes a collective work rather than a derivative one) than I would get into those questions.
It states that you can remove additional permissions when you *convey* the software. Conveyance doesn't add copyrights but it requries copyright permission.
The problem is that many of us believe that this is not allowed by permissive licenses in general-- that the permissive license always follows those specific copyrights which are licensed under it and that this is passed on to downstream users. This isn't an issue with the GPL v2 because when you create a derivative work, you add your own copyrights which can be licensed under the GPL v2 (and hence the work as a whole is licensed under the GPL v2 even if certain things could be extracted and used under the BSDL). Same with Microsoft's use of BSDL code-- they haven't changed the license on those specific copyrights, they have only enforced their own copyrights under different terms.
Suppose I license a program under the GPL v3 but also include a 7(b) legal notice which states:
"The author of this software hereby provides permission to all downstream recipients, without regard to the excersize of section 7, paragraph 2 removal of additional permissions, the right to extract the code from the following functions and use in any works under any other licenses provided that this notice is maintained."
Is that a valid section 7(b) legal notice? Is it an additional permission which can be removed? Is it an additional restriction which can be ignored? I believe that the BSDL, MITL, and similar licenses are of a similar nature.
For example, the inclusion of such clauses by the Apache Software License does not seem to make businesses less eager to donate code there....
However, the general argument still stands. In particular, there are sections in the GPL v3 which seem to me to be lawyerbombs or litigation magnets in that they appear to any reasonable reading to make license compatibility an open question, In particular, go read section 7, paragraph 2 of the GPL v3 and ask yourself if it can be applied to BSD-licensed software where the license grant must be reproduced exactly for covered copyrights (BSDL is not copyleft because it *only* follows copyrights licensed under that license and does not provide restrictions on licensing other copyrights added for derivative works).
I would argue that the MIT license is incompatible for the same reason. Namely because one cannot take BSD or MIT-licensed copyrights and change the terms on them later because the author grants these rights to all downstream users. The only answers that I have been able to get from Mr Moglen seem to be that it doesn't matter because you could get such a suit dismissed for reasons of standing, but that ought to make people nervous.
The FSF addresses the ability to remove additional permissions and distribute under a more restrictive license. The GPL v3 is written as if this can be done for any piece of a covered work and does *not* suggest that the license reverts when that piece is later extracted. This has lead me to conclude that the GPL v3 is incompatible with permissive licenses such as the BSDL because:
1) The BSDL addresses *all* downstream recipients of covered copyrights and
2) The BSDL itself is an invariant license which follows those covered copyrights.
Thus I argue that these permissive licenses essentially limit the ways in which section 7 paragraph 2 can be meaningfully excersized. One cannot just take some BSD files include them verbatem, and change the license as one desires to do.
What does going with a relational system as opposed to a simple object persistance mechanism give you in this case?
In an accounting system, we have to do a lot of aggregates and are dealing generally with complex ways of presetning relational data. Yes, this could be abstracted away but you would lose the ability to do certain types of data enforcement unless you put it in stored procedures (for example, the fact that each transaction must have an equal number of debits and credits).
I guess you are missing my point.
If all you are doing is storing and retriving object data and meta-data, why use a relational system at all? Why not program to the interfaces with BDB, the equivalent from GNU, or the like?
Of course, if you are (like me) creating an accounting/ERP system, then the relational needs are a lot heavier and hence we need to keep quite a bit closer to the db.
If course they have some UNIX IP. Just not the source for SVRX. For example, I am pretty sure that the source code for every version of Xenix/OpenUnix, etc. is going to be copyrighted by them. That may be sorth something. Part of the issue though is that IBM's patent counterclaims basically can be used to ensure that IBM has control over the use of certain technologies marketed in the past by Caldera/SCO.
When I built HERMES, I took the approach of wrapping various forms of database behavior in abstraction layers. Eventually I dropped MySQL because there were some things I needed subqueries for and MySQL didn't support them at the time. I had by that time emulated role-based security on MySQL 3.x which required a *lot* of code.
Later I have looked at ORMs and the like. I have concluded that there is no good answer to the ORM problem on a math level (though I am slowly reconsidering that perspective, it is clear that nearly all ORM's suck from a relational perspective).
Also, if all you want is a data bucket, why use MySQL at all? Why not use BDB?
Yes, but it does mean that as a programmer, you can't count on your user having foreign key enforcement.
The issues are:
1) Only *some* MySQL servers have foreign keys
2) Valid SQL syntax for foreign keys is silently ignored.
#2 isn't a huge issue but it leads to bugs. #1 is the killer when you are distributing real software.
They still have copyrights of their own and UNIX license revenue.
The big issue is that unless the lawsuits are stupped, IBM will more or less destroy what UNIX IP SCO does have via patent infringement lawsuits.
There may be other assets here too, MWouldn't it be funny of Microsoft purchased the SCO OpenUNIX source code copyrights (full circle since the original SCO got their UNIX division started by buying Xenix from Microsoft).
IBM has patent counterclaims which would follow the UNIX IP. If YCM takes over the UNIX IP, and they let SCO take on the current liability, then IBM's counterclaims could still make their IP worthless.
Am I missing something? This is not a no-risk deal for YCM.
Not so sure.
This whole thing smells of back-room deals. It basicaly means that you only have two possibilities:
1) Deals have already been made to end the lawsuits (remember IBM's patent counterclaims? Those go with the UNIX business!)
2) There is an honest belief that there is sufficient reward to continue with the suits. In which case YCM will get buried along with SCO.
I certainly hope it is the former. But corporations can be stupid sometimes (remember MS Bob? this could be the same sort of thing but with far greater consequence.)
Given how different the internals of the software are, I am not sure there would be any derivation of the PostgreSQL patches from the original code.
Furthermore, nothing prevents Google from licensing their code with more permissions than the GPL. Hence the BSDL could be used on the patch as well, though again, I very much doubt that it would be helpful to PostgreSQL.
Google will get a MySQL injection....