Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer <oub@mat.ucm.es>]

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

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

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

Ok, I tried 
 hg churn

And more or less its git equivalent 

git shortlog -ns | more

These commands reveal one author more, but not the same one.
A comment about the history of matlab-mode might help. It started using
patches and emails, as many now attic proyects that dates back to the 90
or 80, at some point I think RCS was used, then CVS and then it was
converted to git (and mercurial). [1]

The problem is that old «commits» often very sketchy, and not full names
were used, but usernames such as for examples RMS, DAK etc (actually
neither RMS nor David contributed to matlab, it was just an example).

In any case, I presume I have to checkout the corresponding commit and
then try to eyeball the relevant code, whether it still remains in the
current commit.

The problem is if it remains but the author cannot not be found or does
not respond. But before I even start this, I want to know whether at the
end matlab-mode can enter ELPA or the tree, so see below:

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

Actually this worries me much more, because in some cases the commit
reads apply patch from Name without an email address.


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

That last part I don't understand. Let me try to get that straight.

You would allow a part of matlab that could be used also in octave (and
I presume in other matlab clones such as scilab) to be part of ELPA or
the GNU emacs tree.

That part of the code most likely would be the part that takes care of
fortification or syntax checking. However octave's commands are is at
best a subset of matlab's so matlab would highlight more commands than
octave, but I don't think that is a problem. That is not trivial but
somehow doable.

The part where a merge is more difficult or almost impossible (or at
least as difficult as merging Xemacs and GNU emacs 20 years ago)
concerns debugging and the interaction with the shell. But Eric Ludlam
is more qualified to answer that. In any case I doubt that at the moment
any maintainer has the time to deal with that.

So if a merge is not possible, you are saying that the this specific
code could not enter ELPA or the emacs tree?

But then by the very same logic all part of the code (I presume it is
the C code) that allows GNU emacs to be compiled in MS Windows and MacOS
should be removed as well. (I don't think that is a good idea, but just
for the shake of an argument)



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

So, it is up to RMS?

RMS if you read this: would you allow to have a part of matlab-mode that
interacts with matlab via the so called matlab shell, to be part of ELPA or GNU
emacs?

Rationale: there is already specific code that allows GNU emacs to be
compiled in non free systems.

regards

Uwe 


>         Stefan




Footnotes:
[1]  Fun fact, there was a discussion on the mailing list, whether it
     should be git or mercurial, no surprise git won, but then those who
     voted for git (and wanted in github) never really contributed, at
     least not with write access to the repository.


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