unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Uwe Brauer <oub@mat.ucm.es>
Cc: emacs-devel@gnu.org
Subject: Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?
Date: Sat, 20 Nov 2021 19:00:14 -0500	[thread overview]
Message-ID: <jwvzgpy8k3b.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <878rxiu323.fsf@mat.ucm.es> (Uwe Brauer's message of "Sat, 20 Nov 2021 18:53:08 +0100")

Uwe Brauer [2021-11-20 18:53:08] wrote:
> That however changed a while ago: Mathwork not only renounced its
> copyright, they explicitly asked us to remove any reference to it from
> all the files, which we did.
>
>     1. Git blame (or hg annotate for that matter) told me that currently
>        the code belongs to only 4 authors, of whom 3 have signed the FSF
>        papers, and the other one is in the process of doing so.
>
>     2. There is another point that worries me: According to the
>        changelogs at some points the maintainers committed patches from
>        other authors, but in their own (the maintainers name).

Regarding point 1: the output of `git blame` does not tell the whole
story (if you reindent or move code, `git blame` will only list you as
the author even tho the real author is the one who write that code
before you moved/reindented it).

It's not irrelevant, but it's not sufficient to decide if the copyright
is clean.

Point 2 is also another example where Git metadata (not just `git
blame`) needs to be double checked, indeed.

> However, before addressing this problem, I would like to know:
>
> Could matlab-mode become part of ELPA or even could dwell in the GNU
> emacs tree?

Very good question.  I think it would be acceptable in GNU ELPA or Emacs
(the legal&philosophical issues are the same for both) *if*
`matlab-mode` can be used meaningfully without proprietary software
(i.e. without Matlab).

I think it's a big "if".  Maybe a more interesting/promising path might
be to split the part of `matlab-mode` that also makes sense with Octave
and try to add/include/merge it into `octave-mode`, and then turn
`matlab-mode` into an extension on top of `octave-mode` that's dedicated
to supporting the bits of Matlab that aren't in Octave (that
extension won't be included in GNU ELPA nor Emacs, obviously).

> I know that matlab is a commercial product and its license is not
> compatible with the GPL, but the same could be said about MS Windows OS
> and MacOS and yet GNU Emacs support these OSs.
> It would benefit the users of matlab who wish to use GNU Emacs for coding.

Indeed, it's not completely black or white.  You may want to ask RMS
whether this gray is rather dark or light.


        Stefan




  parent reply	other threads:[~2021-11-21  0:00 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-20 17:53 could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)? Uwe Brauer
2021-11-20 22:42 ` Philip Kaludercic
2021-11-21  0:00 ` Stefan Monnier [this message]
2021-11-21  8:08   ` Uwe Brauer
2021-11-21  8:17     ` Po Lu
2021-11-21  8:25       ` Uwe Brauer
2021-11-21  9:23         ` Po Lu
2021-11-21  9:34           ` Uwe Brauer
2021-11-21  9:55             ` Po Lu
2021-11-21 10:04               ` Uwe Brauer
2021-11-21 11:40               ` dick
2021-11-21 20:16                 ` Andy Moreton
2021-11-21 10:58         ` Alfred M. Szmidt
2021-11-21 12:16           ` dick
2021-11-21 14:17           ` Uwe Brauer
2021-11-21 16:15             ` Alfred M. Szmidt
2021-11-21 16:25               ` Uwe Brauer
2021-11-21 16:39                 ` Alfred M. Szmidt
2021-11-21 17:13                   ` Uwe Brauer
2021-11-21 14:49         ` Stefan Monnier
2021-11-21 16:31           ` Uwe Brauer
2021-11-21 17:32             ` dick
2021-11-22 13:58             ` Stefan Monnier
2021-11-23  6:13               ` Richard Stallman
2021-11-21  8:22     ` Eli Zaretskii
2021-11-21  8:32       ` Uwe Brauer
2021-11-21  8:39         ` Eli Zaretskii
2021-11-21  8:51           ` Uwe Brauer
2021-11-21  9:05             ` Eli Zaretskii
2021-11-21  9:29               ` Uwe Brauer
2021-11-21 11:32           ` dick
2021-11-21 14:26             ` Uwe Brauer
2021-11-22  2:30 ` Richard Stallman
2021-11-22  7:56   ` Uwe Brauer
2021-11-22 13:59     ` Stefan Monnier
2022-02-14 11:51       ` Jean Louis
2022-02-14 11:49   ` Jean Louis
2022-02-16  4:11     ` Richard Stallman

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.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvzgpy8k3b.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=oub@mat.ucm.es \
    /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.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).