copyright issues and derivative work (the case of matlab-mode)

copyright issues and derivative work (the case of matlab-mode)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]


Hi

I am in the second round to make sure that every code line in
matlab-mode has been written by an author who signed the FSF papers,
following Stefan's suggestion.


Since the repository started more than 20 years ago as CVS, that work is
a bit extensive. So far I found the following cases

    1. Patches, that contain more than 15 lines, which according to
       https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
       is legally relevant. Fortunately the corresponding authors  sign
       or are willing to sign the FSF papers.

    2. Patches, that contain less *than* 15 lines, which according to
       https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
       is *not* legally relevant. No action is needed.

    3. Patches, that contain more than 15 lines, which according to
       https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
       is legally relevant. However the current HEAD (tip) state of the
       repository contains less than 15 lines or even no line at all.
       Now there are two possibilities.

       a. The orginal patch is no longer relevant, and therefore no action is needed.
          That is what common sense would tell me.

       b. Although the code is not present now, it was present in some
          commit in the past, therefore the rest of the commits is
          derivative work.

If b. is the case we are doomed, but I cannot belive that some commit at
some point acts like a virus «infecting» the descents of that commit,
till today.

Can somebody please enlighten me?

Regards

Uwe Brauer 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: copyright issues and derivative work (the case of matlab-mode)

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Tue, 23 Nov 2021 17:25:45 +0100
> 
>     3. Patches, that contain more than 15 lines, which according to
>        https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
>        is legally relevant. However the current HEAD (tip) state of the
>        repository contains less than 15 lines or even no line at all.
>        Now there are two possibilities.
> 
>        a. The orginal patch is no longer relevant, and therefore no action is needed.
>           That is what common sense would tell me.
> 
>        b. Although the code is not present now, it was present in some
>           commit in the past, therefore the rest of the commits is
>           derivative work.
> 
> If b. is the case we are doomed, but I cannot belive that some commit at
> some point acts like a virus «infecting» the descents of that commit,
> till today.

It's a, assuming that those code lines are gone for good, i.e. the
current code is not merely some transformation of those original
lines.  The "annotate" (or "blame") command will not tell you, because
it attributes whole lines; you need to look at the diffs between the
last version that did have that code and the current code, and analyze
that.

Btw, the "15-lines" rule is just an approximation: depending on what
are those lines, it could be much more, or it could be slightly less.
It's a judgment call, not a mechanistic line count.

Re: copyright issues and derivative work (the case of matlab-mode)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]



> It's a, assuming that those code lines are gone for good, i.e. the
> current code is not merely some transformation of those original
> lines.  The "annotate" (or "blame") command will not tell you, because
> it attributes whole lines; you need to look at the diffs between the
> last version that did have that code and the current code, and analyze
> that.

I know that annotate/blame is not enough. I do precisely what you are
suggesting: looking  at the diffs, that is why this it is so extensive, 🙃
 

> Btw, the "15-lines" rule is just an approximation: depending on what
> are those lines, it could be much more, or it could be slightly less.
> It's a judgment call, not a mechanistic line count.

I see, on that subject another question for the future: suppose I as a
maintainer receive a 2 lines patch for example

,----
| 
| diff --git a/elisp/matlab-emacs/matlab.el b/elisp/matlab-emacs/matlab.el
| index 63ce838..71b6ff0 100755
| --- a/elisp/matlab-emacs/matlab.el
| +++ b/elisp/matlab-emacs/matlab.el
| @@ -3731,6 +3731,6 @@ If ARG is nil, then highlighting is toggled."
|  			  post-command-hook)
|  		  -1 1)))
|      (if (> arg 0)
| -	(add-hook 'post-command-hook 'matlab-start-block-highlight-timer)
| -      (remove-hook 'post-command-hook 'matlab-start-block-highlight-timer))))
| +	(add-hook 'post-command-hook 'matlab-start-block-highlight-timer nil :local)
| +      (remove-hook 'post-command-hook 'matlab-start-block-highlight-timer :local))))
| 
`----

Since this is legally not significant, (I hope you agree): 

Should I commit this under my name (with reference in the log message to
the author), or should I commit that under the authors name?

Regards


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: copyright issues and derivative work (the case of matlab-mode)

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Tue, 23 Nov 2021 17:59:21 +0100
> 
> Should I commit this under my name (with reference in the log message to
> the author), or should I commit that under the authors name?

You should always commit with --author set to the author's name.  The
attribution should be as accurate as possible, regardless of whether
the contribution is legally significant.

Re: copyright issues and derivative work (the case of matlab-mode)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

>> From: Uwe Brauer <oub@mat.ucm.es>
>> Date: Tue, 23 Nov 2021 17:59:21 +0100
>> 
>> Should I commit this under my name (with reference in the log message to
>> the author), or should I commit that under the authors name?

> You should always commit with --author set to the author's name.  The
> attribution should be as accurate as possible, regardless of whether
> the contribution is legally significant.

Ok, we did not do that in the past, most likely because we were careless
and also we could not imagine  that one day mathwork would renounce its
copyright.

The question is should I «rewrite» the repository changing commits and
trying to add the name of the authors before it will, hopefully one day
enter ELPA?

(I think I can do that in mercurial with the evolve extension and then
try to push that locally with the hg-git extension to the local git
repository). That might however mess up things.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: copyright issues and derivative work (the case of matlab-mode)

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Tue, 23 Nov 2021 18:45:12 +0100
> 
> > You should always commit with --author set to the author's name.  The
> > attribution should be as accurate as possible, regardless of whether
> > the contribution is legally significant.
> 
> Ok, we did not do that in the past, most likely because we were careless
> and also we could not imagine  that one day mathwork would renounce its
> copyright.
> 
> The question is should I «rewrite» the repository changing commits and
> trying to add the name of the authors before it will, hopefully one day
> enter ELPA?

I wouldn't recommend that.  If the real authors are mentioned in the
commit log messages, it's enough, I think.

Re: copyright issues and derivative work (the case of matlab-mode)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > > You should always commit with --author set to the author's name.  The
  > > > attribution should be as accurate as possible, regardless of whether
  > > > the contribution is legally significant.

Perhaps we should send a message about this point
to each person with commit access.  Our committers would more
reliably do it, with this reminder.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: copyright issues and derivative work (the case of matlab-mode)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 00:31:22 -0500
> 
>   > > > You should always commit with --author set to the author's name.  The
>   > > > attribution should be as accurate as possible, regardless of whether
>   > > > the contribution is legally significant.
> 
> Perhaps we should send a message about this point
> to each person with commit access.  Our committers would more
> reliably do it, with this reminder.

That is unlikely to have any effect, down the way.  People easily
forget this stuff.  And the list of people with commit access is very
long.  The message I posted to emacs-devel, which you quote, is likely
to have the same or better effect, because everyone who is actively
involved reads it.

We have this spelled out in CONTRIBUTE already:

  ** Committing changes by others

  If committing changes written by someone else, commit in their name,
  not yours.  You can use 'git commit --author="AUTHOR"' to specify a
  change's author.

Re: copyright issues and derivative work (the case of matlab-mode)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
>> Date: Thu, 25 Nov 2021 00:31:22 -0500
>> 
>> > > > You should always commit with --author set to the author's name.  The
>> > > > attribution should be as accurate as possible, regardless of whether
>> > > > the contribution is legally significant.
>> 
>> Perhaps we should send a message about this point
>> to each person with commit access.  Our committers would more
>> reliably do it, with this reminder.

> That is unlikely to have any effect, down the way.  People easily
> forget this stuff.  And the list of people with commit access is very
> long.  The message I posted to emacs-devel, which you quote, is likely
> to have the same or better effect, because everyone who is actively
> involved reads it.

> We have this spelled out in CONTRIBUTE already:

>   ** Committing changes by others

>   If committing changes written by someone else, commit in their name,
>   not yours.  You can use 'git commit --author="AUTHOR"' to specify a
>   change's author.

Just one observation, by author you mean

Author =  Name <emailaddress> 

Right?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: copyright issues and derivative work (the case of matlab-mode)

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: rms@gnu.org, oub@mat.ucm.es, emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 09:03:36 +0100
> 
> >   If committing changes written by someone else, commit in their name,
> >   not yours.  You can use 'git commit --author="AUTHOR"' to specify a
> >   change's author.
> 
> Just one observation, by author you mean
> 
> Author =  Name <emailaddress> 
> 
> Right?

Yes.  That's Git rules, not ours.

Re: copyright issues and derivative work (the case of matlab-mode)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > >   If committing changes written by someone else, commit in their name,
  > > >   not yours.  You can use 'git commit --author="AUTHOR"' to specify a
  > > >   change's author.
  > > 
  > > Just one observation, by author you mean
  > > 
  > > Author =  Name <emailaddress> 
  > > 
  > > Right?

  > Yes.  That's Git rules, not ours.

Regardless of where the rule comes from, restating it here will
help people know what to do.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: copyright issues and derivative work (the case of matlab-mode)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: oub@mat.ucm.es, oub@mat.ucm.es, emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 23:08:36 -0500
> 
>   > > Just one observation, by author you mean
>   > > 
>   > > Author =  Name <emailaddress> 
>   > > 
>   > > Right?
> 
>   > Yes.  That's Git rules, not ours.
> 
> Regardless of where the rule comes from, restating it here will
> help people know what to do.

Sorry, no.  There's a lot of small factoids like this one, so if we
start mentioning them, it's a slippery slope, because we will get
pressured to mention more and more by people who must have everything
in writing for them to accept it.  I object to making our
documentation a Git tutorial.  Once again, people with write access to
the repository are expected to know how to use Git.  Besides, many, if
not all, mistakes in the value of --author will be detected by Git
itself and rejected.

Re: copyright issues and derivative work (the case of matlab-mode)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   I object to making our
  > documentation a Git tutorial.  Once again, people with write access to
  > the repository are expected to know how to use Git.

There is no moral aspect in these questions, so they are purely
pragmatic -- what works best for us?

For instance, when should we presume everyone knows the right way to
do something with git, and when should we explain?  That depends on
how much of a problem results when someone doesn't know.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: copyright issues and derivative work (the case of matlab-mode)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
> Date: Sat, 27 Nov 2021 23:24:52 -0500
> 
>   >   I object to making our
>   > documentation a Git tutorial.  Once again, people with write access to
>   > the repository are expected to know how to use Git.
> 
> There is no moral aspect in these questions, so they are purely
> pragmatic -- what works best for us?
> 
> For instance, when should we presume everyone knows the right way to
> do something with git, and when should we explain?  That depends on
> how much of a problem results when someone doesn't know.

Yes, it's a judgment call.  In this case, given the probability that
Git itself will catch incorrectly formatted author identification, I
see no reason to have this in our docs.

Re: copyright issues and derivative work (the case of matlab-mode)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yes, it's a judgment call.  In this case, given the probability that
  > Git itself will catch incorrectly formatted author identification, I
  > see no reason to have this in our docs.

I see your point.

But will git catch an _omitted_ author specification?
Maybe we should remind people to specify that.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: copyright issues and derivative work (the case of matlab-mode)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
> Date: Sun, 28 Nov 2021 22:02:08 -0500
> 
>   > Yes, it's a judgment call.  In this case, given the probability that
>   > Git itself will catch incorrectly formatted author identification, I
>   > see no reason to have this in our docs.
> 
> I see your point.
> 
> But will git catch an _omitted_ author specification?

No, of course not.  It assumes by default that the committer is the
author.

> Maybe we should remind people to specify that.

We already do, in CONTRIBUTE.

Re: copyright issues and derivative work (the case of matlab-mode)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > But will git catch an _omitted_ author specification?

  > No, of course not.  It assumes by default that the committer is the
  > author.

  > > Maybe we should remind people to specify that.

  > We already do, in CONTRIBUTE.

Yes, but as we've noticed, people don't look at that very often.
A person who has contributed for a year, and checked in only per
own work, and then for the first time checks in someone else's work,
is very likely to forget about --author.

I'm wondering if we can do something to make that sort of mistake
less likely.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: copyright issues and derivative work (the case of matlab-mode)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
> Date: Mon, 29 Nov 2021 23:10:00 -0500
> 
>   > > Maybe we should remind people to specify that.
> 
>   > We already do, in CONTRIBUTE.
> 
> Yes, but as we've noticed, people don't look at that very often.
> A person who has contributed for a year, and checked in only per
> own work, and then for the first time checks in someone else's work,
> is very likely to forget about --author.

There's nothing we can do about things people forget, except tell
them, sometimes post-factum, that the procedures are in CONTRIBUTE, in
the hope that next time they will look there when in doubt.
CONTRIBUTE is our basic document for this kind of stuff, and I cannot
see any way to make it more in the face of contributors than having it
in a file with a telltale name right at the top of our tree.

Re: copyright issues and derivative work (the case of matlab-mode)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Yes, but as we've noticed, people don't look at that very often.
  > > A person who has contributed for a year, and checked in only per
  > > own work, and then for the first time checks in someone else's work,
  > > is very likely to forget about --author.

  > There's nothing we can do about things people forget, 

That's true, I agree, if we consider only changes in the informational
files such as CONTRIBUTING.  But if we consider ideas that go beyond
that, yes there are things that might work.

An extreme example just to prove that point: if we make a special
command for making commits in Emacs, and it asks each time "Is there
any code in this commit that you did not write," and told contributors
always to use that special command for commits on Emacs, no one would
ever forget to enter the author.

Maybe that would be considered too annoying, but it shows that there
are ways to have an effect on this.

We could approve certain contributors to commit code written
by others, and tell all other contributors not to do that.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: copyright issues and derivative work (the case of matlab-mode)

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Perhaps we should send a message about this point
>> to each person with commit access.  Our committers would more
>> reliably do it, with this reminder.

FWIW, I have heard that `git am' will do this automatically.

Perhaps it would be a good idea to suggest people to always use `git am'
to install changes made by others?

Thanks.

Re: copyright issues and derivative work (the case of matlab-mode)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rms@gnu.org,  oub@mat.ucm.es,  emacs-devel@gnu.org
> Date: Thu, 25 Nov 2021 16:14:47 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Perhaps we should send a message about this point
> >> to each person with commit access.  Our committers would more
> >> reliably do it, with this reminder.
> 
> FWIW, I have heard that `git am' will do this automatically.

Only if the patch was formatted with "git format-patch".  Which is why
we prefer that, see below.

> Perhaps it would be a good idea to suggest people to always use `git am'
> to install changes made by others?

This is trivial for anyone who installs patches, and I very much doubt
that anyone doesn't use that already.  CONTRIBUTE hints on that:

  However, we prefer the 'git format-patch' method with attachment, as
  doing so delivers patches in the correct and easily-recognizable format
  more reliably, and makes the job of applying the patches easier and less
  error-prone.  It also allows sending patches whose author is someone
  other than the email sender.

Note the last sentence.  It doesn't mention "git am" because it is a
trivium, but it's clear it assumes that.

I don't think we should have a Git tutorial as part of Emacs; someone
who gets write access to the repository is supposed to be sufficiently
proficient in Git commands.  We don't explain too much about how to
push, either, for the same reason.

Let's not make a mountain out of a molehill.

Re: copyright issues and derivative work (the case of matlab-mode)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: rms@gnu.org,  oub@mat.ucm.es,  emacs-devel@gnu.org
>> Date: Thu, 25 Nov 2021 16:14:47 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Perhaps we should send a message about this point
>> >> to each person with commit access.  Our committers would more
>> >> reliably do it, with this reminder.
>> 
>> FWIW, I have heard that `git am' will do this automatically.

> Only if the patch was formatted with "git format-patch".  Which is why
> we prefer that, see below.

>> Perhaps it would be a good idea to suggest people to always use `git am'
>> to install changes made by others?

> This is trivial for anyone who installs patches, and I very much doubt
> that anyone doesn't use that already.  CONTRIBUTE hints on that:

On the matlab-mode mailing list, 99% of the patches were generated by a
simple diff command.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: copyright issues and derivative work (the case of matlab-mode)

[Stefan Monnier]

> The question is should I «rewrite» the repository changing commits and
> trying to add the name of the authors before it will, hopefully one day
> enter ELPA?

As long as the code is not in `elpa.git`, it's up to you to decide
whether to perform such rewrites.  Once it's in `elpa.git` such rewrites
should be avoided at (almost) all cost.

It sounds like a lot of work and could lead to trouble for other people
who're tracking your repository, so I probably wouldn't do it if I were you.


        Stefan

Re: copyright issues and derivative work (the case of matlab-mode)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The question is should I «rewrite» the repository changing commits and
>> trying to add the name of the authors before it will, hopefully one day
>> enter ELPA?

> As long as the code is not in `elpa.git`, it's up to you to decide
> whether to perform such rewrites.  Once it's in `elpa.git` such rewrites
> should be avoided at (almost) all cost.

That is what I thought.

> It sounds like a lot of work and could lead to trouble for other people
> who're tracking your repository, so I probably wouldn't do it if I were you.

Right, after some thinking I decided not to start with it, GNU emacs
has also been transformed many times, from RCS(?) To CVS to bazzarr to
git.

Its first commit reads 
,----
| 
| ◍  commit 0:ce5584125c44a1a2fbb46e810459c50b227a95e2
|    Author: Jim Blandy <jimb@redhat.com>
|    Date: Thu, 18 Apr 1985 00:48:29 +0000
| 
|    entered into RCS
`----

Which has we discussed some time ago is impossible since redhat was
Founded: March 26, 1993, Raleigh, North Carolina, United States,
according to wikipedia 😝.

So a repository this old is different from one started freshly with git
or mercurial.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: copyright issues and derivative work (the case of matlab-mode)

[Stefan Monnier]

> (I think I can do that in mercurial with the evolve extension and then
> try to push that locally with the hg-git extension to the local git
> repository).  That might however mess up things.

Side note: the current elpa.gnu.org scripts only know how to deal with
upstream Git repositories.  In theory they might be able to deal with
a Mercurial upstream using `hg::...`, but I wouldn't bet on it working
reliably (based on my past experience with the `git-remote-hg` plugin).


        Stefan

Re: copyright issues and derivative work (the case of matlab-mode)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (I think I can do that in mercurial with the evolve extension and then
>> try to push that locally with the hg-git extension to the local git
>> repository).  That might however mess up things.

> Side note: the current elpa.gnu.org scripts only know how to deal with
> upstream Git repositories.  In theory they might be able to deal with
> a Mercurial upstream using `hg::...`, but I wouldn't bet on it working
> reliably (based on my past experience with the `git-remote-hg` plugin).

In my understanding git-remote-hg is to do things  the other way around:
access a mercurial repository with git. 

It is my understanding from discussions in the mercurial list, however
that this strategy is a lot harder (because mercurial has a lot of
concepts git is lacking, please no flamewar)

I use the hg-git plugin to push and pull to a git repository using
mercurial.

In any case, I put in some security layers (for example for matlab-mode)

    1. I clone with git the repository to my machine (matlab-git)

    2. I locally clone that repository with mercurial (matlab-hg)

    3. I do whatever I do in matlab-hg, then I push to matlab-git

    4. Then I push with git to the matlab repository 

That works quite well. Sometimes I have pushed directly from the
mercurial repository to a sandbox repository in bitbucket and cloned
that repository with git back.

As long as one sticks with mercurial bookmarks that works well. Named
branches are more complicated (one can push them to a git repository and
they will be recognised as git branches, the pulling is more
complicated), but that is now off-topic 








[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: copyright issues and derivative work (the case of matlab-mode)

[Stefan Monnier]

>> Side note: the current elpa.gnu.org scripts only know how to deal with
>> upstream Git repositories.  In theory they might be able to deal with
>> a Mercurial upstream using `hg::...`, but I wouldn't bet on it working
>> reliably (based on my past experience with the `git-remote-hg` plugin).
>
> In my understanding git-remote-hg is to do things  the other way around:
> access a mercurial repository with git. 

As long as you don't have write access to GNU ELPA/Emacs's repository
then elpa.gnu.org needs to *pull* from the upstream.

> I use the hg-git plugin to push and pull to a git repository using
> mercurial.

Ah, so elpa.gnu.org can pull from that Git.  Great, so there's
no problem.  Sorry 'bout the noise,


        Stefan

Re: copyright issues and derivative work (the case of matlab-mode)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

How, precisely, did Mathworks state that it has renounced its
copyright on those materials?  The FSF will want to see what Mathworks
actually published or signed, and verify that that really does the job.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: copyright issues and derivative work (the case of matlab-mode)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

>>> "RS" == Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

> How, precisely, did Mathworks state that it has renounced its
> copyright on those materials?  The FSF will want to see what Mathworks
> actually published or signed, and verify that that really does the job.

Very good point. Eric Ludlam who single handed maintained matlab-mode
for almost 2 decades is still working for mathworks told me (if I
remember correctly) that he was approached by some mathwork officials
discussing the matters with him.

So he should know all the details, I put him on the CC just in case.

@Eric could you provide us, or RMS with some details of this copyright
issue, please 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: copyright issues and derivative work (the case of matlab-mode)

[Eric Ludlam]

On 11/24/21 2:42 AM, Uwe Brauer wrote:
>>>> "RS" == Richard Stallman <rms@gnu.org> writes:
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>> How, precisely, did Mathworks state that it has renounced its
>> copyright on those materials?  The FSF will want to see what Mathworks
>> actually published or signed, and verify that that really does the job.
> Very good point. Eric Ludlam who single handed maintained matlab-mode
> for almost 2 decades is still working for mathworks told me (if I
> remember correctly) that he was approached by some mathwork officials
> discussing the matters with him.
>
> So he should know all the details, I put him on the CC just in case.
>
> @Eric could you provide us, or RMS with some details of this copyright
> issue, please

Hi,


MathWorks has had developers contribute to other GNU projects in the 
past (such as my own contributions to Emacs for projects unrelated to 
MATLAB) so I will just need to get the standard  GNU form for myself and 
John C. signed to make this official.  I hadn't worried about it yet 
because it was unclear if we could overcome the other hurdles.


Eric

Re: copyright issues and derivative work (the case of matlab-mode)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It sounds like things are going well.  Happy hacking.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: copyright issues and derivative work (the case of matlab-mode)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

>>> "EL" == Eric Ludlam <ericludlam@gmail.com> writes:

>> Very good point. Eric Ludlam who single handed maintained matlab-mode
>> for almost 2 decades is still working for mathworks told me (if I
>> remember correctly) that he was approached by some mathwork officials
>> discussing the matters with him.
>> 
>> So he should know all the details, I put him on the CC just in case.
>> 
>> @Eric could you provide us, or RMS with some details of this copyright
>> issue, please

> Hi,


> MathWorks has had developers contribute to other GNU projects in the
> past (such as my own contributions to Emacs for projects unrelated to
> MATLAB) so I will just need to get the standard  GNU form for myself
> and John C. signed to make this official.  I hadn't worried about it
> yet because it was unclear if we could overcome the other hurdles.

To be honest, I still have to finish the issue check-all-patches.
I propose to add a branch in our repository with a documentation
explaining the state of art of these patches for somebody of the FSF to
check and give its ok. I am optimistic, but don't want to shout victory
too early.

In any case I recommend that you both sign the papers.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: copyright issues and derivative work (the case of matlab-mode)

[Tassilo Horn]

Uwe Brauer <oub@mat.ucm.es> writes:

> Since this is legally not significant, (I hope you agree):
>
> Should I commit this under my name (with reference in the log message
> to the author), or should I commit that under the authors name?

Eli already gave the answer but I just want to add that this makes life
easier for you as well.  The ~15 LOC rule doesn't apply to each patch on
its own but to the cumulative contributions of one individual.  If
someone contributed four patches, each adding/changing just four lines,
they'd be one line over the (not so hard) limit already.  And getting
diffstats for commits of one author is easy whereas it's harder if you
need to take the commit message into account.

Bye,
Tassilo

Re: copyright issues and derivative work (the case of matlab-mode)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >     3. Patches, that contain more than 15 lines, which according to
  > >        https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
  > >        is legally relevant. However the current HEAD (tip) state of the
  > >        repository contains less than 15 lines or even no line at all.
  > >        Now there are two possibilities.
  > > 
  > >        a. The orginal patch is no longer relevant, and therefore no action is needed.
  > >           That is what common sense would tell me.
  > > 
  > >        b. Although the code is not present now, it was present in some
  > >           commit in the past, therefore the rest of the commits is
  > >           derivative work.

It isn't quite that simple and rigid.  The question that needs to be
answered is: is a substantial part of the current code more or less a
rewriting of the original patch?  If so, then that part is a
derivative of the original patch.

The FSF can can ask a lawyer about the specific case, if that's
necessary.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: copyright issues and derivative work (the case of matlab-mode)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]

>>> "RS" == Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>> >     3. Patches, that contain more than 15 lines, which according to
>> >        https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
>> >        is legally relevant. However the current HEAD (tip) state of the
>> >        repository contains less than 15 lines or even no line at all.
>> >        Now there are two possibilities.
>> > 
>> >        a. The orginal patch is no longer relevant, and therefore no action is needed.
>> >           That is what common sense would tell me.
>> > 
>> >        b. Although the code is not present now, it was present in some
>> >           commit in the past, therefore the rest of the commits is
>> >           derivative work.

> It isn't quite that simple and rigid.  The question that needs to be
> answered is: is a substantial part of the current code more or less a
> rewriting of the original patch?  If so, then that part is a
> derivative of the original patch.

> The FSF can can ask a lawyer about the specific case, if that's
> necessary.


Ok, I see. I am planning to do the following:
I will extract all patches sent to us in the last two decades and
compare it with the actual version and put in a directory for someone to
inspect. (I have to think about the details)

The case I had in mind was (that is anyhow very short but just to
emphasize my point)


,----
| diff --git a/elisp/matlab-emacs/matlab.el b/elisp/matlab-emacs/matlab.el
| index 63ce838..71b6ff0 100755
| --- a/elisp/matlab-emacs/matlab.el
| +++ b/elisp/matlab-emacs/matlab.el
| @@ -3731,6 +3731,6 @@ If ARG is nil, then highlighting is toggled."
|  			  post-command-hook)
|  		  -1 1)))
|      (if (> arg 0)
| -	(add-hook 'post-command-hook 'matlab-start-block-highlight-timer)
| -      (remove-hook 'post-command-hook 'matlab-start-block-highlight-timer))))
| +	(add-hook 'post-command-hook 'matlab-start-block-highlight-timer nil :local)
| +      (remove-hook 'post-command-hook 'matlab-start-block-highlight-timer :local))))
|  
`----

But we removed *all* calls to the post-command-hook in the current
matlab.el version and that is why I think, the current version is *not*
derivative work of this particular patch.

But as I said, there will be more complicated cases
 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]