I'm implementing a very simplified metaobject protocol
in SKILL (a non-common lisp). Originally I was not
modeling it after the MOP of CLOS.
But of late I have been putting more and more
standard MOP features and naming conventions into
my code. Especially I am encorporating many of the
examples from the book into my set of test
cases.
I notice the copyright of the book "The Art of
the Metaobject Protocol" says "No part of this book
may be reporduced by any electronic or mechanical
means..."
Do I have to get express written consent from MIT
Press in order to do this legally?
I imagine many people who have implemented MOPs
have read that book and copied lines of code from
it and copied paragraphs into their LISP function
comments.
Does anyone know if there is a special allowance for
this made by MIT Press?
-jim
From: Paul F. Dietz
Subject: Re: copyright notice in Art of the Metaobject Protocol
Date:
Message-ID: <R-Wdnap-3ppcUlXcRVn-jg@dls.net>
Jim Newton wrote:
> I imagine many people who have implemented MOPs
> have read that book and copied lines of code from
> it and copied paragraphs into their LISP function
> comments.
>
> Does anyone know if there is a special allowance for
> this made by MIT Press?
Note: I am not a lawyer.
My understanding is that implementing a publically
defined and (somewhat) standardized interface doesn't
violate a copyright. Copying code segments would,
unless it was necessary to implement the interface (if
there is no other good way to do it then there's no
protectable content.)
Paul
Is there contact info in the book so you can get that information "from the
horse's mouth" as it were?
On Tue, 21 Dec 2004, Jim Newton wrote:
> I'm implementing a very simplified metaobject protocol
> in SKILL (a non-common lisp). Originally I was not
> modeling it after the MOP of CLOS.
> But of late I have been putting more and more
> standard MOP features and naming conventions into
> my code. Especially I am encorporating many of the
> examples from the book into my set of test
> cases.
>
> I notice the copyright of the book "The Art of
> the Metaobject Protocol" says "No part of this book
> may be reporduced by any electronic or mechanical
> means..."
>
> Do I have to get express written consent from MIT
> Press in order to do this legally?
>
> I imagine many people who have implemented MOPs
> have read that book and copied lines of code from
> it and copied paragraphs into their LISP function
> comments.
>
> Does anyone know if there is a special allowance for
> this made by MIT Press?
>
> -jim
>
>
--
From: Jim Newton
Subject: Re: copyright notice in Art of the Metaobject Protocol
Date:
Message-ID: <32t3igF3qam9uU1@individual.net>
Well, there is a link on the MIT Press web page to inquire
about copyright information. So I sent them email (after
I posted to this newsgroup). I'm still waiting to see if they
respond.
-jim
David R. Sky wrote:
> Is there contact info in the book so you can get that information "from
> the horse's mouth" as it were?
>
>
>
> On Tue, 21 Dec 2004, Jim Newton wrote:
>
>> I'm implementing a very simplified metaobject protocol
>> in SKILL (a non-common lisp). Originally I was not
>> modeling it after the MOP of CLOS.
>> But of late I have been putting more and more
>> standard MOP features and naming conventions into
>> my code. Especially I am encorporating many of the
>> examples from the book into my set of test
>> cases.
>>
>> I notice the copyright of the book "The Art of
>> the Metaobject Protocol" says "No part of this book
>> may be reporduced by any electronic or mechanical
>> means..."
>>
>> Do I have to get express written consent from MIT
>> Press in order to do this legally?
>>
>> I imagine many people who have implemented MOPs
>> have read that book and copied lines of code from
>> it and copied paragraphs into their LISP function
>> comments.
>>
>> Does anyone know if there is a special allowance for
>> this made by MIT Press?
>>
>> -jim
>>
>>
>
The book AMOP (which I don't have handy at the moment) is divided
into two parts. The first is a pedagogical development of a
metoobject protocol to outline the issues and operation of the MOP.
The second (chapters 5 and 6, IIRC) is a formal standard for a
suggested metaobjct protocol for ANSI CL. You should know (but
many readers miss) that there are differences between the two,
and that many examples from the first section won't actually
work in an implementation of the second part in a real CL.
Both the first and second sections are copyright, but the second
section was given to X3J13 for possible standardization. (The
authors of that material in 1989 recommended _against_
standardization at that time, since there were no full
implementations of the MOP at that time, and little experience
using the MOP.) There may be minor differences between the
submission and the published AMOP, but it might be legally
simpler to use the X3J13 submission.
You should check also
http://www.franz.com/support/documentation/7.0/doc/mop/contents.html
Yuo will note that this is the same text (or _nearly_ the same text)
as the AMOP chapters 5&6. I believe permission was granted at some
point to include and/or republish these materials, but it might take
me some time to research the details.
That doesn't mean that the copyright holders have granted permission
to use the code examples from the earlier chapters.
Porting CLOS (much less the MOP) to Skill is an interestnig project
with some significant difficulties. For example, call-next-method
is defined to be a lexical function, but Skill doesn't support
lexical closures...
From: Jim Newton
Subject: Re: copyright notice in Art of the Metaobject Protocol
Date:
Message-ID: <332dl9F3s36i5U1@individual.net>
Steven M. Haflich wrote:
>
> Porting CLOS (much less the MOP) to Skill is an interestnig project
> with some significant difficulties. For example, call-next-method
> is defined to be a lexical function, but Skill doesn't support
> lexical closures...
SKILL does indeed support lexical closures. You can chose when
you define a function whether it should obey lexical or dynamic
scoping.
Jim Newton wrote:
> Steven M. Haflich wrote:
>
>> Porting CLOS (much less the MOP) to Skill is an interestnig project
>> with some significant difficulties. For example, call-next-method
>> is defined to be a lexical function, but Skill doesn't support
>> lexical closures...
>
> SKILL does indeed support lexical closures. You can chose when
> you define a function whether it should obey lexical or dynamic
> scoping.
I'd be interested to learn more of this mechanism (although my
interest may be similar to that base human instinct that makes
traffic slow down as it passes a bad accident). In particular,
what is the scope of that choice?
A potential problem is its interaction with functions defined by
macros. It is a common macro idiom in CL for some macros that
might wrap a large amount of code. For example,
cl:with-standard-io-syntax might be implemented as
(defmacro with-standard-io-syntax (&body body)
`(let ((*print-base* 10)
(*read-base* 10)
...and so on for at least 21 special variables...
)
nil
,@body))
but this injects code for binding and unbinding a large coven of
special variables for each expansion of w-s-io-s. An alternate
way to write the function in a lexically-scoped lisp is
(defmacro with-standard-io-syntax (&body body)
`(sys::with-standard-io-syntax-1 #'(lambda () nil ,@body)))
(defun sys::with-standard-io-syntax-1 (continuation)
(let ((*print-base* 10)
(*read-base* 10)
...and so on for at least 21 special variables...
)
(funcall continuation)))
(For the curious, the nil in each version of the macro is there to
prevent declarations from being accepted at the start of the
w-s-io-s code body.)
The second implementation has overhead to create the continuation
closure (which often could be stack consed) and additional overhead
to do two additional function calls, but it saves a lot of code
space for each expansion of w-s-io-s and therefore (on modern
hardware) increases the effectiveness of the processor instruction
cache. Your mileage may vay.
Now, the writer of such a macro assumes that the Lisp universally
mplements proper lexical scoping. The continuation function
rewrite by the macro isn't semantically transparent otherwise.
From: Jim Newton
Subject: Re: copyright notice in Art of the Metaobject Protocol
Date:
Message-ID: <33596nF3tcqdgU1@individual.net>
I'm introducing this thread to comp.cad.cadence
because there was a question about how macros
work in SCHEME mode in the SKILL language.
I do not really understand completely what the limitations
are. In general there are two modes the interpreter/evaluator
can be in, skill-mode and scheme-mode. several things can
trigger the mode to change from one to another.
Skill mode uses dynamic scoping.
Scheme mode uses lexical scoping.
1) the interactive mode defaults to skill-mode
2) files with a .il extension load in skill-mode
3) files with a .ils extension load in scheme-mode
4) code within an (inScheme ...) form evaluate in scheme mode
5) code within an (inSkill ...) form evaluate in skill mode.
6) if a function is defined in skill mode then it always
evaluates in skill mode
7) if a function is defined in scheme mode then it always
evaluates in scheme mode.
What about macros?
If a macro expands inside scheme mode then
the code it generates obeys lexical scoping.
If a macro expands inside skill mode then
the code it generates obeys dynamic scoping.
There are some limitations to this concept. E.g.,
while inside scheme mode, global variables are
not visible. Even stdout and stderr are invisible.
(fprintf stdout "hello world\n") ;; works in SKILL mode
(defun (get_stderr) ;; defining funciton in SKILL mode
stderr)
(fprintf (get_stderr) "hello world\n") ;; works in both modes.
This works in both modes because skill functions can freely
call scheme functions, and scheme functions can freely
call skill functions.
Steven M. Haflich wrote:
> Jim Newton wrote:
>
>> Steven M. Haflich wrote:
>>
>>> Porting CLOS (much less the MOP) to Skill is an interestnig project
>>> with some significant difficulties. For example, call-next-method
>>> is defined to be a lexical function, but Skill doesn't support
>>> lexical closures...
>>
>>
>> SKILL does indeed support lexical closures. You can chose when
>> you define a function whether it should obey lexical or dynamic
>> scoping.
>
>
> I'd be interested to learn more of this mechanism (although my
> interest may be similar to that base human instinct that makes
> traffic slow down as it passes a bad accident). In particular,
> what is the scope of that choice?
>
> A potential problem is its interaction with functions defined by
> macros. It is a common macro idiom in CL for some macros that
> might wrap a large amount of code. For example,
> cl:with-standard-io-syntax might be implemented as
>
> (defmacro with-standard-io-syntax (&body body)
> `(let ((*print-base* 10)
> (*read-base* 10)
> ...and so on for at least 21 special variables...
> )
> nil
> ,@body))
>
> but this injects code for binding and unbinding a large coven of
> special variables for each expansion of w-s-io-s. An alternate
> way to write the function in a lexically-scoped lisp is
>
> (defmacro with-standard-io-syntax (&body body)
> `(sys::with-standard-io-syntax-1 #'(lambda () nil ,@body)))
>
> (defun sys::with-standard-io-syntax-1 (continuation)
> (let ((*print-base* 10)
> (*read-base* 10)
> ...and so on for at least 21 special variables...
> )
> (funcall continuation)))
>
> (For the curious, the nil in each version of the macro is there to
> prevent declarations from being accepted at the start of the
> w-s-io-s code body.)
>
> The second implementation has overhead to create the continuation
> closure (which often could be stack consed) and additional overhead
> to do two additional function calls, but it saves a lot of code
> space for each expansion of w-s-io-s and therefore (on modern
> hardware) increases the effectiveness of the processor instruction
> cache. Your mileage may vay.
>
> Now, the writer of such a macro assumes that the Lisp universally
> mplements proper lexical scoping. The continuation function
> rewrite by the macro isn't semantically transparent otherwise.
From: Jim Newton
Subject: Re: copyright notice in Art of the Metaobject Protocol
Date:
Message-ID: <335a79F3mf4nrU1@individual.net>
My original question was to comp.lang.lisp but let me
ask it also on comp.cad.cadence.
The book. "The Art of the Metaobject Protocol" by
Gregor Kiczales et al explains how to construct an
object system which is much more powerful than SKILL++.
The object system developed in this book is largely
theoretical and needs a framework to already exists
which supports lexical closures and evaluation
within a given environment.
Interestingly enough, SKILL provides these features.
So it is possible with some work to implement
this object system in SKILL. The syntax described
in the book is quite a bit different than SKILL
syntax however, so you cannot just copy it directly;
you have to read and understand and translate.
The original question delt with copyright.
If I implement such a system by copying
code examples, and test cases from the book,
do I violate the copyright?
What good is such a book if you cannot use
the techniques in the real world? The book's
copyright does explicitly grant resuse of
certain chapters in full or in part as long
as acknowledgement be given, and they ask
that such a derivative product also provide
a similar permission for reuse.
This sounds similar to some sort of public
license but the book was written before such
licenses existed.
Has anyone addressed similar problems before?
What do you do if you wish to reuse algorithms or
pseudocode from text books, cookbooks etc?
Jim Newton wrote:
> Has anyone addressed similar problems before?
> What do you do if you wish to reuse algorithms or
> pseudocode from text books, cookbooks etc?
IANAL, but in Germany an author's copyright only covers the written
text, not the concepts that are described. In other words, what is
acknowledged as an accomplishment is the description of a concept, not
the concept itself. (For that, there are other ways to legally protect it.)
What's also important is that major important ideas of the AMOP go back
to other influences, including (but not limited to) LOOPS, Flavors,
Brian Smith's concept of reflection, KRL, Smalltalk, PILOT, and last but
not least, the metacircular definition of the very first Lisp.
I'd be surprised if the fact that someone "suddenly" writes a book about
these ideas would result in noone being allowed anymore to reuse them in
other contexts.
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon
In article <············@newsreader2.netcologne.de>,
Pascal Costanza <········@web.de> wrote:
> I'd be surprised if the fact that someone "suddenly" writes a book about
> these ideas would result in noone being allowed anymore to reuse them in
> other contexts.
The book in question contains significant amounts of code -- an entire
CLOS implementation, in fact. The OP was asking about copying code
directly (or translating it directly into another programming language,
which would probably be considered a derivative work), not about using
the ideas.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Alexander Schmolck
Subject: Re: copyright notice in Art of the Metaobject Protocol
Date:
Message-ID: <yfsacs2ro03.fsf@black4.ex.ac.uk>
Barry Margolin <······@alum.mit.edu> writes:
> In article <············@newsreader2.netcologne.de>,
> Pascal Costanza <········@web.de> wrote:
>
>> I'd be surprised if the fact that someone "suddenly" writes a book about
>> these ideas would result in noone being allowed anymore to reuse them in
>> other contexts.
>
> The book in question contains significant amounts of code -- an entire
> CLOS implementation, in fact. The OP was asking about copying code
> directly (or translating it directly into another programming language,
> which would probably be considered a derivative work), not about using
> the ideas.
It's obviously in scheme, but as for freely available code, might not the tiny
clos code (which seems to have a MIT style license) by the same author be a
reasonable place to start[1]? From the original announcement:
The MOP in Tiny CLOS is very simple -- 8 introspective procedures and 9
intercessory generics -- but it retains much of the power of both of the
MOPs found in AMOP. Even though the Tiny CLOS implementation itself
isn't optimized, this MOP is amenable to optimization, using techniques
like those mentioned in AMOP. In fact, the slot access protocol used in
this MOP is such that it should be possible to get better performance
than is possible with the CLOS MOP.
'as
Footnotes:
[1] <http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/scheme/oop/tinyclos/0.html>
Barry Margolin wrote:
> In article <············@newsreader2.netcologne.de>,
> Pascal Costanza <········@web.de> wrote:
>
>>I'd be surprised if the fact that someone "suddenly" writes a book about
>>these ideas would result in noone being allowed anymore to reuse them in
>>other contexts.
>
> The book in question contains significant amounts of code -- an entire
> CLOS implementation, in fact. The OP was asking about copying code
> directly (or translating it directly into another programming language,
> which would probably be considered a derivative work), not about using
> the ideas.
Oh, I see. But the Closette code is also available from
ftp://ftp.parc.xerox.com/pub/pcl/mop/ and explicitly allows derivative
works.
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon
In article <············@newsreader2.netcologne.de>,
Pascal Costanza <········@web.de> wrote:
> Barry Margolin wrote:
> > In article <············@newsreader2.netcologne.de>,
> > Pascal Costanza <········@web.de> wrote:
> >
> >>I'd be surprised if the fact that someone "suddenly" writes a book about
> >>these ideas would result in noone being allowed anymore to reuse them in
> >>other contexts.
> >
> > The book in question contains significant amounts of code -- an entire
> > CLOS implementation, in fact. The OP was asking about copying code
> > directly (or translating it directly into another programming language,
> > which would probably be considered a derivative work), not about using
> > the ideas.
>
> Oh, I see. But the Closette code is also available from
> ftp://ftp.parc.xerox.com/pub/pcl/mop/ and explicitly allows derivative
> works.
And as other posters in this thread have already pointed out, the book
itself gives permission to copy the code. The OP obviously didn't see
that.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Jim Newton
Subject: Re: copyright notice in Art of the Metaobject Protocol
Date:
Message-ID: <337olgF3mrg5cU1@individual.net>
Well the book's copyright first forbids copying of any part.
Then before chapter 5, an exception is stated allowing
copying of chapters 5 and 6. And then again appendix D
has a copyright notice in the code which allows copying.
So yes you are right, "the book itself gives permission
to copy the code", but it takes a lot of work to find
the notice.
-jim
Barry Margolin wrote:
>
> And as other posters in this thread have already pointed out, the book
> itself gives permission to copy the code. The OP obviously didn't see
> that.
>
From: Bruno Haible
Subject: Re: copyright notice in Art of the Metaobject Protocol
Date:
Message-ID: <cqbpuu$hfu$1@laposte.ilog.fr>
Jim Newton wrote:
>
> I notice the copyright of the book "The Art of
> the Metaobject Protocol" says "No part of this book
> may be reporduced by any electronic or mechanical
> means..."
Some chapters of the book are available under a more liberal license at
http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/standard/ansi/mop/
It contains no examples, though.
Bruno
From: Kalle Olavi Niemitalo
Subject: Re: copyright notice in Art of the Metaobject Protocol
Date:
Message-ID: <87is6unkuy.fsf@Astalo.kon.iki.fi>
Bruno Haible <·····@clisp.org> writes:
> Some chapters of the book are available under a more liberal license at
> http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/standard/ansi/mop/
The same terms are printed in the book itself, in the preface to Part II,
on page 135 of ISBN 0-262-61074-4.
From: Jim Newton
Subject: Re: copyright notice in Art of the Metaobject Protocol
Date:
Message-ID: <32u518F3q8plvU1@individual.net>
Yes you are right. I found it as well.
"To this end, for Part II only (chapeters 5 and 6), we grant
permission to prepare revisions or otehr derivative works
including any amount of the original text. We ask only
that you propery acknowledge the source of the original text
and explicitly allow subsequent revisions and derivative
works under the same terms."
Interesting that they ask but do not demand that users
of the text also offer this permission to their subsequent
revisions.
Kalle Olavi Niemitalo wrote:
> Bruno Haible <·····@clisp.org> writes:
>
>
>>Some chapters of the book are available under a more liberal license at
>>http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/standard/ansi/mop/
>
>
> The same terms are printed in the book itself, in the preface to Part II,
> on page 135 of ISBN 0-262-61074-4.
I am not a lawyer, but I have a sneaky feeling that "ask" is just being
polite, rather than making it optional.
To me, it pretty clearly places conditions on the grant of permission.
That is, if you were not to comply with their request, you would not
have the permission they grant.
In any case, to refuse their request would be at the least rude, even
if not illegal.
--Joe
Jim Newton wrote:
> Yes you are right. I found it as well.
>
> "To this end, for Part II only (chapeters 5 and 6), we grant
> permission to prepare revisions or otehr derivative works
> including any amount of the original text. We ask only
> that you propery acknowledge the source of the original text
> and explicitly allow subsequent revisions and derivative
> works under the same terms."
>
> Interesting that they ask but do not demand that users
> of the text also offer this permission to their subsequent
> revisions.
Note that this was before the open-source hype, so they hadn't had the
experience of being explicit enough at that time.
I recall reading a posting by Gregor Kiczales about the issue of opening
up the specification for derivative works (that Xerox was initially
against it, etc.), but I don't remember anymore whether it was in
comp.lang.lisp, the CLOS/MOP mailing list archives or somewhere else...
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon
Given your concrete problem, it is probably safest and easiest to ask,
but thinking about this case, I began to wonder, what the use of such
books were, if certain uses of its contentet were limited.
I would catheorize this book as a text book trying to teach something.
So while of course the verbatim writing of such books is copyrighted -
if you want to publish a book about the metaobject protocol you better
write one yourself :), the use of the knowledge tought in a
textbook cannot be prohibited (or else there would lie no sense in
reading it at all).
So if you learn calculus from a textbook, obviously you may use the
gained mathematical knowledge without the authors consent. But with
books dealing with "software" things get more complicated. On the one
side, programs are copyrightable works, on the other, most books contain
program listings to display certain ideas and concepts - ideas and
concepts are not copyright materials... So perhaps the question, to
which extend may I use listings from a textbook is a very interesting
one for every programmer. If the usage rights on the content of the book
were too restrictive, they would make many books rather useless. One
could argue of course also, that the content of any such book is "public
knowledge" so its use is free unless you try to merchandize verbatim
copies. As said before, certainly a questions that should be clarified
generally.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/