unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Beverley Eyre <fbe2@comcast.net>
To: Dave Love <fx@gnu.org>
Cc: "skip@pobox.com" <skip@pobox.com>, "rms@gnu.org" <rms@gnu.org>,
	"python-mode@python.org" <python-mode@python.org>,
	"XEmacs-Beta@xemacs.org" <XEmacs-Beta@xemacs.org>,
	"barry@python.org" <barry@python.org>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: replacing python.el
Date: Sun, 01 Feb 2009 18:37:06 -0800	[thread overview]
Message-ID: <49865C52.1060901@comcast.net> (raw)
In-Reply-To: <87vdrt6flh.fsf@liv.ac.uk>

[-- 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 --]

  reply	other threads:[~2009-02-02  2:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4980316B.7080503@online.de>
2009-02-01  6:31 ` replacing python.el Richard M Stallman
2009-02-01  7:00   ` Glenn Morris
2009-02-01  7:58     ` Beverley Eyre
2009-02-01 20:56       ` Dave Love
2009-02-02  2:37         ` Beverley Eyre [this message]
2009-02-02  3:37           ` Chong Yidong
2009-02-02 13:39             ` Barry Warsaw
2009-02-02 16:43         ` Richard M Stallman
2009-02-01 12:33     ` Barry Warsaw
2009-02-01 15:42       ` Jeff Kowalczyk
2009-02-02 13:11         ` Barry Warsaw
2009-02-01 21:57       ` Stefan Monnier
2009-02-02 18:57         ` Barry Warsaw
2009-02-01 20:51     ` Dave Love
2009-02-01 22:03       ` Stefan Monnier
2009-02-02 14:08       ` Barry Warsaw
2009-02-19 20:21       ` ken manheimer
2009-02-19 21:36         ` Barry Warsaw
2009-02-01 22:48     ` Richard M Stallman
2009-02-01  7:55   ` Beverley Eyre
2009-02-01 22:05     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49865C52.1060901@comcast.net \
    --to=fbe2@comcast.net \
    --cc=XEmacs-Beta@xemacs.org \
    --cc=barry@python.org \
    --cc=emacs-devel@gnu.org \
    --cc=fx@gnu.org \
    --cc=python-mode@python.org \
    --cc=rms@gnu.org \
    --cc=skip@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).