From: Blake M. <bl...@mc...> - 2009-01-20 14:44:48
|
Greetings, The book "The Art of the Metaobject Protocol" by Kiczales, Rivieres & Bobrow contains a simplified but working CLOS. It is infinitely better than what's in ABCL right now (it has a full MOP) and IMO offers the shortest path to a pretty-close-to-full CLOS. The code in that book suffers from two problems that could be addressed easier than other solutions as follows: 1. I think the code keeps internal pointers to each object so that nothing ever gets GC'd. The easiest way to fix it would be to support weak pointers (references to objects that don't prevent GC). Weak pointer support is a good thing to have in any case. 2. The other issue has to do with efficiency. This code is pretty much implemented as a design-as-described code. Very straight forward but not efficient in any respect. Real CLOS implementations do a lot of work to pre-compute and minimize runtime lookups / calculations. While doing similar optimizations is beyond the scope of this starting point, it would be easy to implement a lookup cache. Just some thoughts. Blake McBride |
From: Ville V. <vil...@gm...> - 2009-01-20 14:56:19
|
On Tue, Jan 20, 2009 at 4:44 PM, Blake McBride <bl...@mc...> wrote: > Greetings, > The book "The Art of the Metaobject Protocol" by Kiczales, Rivieres & Bobrow > contains a simplified but working CLOS. It is infinitely better than what's While most of us are aware of AMOP, using the CLOS implementation (Closette, found in http://www.scs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/oop/clos/closette/closette.tgz) from that book will not do. It's copyright preamble contains the following: ;;; Use and copying of this software and preparation of derivative works ;;; based upon this software are permitted. Any distribution of this ;;; software or derivative works must comply with all applicable United ;;; States export control laws. Requiring compliance with US export control is incompatible with the GNU GPL. So, unless we can integrate PCL, or find other suitable implementation to integrate, we'll have to implement AMOP as described by the book ourselves. |
From: Blake M. <bl...@mc...> - 2009-01-20 15:26:03
|
I am not an attorney and I couldn't care less about Stallman and his GPL, my analysis of that statement is as follows. The first sentence gives permission to use and modify it as we see fit - essentially public domain. The second sentence does not say the code can't be exported outside the US. It says it can't be exported if it violates any export laws of the US. That sentence has almost no meaning. Anyone who writes code that is restricted from export (e.g. encryption code, advanced rocket guidance systems etc.) is restricted from exporting it whether it has that statement in it or not. The people who put it there just put it in to cover their a**. Neither the US government nor the authors could possible care less who uses that code. There are no top secrets in it and EVERYONE knows that the entire world has already had access to both the book and the code. I hope no decisions are going to be made based on the statement in the code. Blake McBride On Tue, Jan 20, 2009 at 8:56 AM, Ville Voutilainen < vil...@gm...> wrote: > On Tue, Jan 20, 2009 at 4:44 PM, Blake McBride <bl...@mc...> wrote: > > Greetings, > > The book "The Art of the Metaobject Protocol" by Kiczales, Rivieres & > Bobrow > > contains a simplified but working CLOS. It is infinitely better than > what's > > While most of us are aware of AMOP, using the CLOS implementation > (Closette, > found in > http://www.scs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/oop/clos/closette/closette.tgz > ) > from that book will not do. It's copyright preamble contains the following: > > ;;; Use and copying of this software and preparation of derivative works > ;;; based upon this software are permitted. Any distribution of this > ;;; software or derivative works must comply with all applicable United > ;;; States export control laws. > > Requiring compliance with US export control is incompatible with the GNU > GPL. > So, unless we can integrate PCL, or find other suitable implementation > to integrate, > we'll have to implement AMOP as described by the book ourselves. > |
From: Ville V. <vil...@gm...> - 2009-01-20 15:45:34
|
On Tue, Jan 20, 2009 at 5:25 PM, Blake McBride <bl...@mc...> wrote: > I am not an attorney... I am not an attorney either, but I don't want us to pollute abcl codebase with code that we or our users can't distribute to wherever we please. I'd rather err on the safe side than just integrate something we think is in the public domain, but might not be. |
From: Ville V. <vil...@gm...> - 2009-01-20 15:53:14
|
On Tue, Jan 20, 2009 at 5:45 PM, Ville Voutilainen <vil...@gm...> wrote: > I am not an attorney either, but I don't want us to pollute abcl > codebase with code that we > or our users can't distribute to wherever we please. I'd rather err on Portable CommonLoops seems to have the same export yadda-yadda. We should at least check with someone more knowledgeable instead of just making decisions because they allow us to replace the current CLOS with something else. |
From: Mark E. <ev...@pa...> - 2009-01-20 16:18:56
|
Ville Voutilainen wrote: > On Tue, Jan 20, 2009 at 5:45 PM, Ville Voutilainen > <vil...@gm...> wrote: >> I am not an attorney either, but I don't want us to pollute abcl >> codebase with code that we or our users can't distribute to >> wherever we please. I'd rather err on > > Portable CommonLoops seems to have the same export yadda-yadda. We > should at least check with someone more knowledgeable instead of just > making decisions because they allow us to replace the current CLOS > with something else. Gee, Ville, you like making life complicated, don't you? After about half-an-hour research, most definitely not speaking as a lawyer, I found that [Brett Smith commented on GPL v2 vis a vis export restrictions][1], writing: > On Sat, Aug 11, 2007 at 01:14:53AM +0530, Rahul Sundaram wrote: > >> > Fedora as a distribution is affected by export control regulations as >> > any software subjected to US laws from the legal perspective. >> > >> > http://fedoraproject.org/wiki/Distribution/Download/ExportRegulations >> > >> > Clause 8 in GPL mentions that such regulations are compatible with the >> > license but can you confirm FSF's viewpoints on this? > > Section 8 of GPLv2 doesn't make the sort of sweeping policy statement > you're suggesting here. You'll note that we took this clause out of GPLv3 > -- but you're not suddenly going to get into export restriction trouble > because of it. > > The question to ask is: what requirement of the GPL does the law prevent > you from fulfilling? When it comes to export restrictions, the answer is > none. If you comply with local export restrictions, you will not run afoul > of any requirements in the GPL. Therefore, there's no conflict. > > Export restrictions limit who you can give the software to. The GPL has no > problem with you being picky about who you give the software to: if you > want, you can decide that you'll only distribute to paying customers, or > people with blue hair. So the fact that you also decide not to distribute > to Iranians and Syrians is no problem as far as the license is concerned. > > Best regards, > > -- Brett Smith Licensing Compliance Engineer, Free Software Foundation > [1]: http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2009-01-20 23:25:12
|
On Tue, Jan 20, 2009 at 6:18 PM, Mark Evenson <ev...@pa...> wrote: > After about half-an-hour research, most definitely not speaking as a > lawyer, I found that [Brett Smith commented on GPL v2 vis a vis export > restrictions][1], writing: First of all, I'm not trying to reopen this debate. This is just a food-for-thought for those who may find it interesting. Here's Mr. Stallman's take on export restrictions, regarding Closette and PCL: <quote> "Export restrictions", as such, usually refers to certain laws. If you mean license conditions requiring users to comply with a certain country's export restrictions, those make a program non-free. Thus, these Xerox programs are not even free software. A fortiori, the licenses are incompatible with the GNU GPL. </quote> That's of course just one opinion, so as with anyone's opinion, take it with a grain of salt. He mentions that http://www.gnu.org/philosophy/free-sw.html contains discussion about this very matter, among other matters. This is also not supposed to start any flame war, I just thought that maybe people would be interested to know about this view, among others. Cheers, -VJV- |
From: Mark E. <ev...@pa...> - 2009-01-20 16:27:35
|
And it seems we no longer have an actual copy of the GPL license included with the abcl branch. 'COPYING' contains mention of the GPL without specifying a version, the ABCL special exception, and nothing more. 'src/org/armedbear/lisp/COPYING' has the same problem. This should be fixed before we make another release. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2009-01-20 16:33:28
|
On Tue, Jan 20, 2009 at 6:18 PM, Mark Evenson <ev...@pa...> wrote: > Gee, Ville, you like making life complicated, don't you? No, I attempt to not make it more complicated than necessary. The value of necessary being debatable. :) >> Export restrictions limit who you can give the software to. The GPL has >> no >> problem with you being picky about who you give the software to: if you >> want, you can decide that you'll only distribute to paying customers, or >> people with blue hair. So the fact that you also decide not to distribute >> to Iranians and Syrians is no problem as far as the license is concerned. Fine, I stand corrected - the export restriction is not GPL-incompatible, so this is ultimately the case of whether we want to be restricted wrt where abcl can or can not be distributed. And as I said, I'd rather not be restricted in such manner (nor would I like to restrict the possible distributors of abcl in such manner), if avoidable. |
From: Ville V. <vil...@gm...> - 2009-01-20 16:41:26
|
On Tue, Jan 20, 2009 at 6:33 PM, Ville Voutilainen <vil...@gm...> wrote: > Fine, I stand corrected - the export restriction is not GPL-incompatible, so The GPL v2.0 clause 8 says the following: 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. Note the "original copyright holder who places the Program under this License". That would be Peter Graves, not any of us. Adding the export restriction later might not be straightforward, or allowed. I'm not an expert on that. But I damn well want us to check these things before just merging any code that we happen to find. Mark, don't worry, no offense taken. |
From: Chun T. (binghe) <bin...@gm...> - 2009-01-20 17:15:57
|
Hi, Blake Did you have the AMOP book or read the actual code in it? I have the book and just read it once before I get involved last Friday. I think ABCL is already using the AMOP code, and ABCL's clos.lisp mention this clearly: (line 32-38 of clos.lisp) ;;; Originally based on Closette. ;;; Closette Version 1.0 (February 10, 1991) ;;; ;;; Copyright (c) 1990, 1991 Xerox Corporation. ;;; All rights reserved. I think the original ABCL author, Peter Graves, almost copy the entire Closette code, and made some very important changes: 1) Move some basic CLOS work into Java-side, like the definitions of fundamental classes. (So, no bootstrap issues and related code needed any more) 2) Disable the :metaclass support (but most of MOP code still exist) since no way to support it. 2) Fix Closette to support at least forward-reference-class (and these fixes destroyed the beauty of original code) What I still don't understand today is that why he didn't just use the original Closette code and wrote on Java-side code. Maybe the Java- side works just came first, or he want the CLOS implementation in ABCL be as fast as possible (by written in Java). So, what you guys talked on license or law related stuff, was already there. P. S. I still think the Closette implementation in AMOP is just for MOP beginner to understand how MOP works, no intend for CL implementation to copy and really use them. The code used for copy is PCL, which the AMOP authers said in that book... On 2009-1-20, at 22:44, Blake McBride wrote: > > Greetings, > > The book "The Art of the Metaobject Protocol" by Kiczales, Rivieres > & Bobrow contains a simplified but working CLOS. It is infinitely > better than what's in ABCL right now (it has a full MOP) and IMO > offers the shortest path to a pretty-close-to-full CLOS. The code > in that book suffers from two problems that could be addressed > easier than other solutions as follows: > > 1. I think the code keeps internal pointers to each object so that > nothing ever gets GC'd. The easiest way to fix it would be to > support weak pointers (references to objects that don't prevent > GC). Weak pointer support is a good thing to have in any case. > > 2. The other issue has to do with efficiency. This code is pretty > much implemented as a design-as-described code. Very straight > forward but not efficient in any respect. Real CLOS implementations > do a lot of work to pre-compute and minimize runtime lookups / > calculations. While doing similar optimizations is beyond the scope > of this starting point, it would be easy to implement a lookup cache. > > Just some thoughts. > > Blake McBride > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword_______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel -- Chun Tian (binghe) NetEase.com, Inc. P. R. China |
From: Ville V. <vil...@gm...> - 2009-01-20 17:23:57
|
On Tue, Jan 20, 2009 at 7:15 PM, Chun Tian (binghe) <bin...@gm...> wrote: > I think the original ABCL author, Peter Graves, almost copy the entire > Closette code, and made some very important changes: Well, that settles it, we already likely have the export-restriction then. That also removes all my gripes wrt merging either closette or PCL, because we're losing nothing. The remaining issues are probably technical, aka remove-the-java-side clos or not etc. Thanks for all for your patience in digging this info up. |
From: Chun T. (binghe) <bin...@gm...> - 2009-01-20 18:10:13
|
On 2009-1-21, at 01:23, Ville Voutilainen wrote: > > Well, that settles it, we already likely have the export-restriction > then. That also removes > all my gripes wrt merging either closette or PCL, because we're > losing nothing. > > The remaining issues are probably technical, aka remove-the-java-side > clos or not etc. > > Thanks for all for your patience in digging this info up. You're welcome. And I think I can prove that: PCL is "safe" by following materials: Fact 1: CMUCL/SBCL use PCL as their CLOS resolution. Fact 2: CMUCL/SBCL's license are "public domain + BSD" [1], which means anyone can do almost anything on it, and definitely no GPL- related stuff here. Theorem 1: There's no difficulty for a GPLed software merging code from others by "public domain" or BSD. (Am I right?) Fact 3: ABCL is GPLed. Say the technical side, I still cannot talk about how hard to port PCL into ABCL, because I haven't started to really read PCL (though I want). I personal by no means am a CLOS/MOP expert, but if no one else get involved in this quite big CLOS change, *I'll try to research and actual do it in late middle of this year* (Too busy now, sorry). I really like the idea which run a complete CL environment in JVM, and seems there're no other CL projects which do the same thing. (I mean CL, Common Lisp. For other Lisp dialects, there're many projects on JVM [2]) Once ABCL have MOP, some other important Lisp projects would be possible to run on ABCL/JVM: Elephant [3], GBBopen [4], Lisa [5], ... It's totally worth making ABCL better. [1] http://www.sbcl.org/history.html [2] http://www.is-research.de/info/vmlanguages/lisp.html [3] http://common-lisp.net/projects/elephant/ [4] http://gbbopen.org/ [5] http://lisa.sourceforge.net/ -- Chun Tian (binghe) NetEase.com, Inc. P. R. China |
From: Ville V. <vil...@gm...> - 2009-01-20 18:19:08
|
> Once ABCL have MOP, some other important Lisp projects would be possible to > run on ABCL/JVM: Elephant [3], GBBopen [4], Lisa [5], ... It's totally worth > making ABCL better. Agreed, our current CLOS implementation is weak, there's no dispute of that. So making it better is important. I'd rather discuss any issues that arise, instead of going forward hastily. |
From: Erik H. <eh...@gm...> - 2009-01-21 16:20:35
|
On Tue, Jan 20, 2009 at 3:56 PM, Ville Voutilainen <vil...@gm...> wrote: > On Tue, Jan 20, 2009 at 4:44 PM, Blake McBride <bl...@mc...> wrote: >> Greetings, >> The book "The Art of the Metaobject Protocol" by Kiczales, Rivieres & Bobrow >> contains a simplified but working CLOS. It is infinitely better than what's > > While most of us are aware of AMOP, using the CLOS implementation (Closette, > found in http://www.scs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/oop/clos/closette/closette.tgz) > from that book will not do. It's copyright preamble contains the following: > > ;;; Use and copying of this software and preparation of derivative works > ;;; based upon this software are permitted. Any distribution of this > ;;; software or derivative works must comply with all applicable United > ;;; States export control laws. > > Requiring compliance with US export control is incompatible with the GNU GPL. > So, unless we can integrate PCL, or find other suitable implementation > to integrate, > we'll have to implement AMOP as described by the book ourselves. I've been thinking about the preamble. I think it's not a problem: "applicable export control laws" only kick in if the product has been identified as an item which can only be limitedly exported. Usually, the US assign a number to such products for tracking. If this product didn't have such codes assigned, I think it's just lawyers keeping each other busy: It looks like the original author didn't exactly put any export restrictions on the product, but is just mentioning the fact that such restrictions may exist in the US. Bye, Erik. |
From: Florian W. <fw...@de...> - 2009-01-25 12:52:36
|
* Erik Huelsmann: > I've been thinking about the preamble. I think it's not a problem: > "applicable export control laws" only kick in if the product has > been identified as an item which can only be limitedly exported. In addition, geographical distribution restrictions are compatible with the GPL. However, code under such a license might cause problems when incorporated into some distributions (Debian, perhaps Fedora as well). It's also not guaranteed that compiler technology will never fall under export control (in fact, I think some specialized technology for signal processing currently does). |
From: Alessio S. <ale...@gm...> - 2009-01-25 15:08:15
|
On Sun, Jan 25, 2009 at 1:10 PM, Florian Weimer <fw...@de...> wrote: > * Erik Huelsmann: > >> I've been thinking about the preamble. I think it's not a problem: >> "applicable export control laws" only kick in if the product has >> been identified as an item which can only be limitedly exported. > > In addition, geographical distribution restrictions are compatible > with the GPL. I'm not a lawyer, but I don't think that statement qualifies as a "geographical distribution restriction". The distribution of any software is restricted by the law in force, no matter what the license says (or doesn't say). This includes US export regulations for software that is exported from the US. If I distribute the software in another country, I'll have to follow that country's laws. A "geographical distribution restriction" would be e.g. a statement saying, "you can't export this software to such-and-such countries, no matter what the law says". hth, Alessio > However, code under such a license might cause problems when > incorporated into some distributions (Debian, perhaps Fedora as well). > It's also not guaranteed that compiler technology will never fall > under export control (in fact, I think some specialized technology for > signal processing currently does). > |
From: Florian W. <fw...@de...> - 2009-01-25 19:02:31
|
* Alessio Stalla: > On Sun, Jan 25, 2009 at 1:10 PM, Florian Weimer <fw...@de...> wrote: >> * Erik Huelsmann: >> >>> I've been thinking about the preamble. I think it's not a problem: >>> "applicable export control laws" only kick in if the product has >>> been identified as an item which can only be limitedly exported. >> >> In addition, geographical distribution restrictions are compatible >> with the GPL. > > I'm not a lawyer, but I don't think that statement qualifies as a > "geographical distribution restriction". The idea is to restrict the distribution to the U.S., and then add a special exception permitting distribution outside the United States, provided that certain conditions are met. However, this trick depends on whether the software adding the restriction can be considered a "copyrighted interface". But the most straightforward approach is to avoid these conflicts and ambiguities (and some distributions won't pick up code which is affected by them). |
From: Erik H. <eh...@gm...> - 2009-02-15 19:21:50
|
I had this marked for followup, but with the recent commits, I suppose it's sufficiently resolved now. Right? Bye, Erik. On Tue, Jan 20, 2009 at 5:27 PM, Mark Evenson <ev...@pa...> wrote: > And it seems we no longer have an actual copy of the GPL license > included with the abcl branch. 'COPYING' contains mention of the GPL > without specifying a version, the ABCL special exception, and nothing > more. 'src/org/armedbear/lisp/COPYING' has the same problem. > > This should be fixed before we make another release. > > -- > "A screaming comes across the sky. It has happened before, but there is > nothing to compare to it now." > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > |
From: Ville V. <vil...@gm...> - 2009-02-15 19:53:53
|
On Sun, Feb 15, 2009 at 9:21 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > I had this marked for followup, but with the recent commits, I suppose > it's sufficiently resolved now. Right? Trunk contains correct stuff in COPYING, but I haven't put it into the release branch. |