From: Jambunathan K <kjambunathan@gmail.com>
To: Tassilo Horn <tsdh@gnu.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: New maintainer
Date: Sat, 20 Apr 2013 13:27:08 +0530 [thread overview]
Message-ID: <8761zhvdm3.fsf@gmail.com> (raw)
In-Reply-To: <87d2tqsz1t.fsf@thinkpad.tsdh.de> (Tassilo Horn's message of "Fri, 19 Apr 2013 10:30:06 +0200")
Tassilo Horn <tsdh@gnu.org> writes:
> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> How do you interpret the following block extracted from my assignment
>>
>> ,----
>> | 2. Developer will report occasionally, on Developer’s initiative
>> | and whenever requested by FSF, the changes and/ or enhancements
>> | which are covered by this contract, and (to the extent known to
^^^
^^^
^^^
>> | Developer) any outstanding rights, or claims of rights, of any
>> | person, that might be adverse to the rights of Developer or FSF
>> | or to the purpose of this contract.
>> `----
>
> Well, the FSF's intention here is to make sure that contributors report
> back when they change employers, and the new employer doesn't want that
> his employees contribute to some GNU project (maybe because that project
> is in the same business as the company). So I think of that more of a
> safety measure in order not to run into long-running, painful
> lawsuits.
Your interpretation is too narrow. The phrase "and" (marked above)
there makes all the difference.
My reading of the above para and Richard's response down below are
consistent.
,---- http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00066.html
| If a contributor wants to specify precisely which changes are
| assigned, he, she or it can talk with the FSF about it. We can
| work something out. However, we'd prefer to be able to use all of
| someone's changes without specific arrangements.
`----
>> FSF clearly side-steps the important question - when is a work
>> actually assigned. Assignment is not a process but an event tied to
>> specific time and date.
>
> As far as I understand it (just after reading one of my FSF CAs), the
> changes you apply to a program where you've assigned past & future
> changes are assigned as soon as they are written. They don't need to be
> published, distributed, placed in a special repository location, etc.
Assignment of rights is for the purpose of defending GPL. It is *not*
and *cannot* be an annexation policy. What you state above amounts to
annexation policy.
Assignment of rights is my prerogative. I can do it selectively or
cancel it. FSF cannot interfere with what is an individual decision.
I will only quote an authoritative and responsible source. Focus on last
sentence in the below quote.
,---- http://lwn.net/Articles/543436/
|
| Anyway, it's unfortunate the Corbet's article above doesn't
| reiterate the advantages of assigning to FSF to
| developers. Specifically, the FSF takes on the obligation of being
| the publisher of the code (which can sometimes be a dangerous act
| in today's world), and also, FSF handles enforcement of the GPL
| for the codebase. Finally, FSF gives a liberal license back to the
| developer (i.e., Jambunathan could have always made proprietary
| software out of his own assigned works after doing the
| assignment), and FSF further promises never to publish a
| proprietary version of the software itself.
|
`----
I interpret "proprietary" above to mean "any work (available to public,
it is GPL right?) that is not part of Emacs distribution".
Theoretically speaking, it is OK to have future assignment in place
*and* have works that are assigned, as well as non-assigned
*simultaneously*. If a work is not part of Emacs, then it is "not
assigned" to FSF. Simple and practical definition.
----------------------------------------------------------------
It is also important to note that the above paragraph from a FSF board
member is in some conflict with RMS's own claim.
,---- http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00409.html
|
| A diff for Emacs is always a change to Emacs. I will think about
| the questions raised by a separate Lisp file.
|
`----
In my opinion, the most appropriate thing to state would be
"A diff to Emacs submitted to the official channels of the suite -
either the maintainer, mailing list or bug subsystem, *unless stated
otherwise* is potentially part of Emacs, in a non-revocable way."
It will be inappropriate for anyone to claim, my local changes to
doc-view.el that I share with a co-worker is a diff to Emacs and hence
part of Emacs. A change is either part of Emacs or not. When I say
Emacs, I mean the official GNU Emacs distributed from gnu.org.
----------------------------------------------------------------
Now the primary part of current dispute is that it falls in a grey area
1. My files are new.
2. "Org in Emacs Bzr trunk" is not the same as "Org outside of Emacs
trunk". One is "part of Emacs" while the other is "not part of
Emacs". There is a clear dichotomy here. It is easy to answer
"Is this file part of Emacs?" with a "Yes" or "No". Saying that
a file is intended to be part of Emacs is equivalent to saying
"No."
Thought experiment: You cannot claim ownership of a house merely
because the other party "intended" to sell it.
----------------------------------------------------------------
I will advise all vigorous enterprising young men *never* to assign his
rights to any organization other than his own.
----------------------------------------------------------------
"Intent to act is not the act itself"
Jambunathan K,
> Bye,
> Tassilo
next prev parent reply other threads:[~2013-04-20 7:57 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 16:53 New maintainer Bastien
2013-04-18 17:10 ` Jambunathan K
2013-04-18 18:10 ` John Hendy
2013-04-18 18:20 ` Bastien
2013-04-18 18:38 ` Jambunathan K
2013-04-18 19:48 ` Alan L Tyree
2013-04-18 20:07 ` Jambunathan K
2013-04-18 20:16 ` Alan L Tyree
2013-04-19 8:30 ` Tassilo Horn
2013-04-20 7:57 ` Jambunathan K [this message]
2013-04-21 8:06 ` Jambunathan K
2013-04-21 12:41 ` Carsten Dominik
2013-04-18 18:53 ` Jambunathan K
2013-04-18 17:19 ` Glyn Millington
2013-04-18 18:14 ` Aaron Ecay
2013-04-18 18:15 ` Rasmus
2013-04-18 18:23 ` Bastien
2013-04-18 18:20 ` Detlef Steuer
2013-04-18 18:26 ` François Pinard
2013-04-18 19:58 ` Alan Schmitt
2013-04-18 20:07 ` Thomas S. Dye
2013-04-18 20:13 ` Bastien
2013-04-18 20:16 ` Jonathan Leech-Pepin
2013-04-18 21:52 ` Tom Davey
2013-04-20 8:29 ` Ian Barton
2013-04-19 0:24 ` Charles Berry
2013-04-19 7:07 ` Suvayu Ali
2013-04-19 0:32 ` Bernt Hansen
2013-04-19 1:02 ` Yagnesh Raghava Yakkala
2013-04-19 4:12 ` Noorul Islam Kamal Malmiyoda
2013-04-19 6:09 ` Robert Klein
2013-04-19 7:00 ` Christian Moe
2013-04-19 7:58 ` Thank you very much Bastien! Hello Carsten! (was: New maintainer) Karl Voit
2013-04-19 9:36 ` New maintainer Thorsten Jolitz
2013-04-19 9:59 ` Sean O'Halpin
2013-04-19 11:33 ` Charles Philip Chan
2013-04-19 12:52 ` Adolfo Benedetti
2013-04-19 12:53 ` Rainer Stengele
2013-04-19 14:30 ` Russell Adams
2013-04-19 16:04 ` Christopher Allan Webber
[not found] ` <CAFChFyjpy2R10gJmxJ-DKDbAVjj6MnD5JN+vX5bY5MvHbf3z3w@mail.gmail.com>
2013-04-20 1:03 ` Fwd: " Gary Oberbrunner
2013-04-21 10:24 ` T.F. Torrey
2013-04-21 10:47 ` Eric Abrahamsen
2013-04-21 13:22 ` Bastien
2013-04-21 14:08 ` Eric Abrahamsen
2013-04-21 18:04 ` Andreas Röhler
2013-04-21 22:39 ` Bastien
2013-04-22 7:57 ` Andreas Röhler
2013-04-21 22:18 ` AG
2013-04-22 10:27 ` Julian M. Burgos
2013-04-22 16:53 ` Jay Kerns
2013-04-22 16:55 ` Matt Price
2013-04-23 16:46 ` Jason Dunsmore
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.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8761zhvdm3.fsf@gmail.com \
--to=kjambunathan@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=tsdh@gnu.org \
/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/org-mode.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).