FSF assignment policy

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

FSF assignment policy

Andreas Röhler-2

Hi (X)Emacs folks,

as FSF assignment policy was raised again at
[hidden email], 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?

Sincerely

Andreas Röhler
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

Eric S. Johansson
Andreas Roehler wrote:

> Hi (X)Emacs folks,
>
> as FSF assignment policy was raised again at
> [hidden email], 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?

actually, I would call it an affectation.  Before my hands failed, I could
afford the luxury of a strict GPL stance.  After all, I had no trouble taking a
few extra steps for political purity.  Now, I live by the rule that
functionality trumps politics.  I do what I must so I can earn a living using
whatever tools I have available.  EULA's or GPL, I ignore licensing restrictions
if they get in the way.

I now see political stances on licensing as an affectation to gain attention.
These attitudes have led us to ignoring many good pieces of software ignoring
(JFS.ZFS) and people putting effort into redundant work (est4,btrfs).  It has
kept Linux having good handicapped accessibility, especially in my area of
interest, accessible via speech recognition.  We have a good solution with
NaturallySpeaking and wine but, it's not ideologically pure.

As you can see, I only see these licensing arguments as an impediment to people
getting things done with a minimum amount of effort.  You've created some
changes that I am trying to incorporate into a speech grammar and for that I'm
thankful.  Do me a favor, hold your nose, and just sign the damn papers and
let's get on with the task at hand.


---eric
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

Andreas Röhler-2
Eric S. Johansson wrote:

> Andreas Roehler wrote:
>> Hi (X)Emacs folks,
>>
>> as FSF assignment policy was raised again at
>> [hidden email], 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?
>
> actually, I would call it an affectation.  Before my hands failed, I could
> afford the luxury of a strict GPL stance.  After all, I had no trouble taking a
> few extra steps for political purity.  Now, I live by the rule that
> functionality trumps politics.  I do what I must so I can earn a living using
> whatever tools I have available.  EULA's or GPL, I ignore licensing restrictions
> if they get in the way.
>
> I now see political stances on licensing as an affectation to gain attention.
> These attitudes have led us to ignoring many good pieces of software ignoring
> (JFS.ZFS) and people putting effort into redundant work (est4,btrfs).  It has
> kept Linux having good handicapped accessibility, especially in my area of
> interest, accessible via speech recognition.  We have a good solution with
> NaturallySpeaking and wine but, it's not ideologically pure.
>
> As you can see, I only see these licensing arguments as an impediment to people
> getting things done with a minimum amount of effort.  You've created some
> changes that I am trying to incorporate into a speech grammar and for that I'm
> thankful.

Great to hear. Don't hesitate to tell which things you need still, what Emacs
should do in which circumstances.

Some reporting mode, saying after a close-block etc. where you are, what has been closed,
is worked on already.

BTW: Do have a site with your implementation which I could visit?

Should you know some stuff to read about the issue, please tell.

 Do me a favor, hold your nose, and just sign the damn papers

Well, that not so easy. Things are much more serious IMO. In any case programs
published here will be GPL as far as it concerns me, so it shouldn't matter for
the user if its assigned to FSF or not.

 and
> let's get on with the task at hand.
>
>
> ---eric
>

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

Barry Warsaw
In reply to this post by Andreas Röhler-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 27, 2009, at 4:08 AM, Andreas Roehler wrote:

> as FSF assignment policy was raised again at
> [hidden email], 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 [hidden email]
  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 possibility.

Thanks
Barry

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

iQCVAwUBSX8fv3EjvBPtnXfVAQLmIQP+PEmVj8VAScnjy7VqMTWiDlAQGIk18m++
//9mPWX0/v30dzaeCJqQclnde229I6sLQf0hshRRUUcBwKvbrGmZB6ehBHLI+u1P
fSDsThQsN46rhnnpmloMxONXVJ4g4ubuDTsjUNy8Pixj7MHTBkqxgNhPBQO42twf
/xu4vVhjj5g=
=pr3h
-----END PGP SIGNATURE-----
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

Barry Warsaw
In reply to this post by Andreas Röhler-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 27, 2009, at 9:51 AM, Andreas Roehler wrote:

> Well, that not so easy. Things are much more serious IMO. In any  
> case programs
> published here will be GPL as far as it concerns me, so it shouldn't  
> matter for
> the user if its assigned to FSF or not.

The python-mode.el's header is currently a bit ambiguous as to  
copyright ownership and license.  The last asserted copyright in the  
file is from 1994 by Tim Peters.  I know that Tim has since assigned  
his copyright to the FSF.

I'm willing to change that line to "Copyright 2009 Free Software  
Foundation" and slap a GPL license on the file.  I think we're in  
legal rights to do this.

Please note that we resisted the GPL for a long time because python-
mode.el was distributed with Python.  All code in the Python  
distribution should have the PSF license and specifically cannot have  
the GPL.  Now that python-mode.el has been distributed separately for  
a long time, this restriction no longer applies.

Barry

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

iQCVAwUBSX8gnXEjvBPtnXfVAQJR1gP/YdEHO+rSOoH0UbcPhoD+JgvftMAe0d8K
kKJx6XnimT3vANrZCkWoAE5ijHO8cx7RoSPr2itvZgqIg+WM9GpRK/BUwmnRJz/f
UOcX6t3HRXirmp7uj5kXr0SQQYMYAoe2o36HzPg6vtjb7zK+yQGVHrbe4Hq9XQm/
IUM/nUWofzE=
=T6va
-----END PGP SIGNATURE-----
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

FSF assignment policy

Stephen J. Turnbull
In reply to this post by Andreas Röhler-2
I am not a lawyer, and I don't speak for the FSF or the Emacs Project.
I do speak for the XEmacs Project until such time as someone feels
like complaining about it. :-)

Andreas Roehler writes:

 > as FSF assignment policy was raised again at
 > [hidden email], 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.

AIUI, this is one of the motivations for the free software movement:
each program created is a joint creation of the apparent author(s),
and of the community around them.  (I'm pretty sure Richard would say
it's not the most important motivation, but I suppose he will
acknowledge it.)

Nevertheless, software *also* exists in a legal environment, and the
assignment policy (like the GPL) is a compromise between the *goal* of
software freedom and the *limited means* provided[1] by that legal
system for implementing software freedom.

 > 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.

For starters, he doesn't make such a declaration about "the" code.  He
makes that declaration about his own contribution.  The way he
acquires that power is simple: he writes some code down.  That's all
it takes!  Whether he publishes or not.  Then, according to the Berne
Convention and other applicable treaties, he is automatically awarded
such copyright privileges as are created by the law of each
jurisdiction in which the software is available.

Exactly what privileges he is awarded are determined by the local
laws, and which parts of the software are "his" are determined in
principle by the law, and in practice by a court if his claims are
contested.  In other words, the question you are asking is not posed
by the assignment policy, but rather by the very existence of
copyright itself.  The assignment policy, then, is one of an array of
policies (including advocacy of copyleft licenses, for example)
adopted by the free software movement to preserve software freedom, in
the context of such a legal system.

 > 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?

No.  There is no forgery, assuming you make the claim in good faith.
You may still be liable for infringement if you are mistaken about the
extent of your rights, just as you may be liable for an automobile
accident if the car in front of you stops without warning for no
apparent reason and you run into it.

 > Or am I simply dreaming a bad dream?

There is no law in the U.S. or Japan about "making declarations", I
don't know about Europe.  That is, the fact that you assign what you
believe to be your code to another party does not increase your risk,
per se.  What matters is if you make or enable copies, or the assignee
does.  But for free software, the risk imposed by assignee-made copies
is precisely the same as the risk imposed by GPL-licensee-made copies.
In other words, if the risk involved in assigning your code bothers
you, what are you doing participating in free software at all?

However, the idemnity clause of the standard FSF assignment contract
may increase your risk, since you're required to defend the FSF as
well as yourself.  Ask a lawyer if that bothers you.

Note: I personally am not particularly a fan of the assignment policy,
though the recent trend in many projects to adopt such a policy may
force me to reconsider that position.  However, the objections you
seem to have in mind really apply to copyright itself, and the
assignment policy is just shadowing it.

Regards,
Steve

Footnotes:
[1]  Or barriers presented, if you will.

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

Andreas Röhler-2
Stephen J. Turnbull wrote:

> I am not a lawyer, and I don't speak for the FSF or the Emacs Project.
> I do speak for the XEmacs Project until such time as someone feels
> like complaining about it. :-)
>
> Andreas Roehler writes:
>
>  > as FSF assignment policy was raised again at
>  > [hidden email], 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.
>
> AIUI, this is one of the motivations for the free software movement:
> each program created is a joint creation of the apparent author(s),
> and of the community around them.  (I'm pretty sure Richard would say
> it's not the most important motivation, but I suppose he will
> acknowledge it.)
>
> Nevertheless, software *also* exists in a legal environment, and the
> assignment policy (like the GPL) is a compromise between the *goal* of
> software freedom and the *limited means* provided[1] by that legal
> system for implementing software freedom.
>
>  > 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.
>
> For starters, he doesn't make such a declaration about "the" code.  He
> makes that declaration about his own contribution.  The way he
> acquires that power is simple: he writes some code down.  That's all
> it takes!  Whether he publishes or not.  Then, according to the Berne
> Convention and other applicable treaties, he is automatically awarded
> such copyright privileges as are created by the law of each
> jurisdiction in which the software is available.
>
> Exactly what privileges he is awarded are determined by the local
> laws, and which parts of the software are "his" are determined in
> principle by the law, and in practice by a court if his claims are
> contested.  In other words, the question you are asking is not posed
> by the assignment policy, but rather by the very existence of
> copyright itself.  The assignment policy, then, is one of an array of
> policies (including advocacy of copyleft licenses, for example)
> adopted by the free software movement to preserve software freedom, in
> the context of such a legal system.
>
>  > 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?
>
> No.  There is no forgery, assuming you make the claim in good faith.
> You may still be liable for infringement if you are mistaken about the
> extent of your rights, just as you may be liable for an automobile
> accident if the car in front of you stops without warning for no
> apparent reason and you run into it.
>
>  > Or am I simply dreaming a bad dream?
>
> There is no law in the U.S. or Japan about "making declarations", I
> don't know about Europe.  That is, the fact that you assign what you
> believe to be your code to another party does not increase your risk,
> per se.  What matters is if you make or enable copies, or the assignee
> does.  But for free software, the risk imposed by assignee-made copies
> is precisely the same as the risk imposed by GPL-licensee-made copies.
> In other words, if the risk involved in assigning your code bothers
> you, what are you doing participating in free software at all?
>
> However, the idemnity clause of the standard FSF assignment contract
> may increase your risk, since you're required to defend the FSF as
> well as yourself.  Ask a lawyer if that bothers you.
>
> Note: I personally am not particularly a fan of the assignment policy,
> though the recent trend in many projects to adopt such a policy may
> force me to reconsider that position.  However, the objections you
> seem to have in mind really apply to copyright itself, and the
> assignment policy is just shadowing it.

Precisely.

The question already touched so far is, if or how copyright might declared with
respect to programs.

Is copyright a useful term with respect to computer programs?

I say: no. You, Steve, knows that very well. Some days ago we discussed
"beginning-of-defun-function".

Reflection was: maybe implement it differently then GNU function.

Why not, no matter.

Now, can you implement a poem from --say-- Allan Ginsberg differently
then Ginsberg did?

You can't. And that's the different between the realm, where copyright
makes some sense and where it's nonsense.

You may be condemed for nonsense, wars are declared for nonsense, yes.
Nonsense is a real existing force.

But let's consider another aspect of dangers I see coming:

Copyright always was and is a weapon to witheld things.
It might turn into a terrible weapon with computers, if people
depend on them.

That's why giving it free is ok and best. Then copyright is no longer a danger.

So why collect, harbour and even monopolize things, you want to be
free?

AFAIS the reason is the gain of power. To do some other things then distribution
 with this power.

The will to do the best, certainly. I don't question this will as far it concerns Richard
or majority of code contributors.

However, things have their own dynamic. We will see it.
Because power has it's own dynamic. FSF is already a remarkable power and will be a
 really big one.

IMHO FSF will outweight on the long run all other known powers.
Others will be nothing in comparison.

As all power is misused, the misuse will happen.

Simply want to say already now: not in my name.

In contrast freedom lives from the distribution of power,
not in collection them in form of copyrights or otherwise.

The way to freedom is to assist each other to defend or gain them,
best on a truly personal level - even through the line.

Thanks all


Andreas Röhler

>
> Regards,
> Steve
>
> Footnotes:
> [1]  Or barriers presented, if you will.
>
>

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

Richard Stallman
In reply to this post by Andreas Röhler-2
    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.

Inspiration is irrelevant to copyright law.  It is concerned
with the authorship of the code.

If a file has been in Emacs for many years, often many people have
changed it.  But typically when a file is first contributed, only a few
people have worked on the code.  They can honestly sign the assignments.
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

Stephen J. Turnbull
In reply to this post by Andreas Röhler-2
Andreas Roehler writes:

 > The question already touched so far is, if or how copyright might
 > declared with respect to programs.

Sure, but that is entirely irrelevant to the assignment issue.  The
assignment policy takes current copyright law as given.

So I don't think this is a useful conversation to have on python-mode
or xemacs-beta at this time.  Better gnu.misc.discuss or so.

 > That's why giving it free is ok and best. Then copyright is no
 > longer a danger.

This is something that is relevant to python-mode, but not really to
xemacs-beta, since XEmacs has no assignment policy and is unlikely to
get one AFAICS.  If you want a change in Emacs's policy, you'll need
to do direct lobbying of the FSF officers and/or Emacs maintainers:
xemacs-beta and python-mode have no power there.

I will say that opinions diverge dramatically on the efficacy of
various possible ways of "neutralizing" copyright.  AFAICS the Emacs
Project is not about to change its assignment policy.  If you do not
want to assign your work, you can dedicate it to the public domain,
for example.  But if you do not do something that allows the FSF
control over derived code (ie, code written by others based on your
code), AIUI it will not be possible for a merged package incorporating
your contributions to be accepted into Emacs.

I don't have a strong preference one way or the other; if you don't
(or do!) want to assign, I'm not going to ask you to reconsider.  But
you should remember that failing to assign will inherently cause more
work for you, and also may increase friction within your community.
To mitigate that, I would be mildly pleased if you assigned your
rights to any merger of python.el and python-mode.el to the FSF.
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

Andreas Röhler-2
In reply to this post by Barry Warsaw
Barry Warsaw wrote:

> On Jan 27, 2009, at 4:08 AM, Andreas Roehler wrote:
>
>> as FSF assignment policy was raised again at
>> [hidden email], 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
> [hidden email] 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
> possibility.
>
> Thanks
> Barry
>

Hi Barry,

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.


Thanks all

Andreas Röhler
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

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

I've just released python-mode.el 5.1.0:

https://launchpad.net/python-mode/trunk/5.1.0

Since 5.0.0, this fixes a problem with syntax highlighting None, and  
places the file under the GPLv3.

Barry

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

iQCVAwUBSYIGgHEjvBPtnXfVAQIaiwQAsIso85sDuWwfpFscsRl8+g/AxSwH/Kpc
WlwtgQ/4nOg6hGXMBy1oCoYLDiv2bIHJR9b6Wj2NhBikm/BUiTUy5Z5k1N4d1DZr
UseIM0JZ0l8mUFIP9VaMqvmHICuSjEt++KZl4ftbINB/gNgMvVThsaoHsX4gGWfo
0QT6VZZk2h0=
=H94V
-----END PGP SIGNATURE-----
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: replacing python.el

Glenn Morris-3
In reply to this post by Andreas Röhler-2
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.
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: replacing python.el

fbe2
In reply to this post by Andreas Röhler-2
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
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: replacing python.el

fbe2
In reply to this post by Glenn Morris-3
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

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: replacing python.el

Andreas Röhler-2
In reply to this post by fbe2
Beverley Eyre wrote:

> 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.


There is not until now. Barry didn't merge my stuff.

BTW experience tells: that position concerning
assignment might be wrong. For the moment, I'm thinking
as I do and can't change that.

Also FSF's assignment policy may change still. In this
case I'm certainly not going to blame them making
errors in the past.

As said, I feel somehow fooled as copyright owner by
present legal system.

If legal system is fooling people, betraying them
rather than defend their rights, might reason not go
through, finding a solution?

I mean, it can.

So lets look for the practical, exchanging experiences
with features for example.

Sincerely


Andreas Röhler

--
http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files
https://code.launchpad.net/s-x-emacs-werkstatt/


 Was that some of
> the stuff that Dave.....ah... took from python-mode.el?
>
> Bev
> _______________________________________________
> Python-mode mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-mode
>

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: replacing python.el

Barry Warsaw
In reply to this post by Glenn Morris-3
-----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-----
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

Dave Love-2
In reply to this post by Andreas Röhler-2
Andreas Roehler <[hidden email]> writes:

> Barry Warsaw wrote:

>> 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.

For this audience, again:  Unfortunately the FSF only has an assignment
from Tim Peters, and when I tried to get one from Barry some years go,
the problem was that it needed papers from his employer.  (Several of us
had tried to get full paperwork for python-mode.el, maybe including rms.
The authorship of all the code wasn't clear at that stage, so it may not
have been profitable anyway.  I've no doubt that Barry wants to DTRT in
this respect, and I wouldn't have spent the effort on separate code if
it looked as if we had a reasonable chance of complete paperwork.  If
the employer isn't now a problem, maybe an assignment for future
contributions would be useful.)

>> 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.

Current maintainers may disagree, but I don't think popularity with
Python programmers trumps the Emacs coding conventions.  Still, the only
missing things I've heard of either violate the conventions or aren't
specific to Python and should be elsewhere, or already are.

> 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.

Yes, this follows what's mostly happened with XEmacs historically.  It's
not a question of merging now, though -- this was all long ago.

> From this some chances too: Not every feature once
> implemented turns out useful. Not every feature is
> needed by everyone.

After working with and on python-mode.el, I did take the opportunity to
try to write something clean without undue mis-features.

> 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.

We wanted decent Python support for and in Emacs.  There's commentary in
the file, although it may not be complete.

--
We want to cooperate, but we are not doormats.  -- rms
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: FSF assignment policy

Andreas Röhler-2
Dave Love wrote:

> Andreas Roehler <[hidden email]> writes:
>
>> Barry Warsaw wrote:
>
>>> 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.
>
> For this audience, again:  Unfortunately the FSF only has an assignment
> from Tim Peters, and when I tried to get one from Barry some years go,
> the problem was that it needed papers from his employer.  (Several of us
> had tried to get full paperwork for python-mode.el, maybe including rms.
> The authorship of all the code wasn't clear at that stage, so it may not
> have been profitable anyway.  I've no doubt that Barry wants to DTRT in
> this respect, and I wouldn't have spent the effort on separate code if
> it looked as if we had a reasonable chance of complete paperwork.

IMO assignment policy contradicts the spirit of free software.
It shows very unpleasant damages in mind
already. Copyright is an important issue now, taken
very seriously. Before code was exchanged freely, as
Richard told nicely the very beginnings of the
movement. Meanwhile we came to the opposite: jealously
and meticulous line counting habits.

Assignment stifles cooperation rather then being helpful.

 If

> the employer isn't now a problem, maybe an assignment for future
> contributions would be useful.)
>
>>> 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.
>
> Current maintainers may disagree, but I don't think popularity with
> Python programmers trumps the Emacs coding conventions.  Still, the only
> missing things I've heard of either violate the conventions or aren't
> specific to Python and should be elsewhere, or already are.
>
>> 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.
>
> Yes, this follows what's mostly happened with XEmacs historically.  It's
> not a question of merging now, though -- this was all long ago.
>
>> From this some chances too: Not every feature once
>> implemented turns out useful. Not every feature is
>> needed by everyone.
>
> After working with and on python-mode.el, I did take the opportunity to
> try to write something clean without undue mis-features.

That was a general remark, in no way aimed at your code.
Let me take the opportunity to assert you: I'm well
respecting the work.

My offer was and is: let's cooperate. There are enough
things to do beside pure code-writing. Nor should the
assignment nor the GPL-versions-question block
cooperation completely. We must respect hindrances as
it exists, that's right.


>
>> 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.
>
> We wanted decent Python support for and in Emacs.  There's commentary in
> the file, although it may not be complete.
>

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: replacing python.el

Dave Love-2
In reply to this post by Glenn Morris-3
I seem to be repeating this to ever-expanding lists of addresses.

Glenn Morris <[hidden email]> 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.]
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
123