From: Peter G. <pe...@ar...> - 2004-06-21 23:58:46
|
Getting ready for the first release of ABCL as an independent entity (which may or may not occur in the near future; I'm not promising anything), I'd like to propose a change to ABCL's license. The proposed change will apply to ABCL only; j (the editor) will continue to be licensed under the GPL, as has always been the case. (For the purposes of this discussion, think of ABCL as "the files in the src/org/armedbear/lisp directory".) The new license for ABCL will be the GPL, as before, with an added clarification and special exception. I plan to adapt the text of the clarification and special exception from similar text used by the GNU Classpath project. This is the relevant part of the LICENSE file in the GNU Classpath distribution: The software in this package is distributed under the GNU General Public License (with a special exception described below). A copy of GNU General Public License (GPL) is included in this distribution, in the file COPYING. If you do not have the source code, it is available at: http://www.gnu.org/software/classpath/ Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination. As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. As applied to ABCL, this means that you can link ABCL with independent modules to produce an executable that you can then license however you please, provided you meet the licensing requirements of any other code you include or link to. In other words, software that uses ABCL "as is" does not have to be GPLed just because it uses ABCL. Note "as is": this exception does not cover modifications you might make to the ABCL code itself. Such modifications are covered by Section 2 of the COPYING file (in the root directory of the j distribution). Bottom line, if you modify the ABCL code, you're making a derived work, and the derived work must be licensed under the GPL. (The next-to-last sentence of the special exception quoted above lets you decide whether or not to extend the special exception to the derived work that you've thereby created.) So, it's OK to modify ABCL and use the modified ABCL in non-GPLed software, as long as you release the source of the modified ABCL under the GPL (with or without the aforementioned special exception). Of course, I've been called many things but never a lawyer, so my account of this should be taken with a grain of salt (maybe more). Please let me know if you have any questions or concerns. Thanks for your support. -Peter |
From: Sunil M. <sm...@ai...> - 2004-06-22 20:13:43
|
Hi Peter, Thanks for attempting to make armedbear an independent, usable package. The GPL modification you have proposed, according to the IP person here at SRI, would allow us to distribute a binary software package that includes ABCL. We cannot, say, distribute our source code and include ABCL as part of our distribution without making our sources GPL'ed. Regardless, I believe the modification will allow us to effectively use ABCL. We can by default supply executables, and if we ever need to distribute sources we will have to create a different packaging that excludes ABCL. If we discover issues down the line, I shall be sure to share them with this list. Thanks again! Sunil On Jun 21, 2004, at 4:58 PM, Peter Graves wrote: > Getting ready for the first release of ABCL as an independent entity > (which may or may not occur in the near future; I'm not promising > anything), I'd like to propose a change to ABCL's license. > > The proposed change will apply to ABCL only; j (the editor) will > continue to be licensed under the GPL, as has always been the case. > (For the purposes of this discussion, think of ABCL as "the files in > the src/org/armedbear/lisp directory".) > > The new license for ABCL will be the GPL, as before, with an added > clarification and special exception. > > I plan to adapt the text of the clarification and special exception > from similar text used by the GNU Classpath project. > > This is the relevant part of the LICENSE file in the GNU Classpath > distribution: > > The software in this package is distributed under the GNU General > Public License (with a special exception described below). > > A copy of GNU General Public License (GPL) is included in this > distribution, in the file COPYING. If you do not have the source > code, it is available at: > > http://www.gnu.org/software/classpath/ > > Linking this library statically or dynamically with other modules > is making a combined work based on this library. Thus, the terms > and conditions of the GNU General Public License cover the whole > combination. > > As a special exception, the copyright holders of this library give > you permission to link this library with independent modules to > produce an executable, regardless of the license terms of these > independent modules, and to copy and distribute the resulting > executable under terms of your choice, provided that you also meet, > for each linked independent module, the terms and conditions of the > license of that module. An independent module is a module which is > not derived from or based on this library. If you modify this > library, you may extend this exception to your version of the > library, but you are not obligated to do so. If you do not wish to > do so, delete this exception statement from your version. > > As applied to ABCL, this means that you can link ABCL with independent > modules to produce an executable that you can then license however you > please, provided you meet the licensing requirements of any other code > you include or link to. > > In other words, software that uses ABCL "as is" does not have to be > GPLed just because it uses ABCL. > > Note "as is": this exception does not cover modifications you might > make to the ABCL code itself. > > Such modifications are covered by Section 2 of the COPYING file (in the > root directory of the j distribution). > > Bottom line, if you modify the ABCL code, you're making a derived work, > and the derived work must be licensed under the GPL. (The next-to-last > sentence of the special exception quoted above lets you decide whether > or not to extend the special exception to the derived work that you've > thereby created.) > > So, it's OK to modify ABCL and use the modified ABCL in non-GPLed > software, as long as you release the source of the modified ABCL under > the GPL (with or without the aforementioned special exception). > > Of course, I've been called many things but never a lawyer, so my > account of this should be taken with a grain of salt (maybe more). > > Please let me know if you have any questions or concerns. > > Thanks for your support. > > -Peter > |
From: Peter G. <pe...@ar...> - 2004-06-22 23:24:17
|
On Tue, 22 Jun 2004 at 13:13:16 -0700, Sunil Mishra wrote: > Hi Peter, > > Thanks for attempting to make armedbear an independent, usable > package. The GPL modification you have proposed, according to the IP > person here at SRI, would allow us to distribute a binary software > package that includes ABCL. We cannot, say, distribute our source > code and include ABCL as part of our distribution without making our > sources GPL'ed. That is not my understanding; I don't think the change I'm proposing has such a restrictive effect. The only thing you can't do (loosely speaking) is modify the ABCL source, build something on top of the modified ABCL, and then NOT release the source of your modifications to ABCL. As long as you either (a) use ABCL unmodified or (b) modify ABCL and release the source of those modifications, you're fine. If you choose option (b), the modified ABCL that you release still has to be released under the GPL (either with or without the special exception we're discussing, at your choice). But your independent code can be released under whatever license you please (subject, possibly, to other constraints that have nothing to do with ABCL). I don't see why it should work to your disfavor if you want to release source. Or am I missing some legal subtlety here? -Peter > Regardless, I believe the modification will allow us to effectively > use ABCL. We can by default supply executables, and if we ever need > to distribute sources we will have to create a different packaging > that excludes ABCL. If we discover issues down the line, I shall be > sure to share them with this list. > > Thanks again! > > Sunil |
From: Sunil M. <sm...@ai...> - 2004-06-23 00:21:57
|
After much deliberation, the key issue that we're seeing here is that GPL's definition of a derivative work isn't clear. The issue is that the exemption you are proposing will allow us to distribute executables, without a doubt. But if we write some code that explicitly manipulates ABCL internals, then is that a derivative work of ABCL? The GPL is somewhat slippery on this point. Another problem that I see is that the exemption applies to executables. Java class files and jar files are technically *not* executables. The executable is the JVM, which loads bytecodes in the jar and class files. The vagueness in the GPL is really quite unfortunate. The exemption would have to be suitably expanded to first clearly distinguish what constitutes ABCL, and what would constitute a non-derivative use of ABCL, in source, object, and executable form. Once we have established clearly what is derivative, and what is not, we should be able to start using ABCL without risk of contaminating our IP with the GPL. I think I spoke a little too soon when I said the exemption will give us what we want. Further internal conversations have pointed out that there are risks we would face despite the exemption. You have to understand just *how* badly I would like to use something like ABCL. But if that's at the risk of our ability to distribute the resulting work while protecting it, I would unfortunately be forced to avoid ABCL. I'd like there to be a way out, though. Hope you can understand our concerns. Sunil On Jun 22, 2004, at 4:24 PM, Peter Graves wrote: > On Tue, 22 Jun 2004 at 13:13:16 -0700, Sunil Mishra wrote: >> Hi Peter, >> >> Thanks for attempting to make armedbear an independent, usable >> package. The GPL modification you have proposed, according to the IP >> person here at SRI, would allow us to distribute a binary software >> package that includes ABCL. We cannot, say, distribute our source >> code and include ABCL as part of our distribution without making our >> sources GPL'ed. > > That is not my understanding; I don't think the change I'm proposing > has such a restrictive effect. > > The only thing you can't do (loosely speaking) is modify the ABCL > source, build something on top of the modified ABCL, and then NOT > release the source of your modifications to ABCL. > > As long as you either (a) use ABCL unmodified or (b) modify ABCL and > release the source of those modifications, you're fine. > > If you choose option (b), the modified ABCL that you release still has > to be released under the GPL (either with or without the special > exception we're discussing, at your choice). But your independent code > can be released under whatever license you please (subject, possibly, > to other constraints that have nothing to do with ABCL). > > I don't see why it should work to your disfavor if you want to release > source. > > Or am I missing some legal subtlety here? > > -Peter > >> Regardless, I believe the modification will allow us to effectively >> use ABCL. We can by default supply executables, and if we ever need >> to distribute sources we will have to create a different packaging >> that excludes ABCL. If we discover issues down the line, I shall be >> sure to share them with this list. >> >> Thanks again! >> >> Sunil > |
From: Peter G. <pe...@ar...> - 2004-06-23 01:25:51
|
On Tue, 22 Jun 2004 at 17:21:50 -0700, Sunil Mishra wrote: > After much deliberation, the key issue that we're seeing here is that = > GPL's definition of a derivative work isn't clear. The issue is that = > the exemption you are proposing will allow us to distribute = > executables, without a doubt. But if we write some code that explicitly= = > manipulates ABCL internals, then is that a derivative work of ABCL? The= = > GPL is somewhat slippery on this point. Well, if you MODIFY the internals of ABCL, you've created a derived work, and you need to publish the source of the modified ABCL. You don't need to GPL the application that you've built on top of the modified (or unmodified) ABCL, and you don't need to publish the application's source (but you are free to do so if you want). If you don't modify anything in the ABCL distribution, but (for example) your code calls some internal ABCL function, then you're still OK, as far as I'm concerned, from a legal point of view. =46rom a technical point of view, internal functions (or, for that matter, any function whatsoever) may go away at any time, so your code might not run without modification on a newer version of ABCL. That's a technical problem, but not a legal one, as I see it. It's no problem at all if you just ship a snapshot of ABCL that you're happy with, and you don't care about running that same exact code on a newer version of ABCL that might not contain the function in question. > Another problem that I see is that the exemption applies to = > executables. Java class files and jar files are technically *not* = > executables. The executable is the JVM, which loads bytecodes in the = > jar and class files. The vagueness in the GPL is really quite = > unfortunate. > > The exemption would have to be suitably expanded to first clearly = > distinguish what constitutes ABCL, and what would constitute a = > non-derivative use of ABCL, in source, object, and executable form. = > Once we have established clearly what is derivative, and what is not, = > we should be able to start using ABCL without risk of contaminating our= = > IP with the GPL. > > I think I spoke a little too soon when I said the exemption will give = > us what we want. Further internal conversations have pointed out that = > there are risks we would face despite the exemption. You have to = > understand just *how* badly I would like to use something like ABCL. = > But if that's at the risk of our ability to distribute the resulting = > work while protecting it, I would unfortunately be forced to avoid = > ABCL. > > I'd like there to be a way out, though. Hope you can understand our = > concerns. Well, to be honest, I am having a bit of a hard time understanding your concerns (and real soon now, I'm going to stop trying). I think I've basically said you can do what you want, and I'm not going to try to stop you, as long as you publish any modifications you make to ABCL itself (the source files in the src/org/armedbear/lisp directory). I think that's clear, and I think that's about the best I can do. I'm not going to allow ABCL to be taken private, but by the same token, I'm not going to try to claim that your application is a derived work of ABCL just because it calls ABCL functions. To paraphrase Linus, calling functions is merely considered normal use, and does NOT fall under the heading of "derived work", the way I see things. It may not be within my power (or more to the point, my patience) to make all the lawyers happy; there are just too many of them. If you decide not to use ABCL, I will try to struggle on... ;) -Peter |
From: Sunil M. <sm...@ai...> - 2004-06-23 17:59:05
|
Hi Peter, I'm not trying to be difficult, really. I'm constrained in how our group can use software based on how our legal people interpret the GPL and modifications thereof. I'm not asking to be given permission to use ABCL in a private manner. This would be neither in our interest, nor in the interest of the larger lisp community. The only *real* problem I presently see is that the exemption, as stated, only applies to executables, and nothing else. It would be great if the exemption for executables could be extended to cover compiled object code as well, since that is what jvm bytecode really is. Other than that, I think I'm getting too strict an interpretation, and I'm still negotiating with the powers-that-be here. I like what you are doing with abcl, I'll likely be using it in private, but I see the real win in being able to use it at work here. Regards, Sunil On Jun 22, 2004, at 6:25 PM, Peter Graves wrote: > On Tue, 22 Jun 2004 at 17:21:50 -0700, Sunil Mishra wrote: >> After much deliberation, the key issue that we're seeing here is that >> GPL's definition of a derivative work isn't clear. The issue is that >> the exemption you are proposing will allow us to distribute >> executables, without a doubt. But if we write some code that >> explicitly >> manipulates ABCL internals, then is that a derivative work of ABCL? >> The >> GPL is somewhat slippery on this point. > > Well, if you MODIFY the internals of ABCL, you've created a derived > work, and you need to publish the source of the modified ABCL. You > don't need to GPL the application that you've built on top of the > modified (or unmodified) ABCL, and you don't need to publish the > application's source (but you are free to do so if you want). > > If you don't modify anything in the ABCL distribution, but (for > example) your code calls some internal ABCL function, then you're still > OK, as far as I'm concerned, from a legal point of view. > > From a technical point of view, internal functions (or, for that > matter, any function whatsoever) may go away at any time, so your code > might not run without modification on a newer version of ABCL. That's a > technical problem, but not a legal one, as I see it. It's no problem at > all if you just ship a snapshot of ABCL that you're happy with, and you > don't care about running that same exact code on a newer version of > ABCL that might not contain the function in question. > >> Another problem that I see is that the exemption applies to >> executables. Java class files and jar files are technically *not* >> executables. The executable is the JVM, which loads bytecodes in the >> jar and class files. The vagueness in the GPL is really quite >> unfortunate. >> >> The exemption would have to be suitably expanded to first clearly >> distinguish what constitutes ABCL, and what would constitute a >> non-derivative use of ABCL, in source, object, and executable form. >> Once we have established clearly what is derivative, and what is not, >> we should be able to start using ABCL without risk of contaminating >> our >> IP with the GPL. >> >> I think I spoke a little too soon when I said the exemption will give >> us what we want. Further internal conversations have pointed out that >> there are risks we would face despite the exemption. You have to >> understand just *how* badly I would like to use something like ABCL. >> But if that's at the risk of our ability to distribute the resulting >> work while protecting it, I would unfortunately be forced to avoid >> ABCL. >> >> I'd like there to be a way out, though. Hope you can understand our >> concerns. > > Well, to be honest, I am having a bit of a hard time understanding your > concerns (and real soon now, I'm going to stop trying). > > I think I've basically said you can do what you want, and I'm not going > to try to stop you, as long as you publish any modifications you make > to ABCL itself (the source files in the src/org/armedbear/lisp > directory). > > I think that's clear, and I think that's about the best I can do. > > I'm not going to allow ABCL to be taken private, but by the same token, > I'm not going to try to claim that your application is a derived work > of ABCL just because it calls ABCL functions. To paraphrase Linus, > calling functions is merely considered normal use, and does NOT fall > under the heading of "derived work", the way I see things. > > It may not be within my power (or more to the point, my patience) to > make all the lawyers happy; there are just too many of them. > > If you decide not to use ABCL, I will try to struggle on... ;) > > -Peter |