Re: [Python-mode] merging python-mode.el and python.el
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 1, 2009, at 1:26 PM, Dave Love wrote: Doubtless, but Emacs isn't just for Python programmers, and surely modes should be consistent. That's pretty much a universal design decision across all of software, isn't it? python.el takes one approach, python-mode.el takes a different one. I've been a X/Emacs user for probably close to 25 years and python-mode.el does not feel unnatural to me, even if it has some unorthodox coding conventions. I rely (modulo a few historical things which should be fixed) on the same conventions if I'm hacking Python as, say, Fortran, sh, or Lisp. In fact, part of the idea of the new mode was to figure out what more to abstract over similar modes. Sure, all valid approaches, although there's an important difference in aims between python.el and python-mode.el. The former only cares about Emacs compatibility. The latter cares about both Emacs and XEmacs compatibility. In many cases the abstraction are different enough as to make refactoring a challenge. If people don't like the conventions or want things which break other code, they can customize and distribute the customizations, of course. (Custom theme support may help.) I'd hope they'd try to understand the general conventions, though, and not cause confusion over them. Sure, but there's another difference. python-mode.el has been around for a very long time and its users for the most part like the way it works. As someone who would likely begin to curse his own fingers, I don't think we should break that backwards compatibility in python- mode.el. Let's agree that everyone involved have the right intention to improve the situation, I don't doubt your intentions -- sorry if it seems otherwise. It's a different matter for someone else if they don't respect the FSF's copyright, for instance, and that's presumably mutual. Of course. I certainly appreciate the arguments that Andreas and Beverley make as to copyright. I have my own opinions on that subject both as a FLOSS developer and musician. But this isn't an effective forum for changing either the FSF's stance, nor US or international law on the matter, so I believe we must adapt to the regime under which we live, and take the fight to the forums where such change can actually be affected. I still propose we GPLv3 python-mode.el. Thus if we cannot merge, we will simply continue to develop python-mode.el separately, educate users as to the differences, and let them decide which they prefer. With a GPLv3 python-mode.el we can all borrow from each other. Fine. That solves the basic problem of copying code from Emacs in accordance with the licence -- e.g. with appropriate copyright notices -- but I'm sure you'll keep an eye on that. Cool. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCUAwUBSYcUgHEjvBPtnXfVAQI16AP3d62FgQ3YTFmpReFPG6X5a1udkj0Uas/d 9DwWOtXT/PZ4+f5MmwuhIO/Ehx3+rlbL3BFwYYHeQgVfgx+LudRZT7zi+A64KhG1 TzhGWCfSPED7DsP0HsDGZDaXuGcWkm/PEWkEi0fvqet5alaOkDi4SA7KTmNijINT G0yCdQajsg== =m+IZ -END PGP SIGNATURE- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
Barry Warsaw wrote: I also think that python-mode.el feels more natural to Python programmers, but I have only anecdotal evidence for that. Just last week I had a colleague ask me why Emacs wasn't working the way he wanted while editing his Python code. I made a wild guess and pointed him to python-mode.el and it solved his problem. That's happened to me several times when Emacs users don't realize that they have a different Python mode. Yes, I was one of those who wondered why Python didn't feel right in Emacs until I realized there were multiple versions. It's a subjective thing, but no less important for that. I still propose we GPLv3 python-mode.el. Thus if we cannot merge, we will simply continue to develop python-mode.el separately, educate users as to the differences, and let them decide which they prefer. With a GPLv3 python-mode.el we can all borrow from each other. +1 Jeff Bauer Rubicon, Inc. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
s...@pobox.com s...@pobox.com writes: Based on my own personal experience I don't think you can lay all the blame on the folks who have contributed to python-mode.el. Who's laying blame? There wasn't much point in me pursuing any other authors without an assignment for Barry's code, but it's now moot. If you're having trouble with copyright assignments, and don't get anywhere with the clerk, rms would probably like to know. Dave It's not clear to me what's in python-mode.el that would be useful Dave to put in python.el... A lot of people like pdbtrack. Maybe, but it shouldn't be in Python mode, per my commentary. Something like that clearly shouldn't be done there and more-or-less duplicated in N other modes with inferior interpreters. (Actually, there is a bunch of stuff left in python.el that shouldn't be there, and would have been abstracted over similar modes if I'd had the chance, but at least some of that required modifications to Emacs.) The python-mode project also includes bits Emacs Lisp and Python code to interface with Pymacs. I believe both are unique to the python-mode project. $ grep -i pymacs python-mode.el $ grep -i pymacs python.el (autoload 'pymacs-load pymacs nil t) (pymacs-load bikeemacs brm-) ; first line of normal recipe When I wrote python.el, as far as I could tell it had a superset of features of the old mode which, as an experienced maintainer, I thought should or had to be there (as opposed to things like generalized Eldoc support, symbol completion, Capitalized Words mode, c, and things which violate Emacs requirements for keybindings and things). ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
Andreas Roehler andreas.roeh...@online.de writes: Somehow this diff --thanks btw-- contradicts your arging here, don't it? No, but what's that got to do with FSF copyright? so I wrote an intentionally incompatible mode that's human... Mainly engineering as far as I'm concerned. Is python.el now included in FSF Emacs? AFAIK not, for the kind of reasoning above. Please check, if you don't know. Please let us contribute free code to free software. What?? I've spent a lot of effort encouraging and facilitating that, even before the term was invented, and I've learnt to take legalities seriously -- apart from maintaining GNU software. If you have an argument with someone over doing anything you like with my Emacs code, it's with the FSF. They hold the copyright, as it says in the notice. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
Barry Warsaw ba...@python.org writes: While technically the python-mode.el file does not have GPL license on it, we've tried many times in the past to assign copyright so that it /could/ have such a license on it, and even be owned by the FSF. Like I just posted elsewhere (?), we -- I think at least three people at different times -- tried to get proper paperwork for Emacs, and I gave up when it seemed we weren't going to get paperwork from your then (or former?) employer. I don't know whether I can find the mail at this remove, and I don't want to spend time looking. I'm not questioning your willingness, obviously; you had multiple assignments on file, and it was clear it wasn't in your control. I wasn't aware you'd tried and failed (apart from that) and, as far as I remember, at that time we were proactive in seeking assignments. That's only relevant to copying _into_ Emacs, though, not out of it. though there may be contributions described in comments that need to be looked at. Indeed (or not described anywhere). I believe there should be no reason why python-mode.el could not be released under the GPL, probably even with a copyright FSF. If there are a few contributors who need to be tracked down to get assignments from, that shouldn't be difficult. I'm not exactly a beginner in that area, unfortunately, and I wouldn't bank on it; re-implementation is often a better bet. Now that there's support for, and in, Emacs, I think the issue is moot. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
Beverley Eyre f...@comcast.net writes: 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. Partly, yes. More, they can distribute this altered code to all and sundry as long it remains 'free'. You should re-read rms, and read the GPL and probably the licensing area of the GNU web site. After all, Dave, we're not doing anything that you haven't done. I've never knowingly (or even inadvertently, as far as I know) violated a free software licence -- rms' archetype here -- which is what you seem to be advocating, 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) You're arguing interfaces are copyrightable?? (In which case python-mode.el would have a problem.) Even if I copied a significant amount of code directly -- which I didn't, unless you want to argue against legal advice and case law -- the python-mode.el licence would allow me. 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? I've no idea what that's about -- objecting to me calling the function `python-mode'? Our 'merge' effort isn't different in any way from the spirit of your comments in your own code, nyet? The words `apples' and `oranges' come to mind. If you want to argue copyright, you should consult a lawyer, like rms does. (I'm not a lawyer, but I hope what I say is consistent with the FSF's legal advice; if not, I'd like to be corrected with a proper reference.) Secondly, it seems as if your main objections center around the question of which mode will be included in distributions of GNU Emacs. No. 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? Yes, you are misunderstanding. You merely need to abide by the licence. The FSF publishes guides to such things. I think it's all under URL:http://www.gnu.org/licensing. 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). Indeed, and `GNU' didn't write it, or ask me to. It seems more natural for python (or ruby or...) folk to do so. I'm sorry I'm not in your club, but I think understanding Emacs is most important thing for contributing language support (assuming the language is sufficiently well-defined and it doesn't require large amounts of non-Emacs support code). `Python folk' haven't supported recent Emacs -- as opposed to XEmacs -- or even the latest version of Python as far as I can tell. That's perfectly OK, just as me doing it is. As things stand now, both python-mode.el and python.el need work. Both have good stuff and bad stuff, imo. I'll probably at least fix clear bugs and omissions (apart from XEmacs support) in python.el that I hear about. I'll also listen to _well-informed_ opinion about possible mis-features. 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. It says `[...] maintained for _Emacs_'. Ok, if you think that's so, then you can't reasonably object to an effort to maintain and upgrade it. Please don't put words in my mouth. All I'm actually objecting to is potential copyright violation. If you insist on copying code from Emacs in violation of the licence, you'll end up on the wrong side of the FSF `compliance lab' (ugh). As far as your code goes, the number of your 'fixme's speak for itself.) The number doesn't say anything per se, even if they are all mine that you're looking at. 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? That's a pretty bizarre thing to lecture me about. -- Copyleft (Ɔ) All rights reversed. — Don Hopkins ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
Barry Warsaw wrote: On Jan 18, 2009, at 4:29 PM, 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. While technically the python-mode.el file does not have GPL license on it, we've tried many times in the past to assign copyright so that it /could/ have such a license on it, and even be owned by the FSF. It's long been pulled out of the Python distribution so it needn't (and in fact doesn't) have a PSF license on it. Tim and I have both assigned copyright in our changes to the FSF. I think Ken did too, as he was the author of pdb-track among other good code in python-mode.el. I'm not sure about Skip. Looking at the committer line from 'bzr log' (which should include the svn history), that should just about cover it, though there may be contributions described in comments that need to be looked at. I believe there should be no reason why python-mode.el could not be released under the GPL, probably even with a copyright FSF. If there are a few contributors who need to be tracked down to get assignments from, that shouldn't be difficult. -Barry Hi Barry, I didn't sign code to FSF and probably will not. The reasons I already declared on FSF-list and towards RMS. Will not make it up here, unless you ask me to. As you approved my tiny peace of code, but not merged AFAIS, should I keep a separate branch on lp? Cheers Andreas Röhler ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 19, 2009, at 4:48 AM, Andreas Roehler wrote: I didn't sign code to FSF and probably will not. The reasons I already declared on FSF-list and towards RMS. Do you have a pointer to that discussion? Will not make it up here, unless you ask me to. As you approved my tiny peace of code, but not merged AFAIS, should I keep a separate branch on lp? Please do that for now, until we resolve any legal issues that Dave is bringing up. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXSFo3EjvBPtnXfVAQIS+gP+MI6XdhGay+tz/jhs2RswxP8yGljPYuX4 9NVzWZBOmWNTsod/iDKXOzZfrITN9T94dCrLo9fkj3A1tf4Sax/Y8HJjgrzEJQIP NDvYD9y1kSheNpbS9NjLjiJGT4eiUfSUyP5C9k/EIQzst6fRXzMAbe4s8zRpTDWG 0ydfmtiH9RU= =eLGM -END PGP SIGNATURE- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] merging python-mode.el and python.el
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@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
Dave Anyway the main raison d'être for python.el was that we couldn't Dave get copyright papers for python-mode.el for inclusion in Emacs Funny that. The FSF paperwork mavens have failed several times (at least three that I'm aware of) to get paperwork to me for my signature. The one time they got the paperwork to me I signed and returned immediately. They still didn't get it. Based on my own personal experience I don't think you can lay all the blame on the folks who have contributed to python-mode.el. Dave It's not clear to me what's in python-mode.el that would be useful Dave to put in python.el... A lot of people like pdbtrack. The python-mode project also includes bits Emacs Lisp and Python code to interface with Pymacs. I believe both are unique to the python-mode project. Skip ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 18, 2009, at 4:29 PM, 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. While technically the python-mode.el file does not have GPL license on it, we've tried many times in the past to assign copyright so that it /could/ have such a license on it, and even be owned by the FSF. It's long been pulled out of the Python distribution so it needn't (and in fact doesn't) have a PSF license on it. Tim and I have both assigned copyright in our changes to the FSF. I think Ken did too, as he was the author of pdb-track among other good code in python- mode.el. I'm not sure about Skip. Looking at the committer line from 'bzr log' (which should include the svn history), that should just about cover it, though there may be contributions described in comments that need to be looked at. I believe there should be no reason why python-mode.el could not be released under the GPL, probably even with a copyright FSF. If there are a few contributors who need to be tracked down to get assignments from, that shouldn't be difficult. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXQAR3EjvBPtnXfVAQJQsgP+OP/z9ZVs5Q4Ha5A7gkNGr3oDb+FFobKW r4Q2NxW1BjVg/B15Iq/u68gI4KjH76IquvdQt0u5mHSoKCYvdKyGB1Ibdpuav7M5 pphwRUfmJaKDCVd4zvxD3jXuVOZW896RImnsALPdvn+X5Ff4/fB8TOfleVHrCbn+ EttPfswKUGw= =8mGQ -END PGP SIGNATURE- ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
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@python.org http://mail.python.org/mailman/listinfo/python-mode ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
