[Python-mode] FSF assignment policy
andreas.roehler at online.de
Wed Jan 28 11:20:27 CET 2009
Barry Warsaw wrote:
> On Jan 27, 2009, at 4:08 AM, Andreas Roehler wrote:
>> as FSF assignment policy was raised again at
>> python-mode at python.org, please permit to ask you a
>> thing I never understood:
>> AFAIS every Emacs-file is inspired by many, many others
>> from the very beginning. We see almost always a plenty
>> of revisions with a lot of people involved.
>> So how a single developer could ever declare what the
>> assignment formula demands? How could any person
>> declare, he _owns_ the rights at the code, thus
>> assigning it.
>> Isn't that assignment policy driving developers in a
>> kind of forgery? Making them false declarations,
>> thus having rights about them, being everyday able to
>> sue them for these false declarations?
>> Or am I simply dreaming a bad dream?
> For this audience, I'll restate my position, vis-à-vis python-mode.
> I assert that Tim Peters and myself have assigned copyright in
> python-mode.el to the FSF. I believe that Ken Manheimer has done the
> same, and I believe that Skip Montanaro has tried to do so several times
> in the past. This should cover the majority if not the entirety of the
> current python-mode.el file.
> I want it to be possible from a legal standpoint to merge python-mode.el
> and python.el, taking the best and most popular features and
> functionality from each. I think python-mode.el should form the basis
> of the merge, with code pulled in from python.el as needed.
> Andreas has the current momentum pumpkin for working on python-mode.el,
> so I want to find a way for him to do this while still retaining the
> ability to merge the two modes. Note that Andreas, AFAIK has not
> volunteered to do this merge, although others on the
> python-mode at python.org mailing list have expressed interest. If Andreas
> is unwilling to assign copyright to the FSF, then perhaps some other
> mechanism will be acceptable to him and to the FSF. Please explore this
thanks a lot investing that much care in the matter.
For me --due to FSF assignment -- XEmacs
represents much more the principle of four freedoms than
GNU Emacs now.
Incidentally that's the reason I changed my focus from
GNU to X. So originally a pure political change, I'm
not unhappy now. And yes: XEm looks nicer... :)
Concerning the intended merge, let me say it again: IMO
its technically impossible.
As Dave wrote: proceeding differs profoundly and
deliberately. We have two different modes now which
implement respective features in a different way.
Difference is not at the level of feature-function, but
from the very beginning. It's a little bit the same as
with GNU and XEmacs: you can't merge with reasonable
cost and result now.
>From this some chances too: Not every feature once
implemented turns out useful. Not every feature is
needed by everyone.
I would welcome a friendly, sportive concurrence. So if
Dave may tell, what's the point of python.el is in
contrast to python-mode.el, I'm interested to read.
Maybe we should consider development as a kind of
climbing: at least one team must get the peak. From the
users perspective --which should be the final measure--
it doesn't matter which team wins.
Back to politics: As we have a GNU backed python.el, it
seems reasonable to proceed --waving the flag of
freedom :)-- with a XEmacs associated python-mode.el.
More information about the Python-mode