-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sam Liddicott wrote:
Sorry for top quoting (darn pocket outlook, roll-on neo 1973)
Your scenario is nearly right.
What if the same person adds features to gcc as well.
Are those features AGPL or GPL as gcc is gpl. I want then to be gpl, I think they would be AGPl.
Well, since the features added would be part of the work for which the GPLv3 "will continue to apply", they will be GPLv3.
Any changes which can be isolated to a part covered by the GPLv3 will be GPLv3. Only such changes as apply to the parts covered by the AGPL or the work as a whole (i.e., glue connecting the two parts) will be AGPL.
At least that's how I read it.
- -- http://www.modspil.dk/itpolitik
On Fri, 2007-11-23 at 23:03 +0100, Carsten Agger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sam Liddicott wrote:
Sorry for top quoting (darn pocket outlook, roll-on neo 1973)
Your scenario is nearly right.
What if the same person adds features to gcc as well.
Are those features AGPL or GPL as gcc is gpl. I want then to be gpl, I think they would be AGPl.
Well, since the features added would be part of the work for which the GPLv3 "will continue to apply", they will be GPLv3.
Any changes which can be isolated to a part covered by the GPLv3 will be GPLv3. Only such changes as apply to the parts covered by the AGPL or the work as a whole (i.e., glue connecting the two parts) will be AGPL.
At least that's how I read it.
This is how I read it too so far.
Simo.
simo wrote:
On Fri, 2007-11-23 at 23:03 +0100, Carsten Agger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sam Liddicott wrote:
Sorry for top quoting (darn pocket outlook, roll-on neo 1973)
Your scenario is nearly right.
What if the same person adds features to gcc as well.
Are those features AGPL or GPL as gcc is gpl. I want then to be gpl, I think they would be AGPl.
Well, since the features added would be part of the work for which the GPLv3 "will continue to apply", they will be GPLv3.
Any changes which can be isolated to a part covered by the GPLv3 will be GPLv3. Only such changes as apply to the parts covered by the AGPL or the work as a whole (i.e., glue connecting the two parts) will be AGPL.
At least that's how I read it.
This is how I read it too so far.
It's how I read the AGPL - except the GPL3/13 allows conversion of the GPL3 work to AGPL in which case the modifications could be AGPL.
It seems to me that GPL3/13 that gives authority to do this, not AGP - if the recipient chooses to act on that authority and do so.
However, a summary of points will be collated on Monday for a request of official clarification as per Shane's suggestion.
I enjoyed the discussion, anyway... even though I got a little overheated, so thanks all, for being so frank so that we could understand each-others concerns and understandings.
Sam
On Sat, 2007-11-24 at 00:06 +0000, Sam Liddicott wrote:
simo wrote:
On Fri, 2007-11-23 at 23:03 +0100, Carsten Agger wrote:
Well, since the features added would be part of the work for which the GPLv3 "will continue to apply", they will be GPLv3.
Any changes which can be isolated to a part covered by the GPLv3 will be GPLv3. Only such changes as apply to the parts covered by the AGPL or the work as a whole (i.e., glue connecting the two parts) will be AGPL.
At least that's how I read it.
This is how I read it too so far.
It's how I read the AGPL - except the GPL3/13 allows conversion of the GPL3 work to AGPL in which case the modifications could be AGPL.
It seems to me that GPL3/13 that gives authority to do this, not AGP - if the recipient chooses to act on that authority and do so.
However, a summary of points will be collated on Monday for a request of official clarification as per Shane's suggestion.
I enjoyed the discussion, anyway... even though I got a little overheated, so thanks all, for being so frank so that we could understand each-others concerns and understandings.
I have exchanged a couple of emails with Richard Fontana of SFLC, one of they key lawyers involved in helping FSF coming up with the GPLv3 during the drafting process.
He told me his personal opinion, which is not necessarily what the FSF thinks, is that my read of the clause is close to his reading.
Basically, Richard thinks that the "linked or combined" language does not imply modification. IE, releasing a patch against the GPLv3 part of the work under AGPLv3 would even be a copyright violation. The patch needs to be GPLv3. Only the combination of the works obeys to AGPLv3's additional requirements. But each piece retains completely its license.
Therefore there is no risk that a GPLv3 work can be effectively turned into an AGPLv3 work by means of patches.
Simo.
* simo wrote, On 29/11/07 22:57:
It's how I read the AGPL - except the GPL3/13 allows conversion of the GPL3 work to AGPL in which case the modifications could be AGPL.
It seems to me that GPL3/13 that gives authority to do this, not AGP - if the recipient chooses to act on that authority and do so.
However, a summary of points will be collated on Monday for a request of official clarification as per Shane's suggestion.
I enjoyed the discussion, anyway... even though I got a little overheated, so thanks all, for being so frank so that we could understand each-others concerns and understandings.
I have exchanged a couple of emails with Richard Fontana of SFLC, one of they key lawyers involved in helping FSF coming up with the GPLv3 during the drafting process.
He told me his personal opinion, which is not necessarily what the FSF thinks, is that my read of the clause is close to his reading.
Basically, Richard thinks that the "linked or combined" language does not imply modification. IE, releasing a patch against the GPLv3 part of the work under AGPLv3 would even be a copyright violation. The patch needs to be GPLv3. Only the combination of the works obeys to AGPLv3's additional requirements. But each piece retains completely its license.
Therefore there is no risk that a GPLv3 work can be effectively turned into an AGPLv3 work by means of patches.
Thanks for following this up.
I hope then, that "combine" does not permit modification.
(Please don't think I am being pedantic here, I try to understand the scope of rules by discovering their boundaries, and that is what I am doing here, and I appreciate your indulgence and help.)
However, if the modifier can't release an AGPL patch to the GPL3 portion they may choose to not release a patch, but to merely continue to distribute the combined work as permitted by the AGPL. It seems like the AGPL then would prohibit the separation of the patch from the combined work (which may not be what the license authors intended)
Do you think from what Richard says that the original GPL3 author can extract this modification to the GPL3 portion as a GPL3 patch, (the patch not being his work and only distributed as part of the AGPL combination) and combine this patch with his own work and distribute it according to the GPL3?
An example case: if a glue-class is written in php, subclassing a class from the GPL3 module, but instantiated by the AGPL3 module (thus also performing a link operation), and it be this subclass that has some implementation that "ought" to be incorporated into the GPL3 module, will the GPL3 author, receiving the source by virtue of being a "user" of the AGPL3 work, be able to combine parts of this subclass into his own work, without receiving addition permissions fro the subclass author?
Sam
On Fri, 2007-11-30 at 09:39 +0000, Sam Liddicott wrote:
- simo wrote, On 29/11/07 22:57:
It's how I read the AGPL - except the GPL3/13 allows conversion of the GPL3 work to AGPL in which case the modifications could be AGPL.
It seems to me that GPL3/13 that gives authority to do this, not AGP - if the recipient chooses to act on that authority and do so.
However, a summary of points will be collated on Monday for a request of official clarification as per Shane's suggestion.
I enjoyed the discussion, anyway... even though I got a little overheated, so thanks all, for being so frank so that we could understand each-others concerns and understandings.
I have exchanged a couple of emails with Richard Fontana of SFLC, one of they key lawyers involved in helping FSF coming up with the GPLv3 during the drafting process.
He told me his personal opinion, which is not necessarily what the FSF thinks, is that my read of the clause is close to his reading.
Basically, Richard thinks that the "linked or combined" language does not imply modification. IE, releasing a patch against the GPLv3 part of the work under AGPLv3 would even be a copyright violation. The patch needs to be GPLv3. Only the combination of the works obeys to AGPLv3's additional requirements. But each piece retains completely its license.
Therefore there is no risk that a GPLv3 work can be effectively turned into an AGPLv3 work by means of patches.
Thanks for following this up.
I hope then, that "combine" does not permit modification.
(Please don't think I am being pedantic here, I try to understand the scope of rules by discovering their boundaries, and that is what I am doing here, and I appreciate your indulgence and help.)
Yes I think "combine" does not include modification, just those cases where "linking" was not enough to include "potentially license infringing" interactions beyond linking.
However, if the modifier can't release an AGPL patch to the GPL3 portion they may choose to not release a patch, but to merely continue to distribute the combined work as permitted by the AGPL.
No, I think you can *not* release that patch under the AGPL. That patch will always be GPLv3. When you let people download the source code it will be on the GPLv3 work side and clearly GPLv3.
It seems like the AGPL then would prohibit the separation of the patch from the combined work (which may not be what the license authors intended)
I don't think this is possible or make sense to me.
Do you think from what Richard says that the original GPL3 author can extract this modification to the GPL3 portion as a GPL3 patch, (the patch not being his work and only distributed as part of the AGPL combination) and combine this patch with his own work and distribute it according to the GPL3?
I think, and Richard opinion seem to be the same, that you simply can't release that patch "under the AGPL". All you do is release it under the GPL together with the rest of the GPL work. Only if the application is a combination of AGPL and GPL code, then you have to provide for download also the GPL part. But the GPL stuff is *always* GPL, it is never AGPL.
An example case: if a glue-class is written in php, subclassing a class from the GPL3 module, but instantiated by the AGPL3 module (thus also performing a link operation), and it be this subclass that has some implementation that "ought" to be incorporated into the GPL3 module, will the GPL3 author, receiving the source by virtue of being a "user" of the AGPL3 work, be able to combine parts of this subclass into his own work, without receiving addition permissions fro the subclass author?
I think the "instantiation" is the linking/combination, but the class is tied to the GPLv3 work. Therefore, my interpretation in this case, would be that the class is GPLv3 bound. But this is all thin air, I think we need to see a very specific case to determine that with some clue.
I think in some cases it can be very hard, but I guess it all boils down to the authors defining what they consider being the boundaries. If I were an AGPL author I would think twice the way I link to GPLv3 stuff and err on the GPLv3 side for any glue code.
Simo.
* simo wrote, On 30/11/07 15:25:
On Fri, 2007-11-30 at 09:39 +0000, Sam Liddicott wrote:
- simo wrote, On 29/11/07 22:57:
It's how I read the AGPL - except the GPL3/13 allows conversion of the GPL3 work to AGPL in which case the modifications could be AGPL.
It seems to me that GPL3/13 that gives authority to do this, not AGP - if the recipient chooses to act on that authority and do so.
However, a summary of points will be collated on Monday for a request of official clarification as per Shane's suggestion.
I enjoyed the discussion, anyway... even though I got a little overheated, so thanks all, for being so frank so that we could understand each-others concerns and understandings.
I have exchanged a couple of emails with Richard Fontana of SFLC, one of they key lawyers involved in helping FSF coming up with the GPLv3 during the drafting process.
He told me his personal opinion, which is not necessarily what the FSF thinks, is that my read of the clause is close to his reading.
Basically, Richard thinks that the "linked or combined" language does not imply modification. IE, releasing a patch against the GPLv3 part of the work under AGPLv3 would even be a copyright violation. The patch needs to be GPLv3. Only the combination of the works obeys to AGPLv3's additional requirements. But each piece retains completely its license.
Therefore there is no risk that a GPLv3 work can be effectively turned into an AGPLv3 work by means of patches.
Thanks for following this up.
I hope then, that "combine" does not permit modification.
(Please don't think I am being pedantic here, I try to understand the scope of rules by discovering their boundaries, and that is what I am doing here, and I appreciate your indulgence and help.)
Yes I think "combine" does not include modification, just those cases where "linking" was not enough to include "potentially license infringing" interactions beyond linking.
However, if the modifier can't release an AGPL patch to the GPL3 portion they may choose to not release a patch, but to merely continue to distribute the combined work as permitted by the AGPL.
No, I think you can *not* release that patch under the AGPL. That patch will always be GPLv3. When you let people download the source code it will be on the GPLv3 work side and clearly GPLv3.
And if it is never released or distributed as a patch, but just a combined modified AGPL work?
It seems like the AGPL then would prohibit the separation of the patch from the combined work (which may not be what the license authors intended)
I don't think this is possible or make sense to me.
As you said, if the patch was AGPL it could not be distributed. If the patch is not distributed then there is just a modified AGPL work and if the patch were extracted it would be derived from the combined AGPL work and so AGPL licensed. And then, cannot be distributed as you said, because it is also derived from a GPL3 work? Or can it?
Do you think from what Richard says that the original GPL3 author can extract this modification to the GPL3 portion as a GPL3 patch, (the patch not being his work and only distributed as part of the AGPL combination) and combine this patch with his own work and distribute it according to the GPL3?
I think, and Richard opinion seem to be the same, that you simply can't release that patch "under the AGPL". All you do is release it under the GPL together with the rest of the GPL work. Only if the application is a combination of AGPL and GPL code, then you have to provide for download also the GPL part. But the GPL stuff is *always* GPL, it is never AGPL.
Sure, if the modifier releases a patch. What if they don't? Can the original author as a recipient of the AGPL source diff one?
An example case: if a glue-class is written in php, subclassing a class from the GPL3 module, but instantiated by the AGPL3 module (thus also performing a link operation), and it be this subclass that has some implementation that "ought" to be incorporated into the GPL3 module, will the GPL3 author, receiving the source by virtue of being a "user" of the AGPL3 work, be able to combine parts of this subclass into his own work, without receiving addition permissions fro the subclass author?
I think the "instantiation" is the linking/combination, but the class is tied to the GPLv3 work. Therefore, my interpretation in this case, would be that the class is GPLv3 bound. But this is all thin air, I think we need to see a very specific case to determine that with some clue.
I should have been more clear, but it's hard because the subclass (as glue) could easily equally be part of either work. And what if the subclass author says it is an AGPL subclass? Then precisely the GPL3 author cannot add this to the GPL3 work. So the linking boundary can be used to derive
(I have often subclassed web toolkits because it helps upgrades of the toolkit to easily be applied as long as the API is stable.)
I think in some cases it can be very hard, but I guess it all boils down to the authors defining what they consider being the boundaries. If I were an AGPL author I would think twice the way I link to GPLv3 stuff and err on the GPLv3 side for any glue code.
Yes... I'm worried about authors who want to promote the AGPL and so are happy to break the GPL expectation of equal sharing.
Sam
On Fri, 2007-11-30 at 15:30 +0000, Sam Liddicott wrote:
- simo wrote, On 30/11/07 15:25:
On Fri, 2007-11-30 at 09:39 +0000, Sam Liddicott wrote:
- simo wrote, On 29/11/07 22:57:
It's how I read the AGPL - except the GPL3/13 allows conversion of the GPL3 work to AGPL in which case the modifications could be AGPL.
It seems to me that GPL3/13 that gives authority to do this, not AGP - if the recipient chooses to act on that authority and do so.
However, a summary of points will be collated on Monday for a request of official clarification as per Shane's suggestion.
I enjoyed the discussion, anyway... even though I got a little overheated, so thanks all, for being so frank so that we could understand each-others concerns and understandings.
I have exchanged a couple of emails with Richard Fontana of SFLC, one of they key lawyers involved in helping FSF coming up with the GPLv3 during the drafting process.
He told me his personal opinion, which is not necessarily what the FSF thinks, is that my read of the clause is close to his reading.
Basically, Richard thinks that the "linked or combined" language does not imply modification. IE, releasing a patch against the GPLv3 part of the work under AGPLv3 would even be a copyright violation. The patch needs to be GPLv3. Only the combination of the works obeys to AGPLv3's additional requirements. But each piece retains completely its license.
Therefore there is no risk that a GPLv3 work can be effectively turned into an AGPLv3 work by means of patches.
Thanks for following this up.
I hope then, that "combine" does not permit modification.
(Please don't think I am being pedantic here, I try to understand the scope of rules by discovering their boundaries, and that is what I am doing here, and I appreciate your indulgence and help.)
Yes I think "combine" does not include modification, just those cases where "linking" was not enough to include "potentially license infringing" interactions beyond linking.
However, if the modifier can't release an AGPL patch to the GPL3 portion they may choose to not release a patch, but to merely continue to distribute the combined work as permitted by the AGPL.
No, I think you can *not* release that patch under the AGPL. That patch will always be GPLv3. When you let people download the source code it will be on the GPLv3 work side and clearly GPLv3.
And if it is never released or distributed as a patch, but just a combined modified AGPL work?
AGPL mandates you to distribute the source code. The code will be *there* and it will *have to be* GPLv3. Remember each piece maintains it's own license, it is just that you have to provide the GPLv3 piece as well, but the license for the source code is GPLv3 not AGPLv3.
It seems like the AGPL then would prohibit the separation of the patch from the combined work (which may not be what the license authors intended)
I don't think this is possible or make sense to me.
As you said, if the patch was AGPL it could not be distributed. If the patch is not distributed then there is just a modified AGPL work and if the patch were extracted it would be derived from the combined AGPL work and so AGPL licensed.
I think you still don't get the fact that the license *do not* apply to the whole work. It applies to the AGPL pieces only. It's just that you have to distribute all the pieces, but that does not change any code license.
And then, cannot be distributed as you said, because it is also derived from a GPL3 work? Or can it?
It can be distributed but it will be GPLv3 all the time.
Do you think from what Richard says that the original GPL3 author can extract this modification to the GPL3 portion as a GPL3 patch, (the patch not being his work and only distributed as part of the AGPL combination) and combine this patch with his own work and distribute it according to the GPL3?
I think, and Richard opinion seem to be the same, that you simply can't release that patch "under the AGPL". All you do is release it under the GPL together with the rest of the GPL work. Only if the application is a combination of AGPL and GPL code, then you have to provide for download also the GPL part. But the GPL stuff is *always* GPL, it is never AGPL.
Sure, if the modifier releases a patch. What if they don't? Can the original author as a recipient of the AGPL source diff one?
You always distribute the code, as that's what the AGPL mandates. The fact that the code is in patch form or not makes absolutely no difference in this case.
An example case: if a glue-class is written in php, subclassing a class from the GPL3 module, but instantiated by the AGPL3 module (thus also performing a link operation), and it be this subclass that has some implementation that "ought" to be incorporated into the GPL3 module, will the GPL3 author, receiving the source by virtue of being a "user" of the AGPL3 work, be able to combine parts of this subclass into his own work, without receiving addition permissions fro the subclass author?
I think the "instantiation" is the linking/combination, but the class is tied to the GPLv3 work. Therefore, my interpretation in this case, would be that the class is GPLv3 bound. But this is all thin air, I think we need to see a very specific case to determine that with some clue.
I should have been more clear, but it's hard because the subclass (as glue) could easily equally be part of either work. And what if the subclass author says it is an AGPL subclass?
I think this is too vague. We need to see real examples, trying to make up a case will give you no valuable answer.
Then precisely the GPL3 author cannot add this to the GPL3 work. So the linking boundary can be used to derive
No read the above I think you misunderstand the distribution terms of a combined work completely.
(I have often subclassed web toolkits because it helps upgrades of the toolkit to easily be applied as long as the API is stable.)
Yes but that is a different thing I think you can see the difference between abstracting an interface (and the interface I guess can be considered the GPLv3 boundary in some cases) and adding core functionality.
I think in some cases it can be very hard, but I guess it all boils down to the authors defining what they consider being the boundaries. If I were an AGPL author I would think twice the way I link to GPLv3 stuff and err on the GPLv3 side for any glue code.
Yes... I'm worried about authors who want to promote the AGPL and so are happy to break the GPL expectation of equal sharing.
It is clear to me we will need to educate people a lot, but that's another story :-)
Simo.
* simo wrote, On 30/11/07 16:09:
On Fri, 2007-11-30 at 15:30 +0000, Sam Liddicott wrote:
And if it is never released or distributed as a patch, but just a combined modified AGPL work?
AGPL mandates you to distribute the source code. The code will be *there* and it will *have to be* GPLv3. Remember each piece maintains it's own license, it is just that you have to provide the GPLv3 piece as well, but the license for the source code is GPLv3 not AGPLv3.
This is what I hope is actually the case, and represents what think fair.
It seems like the AGPL then would prohibit the separation of the patch from the combined work (which may not be what the license authors intended)
I don't think this is possible or make sense to me.
As you said, if the patch was AGPL it could not be distributed. If the patch is not distributed then there is just a modified AGPL work and if the patch were extracted it would be derived from the combined AGPL work and so AGPL licensed.
I think you still don't get the fact that the license *do not* apply to the whole work. It applies to the AGPL pieces only. It's just that you have to distribute all the pieces, but that does not change any code license.
I think your explanation of "combine" shows that this is the case. Reading GPL3/13 in this light and
It is clear to me we will need to educate people a lot, but that's another story :-)
Always the hard part.. - thanks for your patience.
I'll ruminate, but I believe that I am content that GPL3/13 and AGPL/13 mean and are intended to mean what you explained, affecting only the distribution of source of the combined work, and not in any way affecting the license of derivations of either work (which are already covered by the rest of the respective licenses).
I think now that GPL3/13 does not permit the "upgrade" of the license, merely makes it subject to the requirements of AGPL/13 when so combined, and allowing de-combination according to the licenses of the individual works. Careless licensing of some enhancements may cause confusion (*cough*) but that is all.
Now I see that, it's hard to see how I mis-understood it. Maybe it was a bad thinking day, or maybe it's like the old-woman/Eskimo picture, you can only see one situation at a time.
Anyway... thanks
Sam
simo simo.sorce@xsec.it wrote: [...]
I think in some cases it can be very hard, but I guess it all boils down to the authors defining what they consider being the boundaries.
That would create a lawyerbomb in itself, which isn't really good for free software.
I think it isn't very clear what is a derived work of a GPLv3 source code and what is combining a GPLv3 with a clean-room AGPLv3 source that just happens to fit well with the GPLv3 one.
If I were an AGPL author I would think twice the way I link to GPLv3 stuff and err on the GPLv3 side for any glue code.
That wouldn't achieve the common AGPL author's desire of enforced sharing over the network. (Nor will the AGPL, but they most people seem to ignore that...)
Best wishes,
MJ Ray wrote:
simo simo.sorce@xsec.it wrote: [...]
I think in some cases it can be very hard, but I guess it all boils down to the authors defining what they consider being the boundaries.
That would create a lawyerbomb in itself, which isn't really good for free software.
I think it isn't very clear what is a derived work of a GPLv3 source code and what is combining a GPLv3 with a clean-room AGPLv3 source that just happens to fit well with the GPLv3 one.
I think (at the moment) that the combining is only an exception for the purposes of running GPL3 code with AGPL. Any modifications to either work fall under existing licenses. GPL3/13 as I presently understand it adds a restriction of AGPL when conveyed with AGPL, but does not affect the works own license.
If I were an AGPL author I would think twice the way I link to GPLv3 stuff and err on the GPLv3 side for any glue code.
That wouldn't achieve the common AGPL author's desire of enforced sharing over the network. (Nor will the AGPL, but they most people seem to ignore that...)
Best wishes,
My current (enlightened?) reading is that GPl3 users who can get the AGPL combined source can use derivations of the GPL work (which must be GPL licensed) in their GPL work according to the GPL.
So true non-linking/combining mix-derivations of AGPL and GPL3 works will be very hard as the licenses are not actually compatible.
Sam
* simo simo.sorce@xsec.it [071129 23:52]:
Basically, Richard thinks that the "linked or combined" language does not imply modification. IE, releasing a patch against the GPLv3 part of the work under AGPLv3 would even be a copyright violation. The patch needs to be GPLv3. Only the combination of the works obeys to AGPLv3's additional requirements. But each piece retains completely its license.
Therefore there is no risk that a GPLv3 work can be effectively turned into an AGPLv3 work by means of patches.
But even if this holds, someone could still patch the GPLv3 work to a state where it no longer works alone, and then linking it with a AGPLv3 code having the missing pieces for it to work, couldn't they?
Hochachtungsvoll, Bernhard R. Link
On Fri, 2007-11-30 at 12:46 +0100, Bernhard R. Link wrote:
- simo simo.sorce@xsec.it [071129 23:52]:
Basically, Richard thinks that the "linked or combined" language does not imply modification. IE, releasing a patch against the GPLv3 part of the work under AGPLv3 would even be a copyright violation. The patch needs to be GPLv3. Only the combination of the works obeys to AGPLv3's additional requirements. But each piece retains completely its license.
Therefore there is no risk that a GPLv3 work can be effectively turned into an AGPLv3 work by means of patches.
But even if this holds, someone could still patch the GPLv3 work to a state where it no longer works alone, and then linking it with a AGPLv3 code having the missing pieces for it to work, couldn't they?
I too think there are probably some pathological cases where it will be difficult to understand the boundaries, or where a patch to the GPLv3 side even if GPLv3ed will not really be much of use without the AGPLv3 part. I guess that's inevitable but I think it will not be as dangerous as permitting an AGPLv3 patch to a GPLv3 work.
Simo.
* simo wrote, On 30/11/07 13:42:
On Fri, 2007-11-30 at 12:46 +0100, Bernhard R. Link wrote:
- simo simo.sorce@xsec.it [071129 23:52]:
Basically, Richard thinks that the "linked or combined" language does not imply modification. IE, releasing a patch against the GPLv3 part of the work under AGPLv3 would even be a copyright violation. The patch needs to be GPLv3. Only the combination of the works obeys to AGPLv3's additional requirements. But each piece retains completely its license.
Therefore there is no risk that a GPLv3 work can be effectively turned into an AGPLv3 work by means of patches.
But even if this holds, someone could still patch the GPLv3 work to a state where it no longer works alone, and then linking it with a AGPLv3 code having the missing pieces for it to work, couldn't they?
I too think there are probably some pathological cases where it will be difficult to understand the boundaries, or where a patch to the GPLv3 side even if GPLv3ed will not really be much of use without the AGPLv3 part.
or even if it will, or part of it will be some use.
I guess that's inevitable but I think it will not be as dangerous as permitting an AGPLv3 patch to a GPLv3 work.
Perhaps, but it thus seems conclusive that the expectation of equality can be broken after all: - AGPL fans can combine with GPL3 works, enhance the GPL3 work, not distribute a patch, comply with the license and yet the GPL3 author may not take these enhancements to their own work unless they re-license as AGPL.
I think I have a good understanding of the possibilities and likelihoods.
Thanks to all for helping explore this.
I predict that Samba4 integration with groupware will be the first such victim (if any), possibly resulting in a fork.
Sam
On Fri, 2007-11-30 at 14:21 +0000, Sam Liddicott wrote:
I predict that Samba4 integration with groupware will be the first such victim (if any), possibly resulting in a fork.
Good luck forking and maintaining our monster :-)
Seriously I think the countrary, it is very easy for me to understand what clearly is samba related, to what is GUI/interface related. I think the most dubious cases will be with web frameworks, they are much more fuzzy to deal with.
Simo.