replacing python.el

replacing python.el

[Richard M Stallman]

Since Andreas Röhler is unwilling to sign legal papers for his
code in python.el, we cannot use it in Emacs.

Would anyone like to implement for python-mode.el whatever
nice features python.el may have?  Barry, could you make a TODO list?

Re: replacing python.el

[Glenn Morris]

Richard M Stallman wrote:

> Since Andreas Röhler is unwilling to sign legal papers for his
> code in python.el, we cannot use it in Emacs.
>
> Would anyone like to implement for python-mode.el whatever
> nice features python.el may have?  Barry, could you make a TODO list?

You've got this backwards.

Emacs includes python.el, written by Dave Love, about which there is
no legal problem.

python-mode.el is the alternative, which has several contributors
including Andreas R. This has never been included in Emacs.

There is no legal problem affecting python.el distributed with GNU
Emacs.

Re: replacing python.el

[Beverley Eyre]

[-- Attachment #1.1: Type: text/plain, Size: 989 bytes --]

On 01/31/2009 11:00 PM, Glenn Morris wrote:
> Richard M Stallman wrote:
>
>    
>> Since Andreas Röhler is unwilling to sign legal papers for his
>> code in python.el, we cannot use it in Emacs.
>>
>> Would anyone like to implement for python-mode.el whatever
>> nice features python.el may have?  Barry, could you make a TODO list?
>>      
>
> You've got this backwards.
>
> Emacs includes python.el, written by Dave Love, about which there is
> no legal problem.
>
> python-mode.el is the alternative, which has several contributors
> including Andreas R. This has never been included in Emacs.
>
> There is no legal problem affecting python.el distributed with GNU
> Emacs.
>
>    
Glenn,

Don't forget that there was a peck of code that Dave Love took from 
python-mode.el in his python.el.  Although he acknowledged it in the 
comments he used inline, if some of it was from Andreas, maybe rms is 
correct and python.el will have to be sidelined.

Bev

[-- Attachment #1.2: Type: text/html, Size: 1379 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: replacing python.el

[Dave Love]

Beverley Eyre <fbe2@comcast.net> writes:

> Don't forget that there was a peck of code that Dave Love took from
> python-mode.el in his python.el.

That's not true, as I've already responded to Eyre with some subset of
these Ccs.  As well as this claim of wholesale copying, and thus me
lying about the copyright status of the code, there was the implication
that I was violating other's copyright, and that people should ignore
the licence on free software (bizarrely on the basis of what rms
supposedly wrote).  I advised legal advice on copyright, and should
probably have mentioned libel.

[For the benefit of emacs-devel, this all originated when I complained
about someone distributing a chunk of my code with the FSF copyright
notice stripped as a patch for python-mode.el, which was under a simple
permissive licence.  I also saw a call for volunteers to merge the two
modes, and pointed out the GPL'd code couldn't be used under the
permissive licence -- there was no mention of changing it -- and that
code couldn't be used in Emacs without a proper assignment.]

Obviously if the FSF's legal advice on what's significant for copyright
purposes has changed, if I misinterpreted it, or made a mistake, I'd
re-write stuff appropriately.  However, I don't think it's worth
worrying about it on the basis of someone who's so far quoted some
duplicated keybindings, and a Fixme comment that was clearly mine, as
evidence of all this copied code.  If Emacs developers are worried,
please contact me more privately.

Re: replacing python.el

[Beverley Eyre]

[-- Attachment #1: Type: text/plain, Size: 5141 bytes --]

Dave et al,
  I'm not sure what you think "isn't true". I'll repeat that I don't blame you for using python-mode.el when you
wrote python.el. My whole point was that you did. The following are some of the comments in your code that generated my
remarks:

(from python.el, GNU Emacs version 22.3.1)
------------------------------
(defvar python-mode-map
(let ((map (make-sparse-keymap)))
;; Mostly taken from python-mode.el.
-------------
   ;; Fixme: Like python-mode.el; not convinced by this.
---------
   ;; indentable comment like python-mode.el
---------
   ;; Fixme: I'm not convinced by this logic from python-mode.el.
---------
   ;; The logic is taken from python-mode.el.
---------------------------------

Plainly you did what those who were talking about 'merging' were going to do too. My 'job' (if you could call it that) was to
compare how the two modes did things (i.e. their logic), and what things they chose to do (their features). The fact that you occasionally used the
'logic' from python-mode.el was something I was glad to see, as it made my job easier.

Maybe you object to the word "peck", but you used code from python-mode, even if you altered it in the transition.
It's unclear from your comments whether you copied the logic only or more, but that's not important (except maybe to lawyers).

My whole point is that if you borrowed logic or code or ideas for features or whatever from python-mode.el for python.el,
then it's a little hypocritical to try to legally prevent those trying to make a better, more useful, mode from potentially
using some of your code in the same manner. Not that I feel like it anymore, to be honest. From my understanding, no one suggesting cutting
and pasting your code. The discussion was about whether your logic was better or not, what features each had, and ultimately whether python.el had
anything in it that was worth learning from when upgrading python-mode.el.

This is where I'm coming from, Dave. The people who wrote python-mode.el start to plan an upgrade, and, noting that there is confusion,
duplication of effort, and, needlessly, two python modes, wonder whether their might be some way to make a better mode using both. As anyone who
looks at both modes at all can instantly see, cutting and pasting is not going to work. Any 'merging' will necessarily have to be done on the
level of using the best algorithm for doing X, and incorporating the most useful features (as well as removing features that aren't so useful).

Tell me this isn't what you did when you wrote python.el. Why did you choose to use the 'logic' from certain features in python-mode.el if you hadn't
gone through it specifically for the purpose of seeing what you could use and what you couldn't?  Plainly that was what was on your mind.


LEGAL DISCLAIMER:
Dave, I'm not accusing you of doing anything illegal, or even bad. I think what you did was good.
I think others should be allowed to do the same thing.

DEFINITION: "the same thing"
	By "the same thing" this author (to be henceforth designated as "this author") does not mean, imply, point to, or otherwise entail any
	action that can be classed as either legal or illegal (i.e. "follow a copyright law" or "break a copyright law"), but only means, implies,
	points to, and entails actions that can be classed as "programming" (i.e. writing symbols understood by computer compilers and/or
	interpreters for the purpose of causing, directing, or changing the behavior of computers).


Oi vey.

Bev

On 02/01/2009 12:56 PM, Dave Love wrote:

> Beverley Eyre<fbe2@comcast.net>  writes:
>
>    
>> Don't forget that there was a peck of code that Dave Love took from
>> python-mode.el in his python.el.
>>      
>
> That's not true, as I've already responded to Eyre with some subset of
> these Ccs.  As well as this claim of wholesale copying, and thus me
> lying about the copyright status of the code, there was the implication
> that I was violating other's copyright, and that people should ignore
> the licence on free software (bizarrely on the basis of what rms
> supposedly wrote).  I advised legal advice on copyright, and should
> probably have mentioned libel.
>
> [For the benefit of emacs-devel, this all originated when I complained
> about someone distributing a chunk of my code with the FSF copyright
> notice stripped as a patch for python-mode.el, which was under a simple
> permissive licence.  I also saw a call for volunteers to merge the two
> modes, and pointed out the GPL'd code couldn't be used under the
> permissive licence -- there was no mention of changing it -- and that
> code couldn't be used in Emacs without a proper assignment.]
>
> Obviously if the FSF's legal advice on what's significant for copyright
> purposes has changed, if I misinterpreted it, or made a mistake, I'd
> re-write stuff appropriately.  However, I don't think it's worth
> worrying about it on the basis of someone who's so far quoted some
> duplicated keybindings, and a Fixme comment that was clearly mine, as
> evidence of all this copied code.  If Emacs developers are worried,
> please contact me more privately.
>
>    


[-- Attachment #2: Type: text/html, Size: 5627 bytes --]

Re: replacing python.el

[Chong Yidong]

Beverley Eyre <fbe2@comcast.net> writes:

> From my understanding, no one suggesting cutting and pasting your
> code.

Dave's objection, if I understand it correctly, is precisely the cutting
and pasting of his code:

  this all originated when I complained about someone distributing a
  chunk of my code with the FSF copyright notice stripped as a patch for
  python-mode.el, which was under a simple permissive licence.

Re: replacing python.el

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 1, 2009, at 10:37 PM, Chong Yidong wrote:

> Beverley Eyre <fbe2@comcast.net> writes:
>
>> From my understanding, no one suggesting cutting and pasting your
>> code.
>
> Dave's objection, if I understand it correctly, is precisely the  
> cutting
> and pasting of his code:
>
>  this all originated when I complained about someone distributing a
>  chunk of my code with the FSF copyright notice stripped as a patch  
> for
>  python-mode.el, which was under a simple permissive licence.

Which is no longer a problem.

https://launchpad.net/python-mode/+announcement/1906

Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSYb3knEjvBPtnXfVAQJymAP/RKNaA+/WG9z97Zbq/s0t/PC4U7CBR9oy
9SweAhvOF+SOQMgRE0pqiZOxqXxvxfokvxqXjiOinHUAya7m0ViwY6tMwTnCgKcL
q5bnlOMO1H/b8lxicKDvtzReMZOjHVR3YwMCTu6r87RMn0ODEOcngsHJgVanYr8q
QBc0t5HFvhQ=
=6Yc2
-----END PGP SIGNATURE-----

Re: replacing python.el

[Richard M Stallman]

      However, I don't think it's worth
    worrying about it on the basis of someone who's so far quoted some
    duplicated keybindings, and a Fixme comment that was clearly mine, as
    evidence of all this copied code.  If Emacs developers are worried,
    please contact me more privately.

Those facts give us no reason to be concerned legally about your code.

I also have no opinion about whether we would prefer to use
python-mode.el, python.el, or some combination of the two.
(I have never used either one, since I don't know Python.)
That question is up to the Emacs maintainers, Stefan and Yidong.

Re: replacing python.el

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 1, 2009, at 2:00 AM, Glenn Morris wrote:

>> Since Andreas Röhler is unwilling to sign legal papers for his
>> code in python.el, we cannot use it in Emacs.
>>
>> Would anyone like to implement for python-mode.el whatever
>> nice features python.el may have?  Barry, could you make a TODO list?
>
> You've got this backwards.
>
> Emacs includes python.el, written by Dave Love, about which there is
> no legal problem.
>
> python-mode.el is the alternative, which has several contributors
> including Andreas R. This has never been included in Emacs.
>
> There is no legal problem affecting python.el distributed with GNU
> Emacs.

As Andreas pointed out, we have not yet merged his changes into python- 
mode.el.

I had hoped that it would be possible to merge python-mode.el and  
python.el and reduce the confusion and inconvenience of Python X/Emacs  
users.  Andreas's opinion is that that is technically impossible and I  
believe it is Dave's opinion that it will be practically impossible  
from a legal perspective.  If that's the case, then so be it; we will  
continue to develop and maintain python-mode.el as an alternative and  
XEmacs will likely include our version in its distribution.  Emacs  
users will have to find it if they are looking for an alternative, but  
once they do, it should work just fine for them.

python-mode.el is now GPLv3.

I don't know what more we can do and it seems like python-mode.el will  
never be included in Emacs.  Oh well.  Under those circumstances, I  
see no reason not to allow Andreas to merge his changes into python- 
mode.el even without his copyright assignments.

If I'm wrong in any of the above, please correct me.

Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSYWWi3EjvBPtnXfVAQKkuQP/VHorZluGw6k1NSZ6cOCLB3AuZGuMiooy
o3j+1MpuP1vL5GFc5eVrv92vOLesaDnj+odV5ZTrPWujxu8vVSR6RZREp9hPVT8e
CptPo/SsBZwKW8e3vkQNQ5n/p75Yvqw5AZdbwVH6WF6rVRTq3rqDd8/Mn56JDvvU
zKgXgwKVnKY=
=AO9T
-----END PGP SIGNATURE-----

Re: replacing python.el

[Jeff Kowalczyk]

On Sun, 01 Feb 2009 07:33:15 -0500, Barry Warsaw wrote:
> As Andreas pointed out, we have not yet merged his changes into python- 
> mode.el.
> 
> I had hoped that it would be possible to merge python-mode.el and  
> python.el and reduce the confusion and inconvenience of Python X/Emacs  
> users.  Andreas's opinion is that that is technically impossible and I  
> believe it is Dave's opinion that it will be practically impossible  
> from a legal perspective.

If Andreas' changes were to remain unmerged, would the merger of
python-mode.el and python.el still be regarded as technically and/or
legally impossible? 

Jeff

Re: replacing python.el

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 1, 2009, at 10:42 AM, Jeff Kowalczyk wrote:

> On Sun, 01 Feb 2009 07:33:15 -0500, Barry Warsaw wrote:
>> As Andreas pointed out, we have not yet merged his changes into  
>> python-
>> mode.el.
>>
>> I had hoped that it would be possible to merge python-mode.el and
>> python.el and reduce the confusion and inconvenience of Python X/ 
>> Emacs
>> users.  Andreas's opinion is that that is technically impossible  
>> and I
>> believe it is Dave's opinion that it will be practically impossible
>> from a legal perspective.
>
> If Andreas' changes were to remain unmerged, would the merger of
> python-mode.el and python.el still be regarded as technically and/or
> legally impossible?

I will defer to Andreas and Bev since they've looked at this issue  
most closely.

Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSYbw8HEjvBPtnXfVAQL6CQP/dWgzfxYptW7BXcVmliK6ufZYMjHQ8Mna
Yi9bX3gJxFsh8A0XG2OmiydHoKxNHv3EMao3rVoZHA3xcpOAtPfAGxdFbOoRJx+Q
idw8j3Z3A7lFO2S8zxQqaRFAliohhh1QNCpPS9iVxWkiTkK+0jyv55EuRe8TV2sq
+vmMDu0FPQk=
=s2L0
-----END PGP SIGNATURE-----

Re: replacing python.el

[Stefan Monnier]

> I had hoped that it would be possible to merge python-mode.el and python.el
> and reduce the confusion and inconvenience of Python X/Emacs  users.
> Andreas's opinion is that that is technically impossible and I  believe it
> is Dave's opinion that it will be practically impossible  from a legal
> perspective.  If that's the case, then so be it; we will  continue to
> develop and maintain python-mode.el as an alternative and  XEmacs will
> likely include our version in its distribution.  Emacs  users will have to
> find it if they are looking for an alternative, but  once they do, it should
> work just fine for them.

> python-mode.el is now GPLv3.

I'm glad to hear it's now GPLv3.  From Emacs's point of view, we'd like
to see the two converge, but this seems only possible if python-mode.el
can be included in Emacs which requires its code to be assigned to
the FSF.  If the copyright assignment is reasonably possible, then
I see no reason why the two code bases can't converge (clearly half the
code would be thrown out, and there may be some tricky political work to
do to get keybindings aligned, etc...).

Last time this was brought up, the general sentiment was that, if
merging is too difficult, it might be preferable to switch wholesale to
python-mode.el (and then maybe try to retrofit some of python.el's
featureset).

> It seems like python-mode.el will never be included in Emacs.

Why is that?  Too many contributors?  Can't be tracked down?
Won't sign papers?


        Stefan

Re: replacing python.el

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 1, 2009, at 4:57 PM, Stefan Monnier wrote:

>> It seems like python-mode.el will never be included in Emacs.
>
> Why is that?  Too many contributors?  Can't be tracked down?
> Won't sign papers?

Just pessimistic we can work out the legal details.  I'm willing to do  
my part though.

Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSYdCI3EjvBPtnXfVAQLPTwP9GEKr+Y6DQtGNmEeBHxpcVSg9LqF8JXP0
M9HumrOd5eOUnADQSA3WHVPPWwZa/TMb8CpRsMk8JZHpzjKOpnichU1Bn1AymDbd
wLhQGi4XKN7MtgR7vnZKlK3NRE39a8S6uicx+hcS0ukmBsddZEg0frp3pbV2LqVE
jw3ahTdw6NI=
=ZPSO
-----END PGP SIGNATURE-----

Re: replacing python.el

[Dave Love]

I seem to be repeating this to ever-expanding lists of addresses.

Glenn Morris <rgm@gnu.org> writes:

> You've got this backwards.
>
> Emacs includes python.el, written by Dave Love, about which there is
> no legal problem.

Indeed, and I don't understand what other problem there is with it,
other than maintenance.  Why does it need to be replaced with
python-mode.el, even if that was properly assigned?

The only other worthwhile feature I know of sort-of from python-mode.el
is related to something called pdbtrack (?).  My commentary explains
that part of the functionality already exists, and something more
general than the rest should be a general feature in GUD.  (The
Python-specifics are already there.)  It's not difficult to restructure
GUD -- or wasn't when I hacked it originally -- and it's not clean to
make an add-on, which is why it's not in python.el.  I know there isn't
interest in abstractions like that, but I didn't want to preempt a
possible change of opinion.

> python-mode.el is the alternative, which has several contributors
> including Andreas R. This has never been included in Emacs.

Right.  We'd have included (a significantly modified version of) it if
we'd been able to get the paperwork.  As far as I know, I was the last
person to try to sort that out after previous attempts.  The GNU
copyright.list shows I failed in Barry's case (through no fault of his
-- it needed paperwork from his employer, and I'm sure he wanted to
DTRT).  I think at least gerd and monnier worked on it previously, and
there's an assignment on file from the original author, which I don't
remember anything about.  We never addressed possible significant
contributions from others as far as I know, and this was over five years
ago.

[Skip Montanaro says his multiple attempts to assign copyright failed
due to the FSF office.  I don't know who asked for the papers, and I
advised telling rms about the problem, though I think the assignment
would only be useful for future contributions.]

Re: replacing python.el

[Stefan Monnier]

>> Emacs includes python.el, written by Dave Love, about which there is
>> no legal problem.
> Indeed, and I don't understand what other problem there is with it,
> other than maintenance.  Why does it need to be replaced with
> python-mode.el, even if that was properly assigned?

Maintenance is pretty significant problem, actually.  The other problem
is that all the Python coders I know install python-mode.el rather than
use python.el.  I don't know if it's representative, but if that's the
case, then our users would be better served with python-mode.el
included in Emacs.

> The only other worthwhile feature I know of sort-of from python-mode.el
> is related to something called pdbtrack (?).  My commentary explains
> that part of the functionality already exists, and something more
> general than the rest should be a general feature in GUD.  (The
> Python-specifics are already there.)  It's not difficult to restructure
> GUD -- or wasn't when I hacked it originally -- and it's not clean to
> make an add-on, which is why it's not in python.el.  I know there isn't
> interest in abstractions like that, but I didn't want to preempt a
> possible change of opinion.

Yes, that sounds very good.  But someone has to make this change to
gud.el.  Feel free to submit your patches here.


        Stefan

Re: replacing python.el

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the meantime, can you fix a few small inaccuracies in python.el?

;; There is another Python mode, python-mode.el, used by XEmacs and
;; maintained with Python.  That isn't covered by an FSF copyright
;; assignment, unlike this code, and seems not to be well-maintained
;; for Emacs (though I've submitted fixes).  This mode is rather
;; simpler and is better in other ways.  In particular, using the
;; syntax functions with text properties maintained by font-lock makes
;; it more correct with arbitrary string and comment contents.

python-mode.el is now maintained as a separate package, by some of the  
core Python developers and others.  Please include a link to its  
project page:

http://launchpad.net/python-mode

Also, python-mode.el works perfectly fine with Emacs.  I use it 8+  
hours a day this way.

Thanks,
Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSYb+SXEjvBPtnXfVAQJXgwP+KYiAqn2xueZCSwmdZrtauljVw0FFaG5H
JC/EFkb8S7D24Vuls9kjMwMGhfaS916dGE5qJ8IM/cBPnuIcdN6/vwssx9rgGhy+
QsyMWA1T7Wg4vRIO1u/cCOcPOsOFVIEt7pBnqK3dTfGS2mDH3e6skRtqGy6s7+I8
z3dk/7UJv68=
=JowZ
-----END PGP SIGNATURE-----

Re: replacing python.el

[ken manheimer]

sorry to be late to this python.el / python-mode.el convergence
discussion.  i'm concerned that what dave is describing would not
preserve a crucial feature of pdbtrack, a feature that may be a reason
some python developers choose python-mode.el over python.el.  (it is
for me.)

On Sun, Feb 1, 2009 at 3:51 PM, Dave Love <fx@gnu.org> wrote:
>[...]
> Indeed, and I don't understand what other problem there is with it,
> other than maintenance.  Why does it need to be replaced with
> python-mode.el, even if that was properly assigned?
>
> The only other worthwhile feature I know of sort-of from python-mode.el
> is related to something called pdbtrack (?).  My commentary explains
> that part of the functionality already exists, and something more
> general than the rest should be a general feature in GUD.  (The
> Python-specifics are already there.)  It's not difficult to restructure
> GUD -- or wasn't when I hacked it originally -- and it's not clean to
> make an add-on, which is why it's not in python.el.  I know there isn't
> interest in abstractions like that, but I didn't want to preempt a
> possible change of opinion.

when i last looked at it, gud was a terrible fit for pdbtrack.  if
things haven't changed drastically,  i'm concerned that what you're
suggesting would sacrifice pdbtrack's dynamicism.

this is all the more worrisome since i spent some time porting
pdbtrack to python.el.  it's currently there in emacs 23.0.90, but i
see it's not in the emacs that comes w/recent ubuntu, emacs 22.2.

here's the scoop, as best i can describe it.

gud is oriented to being in control of debugging, in particular
launching the program being debugged, or injecting a connection to
the executive to start the debugging at an arbitrary point, or
post-mortem.

pdbtrack, on the other hand, simply works wherevever python's
debugger, pdb, does.  the pdbtrack code is responsible for detecting
pdb activity within an (any) emacs shell and presenting, in a
companion buffer,  the source file and line that pdb is reporting as
the current instruction.

pdbtrack provides functionality for python's debugger, pdb, much like
edebug does for emacs lisp, except that pdb can be triggered as a
statement within the subject program's code, and not just taking over
execution of the program (as gdb and edebug do), or run
onerror/post-mortem.  (pdb also provides those modes.)  this turns out
to be invaluable in general, and especially for long-running programs
like servers, where you want debugging to trigger in very specific
situations.  with pdb, you just situate the debug-triggering code
exactly in the situation (i wish i could do this with edebug), or as
error handling around the situation.

gud may have facilities that could be used to enhance pdbtrack, but i
don't think it is designed to operate the way i describe above.  plus,
gud is massive, and i suspect it would take more emacs lisp code to
craft gud python accommodations than all of pdbtrack (last i checked
around 150 lines, including copious comments).

i hope this is clear.  as i said, pdbtrack porting to python.el has
already been done, it just isn't in the currently released version.
and, of course, there are other benefits to be had from a
python-mode.el/python.el convergence, but i want to make sure this
one, at least, is preserved.  (i also think the pdbtrack approach
would be appreciated for other dynamic languages, including emacs
lisp.)
-- 
ken
http://myriadicity.net

Re: replacing python.el

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 19, 2009, at 3:21 PM, ken manheimer wrote:

> this is all the more worrisome since i spent some time porting
> pdbtrack to python.el.  it's currently there in emacs 23.0.90, but i
> see it's not in the emacs that comes w/recent ubuntu, emacs 22.2.

FWIW, on Intrepid (Ubuntu 8.10) if you install the emacs-snapshot  
package instead, you'll get Emacs 23.  It does look like it contains  
something called pdbtrack, though I haven't tried it.

(Hi Ken!)
Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSZ3QxXEjvBPtnXfVAQKjZQQAjxKcLicxnXBhq8kao7bwqZA84tcRz2fb
0755rVcviHehCzDf8l2xs5ey4brISrerd8eRGxWYSc1ezm6xBjZCz7FduGeZgxUt
tAP72kUEygt0eF4BJtirUF6ZqadhXESQsJNvv3qsraauXbTSzf+IACgeGLiu2kmT
UI7TLkaw4wA=
=PslZ
-----END PGP SIGNATURE-----

Re: replacing python.el

[Richard M Stallman]

    You've got this backwards.

    Emacs includes python.el, written by Dave Love, about which there is
    no legal problem.

    python-mode.el is the alternative, which has several contributors
    including Andreas R. This has never been included in Emacs.

Please forgive my confusion.  I did not remember any of this, so I
tried to figure out the situation from the message I was reading.

Since neither program includes Andreas' code, it seems there is no
legal obstacle to using some or all of python-mode.el in Emacs, except
whether Barry can get a disclaimer from the employers he has worked
for while writing the code.

If it is useful, we could ask a lawyer whether we can get by without
some or all of those disclaimers.  The lawyer would need to get more
detailed information from Barry about various things.

It's up to the Emacs maintainers to decide what to do about this.  If
they think this legal advice is useful, they should ask me to get it.

Re: replacing python.el

[Beverley Eyre]

On 01/31/2009 10:31 PM, Richard M Stallman wrote:
> Since Andreas Röhler is unwilling to sign legal papers for his
> code in python.el, we cannot use it in Emacs.
>
> Would anyone like to implement for python-mode.el whatever
> nice features python.el may have?  Barry, could you make a TODO list?
>
>
>    
I didn't know any of Andreas' code was in Python.el. Was that some of 
the stuff that Dave.....ah... took from python-mode.el?

Bev

Re: replacing python.el

[Stefan Monnier]

>> Since Andreas Röhler is unwilling to sign legal papers for his
>> code in python.el, we cannot use it in Emacs.
>> 
>> Would anyone like to implement for python-mode.el whatever
>> nice features python.el may have?  Barry, could you make a TODO list?
> I didn't know any of Andreas' code was in Python.el. Was that some of the
> stuff that Dave.....ah... took from python-mode.el?

Dave is usually pretty anal about copyright, so I'd be very surprised he
copied code like that without mentioning it very clearly.  Much more
likely is a typo in the above message.


        Stefan