Re: New maintainer

[Jambunathan K <kjambunathan@gmail.com>]

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