[Python-mode] merging python-mode.el and python.el

[Beverley Eyre]

Dave,

Please forgive me for asking, what may seem to you to be, a dumb 
question. But I'm not a lawyer and my brain is not formatted with 
whatever structure it needs to understand legal stuff. But, it was my 
understanding, based on my readings of rms' stuff, that 'free' software 
is free so that people who care to can change the code. More, they can 
distribute this altered code to all and sundry as long it remains 
'free'.  After all, Dave, we're not doing anything that you haven't 
done. Here's the first few lines from the python-mode-map variable from 
*your* python.el code:

(defvar python-mode-map
  (let ((map (make-sparese-keymap)))
;; Mostly taken from python-mode.el     <<<<<<<==============!!!!!
   (define-key map ":" 'python-electric-colon)
    ....

Also, here's one of your comments from the 'inferior-python-mode' section:
;; Fixme: This should inherit some stuff from `python-mode', but I'm
;; not sure how much: at least some keybindings, like C-c C-f;
;; syntax?; font-locking, e.g. for triple-quoted strings?

Our 'merge' effort isn't different in any way from the spirit of your 
comments in your own code, nyet?

Secondly, it seems as if your main objections center around the question 
of which mode will be included in distributions of GNU Emacs. And you 
aren't going to include anything in Emacs which hasn't been legally 
assigned to FSF, which I can understand. But it also sounds like you are 
saying that any software 'borrowed' from some GNU Emacs 'assigned' code 
can't be distributed unless it is also assigned to the FSF. Am I 
misunderstanding you?

Also, on a personal note, I couldn't care less whether the python mode 
that I use is the officially distributed one or not. I kind of  like the 
idea of python.org distributing a python-mode, much in the same spirit 
as, say, the IEEE distributes it's own IEEEtrans.cls for those who want 
to use LaTeX to write IEEE papers. This is common in organizations that 
want their publications formatted a special way. There's no real reason 
why GNU should have to write a python mode (or a ruby mode, or a mode 
for any new language that comes down the pike). It seems more natural 
for python (or ruby or...) folk to do so.

As things stand now, both python-mode.el and python.el need work. Both 
have good stuff and bad stuff, imo. I know you agree with this, based on 
comments you yourself have made, (e.g. in the comments you make in the 
python.el header section you say that python-mode.el is "not well 
maintained. " Ok, if you think that's so, then you can't reasonably 
object to an effort to maintain and upgrade it. As far as your code 
goes, the number of your 'fixme's speak for itself.)

I'm wondering what the rms of 25 years ago would say if a lot of legal 
wrangling and copyright issues were standing in the way of a handful of 
programmers trying to get together to improve some code which they use 
all the time? AFAIK, Dave, that's all that's going on here, just some 
geeks trying to write a better tool.  At the top of my own wish list for 
this project is your help. Is that out of the question, tovarisch?

Beverley Eyre



Dave Love wrote:
> There is talk in the python-mode.el and on the web site of merging it
> with python.el.  I hope people realize that can only be done in
> accordance with the GPL licence of python.el -- i.e. one way -- although
> it doesn't seem useful anyhow.  There's already been an attempt to put
> python.el code into python-mode.el contrary to the licence via a bug
> report, and I'm concerned that it doesn't happen any more (unless
> python-mode.el's licence is changed, obviously).
>
> It's not clear to me what's in python-mode.el that would be useful to
> put in python.el, although I've only skimmed the current version.
> Anyway the main raison d'être for python.el was that we couldn't get
> copyright papers for python-mode.el for inclusion in Emacs (and I won't
> put unassigned code in my version).  Also, python-mode.el changes for
> Emacs weren't accepted, so I wrote an intentionally incompatible mode to
> minimize confusion and ease maintenance.
> _______________________________________________
> Python-mode mailing list
> Python-mode at python.org
> http://mail.python.org/mailman/listinfo/python-mode
>
>