Re: Why are so many great packages not trying to get included in GNU Emacs?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

> The reasons why package authors would not want to include it

Also, it may not even occur to the developer to include the code
in emacs, because it works for him and he's happy with it.

Is there an actual effort too seek out prospective packages and ask the
code owners to include it in emacs? Or is it left to the chance
that it occurs to the developer?

What about current popular packages outside Emacs? Were those developers
all asked?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Yuan Fu]

> On Apr 23, 2020, at 1:47 PM, ndame <ndame@protonmail.com> wrote:
> 
>> The reasons why package authors would not want to include it
> 
> Also, it may not even occur to the developer to include the code
> in emacs, because it works for him and he's happy with it.
> 

Another downside to adding one’s package to ELPA is the inconvenience. On GitHub one can freely commit however he wants, receive PR and issues; but if it’s in ELPA, you need to take care of commit message formats, submit a patch and wait for someone to review & commit the patch. Also, admittedly, while the email based workflow works, and works fine, admittedly it is not as convenient as github’s PR. It would be interesting to see a Emacs+email-based PR system/interface. E.g., save comments and stuff into a “PR file” and pass that back and forth through email, and view the PR file with an elaborate interface in Emacs. Essentially an interactive improved patch.

Yuan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Kangas]

Yuan Fu <casouri@gmail.com> writes:
> Another downside to adding one’s package to ELPA is the inconvenience. On GitHub one can freely commit however he wants, receive PR and issues

There are many packages in GNU ELPA hosted on GitHub, for example eglot:
https://github.com/joaotavora/eglot

See the "externals-list" file in the elpa repository.

Best regards,
Stefan Kangas

Re: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

>
> Another downside to adding one’s package to ELPA is the inconvenience.  On GitHub one can freely commit however he wants, receive PR and issues; but if it’s in ELPA, you need to take care of commit message formats, submit a patch and wait for someone to review & commit the patch.

I thought that the advantage of ELPA was that the author could develop the package independently of the strict emacs commit rules and he only had to pay attention to the copyright assignment.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Yuan Fu]

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

> There are many packages in GNU ELPA hosted on GitHub, for example eglot:
> https://github.com/joaotavora/eglot <https://github.com/joaotavora/eglot>
> 
> See the "externals-list" file in the elpa repository.

>> 
>> Another downside to adding one’s package to ELPA is the inconvenience.  On GitHub one can freely commit however he wants, receive PR and issues; but if it’s in ELPA, you need to take care of commit message formats, submit a patch and wait for someone to review & commit the patch.
> 
> I thought that the advantage of ELPA was that the author could develop the package independently of the strict emacs commit rules and he only had to pay attention to the copyright assignment.

I see. Apparently this is another example of the “misconceptions” about ELPA :-)

Yuan

[-- Attachment #2: Type: text/html, Size: 1718 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

>> Another downside to adding one’s package to ELPA is the inconvenience.
>> On GitHub one can freely commit however he wants, receive PR and issues;
>> but if it’s in ELPA, you need to take care of commit message formats,
>> submit a patch and wait for someone to review & commit the patch.
>
> I thought that the advantage of ELPA was that the author could develop the
> package independently of the strict emacs commit rules and he only had to
> pay attention to the copyright assignment.

That's right.  There is a practical problem, OTOH, which is that
write/push access to a GNU ELPA package currently means write access to
all GNU ELPA packages as well as to Emacs's repository.

For this reason, while some GNU ELPA package maintainers can "just push"
as they see fit, as it should be, others haven't yet been granted this
right.  This is a problem which we should solve, indeed, for the benefit
of those less-lucky package maintainers, as well as for the benefit of
those Emacs maintainers who have to play the middle men, and more
generally for the benefit of the GNU ELPA archive and hence Emacs users
since the current situation tends to discourage submissions.

Note that giving write access widely, as we do now, has advantages as
well, in that it encourages package maintainers to participate in
development of Emacs more generally.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

>
> For this reason, while some GNU ELPA package maintainers can "just push"
> as they see fit, as it should be, others haven't yet been granted this
> right. This is a problem which we should solve,

A simple solution which occurs to me that a script which has the necessary
permissions could pull the changes to its local repo and push from there
to ELPA. (This implies that the author pushes his changes to a public
place like GitHub, so the script can pull them from there.)

The script pulls the changes from the external repo when a certain dedicated
file in the repo (e.g. ELPA.pull) changes. The author changes this file
when he wants to authorize a new pull (wants to do a release to ELPA).

The script can discover the changed trigger file either by regularly checking
the external repos of the ELPA packages which follow this protocol, or if it's
too much work then the author can send a mail to a dedicated mail address
which triggers the pull of his repo (e.g. sends a mail to elpapull@gnu.org
with the subject <package name>.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

ndame <ndame@protonmail.com> writes:

>>
>> For this reason, while some GNU ELPA package maintainers can "just push"
>> as they see fit, as it should be, others haven't yet been granted this
>> right. This is a problem which we should solve,
>
> A simple solution which occurs to me that a script which has the necessary
> permissions could pull the changes to its local repo and push from there
> to ELPA. (This implies that the author pushes his changes to a public
> place like GitHub, so the script can pull them from there.)
>
> The script pulls the changes from the external repo when a certain dedicated
> file in the repo (e.g. ELPA.pull) changes. The author changes this file
> when he wants to authorize a new pull (wants to do a release to ELPA).
>
> The script can discover the changed trigger file either by regularly checking
> the external repos of the ELPA packages which follow this protocol, or if it's
> too much work then the author can send a mail to a dedicated mail address
> which triggers the pull of his repo (e.g. sends a mail to elpapull@gnu.org
> with the subject <package name>.

I think it could be even simpler than that: ELPA is built every 24 hours
right now. If we just registered external repos with ELPA, part of the
build process could be pulling from those repos automatically, once per
day. Package authors already have a mechanism for manually triggering a
release: incrementing the package version number. There's no harm in
ELPA bringing in new commits from the externals, if the author is still
in control of when a new version is released.

Eric

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> I think it could be even simpler than that: ELPA is built every 24 hours
> right now. If we just registered external repos with ELPA, part of the
> build process could be pulling from those repos automatically, once per
> day. Package authors already have a mechanism for manually triggering a
> release: incrementing the package version number. There's no harm in
> ELPA bringing in new commits from the externals, if the author is still
> in control of when a new version is released.

I think it's important that we don't "pull" from "random" places like
Github repositories.  More specifically, the "push to elpa.git" serves
as a confirmation that someone thinks this code is appropriate for
elpa.git (typically the concern being copyright).

For a pure "distribution only", we already have MELPA.

But yes, like "ndame" suggests, we could pull from some other
repositories kept under the gnu.org domain and then give write access
more liberally (or differently) to those repositories.  I think
currently creating new repositories with different access rights on
savannah is administrively too heavy to have a separate "savannah
project" per GNU ELPA package.  My hope is that the "new forge"
(Gitea/Pagure/SourceHut?) will solve this problem, but I don't know when
it will be available.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

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

>> I think it could be even simpler than that: ELPA is built every 24 hours
>> right now. If we just registered external repos with ELPA, part of the
>> build process could be pulling from those repos automatically, once per
>> day. Package authors already have a mechanism for manually triggering a
>> release: incrementing the package version number. There's no harm in
>> ELPA bringing in new commits from the externals, if the author is still
>> in control of when a new version is released.
>
> I think it's important that we don't "pull" from "random" places like
> Github repositories.  More specifically, the "push to elpa.git" serves
> as a confirmation that someone thinks this code is appropriate for
> elpa.git (typically the concern being copyright).

It doesn't seem much more random to say "we're adding your repo URL to
our list of approved ELPA pull-sources" than to say "you're now free to
push whatever you like", does it? An ELPA administrator still has to
make that explicit decision to add the URL, so there's still a level of
approval?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross]

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

I think a pull model wold actually be more secure and less maintenance. It
would mean that the contents of ELPA is 100% under the control of GNU. You
would have fewer access credentials to manage and would eliminate the risk
associated with external people and their management of their access
credentials. If wanted, you could also add processes to do any verification
tasks e.g. has tests, documentation, no large commits from people without
copyright assignment, code quality whatever.

On Fri, 24 Apr 2020 at 09:12, Eric Abrahamsen <eric@ericabrahamsen.net>
wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >> I think it could be even simpler than that: ELPA is built every 24 hours
> >> right now. If we just registered external repos with ELPA, part of the
> >> build process could be pulling from those repos automatically, once per
> >> day. Package authors already have a mechanism for manually triggering a
> >> release: incrementing the package version number. There's no harm in
> >> ELPA bringing in new commits from the externals, if the author is still
> >> in control of when a new version is released.
> >
> > I think it's important that we don't "pull" from "random" places like
> > Github repositories.  More specifically, the "push to elpa.git" serves
> > as a confirmation that someone thinks this code is appropriate for
> > elpa.git (typically the concern being copyright).
>
> It doesn't seem much more random to say "we're adding your repo URL to
> our list of approved ELPA pull-sources" than to say "you're now free to
> push whatever you like", does it? An ELPA administrator still has to
> make that explicit decision to add the URL, so there's still a level of
> approval?
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2475 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> It doesn't seem much more random to say "we're adding your repo URL to
> our list of approved ELPA pull-sources" than to say "you're now free to
> push whatever you like", does it? An ELPA administrator still has to
> make that explicit decision to add the URL, so there's still a level of
> approval?

I think there's a fairly large difference:

- When we pull from an external repository, every person who has write
  access to that repository is now in charge of thinking "does this fit
  the copyright requirements?", whereas only the original official
  maintainer has been explicitly informed about those requirements.
- The set of such people can be changed completely outside of our control,
  whereas we always make sure that people have signed the proper
  copyright paperwork before they get push access.
- After the initial setup, everything else would be transparent, so it'd
  be easy for the developers to forget or be unaware that it's published
  in GNU ELPA.
  The mindset on github is one that doesn't encourage careful
  consideration of licensing and authorship but instead encourages
  "happy sharing" [ Paradoxically, the FSF's insistence on tracking
  copyright assignments makes this very problematic (even tho, "happy
  sharing" is really what we all want to do) unless it's between people
  who we know have signed the copyright paperwork.  ]
  So psychologically, I think there is a big difference between
  "everything takes place on github" and "an explicit step is needed
  every time you want to get the code to the gnu.org side".


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

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

>> It doesn't seem much more random to say "we're adding your repo URL to
>> our list of approved ELPA pull-sources" than to say "you're now free to
>> push whatever you like", does it? An ELPA administrator still has to
>> make that explicit decision to add the URL, so there's still a level of
>> approval?
>
> I think there's a fairly large difference:
>
> - When we pull from an external repository, every person who has write
>   access to that repository is now in charge of thinking "does this fit
>   the copyright requirements?", whereas only the original official
>   maintainer has been explicitly informed about those requirements.
> - The set of such people can be changed completely outside of our control,
>   whereas we always make sure that people have signed the proper
>   copyright paperwork before they get push access.
> - After the initial setup, everything else would be transparent, so it'd
>   be easy for the developers to forget or be unaware that it's published
>   in GNU ELPA.
>   The mindset on github is one that doesn't encourage careful
>   consideration of licensing and authorship but instead encourages
>   "happy sharing" [ Paradoxically, the FSF's insistence on tracking
>   copyright assignments makes this very problematic (even tho, "happy
>   sharing" is really what we all want to do) unless it's between people
>   who we know have signed the copyright paperwork.  ]
>   So psychologically, I think there is a big difference between
>   "everything takes place on github" and "an explicit step is needed
>   every time you want to get the code to the gnu.org side".

Okay, that makes sense.

Thanks,
Eric

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 23 Apr 2020 23:24:53 -0400
> Cc: Yuan Fu <casouri@gmail.com>, ndame <ndame@protonmail.com>,
>  Emacs developers <emacs-devel@gnu.org>
> 
>   The mindset on github is one that doesn't encourage careful
>   consideration of licensing and authorship but instead encourages
>   "happy sharing" [ Paradoxically, the FSF's insistence on tracking
>   copyright assignments makes this very problematic (even tho, "happy
>   sharing" is really what we all want to do) unless it's between people
>   who we know have signed the copyright paperwork.  ]

I don't see that as a paradox.  The world of Free Software is much
larger than the world of GNU projects.  The FSF is advancing the
former to encourage "happy sharing", but exercise extra caution with
the latter.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[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 don't see that as a paradox.  The world of Free Software is much
  > larger than the world of GNU projects.  The FSF is advancing the
  > former to encourage "happy sharing", but exercise extra caution with
  > the latter.

That is basically true, but to be entirely correct it should say "SOME
GNU packages".  The "extra caution" applies to GNU packages which are
copyright FSF, and is for the sake of being able to enforce copyleft
in court.  Other GNU packages are copyrighted by their authors.


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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Phillip Lord]

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

>   The mindset on github is one that doesn't encourage careful
>   consideration of licensing and authorship but instead encourages
>   "happy sharing" [ Paradoxically, the FSF's insistence on tracking
>   copyright assignments makes this very problematic (even tho, "happy
>   sharing" is really what we all want to do) unless it's between people
>   who we know have signed the copyright paperwork.  ]


It is worth saying that while the process of getting copyright
assignment is clunky, it is not insurmountable. However, the process of
working out whether someone has copyright assignment already is a total
pain.

It should be possible to check automatically whether commits coming in
from any git repo are from someone who has assigned copyright. That
would, at least, remove the hassle in the case where the papers have
been done.

I have been through the process with dash.el as you know, and while I
managed to get it into ELPA, I have not managed to update it for a while
because there are new contributors and the process is all too painful.

Phil

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> I have been through the process with dash.el as you know, and while I
> managed to get it into ELPA, I have not managed to update it for a while
> because there are new contributors and the process is all too painful.

The check has to be done right when a new contributor appears, not after
the fact, indeed, otherwise it quickly becomes unmanageable.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Phillip Lord]

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

>> I have been through the process with dash.el as you know, and while I
>> managed to get it into ELPA, I have not managed to update it for a while
>> because there are new contributors and the process is all too painful.
>
> The check has to be done right when a new contributor appears, not after
> the fact, indeed, otherwise it quickly becomes unmanageable.


Even then, there is no easy way of doing it, other than just asking and
taking it on trust. Or in some cases, just assuming, because they have
contributed directly to Emacs, for instance. In one case, I nearly did
this, and it turned out to be wrong.

It's probably not worth re-opening the debate on whether this needs to
happen at all, but it if this is mandated by the FSF then spending some
money on making it easier is surely worth it.

Phil

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> Even then, there is no easy way of doing it, other than just asking and
> taking it on trust.

Yes, no doubt that this a problem.

You can always ask me or Eli to lookup the name in the official list,
but clearly it's inconvenient.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> It is worth saying that while the process of getting copyright
> assignment is clunky, it is not insurmountable. However, the process of
> working out whether someone has copyright assignment already is a total
> pain.

I'm lucky enough to have access to fencepost.gnu.org where the
`copyright.list` file is kept, so I can look it up fairly easily, but
for those who aren't so lucky it's indeed a problem.

> It should be possible to check automatically whether commits coming in
> from any git repo are from someone who has assigned copyright. That
> would, at least, remove the hassle in the case where the papers have
> been done.

I think for privacy reasons we can't distribute `copyright.list` itself.

But we could maintain a list of people who have signed the paperwork,
built from publicly available information, i.e. from the Git log of
emacs.git and elpa.git.  While not being on that list wouldn't be
a guarantee that paperwork is needed, it would still be helpful,
I think.

Any taker?


        Sefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 24/04/2020 23.11, Stefan Monnier wrote:
> But we could maintain a list of people who have signed the paperwork,
> built from publicly available information, i.e. from the Git log of
> emacs.git and elpa.git.  While not being on that list wouldn't be
> a guarantee that paperwork is needed, it would still be helpful,
> I think.
> 
> Any taker?

git log --format="%aE" | sort | uniq ?
Though I think having a commit in the Emacs repo doesn't necessarily imply having copyright papers on file.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Sat, 25 Apr 2020 00:22:39 -0400
> 
> On 24/04/2020 23.11, Stefan Monnier wrote:
> > But we could maintain a list of people who have signed the paperwork,
> > built from publicly available information, i.e. from the Git log of
> > emacs.git and elpa.git.  While not being on that list wouldn't be
> > a guarantee that paperwork is needed, it would still be helpful,
> > I think.
> > 
> > Any taker?
> 
> git log --format="%aE" | sort | uniq ?

This needs to be audited to exclude people who don't have assignment.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Sat, 25 Apr 2020 00:22:39 -0400
>> 
>> On 24/04/2020 23.11, Stefan Monnier wrote:
>> > But we could maintain a list of people who have signed the paperwork,
>> > built from publicly available information, i.e. from the Git log of
>> > emacs.git and elpa.git.  While not being on that list wouldn't be
>> > a guarantee that paperwork is needed, it would still be helpful,
>> > I think.
>> > 
>> > Any taker?
>> 
>> git log --format="%aE" | sort | uniq ?
>
> This needs to be audited to exclude people who don't have assignment.

I suppose listing committer instead of author would do it
(--format="%cE"), since we're literally only interested in who can
commit. That lists 356 unique committers -- obviously manual checking is
still necessary, but that's the right place to start? The same command
run in the ELPA repository gives 426 committers.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>,
>   emacs-devel@gnu.org
> Date: Sat, 25 Apr 2020 10:41:24 -0700
> 
> >> git log --format="%aE" | sort | uniq ?
> >
> > This needs to be audited to exclude people who don't have assignment.
> 
> I suppose listing committer instead of author would do it
> (--format="%cE"), since we're literally only interested in who can
> commit.

Are we?  I thought this was about knowing when a contributor has an
assignment on file, for people who don't have access to "the file"
itself.  Most contributors who went through the legal paperwork and
assigned copyright to the FSF don't have write access to the
repository.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>,
>>   emacs-devel@gnu.org
>> Date: Sat, 25 Apr 2020 10:41:24 -0700
>> 
>> >> git log --format="%aE" | sort | uniq ?
>> >
>> > This needs to be audited to exclude people who don't have assignment.
>> 
>> I suppose listing committer instead of author would do it
>> (--format="%cE"), since we're literally only interested in who can
>> commit.
>
> Are we?  I thought this was about knowing when a contributor has an
> assignment on file, for people who don't have access to "the file"
> itself.  Most contributors who went through the legal paperwork and
> assigned copyright to the FSF don't have write access to the
> repository.

Oh, then I guess author is more relevant after all, sorry about that.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Phillip Lord]

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

>> It is worth saying that while the process of getting copyright
>> assignment is clunky, it is not insurmountable. However, the process of
>> working out whether someone has copyright assignment already is a total
>> pain.
>
> I'm lucky enough to have access to fencepost.gnu.org where the
> `copyright.list` file is kept, so I can look it up fairly easily, but
> for those who aren't so lucky it's indeed a problem.
>
>> It should be possible to check automatically whether commits coming in
>> from any git repo are from someone who has assigned copyright. That
>> would, at least, remove the hassle in the case where the papers have
>> been done.
>
> I think for privacy reasons we can't distribute `copyright.list` itself.
>
> But we could maintain a list of people who have signed the paperwork,
> built from publicly available information, i.e. from the Git log of
> emacs.git and elpa.git.  While not being on that list wouldn't be
> a guarantee that paperwork is needed, it would still be helpful,
> I think.

I don't understand this logic. If most (although not all) of the
information in copyright.list can be gleaned from running git log, or
looking at AUTHORS, where is the privacy issue?

What not ask everyone when they submit their papers, if they are happy
to be public, along with a list of their commonly used aliases, emails
and so forth? Put this information up on the web, along with a RESTful
API. Add some command line tools, so that people can add it to the CI
tooling.

Phil

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> I don't understand this logic. If most (although not all) of the
> information in copyright.list can be gleaned from running git log, or
> looking at AUTHORS,

The official list is not specific to Emacs, includes real names (for
people who are otherwise only known via pseudonyms), birthdates,
countries, and other such info.
so it's quite different from the info you can get from Git.

> where is the privacy issue?

To be honest, I'm not sure.  I'd also like to know since without with
info it's hard to figure out what could be done.

E.g. would it OK if I filtered the list to only include paperwork that
covers contributions to Emacs and that only includes the names and
email addresses?
I think it would satisfy your use case, but would it be acceptable in
terms of privacy?  I don't know!

> What not ask everyone when they submit their papers, if they are happy
> to be public, along with a list of their commonly used aliases, emails
> and so forth?

That would be great.  Note that we (maintainers) don't have any direct
involvement in this, sadly.  The list is maintained by the FSF's
"clerk", so we should move this conversation there.

> Put this information up on the web, along with a RESTful API.
> Add some command line tools, so that people can add it to the
> CI tooling.

Even better, yes,


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Phillip Lord]

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

>> I don't understand this logic. If most (although not all) of the
>> information in copyright.list can be gleaned from running git log, or
>> looking at AUTHORS,
>
> The official list is not specific to Emacs, includes real names (for
> people who are otherwise only known via pseudonyms), birthdates,
> countries, and other such info.
> so it's quite different from the info you can get from Git.
>
>> where is the privacy issue?
>
> To be honest, I'm not sure.  I'd also like to know since without with
> info it's hard to figure out what could be done.
>
> E.g. would it OK if I filtered the list to only include paperwork that
> covers contributions to Emacs and that only includes the names and
> email addresses?
> I think it would satisfy your use case, but would it be acceptable in
> terms of privacy?  I don't know!
>
>> What not ask everyone when they submit their papers, if they are happy
>> to be public, along with a list of their commonly used aliases, emails
>> and so forth?
>
> That would be great.  Note that we (maintainers) don't have any direct
> involvement in this, sadly.  The list is maintained by the FSF's
> "clerk", so we should move this conversation there.
>
>> Put this information up on the web, along with a RESTful API.
>> Add some command line tools, so that people can add it to the
>> CI tooling.
>
> Even better, yes,


I have tried having this discussion before. We did get a partly working
system which was marginally better than asking copyright@fsf everytime,
but I think it only partly worked, required me to keep manual records of
where requests where and so forth.

Ultimately, anything that we do from here is going to cost time and/or
money either in development or just going through the entire list and
asking everyones permission. For Emacs, development, I am sure it would
be worth it.

Richard, I have cc'd you in. What would be the governance proceedure to
follow to have the FSF investigate and do this work, to make it easier
to check copyright assignment.

Phil

Re: Why are so many great packages not trying to get included in GNU Emacs?

[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 should be possible to check automatically whether commits coming in
  > from any git repo are from someone who has assigned copyright. That
  > would, at least, remove the hassle in the case where the papers have
  > been done.

How could that be possible?  How would we know who wrote those
changes?  We can't assume it is the person whose account checked them
in.  Often that is so, but not always.

There may be other issues, such as, if the name on that account is
John Doe, does that mean the user of that account is the same John Doe
that signed an assignment?

It is not terrible lot of work for people to deal with those issues,
but I wouldn't assume a simple program can.


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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> It is not terrible lot of work for people to deal with those issues,
> but I wouldn't assume a simple program can.

The better option is to stop requiring copyright paperwork.
It is harmful to the Emacs project.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Philippe Vaucher]

> > It is not terrible lot of work for people to deal with those issues,
> > but I wouldn't assume a simple program can.
>
> The better option is to stop requiring copyright paperwork.
> It is harmful to the Emacs project.

Do copyright paperwork really protect Emacs from anything anyway? I
never saw any problems in other open source/free/libre softwares which
didn't do that. It's for sure a big hurdle to new contributors.

(I'm not saying they are useless, I just don't see the point
pragmatically. Don't get upset please, just explain it to me :-)

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Kévin Le Gouguec]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> > It is not terrible lot of work for people to deal with those issues,
>> > but I wouldn't assume a simple program can.
>>
>> The better option is to stop requiring copyright paperwork.
>> It is harmful to the Emacs project.
>
> Do copyright paperwork really protect Emacs from anything anyway? I
> never saw any problems in other open source/free/libre softwares which
> didn't do that. It's for sure a big hurdle to new contributors.

The best assessment of copyright assignment effectiveness I know of is
Bradley Kuhn's recap of the issue in 2012[1]:

> Simply put, the GPL violation defending lawyers have gotten more
> obsessed than ever with delay tactics. They try to raise every
> spurious issue they can think of to delay you, distract you, or
> otherwise try to avoid bringing their client into compliance with the
> terms of GPL.  If you don't hold all the copyrights, they'll focus on
> that issue.  For example, I had an executive of a large computer maker
> tell me that his lawyers say "copyright infringement claims are
> legally invalid unless you hold a majority of the copyrights".  This
> is completely asinine and clearly incorrect in the USA, but violators
> make these arguments all the time.  As another example: I was once
> deposed in a court case for 8 hours about the topic whether or not
> BusyBox's configuration files magically made Erik Andersen's
> copyrights fail to appear in the binary work.  That's a spurious
> argument that I spent 8 hours refuting, yet the violator's lawyer
> again brought it up in the Court as a defense that we had to refute.

To me that sort of suggests that copyright assignment is neither
sufficient (you still need enough resources to overcome "every spurious
issue" the defending lawyers will throw at you) nor necessary (since
Bradley considers it "asinine" to say "an infringement claim is invalid
without holding a majority of the copyrights").

As a layman on these matters (like most potential contributors, I
assume), it would definitely help if the FSF maintained a list[2] of
successful and/or failed GPL enforcement cases *where assignment was a
decisive factor*.  As things stand it's hard to correlate "enforcement
success" with "copyright assignment", so it's really an act of faith we
ask of new contributors…


[1] https://lwn.net/Articles/530239/

[2] Sort of like this FSFE page:
    https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Date: Thu, 07 May 2020 11:40:52 +0200
> Cc: Yuan Fu <casouri@gmail.com>, Richard Stallman <rms@gnu.org>,
>  Eric Abrahamsen <eric@ericabrahamsen.net>,
>  Emacs developers <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Phillip Lord <phillip.lord@russet.org.uk>, ndame@protonmail.com
> 
> The best assessment of copyright assignment effectiveness I know of is
> Bradley Kuhn's recap of the issue in 2012[1]:
> 
> > Simply put, the GPL violation defending lawyers have gotten more
> > obsessed than ever with delay tactics. They try to raise every
> > spurious issue they can think of to delay you, distract you, or
> > otherwise try to avoid bringing their client into compliance with the
> > terms of GPL.  If you don't hold all the copyrights, they'll focus on
> > that issue.  For example, I had an executive of a large computer maker
> > tell me that his lawyers say "copyright infringement claims are
> > legally invalid unless you hold a majority of the copyrights".  This
> > is completely asinine and clearly incorrect in the USA, but violators
> > make these arguments all the time.  As another example: I was once
> > deposed in a court case for 8 hours about the topic whether or not
> > BusyBox's configuration files magically made Erik Andersen's
> > copyrights fail to appear in the binary work.  That's a spurious
> > argument that I spent 8 hours refuting, yet the violator's lawyer
> > again brought it up in the Court as a defense that we had to refute.
> 
> To me that sort of suggests that copyright assignment is neither
> sufficient (you still need enough resources to overcome "every spurious
> issue" the defending lawyers will throw at you) nor necessary (since
> Bradley considers it "asinine" to say "an infringement claim is invalid
> without holding a majority of the copyrights").

Actually, Bradley's conclusion, the very next paragraph after the one
you quoted, is a direct opposite of yours, AFAICT.  If we are going to
cite others who might have educated opinions on this matter, why not
cite them more completely?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> To me that sort of suggests that copyright assignment is neither
>> sufficient (you still need enough resources to overcome "every spurious
>> issue" the defending lawyers will throw at you) nor necessary (since
>> Bradley considers it "asinine" to say "an infringement claim is invalid
>> without holding a majority of the copyrights").
>
> Actually, Bradley's conclusion, the very next paragraph after the one
> you quoted, is a direct opposite of yours, AFAICT.  

Well, Bradley concludes that assignment makes enforcement "easier":

> But, when I am asked: "Isn't it easier to enforce when you have all
> the copyrights?", my answer has to be: "Yes, it's easier". It's a
> trade-off; there's no question. My personal position is probably
> obvious on this, since I have written often about preferring
> multi-copyright held projects myself, but even I admit to being
> annoyed by the downsides from time to time.

But "easier" is not "directly opposite" to "neither sufficient nor
necessary", at least in my understanding?  Assignment may help, but
Bradley says that it's not strictly necessary legally speaking, and it's
not a silver bullet either.

>                                                     If we are going to
> cite others who might have educated opinions on this matter, why not
> cite them more completely?

In this case, because I did not believe the rest of the quote
contradicted my understanding of the issue, but thank you for
underlining Bradley's conclusion, which of course should be given more
consideration than my own.


The reason why I sent my previous message was in the hope that someone
might give us an updated picture of the enforcement landscape; it's been
some years since 2012.  I apologize if it looked like I was putting
words in Bradley's mouth.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[조성빈]

> 2020. 5. 7. 오후 12:34, Stefan Monnier <monnier@iro.umontreal.ca> 작성:
> 
>> It is not terrible lot of work for people to deal with those issues,
>> but I wouldn't assume a simple program can.
> 
> The better option is to stop requiring copyright paperwork.
> It is harmful to the Emacs project.

Thank you so much for saying this, it’s actively harmful and really the only reason why MELPA is a thing.

>        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[tomas]

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

On Wed, May 06, 2020 at 11:33:05PM -0400, Stefan Monnier wrote:
> > It is not terrible lot of work for people to deal with those issues,
> > but I wouldn't assume a simple program can.
> 
> The better option is to stop requiring copyright paperwork.
> It is harmful to the Emacs project.

I respectfully disagree.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Kangas]

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

> The better option is to stop requiring copyright paperwork.
> It is harmful to the Emacs project.

FWIW, I strongly agree.  Thanks for bringing this up.

Best regards,
Stefan Kangas

Re: Why are so many great packages not trying to get included in GNU Emacs?

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

The difficulty about taking precautions,
is that people see the inconvenience of taking them
and may not weigh that against the harm the precautions prevent.

We will continue obtaining copyright assignments
unless we get legal and practical advice that we can stop.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> The difficulty about taking precautions, is that people see the
> inconvenience of taking them and may not weigh that against the harm
> the precautions prevent.

It cuts both ways: I think you don't see the second-order harm that
those precautions do beside the obvious first-order effect of having to
ask people to sign paperwork.

Similarly, you don't seem to realize the extent of the chilling effect
of you saying that `s.el` shouldn't be in GNU ELPA.


        Stefan

Drop the Copyright Assignment requirement for Emacs

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> We will continue obtaining copyright assignments
> unless we get legal and practical advice that we can stop.

Legal considerations are important, yes, but there are other
considerations too.  There is real damage being done to Emacs today, by
excluding code and packages that we really should have in either Emacs
core or ELPA.

The question is:
- How to effectively enforce the GPL without actively damaging Emacs?

We have one answer to that, and it's been the same since the 1980's.
Legal experts are supposedly telling us that we need assignments.  But
is that the whole story?

To quote the post by Bradley M. Kuhn from before:

    "I'm the only person in the world who is involved with both Software
    Freedom Conservancy and the FSF, and I've also likely spent more
    time on GPL enforcement than anyone on the planet, so I feel I have
    some authority to speak on that subject." [1]

So he is clearly qualified, no?  And what is _his_ expert opinion?

    "... Conservancy's GPL compliance work has shown that enforcement is
    possible in a multi-copyright-held project.  I do that every single
    day."

In other words, he claims that it is fine, specifically from the
standpoint of GPL enforcement, to be a "multi-copyright-held project".
(In fact, he says later in the post that he prefers that model.)

So we have, at the very least, _conflicting_ advice from the experts.
So who should we listen to?

Well, Bradley M. Kuhn takes a balanced view, and the above paragraph
continues:

    "But, there is no question that the work is easier if the non-profit
    that seeks to enforce holds an /overwhelming majority/ of the
    copyrights." (my emphasis)

Now, this is very interesting.  And it points to a solution:

    1. Allow contributions without assignments.

    2. Actively encourage every contributor to sign the assignment.

This is a very conservative compromise that ensures that we can both
enforce the GPL effectively, _and_ ensure that Emacs prospers.

Best regards,
Stefan Kangas

Footnotes:
[1] https://lwn.net/Articles/530239/

Re: Drop the Copyright Assignment requirement for Emacs

[Stefan Monnier]

Just a side note: my comment about the copyright assignment being
harmful to our project was about GNU ELPA, not about Emacs.


        Stefan

Re: Drop the Copyright Assignment requirement for Emacs

[Stefan Kangas]

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

> Just a side note: my comment about the copyright assignment being
> harmful to our project was about GNU ELPA, not about Emacs.

Thank you for clarifying.

I think I made my point of view clear, but I also agree that changing
policy for ELPA is more important.

Best regards,
Stefan Kangas

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 08 May 2020 11:14:12 -0400
> Cc: casouri@gmail.com, rms@gnu.org, eric@ericabrahamsen.net,
>  emacs-devel@gnu.org, ndame@protonmail.com, phillip.lord@russet.org.uk
> 
> Just a side note: my comment about the copyright assignment being
> harmful to our project was about GNU ELPA, not about Emacs.

You originally said "Emacs development", so it was easy to
misunderstand that.

Re: Drop the Copyright Assignment requirement for Emacs

[Stefan Monnier]

> You originally said "Emacs development", so it was easy to
> misunderstand that.

Yes, I realized after the fact that my message might have been
misunderstood (I read the discussion within the context of Phil asking
for a way to streamline checking copyright assignment, where Phil's
concern is for GNU ELPA packages (e.g. `dash`), but the message to which
I was responding did not seem to be limited to GNU ELPA).

For this reason I wanted to clarify my position.


        Stefan


PS: I couldn't resist going back to check what I had actually written
and I see I wrote:

    The better option is to stop requiring copyright paperwork.
    It is harmful to the Emacs project.

So it was a bit confusing indeed, but compatible with my opinion:
I consider that requiring copyright assignment for GNU ELPA packages is
harmful to the Emacs project.

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stefankangas@gmail.com,  casouri@gmail.com,  rms@gnu.org,
>   eric@ericabrahamsen.net,  emacs-devel@gnu.org,  ndame@protonmail.com,
>   phillip.lord@russet.org.uk
> Date: Fri, 08 May 2020 14:06:27 -0400
> 
>     The better option is to stop requiring copyright paperwork.
>     It is harmful to the Emacs project.
> 
> So it was a bit confusing indeed, but compatible with my opinion:
> I consider that requiring copyright assignment for GNU ELPA packages is
> harmful to the Emacs project.

After thinking about that for a while, I came to the sad conclusion
that I no longer understand what is the relation between GNU ELPA and
the Emacs project.  So I cannot follow your logic here.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Fri, May 8, 2020 at 7:54 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> After thinking about that for a while, I came to the sad conclusion
> that I no longer understand what is the relation between GNU ELPA and
> the Emacs project.

GNU ELPA distributes some Emacs source files as :core-type
package.el packages.  This means that we can fix bugs and evolve
features in those files in Emacs master and not having to wait many
months until they make into the next core release.  This has proven
invaluable for the development of Eglot, a GNU ELPA package, which
depends on jsonrpc.el and flymake.el, which are in the core.  Bugs
can often be fixed in those files and they'll be available to users the
next day.  I don't know if this counts as a meaningful relationship,
but it is  extremely useful nonetheless and we should expand it (in
fact I discussed it with Dmitry and Stefan I'm going to do it soon for
eldoc.el, xref.el and project.el).

João





-- 
João Távora

Re: Drop the Copyright Assignment requirement for Emacs

[Amin Bandali]

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

João Távora <joaotavora@gmail.com> writes:

> On Fri, May 8, 2020 at 7:54 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> After thinking about that for a while, I came to the sad conclusion
>> that I no longer understand what is the relation between GNU ELPA and
>> the Emacs project.
>
> GNU ELPA distributes some Emacs source files as :core-type
> package.el packages.  This means that we can fix bugs and evolve
> features in those files in Emacs master and not having to wait many
> months until they make into the next core release.  This has proven
> invaluable for the development of Eglot, a GNU ELPA package, which
> depends on jsonrpc.el and flymake.el, which are in the core.  Bugs
> can often be fixed in those files and they'll be available to users the
> next day.  I don't know if this counts as a meaningful relationship,
> but it is  extremely useful nonetheless and we should expand it (in
> fact I discussed it with Dmitry and Stefan I'm going to do it soon for
> eldoc.el, xref.el and project.el).
>
> João

+1.  And I'm hoping to have ERC added to the above list very soon.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

Re: Drop the Copyright Assignment requirement for Emacs

[Fu Yuan]

> 在 2020年5月8日，下午6:35，Amin Bandali <bandali@gnu.org> 写道：
> 
> João Távora <joaotavora@gmail.com> writes:
> 
>>> On Fri, May 8, 2020 at 7:54 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>> After thinking about that for a while, I came to the sad conclusion
>>> that I no longer understand what is the relation between GNU ELPA and
>>> the Emacs project.
>> 
>> GNU ELPA distributes some Emacs source files as :core-type
>> package.el packages.  This means that we can fix bugs and evolve
>> features in those files in Emacs master and not having to wait many
>> months until they make into the next core release.  This has proven
>> invaluable for the development of Eglot, a GNU ELPA package, which
>> depends on jsonrpc.el and flymake.el, which are in the core.  Bugs
>> can often be fixed in those files and they'll be available to users the
>> next day.  I don't know if this counts as a meaningful relationship,
>> but it is  extremely useful nonetheless and we should expand it (in
>> fact I discussed it with Dmitry and Stefan I'm going to do it soon for
>> eldoc.el, xref.el and project.el).
>> 
>> João
> 
> +1.  And I'm hoping to have ERC added to the above list very soon.

That’s a fine idea. But if we move core packages out into ELPA and a I install it using a lower version of Emacs. Which package will be loaded? The ELPA version or the built-in version?

Yuan

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 8 May 2020 22:38:34 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>
> 
> On Fri, May 8, 2020 at 7:54 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > After thinking about that for a while, I came to the sad conclusion
> > that I no longer understand what is the relation between GNU ELPA and
> > the Emacs project.
> 
> GNU ELPA distributes some Emacs source files as :core-type
> package.el packages.  This means that we can fix bugs and evolve
> features in those files in Emacs master and not having to wait many
> months until they make into the next core release.

That's what I thought, but this means GNU ELPA is just a special
branch of Emacs, and apart of the above, all the other requirements
and code conventions should be identical, so that we could move
packages between the core and ELPA at will.  But Stefan evidently
thinks otherwise, because he said the copyright assignment shouldn't
be a requirement for ELPA (and moreover, that requiring it hurts the
Emacs project), and also I see that packages are admitted to GNU ELPA
without asking the authors to adapt them to our coding conventions.

So that led me to a conclusion that there's something fundamental I
don't understand here.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 7:14 AM Eli Zaretskii <eliz@gnu.org> wrote:

> That's what I thought, but this means GNU ELPA is just a special
> branch of Emacs,

Part of it is, kind of, since it distributes the very same files.
Another part isn't really.

> and apart of the above, all the other requirements
> and code conventions should be identical, so that we could move
> packages between the core and ELPA at will.

That was my impression initially too.  But in practice it evolved to
a place for the "not quite ready for prime-time" cases: i.e. we
let most everything in, provided they have copyright and adhere
to some minimal conventions.  So we don't uphold the same
standard there, never did, I think.  Nowadays, I see ELPA as a
staging place for packages to come in, eventually make it into core
_and_ back into ELPA as :core packages.

Eglot, the LSP package, is in that situation: it is in ELPA but is
developed  on Github for now and ,there it has gathered contributors
whom I ask for copyright assignments, GNU-style commits, etc.
Soon, we'll discuss its integration into the core, and if it works out,
I'll want to keep it in GNU ELPA as a :core packge.  In the meantime,
Emacs will have gained 3-4 Eglot regulars as new core Emacs
contributors.

How can it not "work out"? Well, this list might decide it doesn't
have the technical merits yet or, more seriously, I messed up
and forgot to require copyright for a significant contribution. I
will often only ask if the contributor has started the process and
let the commit go in if he confirms.  But I don't double-check
(I should, of course, and that's why it should be easier to do).

I believe, Yasnippet, now maintained by Noam Postavski, is in a
similar situation. It has all the copyright in order, but since some
parts of it which are still a bit gory, it's better not import it into core
until they are resolved.

FWIW, I don't fully agree with Stefan: we should not require
copyright assignment for inclusion in GNU ELPA if that introduces
needless friction, but we should require of authors, maintainers or
proponents that they make an effort to track down the contributors
and solve this, otherwise it makes no sense for it to be there.

Finally, above practical aspects, assigning copyright is declaring
support for an idea larger than the FSF itself.  It's a political
declaration.  I think the reason some people take issue with it
is seeing their names vanish from the first few lines of the source
file, and be replaced by something they don't agree with, or
don't understand.

João

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 9 May 2020 10:48:34 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>
> 
> That was my impression initially too.  But in practice it evolved to
> a place for the "not quite ready for prime-time" cases: i.e. we
> let most everything in, provided they have copyright and adhere
> to some minimal conventions.  So we don't uphold the same
> standard there, never did, I think.  Nowadays, I see ELPA as a
> staging place for packages to come in, eventually make it into core
> _and_ back into ELPA as :core packages.

What is the process of becoming :core? is that documented somewhere?
E.g., is dash.el undergo such a process to be better suited for core?
Or will dash.el never be in core (in which case see below)?

> FWIW, I don't fully agree with Stefan: we should not require
> copyright assignment for inclusion in GNU ELPA if that introduces
> needless friction, but we should require of authors, maintainers or
> proponents that they make an effort to track down the contributors
> and solve this, otherwise it makes no sense for it to be there.
> 
> Finally, above practical aspects, assigning copyright is declaring
> support for an idea larger than the FSF itself.  It's a political
> declaration.  I think the reason some people take issue with it
> is seeing their names vanish from the first few lines of the source
> file, and be replaced by something they don't agree with, or
> don't understand.

Then I ask again the same question: why not let these packages live on
MELPA or in GitHub or anywhere else?  What do we and the package
maintainers gain from having these packages on ELPA?

Still confused.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 10:56 AM Eli Zaretskii <eliz@gnu.org> wrote:

> What is the process of becoming :core? is that documented somewhere?

No idea.  I think we just do it for things that are convenient.
Note that :core is for one-file libs only _already_ in the Emacs tree,
and they are taken from the master branch directly.

> E.g., is dash.el undergo such a process to be better suited for core?
> Or will dash.el never be in core (in which case see below)?

No idea.  I think it has to make it into "the core" first. It has three
barriers to overcome IMO: solving its namespacing problem and
proving its technical merits for general usage in the Emacs core.

> Then I ask again the same question: why not let these packages live on
> MELPA or in GitHub or anywhere else?  What do we and the package
> maintainers gain from having these packages on ELPA?

Well, I would say two reasons: 1. It's a staging ground, a stepping
stone where authors can experiment with Emacs dev procedures
2. We envisioned (I recall) that Emacs might one day be distributed
with some of the packages in ELPA, presumably the well behaved
ones.

João

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 9 May 2020 11:10:09 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>
> 
> On Sat, May 9, 2020 at 10:56 AM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > What is the process of becoming :core? is that documented somewhere?
> 
> No idea.  I think we just do it for things that are convenient.
> Note that :core is for one-file libs only _already_ in the Emacs tree,
> and they are taken from the master branch directly.

So I guess there's no such process at this time.  We just have some
packages that are already in core, and are _also_ available from ELPA.
IOW, it's a static situation that is not designed to change.

> > Then I ask again the same question: why not let these packages live on
> > MELPA or in GitHub or anywhere else?  What do we and the package
> > maintainers gain from having these packages on ELPA?
> 
> Well, I would say two reasons: 1. It's a staging ground, a stepping
> stone where authors can experiment with Emacs dev procedures

Is that really important?  Why cannot the authors experiment with that
while outside ELPA?

> 2. We envisioned (I recall) that Emacs might one day be distributed
> with some of the packages in ELPA, presumably the well behaved
> ones.

This would require the same requirements as we ask for inclusion in
core.  That doesn't seem to be happening, and AFAIU it isn't by
omission.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 11:19 AM Eli Zaretskii <eliz@gnu.org> wrote:

> So I guess there's no such process at this time.  We just have some
> packages that are already in core, and are _also_ available from ELPA.
> IOW, it's a static situation that is not designed to change.

Not 100% sure what you mean by that. But yes, there's no pre-planned
route for :core packages.  We decide if it's convenient to do it on a case
by case.

Notice it does have drawbacks.  Once you do this for a lisp/foo.el file,
you need to add this:

;; Package-Requires: ((emacs "xx.y"))
;; This is an Elpa :core package. Don't use functionality that is not
;; compatible with Emacs xx.y.

Most of the times, I think the trade-off is more than acceptable.

> Is that really important?  Why cannot the authors experiment with that
> while outside ELPA?

They can, of course, but you're denying that "official" GNU stamp.
There's the legitimate ambition of recognition, very common among
younger developers, because these kinds of things can matter in job
interviews, for example.

> > 2. We envisioned (I recall) that Emacs might one day be distributed
> > with some of the packages in ELPA, presumably the well behaved
> > ones.
> This would require the same requirements as we ask for inclusion in
> core.

Not quite the same.  The bar for inclusion in the core is higher.
The candidate code has to have technical merit because it's
going to be used by other code already in the core, creating a
dependency. This is theoretically why including s.el in GNU Elpa
would be less bad than including it in Emacs.  However some
people think, and I agree with them, that this would encourage
other packages in GNU Elpa to adopt s.el's prepotent prefix
and thus create a larger problem.

This is, by the way, why I think this is a technical problem at heart:
  if s.el's default prefix wasn't so harmful there would be no reason
not to include it in GNU Elpa AFAICT.

> [Those requirements] doesn't seem to be happening, and AFAIU
> it isn't by omission.

It's happening de facto for some (or most?), packages in
ELPA, AFAIU.  I don't remember people requesting it from me
explicitly, but my memory is hazy here.

João

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 9 May 2020 10:48:34 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  emacs-devel <emacs-devel@gnu.org>
> 
> I think the reason some people take issue with it is seeing their
> names vanish from the first few lines of the source file, and be
> replaced by something they don't agree with, or don't understand.

I don't know where that rumor comes from, but it's false: this never
happens, except when the author/maintainer disappears from the face of
the earth, and even then it takes many years.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 11:00 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Sat, 9 May 2020 10:48:34 +0100
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
> >  emacs-devel <emacs-devel@gnu.org>
> >
> > I think the reason some people take issue with it is seeing their
> > names vanish from the first few lines of the source file, and be
> > replaced by something they don't agree with, or don't understand.
>
> I don't know where that rumor comes from, but it's false: this never
> happens, except when the author/maintainer disappears from the face of
> the earth, and even then it takes many years.

Oh you're referring to "the Author/Maitainer".  Right that stays.  Indeed
names don't vanish: but the "2020 Copyright John Doe" is now
"2020 Copyright the Free Software Foundation" and some people
don't like that.

Also, it is not a rumor at all, let me be very clear.  It is my personal
conjecture, nothing more.

João

Re: Drop the Copyright Assignment requirement for Emacs

[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 think the reason some people take issue with it is seeing their
  > > names vanish from the first few lines of the source file, and be
  > > replaced by something they don't agree with, or don't understand.

  > I don't know where that rumor comes from, but it's false: this never
  > happens, except when the author/maintainer disappears from the face of
  > the earth, and even then it takes many years.

We delete Maintainer header fields if the person listed stops maintaining
that code.  But why do we ever delete Author fields?

If there is a good reason to delete Author fields, we could, if the
original author wishes, add a file header field "Original author:" to
list the original author's name.  We could agree to keep that as long as that
file or package is still recognizably distinct.

Is there any reason not to do that?


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

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: joaotavora@gmail.com, monnier@iro.umontreal.ca,
> 	emacs-devel@gnu.org
> Date: Sat, 09 May 2020 22:29:42 -0400
> 
> We delete Maintainer header fields if the person listed stops maintaining
> that code.  But why do we ever delete Author fields?

We generally don't, except in some rare and special situations, AFAIR.

Re: Drop the Copyright Assignment requirement for Emacs

[Stefan Monnier]

>> We delete Maintainer header fields if the person listed stops maintaining
>> that code.  But why do we ever delete Author fields?
>
> We generally don't, except in some rare and special situations, AFAIR.

Yup, I can't remember ever seeing someone be removed from an Author
field, actually.


        Stefan

Re: Drop the Copyright Assignment requirement for Emacs

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

  > > We generally don't, except in some rare and special situations, AFAIR.

  > Yup, I can't remember ever seeing someone be removed from an Author
  > field, actually.

That is good.  We can assure contributors that we don't remove the
field that gives them credit for their writing.

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

Re: Drop the Copyright Assignment requirement for Emacs

[Marcin Borkowski]

On 2020-05-09, at 11:48, João Távora <joaotavora@gmail.com> wrote:

> Finally, above practical aspects, assigning copyright is declaring
> support for an idea larger than the FSF itself.  It's a political
> declaration.

Could someone officially confirm or deny the above paragraph?

If that is indeed so, I might consider withdrawing my assignment.  While
I do agree with FSF goals in some part, I never treated the copyright
assignment as a "political declaration", and if this is indeed the case,
I feel quite cheated.  When I assigned the copyright, nobody told me
anything about any "political declaration" stuff.  I was a bit hesitant
to sign the agreement, precisely because I was afraid it might be
understood as a "political declaration", and finally deciding that it is
more of a legal technicality and yet another rms'/FSF's weirdness.

To be clear: I am quite supportive of the idea of free software, and
I have quite a few reasons to agree with and even admire rms (and some
other reasons to firmly refute some of his views, which I consider
morally wrong, even evil maybe, and very harmful), but I e.g. do not
consider non-free software to be morally wrong.  I also agree with many
critical views on big corporations stealing our privacy, and imposing
new meanings on some words (the word "Orwellian" comes to mind).
I personally try to avoid giving away too much of my privacy - I use
Privavy Badger, I seldom google but use DuckDuckGo on a daily basis,
I almost never pay with a debit card (I made an exception because of the
covid-19 lunacy we have now) and I do not even have a credit card, but
I am not paranoid about it, and I do own an Android phone, an Amazon
Kindle and sometimes I use MS Windows (though I consider it clunky).
Also, I very much agree with rms' criticism for using some words (like
"intellectual property" or "piracy"), but consider his insistence on
using expressions like "Kindle Swindle" childish and even slightly
pathetic.

(Just a short summary of my views on free software, FSF and rms.)

So, if someone treats my signature of the copyright assignment as
a "political declaration" of support to FSF's or rms' views, I would
like to make it absolutely clear that this is not the case.

TIA,

--
Marcin Borkowski
http://mbork.pl

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Sat, 09 May 2020 13:49:54 +0200
> 
> On 2020-05-09, at 11:48, João Távora <joaotavora@gmail.com> wrote:
> 
> > Finally, above practical aspects, assigning copyright is declaring
> > support for an idea larger than the FSF itself.  It's a political
> > declaration.
> 
> Could someone officially confirm or deny the above paragraph?

I can.  And also you can (as can anyone who has ever signed those
papers).  You have the contract in your hands, you received it after
signing your copy.  There's nothing in copyright assignment except
what's written in that contract.  Since you've signed it, I take it
that you read it and agreed with what it says.  There's nothing there
about any declaration.  Simply re-read the text you signed to realize
that.

I'm guessing João was talking about the perception of the assignment
by some people.  Not about what it actually is or how it is
interpreted by the FSF.

> So, if someone treats my signature of the copyright assignment as
> a "political declaration" of support to FSF's or rms' views, I would
> like to make it absolutely clear that this is not the case.

They cannot treat it as such, since the document has no words to that
effect.

Re: Drop the Copyright Assignment requirement for Emacs

[Marcin Borkowski]

On 2020-05-09, at 14:22, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Date: Sat, 09 May 2020 13:49:54 +0200
>> 
>> On 2020-05-09, at 11:48, João Távora <joaotavora@gmail.com> wrote:
>> 
>> > Finally, above practical aspects, assigning copyright is declaring
>> > support for an idea larger than the FSF itself.  It's a political
>> > declaration.
>> 
>> Could someone officially confirm or deny the above paragraph?
>
> I can.  And also you can (as can anyone who has ever signed those
> papers).  You have the contract in your hands, you received it after
> signing your copy.  There's nothing in copyright assignment except
> what's written in that contract.  Since you've signed it, I take it
> that you read it and agreed with what it says.  There's nothing there
> about any declaration.  Simply re-read the text you signed to realize
> that.

Well, this is so simple only in theory.  If anyone could just read and
be sure that he understand a legal document, there would be (almost) no
need for lawyers, no?  I did read it, and I specifically paid attention
to whether it contains things João talked about, and did not find them.
But that dos not mean that I was not mistaken.

Thanks,

-- 
Marcin Borkowski
http://mbork.pl

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 12:50 PM Marcin Borkowski <mbork@mbork.pl> wrote:
> On 2020-05-09, at 11:48, João Távora <joaotavora@gmail.com> wrote:
> > Finally, above practical aspects, assigning copyright is declaring
> > support for an idea larger than the FSF itself.  It's a political
> > declaration.
> Could someone officially confirm or deny the above paragraph?

I, the author of this paragraph, hereby officially confirm I hold
that opinion. Send paper and postage my way and I'll stamp a
paper with the official confirmation for framing and posterity.

> I am quite supportive of the idea of free software,

That is a political stance, a way to opine on what the organization
of the polis should be. In fact, it is quite the same idea the I support.
Again, in my offically official opinion.

João

Re: Drop the Copyright Assignment requirement for Emacs

[Alfred M. Szmidt]

   > Finally, above practical aspects, assigning copyright is declaring
   > support for an idea larger than the FSF itself.  It's a political
   > declaration.

   Could someone officially confirm or deny the above paragraph?

It is very much false.  By assigning your copyright to the FSF you do
just that and nothing else, it says nothing about what values you hold
or wish to endorse.

That is intentional, since the GNU project welcomes _anyone_ no matter
what their political views are.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 2:35 PM Alfred M. Szmidt <ams@gnu.org> wrote:
>    > Finally, above practical aspects, assigning copyright is declaring
>    > support for an idea larger than the FSF itself.  It's a political
>    > declaration.
>    Could someone officially confirm or deny the above paragraph?
> It is very much false.  By assigning your copyright to the FSF you do
> just that and nothing else, it says nothing about what values you hold
> or wish to endorse.

I don't resist asking: does relinquishing copyright of a work to
the "Free Software Foundation" a "nonprofit with a worldwide
mission to promote computer user freedom" really say nothing
about what values one wishes to endorse?

Maybe. ¯\_(ツ)_/¯ I'm happy to clarify that it did, _for me_, and
that's how I meant it.  No idea why others did or didn't do that.

João Távora

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 9 May 2020 14:51:18 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> I don't resist asking: does relinquishing copyright of a work to
> the "Free Software Foundation" a "nonprofit with a worldwide
> mission to promote computer user freedom" really say nothing
> about what values one wishes to endorse?

It says only what is in the contract that we sign.  Nothing else.

Btw, the contract doesn't only say that you assign the copyright to
the FSF, it also says that the FSF assigns the copyright back to you,
so the original author can still distribute the code as much as he or
she wants and on what terms that he or she wants, regardless and
independently of what the FSF does with the code whose copyright was
assigned.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 3:00 PM Eli Zaretskii <eliz@gnu.org> wrote:

> Btw, the contract doesn't only say that you assign the copyright to
> the FSF, it also says that the FSF assigns the copyright back to you,
> so the original author can still distribute the code as much as he or
> she wants and on what terms that he or she wants, regardless and
> independently of what the FSF does with the code whose copyright was
> assigned.

Thank you for the clarification.  I didn't read it or don't remember it.
And I signed it because I thought I was advancing the FSF's goals.
But now I went and read it.  My assignment from 2012 thanks
me for my contribution,  emphatically.  But indeed it does not say
I support this or that cause.

I guess all I'm saying I wouldn't voluntarily "contribute" to the
Freedom-denying Software Foundation, is all.

João

Re: Drop the Copyright Assignment requirement for Emacs

[Alfred M. Szmidt]

   I don't resist asking: does relinquishing copyright of a work to
   the "Free Software Foundation" a "nonprofit with a worldwide
   mission to promote computer user freedom" really say nothing
   about what values one wishes to endorse?

Those are the values the FSF promotes, not the person assigning their
copyright to the FSF.  They also do not "relinquishing" their rights;
after signing a copyright assignment you still can use the code you
wrote as you see fit, even license it under a non-free license.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 3:17 PM Alfred M. Szmidt <ams@gnu.org> wrote:
>
>    I don't resist asking: does relinquishing copyright of a work to
>    the "Free Software Foundation" a "nonprofit with a worldwide
>    mission to promote computer user freedom" really say nothing
>    about what values one wishes to endorse?
>
> Those are the values the FSF promotes, not the person assigning their
> copyright to the FSF.  They also do not "relinquishing" their rights;
> after signing a copyright assignment you still can use the code you
> wrote as you see fit, even license it under a non-free license.

I'm not a lawyer.  It would seem from my layman's standpoint that
I performed a voluntary action that helped some other entity in
the world.  I could have chosen not to, but I didn't, and that matters.

João

PS: it also says the FSF owes me a dollar! Where is it? :-)

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> I don't resist asking: does relinquishing copyright of a work to
> the "Free Software Foundation" a "nonprofit with a worldwide
> mission to promote computer user freedom" really say nothing
> about what values one wishes to endorse?

For me (and I suspect others) it was like this: I see something I'd
like to change in Emacs and I want to contribute. I take the time to
write a patch and I want to send, then I'm told I cannot send it until
I sign these papers. This annoys me, the papers looks pretty
fear-based and everywhere else open source I just send a patch and I'm
done. Those other open source entities don't seem to have legal
problems. Also it's not just something where I sign online and click
and I'm done, I have to print, sign, scan and send by email. This
delay my patch sending several months until finally my thirst of
wanting this patch in is too strong and I bother with the assignments.

Re: Drop the Copyright Assignment requirement for Emacs

[조성빈]

> 2020. 5. 9. 오후 11:22, Philippe Vaucher <philippe.vaucher@gmail.com> 작성:
> 
> 
>> 
>> I don't resist asking: does relinquishing copyright of a work to
>> the "Free Software Foundation" a "nonprofit with a worldwide
>> mission to promote computer user freedom" really say nothing
>> about what values one wishes to endorse?
> 
> For me (and I suspect others) it was like this: I see something I'd
> like to change in Emacs and I want to contribute. I take the time to
> write a patch and I want to send, then I'm told I cannot send it until
> I sign these papers. This annoys me, the papers looks pretty
> fear-based and everywhere else open source I just send a patch and I'm
> done. Those other open source entities don't seem to have legal
> problems. Also it's not just something where I sign online and click
> and I'm done, I have to print, sign, scan and send by email. This
> delay my patch sending several months until finally my thirst of
> wanting this patch in is too strong and I bother with the assignments.

This was (and still is) my case too, FWIW. The friction to contribute to Emacs is pretty high, and one hurdle is the assignments. (Actually, it turns out assignment was only one hurdle out of many, which makes me have a few patches that I just apply when I compile emacs myself. I’m pretty sure a lot of people will be doing that. 

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Sat, 9 May 2020 16:20:55 +0200
> Cc: "Alfred M. Szmidt" <ams@gnu.org>, emacs-devel <emacs-devel@gnu.org>
> 
> For me (and I suspect others) it was like this: I see something I'd
> like to change in Emacs and I want to contribute. I take the time to
> write a patch and I want to send, then I'm told I cannot send it until
> I sign these papers. This annoys me, the papers looks pretty
> fear-based and everywhere else open source I just send a patch and I'm
> done. Those other open source entities don't seem to have legal
> problems. Also it's not just something where I sign online and click
> and I'm done, I have to print, sign, scan and send by email.

Assigning the copyright for significant contributions is a basic
requirement of all main GNU projects: GCC, Binutils, glibc, GDB, Bash,
Make, Emacs, Coreutils, Grep, Guile, and many others.  It doesn't
matter whether we feel good or bad about it, it doesn't matter whether
we like it or not.  The FSF wants to protect its baby the GNU Project
against hostile litigation and infringements, and the FSF lawyers say
the assignment is necessary to be able to take the violating parties
to the court of law and have any standing there.

So it is futile to fight against this, as the FSF will not change its
position.  Please keep in mind that we don't _own_ these projects, we
just contribute to them.  We cannot dictate the project owners how to
manage their projects.  We can only fork them and maintain the fork on
our own (not that I want to encourage anyone to fork Emacs).  Or we
can sign that one-time paper.  Or we can disagree and refrain from
contributing.  But trying to change FSF's mind is a waste of breath.

> This delay my patch sending several months until finally my thirst
> of wanting this patch in is too strong and I bother with the
> assignments.

Indeed, assigning copyright only makes sense if you intend to continue
contributing in the future.  It is a one-time effort ("annoyance", if
you wish), and then you are done.

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> > For me (and I suspect others) it was like this: I see something I'd
> > like to change in Emacs and I want to contribute. I take the time to
> > write a patch and I want to send, then I'm told I cannot send it until
> > I sign these papers. This annoys me, the papers looks pretty
> > fear-based and everywhere else open source I just send a patch and I'm
> > done. Those other open source entities don't seem to have legal
> > problems. Also it's not just something where I sign online and click
> > and I'm done, I have to print, sign, scan and send by email.
>
> Assigning the copyright for significant contributions is a basic
> requirement of all main GNU projects: GCC, Binutils, glibc, GDB, Bash,
> Make, Emacs, Coreutils, Grep, Guile, and many others.  It doesn't
> matter whether we feel good or bad about it, it doesn't matter whether
> we like it or not.  The FSF wants to protect its baby the GNU Project
> against hostile litigation and infringements, and the FSF lawyers say
> the assignment is necessary to be able to take the violating parties
> to the court of law and have any standing there.

Yes, I agree.


> So it is futile to fight against this, as the FSF will not change its
> position.  Please keep in mind that we don't _own_ these projects, we
> just contribute to them.  We cannot dictate the project owners how to
> manage their projects.  We can only fork them and maintain the fork on
> our own (not that I want to encourage anyone to fork Emacs).  Or we
> can sign that one-time paper.  Or we can disagree and refrain from
> contributing.  But trying to change FSF's mind is a waste of breath.

I take your word from it, but I still think it's valuable to whine
every now & then to let them know we don't like this situation.

Now maybe we'd whine to them directly instead of here, that I'd agree.
Somehow I expect my whining to be reported to them which is not very
reasonable.

Re: Drop the Copyright Assignment requirement for Emacs

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>            Please keep in mind that we don't _own_ these projects, we
> just contribute to them.  We cannot dictate the project owners how to
> manage their projects.

I sincerely hope that my previous post in this matter was not seen as
dictating.  If so, I failed at communicating my ideas quite badly.

> But trying to change FSF's mind is a waste of breath.

Maybe the FSF will change their mind in the future, maybe not.
We are being told it's down to the lawyers.

In any case, I'm happy to focus on more productive discussions.

Best regards,
Stefan Kangas

Re: Drop the Copyright Assignment requirement for Emacs

[Alfred M. Szmidt]

   The FSF wants to protect its baby the GNU Project [...]

The parent is older than its child.  :-)

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 6:35 PM Alfred M. Szmidt <ams@gnu.org> wrote:
>    The FSF wants to protect its baby the GNU Project [...]
> The parent is older than its child.  :-)

I think you meant that the other way round, right?

João

Re: Drop the Copyright Assignment requirement for Emacs

[Alfred M. Szmidt]

   >    The FSF wants to protect its baby the GNU Project [...]
   > The parent is older than its child.  :-)

   I think you meant that the other way round, right?

I don't think that is how things work.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

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

On Sat, May 9, 2020 at 6:49 PM Alfred M. Szmidt <ams@gnu.org> wrote:

>    >    The FSF wants to protect its baby the GNU Project [...]
>    > The parent is older than its child.  :-)
>
>    I think you meant that the other way round, right?
>
> I don't think that is how things work.
>

They certainly don't Alfred, but the FSF is younger than the
GNU Project re: foundation dates. So the FSF would be protecting
its baby that is actually older than the parent. I thought you trying
to crack a joke about that.  Don't mind me.

João

[-- Attachment #2: Type: text/html, Size: 946 bytes --]

Re: Drop the Copyright Assignment requirement for Emacs

[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 announced GNU in Oct 1983 and launched the FSF to support and
facilitate the GNU Project in Oct 1985.

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

Re: Drop the Copyright Assignment requirement for Emacs

[조성빈]

> 2020. 5. 9. 오후 10:52, João Távora <joaotavora@gmail.com> 작성:
> 
> On Sat, May 9, 2020 at 2:35 PM Alfred M. Szmidt <ams@gnu.org> wrote:
>>> Finally, above practical aspects, assigning copyright is declaring
>>> support for an idea larger than the FSF itself.  It's a political
>>> declaration.
>>   Could someone officially confirm or deny the above paragraph?
>> It is very much false.  By assigning your copyright to the FSF you do
>> just that and nothing else, it says nothing about what values you hold
>> or wish to endorse.
> 
> I don't resist asking: does relinquishing copyright of a work to
> the "Free Software Foundation" a "nonprofit with a worldwide
> mission to promote computer user freedom" really say nothing
> about what values one wishes to endorse?

Well, to improve Emacs maybe? I have pretty strong (negative) arguments about the FSF, but I found out I had to sign the papers so I signed it. I hope it doesn’t get interpreted this way...

> Maybe. ¯\_(ツ)_/¯ I'm happy to clarify that it did, _for me_, and
> that's how I meant it.  No idea why others did or didn't do that.
> 
> João Távora
> 

Re: Drop the Copyright Assignment requirement for Emacs

[Fu Yuan]

As Eli said, signing the assignment doesn’t say anything about your stance legally. How do you interpret it personally is your freedom. But does buying proprietary software indicate your support of it? I doubt it. Likewise submitting patches shouldn’t be interpreted as a personal stance supporting either FSF or free software.

Sincerely, Yuan

> 在 2020年5月9日，上午10:36，조성빈 <pcr910303@icloud.com> 写道：
> 
> 
>> 2020. 5. 9. 오후 10:52, João Távora <joaotavora@gmail.com> 작성:
>> 
>> On Sat, May 9, 2020 at 2:35 PM Alfred M. Szmidt <ams@gnu.org> wrote:
>>>> Finally, above practical aspects, assigning copyright is declaring
>>>> support for an idea larger than the FSF itself.  It's a political
>>>> declaration.
>>>  Could someone officially confirm or deny the above paragraph?
>>> It is very much false.  By assigning your copyright to the FSF you do
>>> just that and nothing else, it says nothing about what values you hold
>>> or wish to endorse.
>> 
>> I don't resist asking: does relinquishing copyright of a work to
>> the "Free Software Foundation" a "nonprofit with a worldwide
>> mission to promote computer user freedom" really say nothing
>> about what values one wishes to endorse?
> 
> Well, to improve Emacs maybe? I have pretty strong (negative) arguments about the FSF, but I found out I had to sign the papers so I signed it. I hope it doesn’t get interpreted this way...
> 
>> Maybe. ¯\_(ツ)_/¯ I'm happy to clarify that it did, _for me_, and
>> that's how I meant it.  No idea why others did or didn't do that.
>> 
>> João Távora
>> 
> 

Re: Drop the Copyright Assignment requirement for Emacs

[Marcin Borkowski]

On 2020-05-09, at 15:51, João Távora <joaotavora@gmail.com> wrote:

> On Sat, May 9, 2020 at 2:35 PM Alfred M. Szmidt <ams@gnu.org> wrote:
>>    > Finally, above practical aspects, assigning copyright is declaring
>>    > support for an idea larger than the FSF itself.  It's a political
>>    > declaration.
>>    Could someone officially confirm or deny the above paragraph?
>> It is very much false.  By assigning your copyright to the FSF you do
>> just that and nothing else, it says nothing about what values you hold
>> or wish to endorse.
>
> I don't resist asking: does relinquishing copyright of a work to
> the "Free Software Foundation" a "nonprofit with a worldwide
> mission to promote computer user freedom" really say nothing
> about what values one wishes to endorse?

No, not necessarily.  As I said, I consider Emacs an extremely useful
tool, I may even feel indebted to the Emacs community (whatever this
expression means), and I agree with _some_ of the values of RMS/FSF, but
_definitely_ not with all of them.

> Maybe. ¯\_(ツ)_/¯ I'm happy to clarify that it did, _for me_, and
> that's how I meant it.  No idea why others did or didn't do that.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: Drop the Copyright Assignment requirement for Emacs

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

  > > Finally, above practical aspects, assigning copyright is declaring
  > > support for an idea larger than the FSF itself.  It's a political
  > > declaration.

  > Could someone officially confirm or deny the above paragraph?

The copyright assignment is not a political statement.  Contributors
to the GNU Project do not have to agree with the free software movement
(although we hope they will), and certainly not with my personal views.

Ridicule is a powerful weapon, so I urge you not to discourage people
from using it against companies that attack freedom.  We shouldn't
have to argue with one mouth tied behind our backs.  But contributing
to GNU software doesn't state an opinion about that.


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

Re: Drop the Copyright Assignment requirement for Emacs

[Marcin Borkowski]

On 2020-05-10, at 04:29, Richard Stallman <rms@gnu.org> wrote:

> [[[ 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. ]]]
>
>   > > Finally, above practical aspects, assigning copyright is declaring
>   > > support for an idea larger than the FSF itself.  It's a political
>   > > declaration.
>
>   > Could someone officially confirm or deny the above paragraph?
>
> The copyright assignment is not a political statement.  Contributors
> to the GNU Project do not have to agree with the free software movement
> (although we hope they will), and certainly not with my personal views.

Thanks.  This is what I thought, and João's opinion made me nervous.

> Ridicule is a powerful weapon, so I urge you not to discourage people
> from using it against companies that attack freedom.  We shouldn't

I agree in principle.  I even usually avoid ridicule on the premise that
it is /too/ powerful a weapon, and too cruel against people.  But saying
"Kindle Swindle" does not sound as ridicule - to me, it sounds as
whining.

It might be a cultural thing.  Maybe Americans do not react this way,
I don't know.

> have to argue with one mouth tied behind our backs.  But contributing
> to GNU software doesn't state an opinion about that.

Understood, thanks.

--
Marcin Borkowski
http://mbork.pl

Re: Drop the Copyright Assignment requirement for Emacs

[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 saying
  > "Kindle Swindle" does not sound as ridicule - to me, it sounds as
  > whining.

Maybe we need to attach more anger and condemnation to it.

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

Amazon

[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 would propose the FSF extended its solidarity to the on-going
  > struggles of Amazon workers.  Here is an article describing a strike on
  > May 1st this year:

  > https://www.wired.com/story/amazon-instacart-target-coronavirus-may-day-strike/

I condemn Amazon for mistreating its workers, and I said so on my
personal site.  I state views on many political issues.

But the FSF, and the GNU Project, limit their political positions to
very few issues.  It is neutral on all other issues.  That strike is
outside our domain of having views.

If Amazon treated its workers decently, I would still condemn Amazon
and urge people not to do business with it, for a host of other
reasons.  See stallman.org/amazon.html for a list, if you have time on
your hands.

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

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 09.05.2020 12:48, João Távora wrote:
> Eglot, the LSP package, is in that situation: it is in ELPA but is
> developed  on Github for now and ,there it has gathered contributors
> whom I ask for copyright assignments, GNU-style commits, etc.
> Soon, we'll discuss its integration into the core, and if it works out,
> I'll want to keep it in GNU ELPA as a :core packge.

I don't understand: it's trivial to M-x install-package eglot. Why do we 
need to add it to Emacs proper? Simply having it inside the distribution 
won't make it more discoverable anyway.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 4:22 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 09.05.2020 12:48, João Távora wrote:
> > Eglot, the LSP package, is in that situation: it is in ELPA but is
> > developed  on Github for now and ,there it has gathered contributors
> > whom I ask for copyright assignments, GNU-style commits, etc.
> > Soon, we'll discuss its integration into the core, and if it works out,
> > I'll want to keep it in GNU ELPA as a :core packge.
>
> I don't understand: it's trivial to M-x install-package eglot. Why do we
> need to add it to Emacs proper? Simply having it inside the distribution
> won't make it more discoverable anyway.

It's not for discoverability.  It's, among other reasons, so that major modes
can adding to Eglot's hooks, for example.  Or that someday font-locking and
or indentation can be done via the LSP server.  I think Eli has indicated
that LSP support in the core is desirable at some point, and this would
be a step in that direction, I think.

João

PL support (was: Drop the Copyright Assignment requirement for Emacs)

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 9 May 2020 16:25:36 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> I think Eli has indicated that LSP support in the core is desirable
> at some point

Not only desirable: long overdue.  Emacs must learn to use the latest
technologies of supporting programming languages based on real
parsing, because the time when it could be done with regular
expressions and similar techniques has come and gone.  We cannot
enable significant new IDE-like features if we don't acquire these
technologies.

Please someone start working on this ASAP.  We sorely need that, just
look at the recent discussions on Reddit that underline these
deficiencies in Emacs.

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)

[Philippe Vaucher]

> > I think Eli has indicated that LSP support in the core is desirable
> > at some point
>
> Not only desirable: long overdue.  Emacs must learn to use the latest
> technologies of supporting programming languages based on real
> parsing, because the time when it could be done with regular
> expressions and similar techniques has come and gone.  We cannot
> enable significant new IDE-like features if we don't acquire these
> technologies.
>
> Please someone start working on this ASAP.  We sorely need that, just
> look at the recent discussions on Reddit that underline these
> deficiencies in Emacs.

Sorry to sound like captain obvious, but shouldn't we contact the
people at https://github.com/emacs-lsp/lsp-mode and work with them on
this? Maybe that's already the case? I know there are also other
repositories with more or less the same goal.

Re: PL support

[David Engster]

>> > I think Eli has indicated that LSP support in the core is desirable
>> > at some point
>>
>
>> Not only desirable: long overdue.  Emacs must learn to use the latest
>> technologies of supporting programming languages based on real
>> parsing, because the time when it could be done with regular
>> expressions and similar techniques has come and gone.  We cannot
>> enable significant new IDE-like features if we don't acquire these
>> technologies.
>>
>> Please someone start working on this ASAP.  We sorely need that, just
>> look at the recent discussions on Reddit that underline these
>> deficiencies in Emacs.
>
> Sorry to sound like captain obvious, but shouldn't we contact the
> people at https://github.com/emacs-lsp/lsp-mode and work with them on
> this? Maybe that's already the case? I know there are also other
> repositories with more or less the same goal.

The emacs-lsp people discussed this, see here

  https://github.com/emacs-lsp/lsp-mode/issues/83

Issue was closed with

  After we started using dash/f/s this is no longer possible. Also, eglot
  is in the core.

-David

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Sat, 9 May 2020 17:39:13 +0200
> Cc: João Távora <joaotavora@gmail.com>, 
> 	Emacs developers <emacs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Dmitry Gutov <dgutov@yandex.ru>
> 
> > Please someone start working on this ASAP.  We sorely need that, just
> > look at the recent discussions on Reddit that underline these
> > deficiencies in Emacs.
> 
> Sorry to sound like captain obvious, but shouldn't we contact the
> people at https://github.com/emacs-lsp/lsp-mode and work with them on
> this?

Who is "we"?  And what does "work with them" mean in this case?

Re: PL support

[Dmitry Gutov]

On 09.05.2020 18:39, Philippe Vaucher wrote:
> Sorry to sound like captain obvious, but shouldn't we contact the
> people athttps://github.com/emacs-lsp/lsp-mode  and work with them on
> this? Maybe that's already the case? I know there are also other
> repositories with more or less the same goal.

Adding it to Emacs doesn't look feasible, but we should collaborate 
anyway. For example, to make sure that using lsp-mode with Emacs doesn't 
become harder in the future.

It's a shame, though. With lsp-ui, they have created some interesting 
new UI elements that we could benefit from.

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)

[João Távora]

On Sat, May 9, 2020 at 4:39 PM Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
>
> > > I think Eli has indicated that LSP support in the core is desirable
> > > at some point
> >
> > Not only desirable: long overdue.  Emacs must learn to use the latest
> > technologies of supporting programming languages based on real
> > parsing, because the time when it could be done with regular
> > expressions and similar techniques has come and gone.  We cannot
> > enable significant new IDE-like features if we don't acquire these
> > technologies.
> >
> > Please someone start working on this ASAP.  We sorely need that, just
> > look at the recent discussions on Reddit that underline these
> > deficiencies in Emacs.
>
> Sorry to sound like captain obvious, but shouldn't we contact the
> people at https://github.com/emacs-lsp/lsp-mode and work with them on
> this? Maybe that's already the case? I know there are also other
> repositories with more or less the same goal.

If I'm not mistaken, at some point the goal of lsp-mode previous
mantainer Vibhav Pant was to eventually enter GNU Elpa, but I
think that goal has been abandoned.

In contrast, Eglot's goal has always been that.  This is why I
collect copyrights and sure to work only with GNU Elpa libraries.

João

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)

[Daniel Colascione]

On May 9, 2020 8:35:25 AM Eli Zaretskii <eliz@gnu.org> wrote:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Sat, 9 May 2020 16:25:36 +0100
>> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>,
>> emacs-devel <emacs-devel@gnu.org>
>>
>> I think Eli has indicated that LSP support in the core is desirable
>> at some point
>
> Not only desirable: long overdue.  Emacs must learn to use the latest
> technologies of supporting programming languages based on real
> parsing, because the time when it could be done with regular
> expressions and similar techniques has come and gone.  We cannot
> enable significant new IDE-like features if we don't acquire these
> technologies.
>
> Please someone start working on this ASAP.  We sorely need that, just
> look at the recent discussions on Reddit that underline these
> deficiencies in Emacs.


It's a hard problem. A mode based on a real parser must be fast, 
incremental, and robust against transient errors that arise in the normal 
course of editing. We'd also want the ability to parse complex languages 
(far beyond LALR) and incorporate out-of-band information in order to 
resolve semantic ambiguities --- e.g. the C++ template problem. On top of 
all that, the parser would need to be highly malleable to make it easy to 
adjust to slight differences in dialect as well as deal with multiple 
languages in a buffer.

I've given the subject a bit of thought. One line of investigation 
consisted of doing GLR parses of each buffer, producing parse forests, and 
disambiguating the parse forests using semantic rules. The nice thing about 
GLR parsers is that they're closed under composition, so you can build 
arbitrary multi-modes. But this approach is, well, complicated. I'm not 
sure whether anyone's done it, even in research. (But I haven't searched 
the literature lately.) Robustness in the face of errors could be helped by 
something like  
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.21.6885&rep=rep1&type=pdf


One nice thing about using formal grammars is that you can analyze and 
transform them, e.g., using the autobracket transform in the previous 
paper, or even doing automatic semantic autocompletion.

A much simpler approach I've also had in mind is providing a C-assisted 
incremental parser combinators facility to Lisp --- something like the 
venerable pyparsing. Parser combinators make it pretty easy to incorporate 
error recovery rules, and the C code can use approaches like current 
syntax-ppss to keep the parse up to date and maintain, cheaply, an AST.

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> CC: <emacs-devel@gnu.org>, <monnier@iro.umontreal.ca>, <dgutov@yandex.ru>
> Date: Sat, 09 May 2020 08:50:45 -0700
> 
> > Please someone start working on this ASAP.  We sorely need that, just
> > look at the recent discussions on Reddit that underline these
> > deficiencies in Emacs.
> 
> It's a hard problem. A mode based on a real parser must be fast, 
> incremental, and robust against transient errors that arise in the normal 
> course of editing.

I agree.  But other IDE's have the same problem, don't they?  And
AFAIU incremental parsers such as tree-sitter are explicitly targeting
such use patterns, and their documentation says they are tolerant to
temporarily incorrect source.

> We'd also want the ability to parse complex languages 
> (far beyond LALR) and incorporate out-of-band information in order to 
> resolve semantic ambiguities --- e.g. the C++ template problem. On top of 
> all that, the parser would need to be highly malleable to make it easy to 
> adjust to slight differences in dialect as well as deal with multiple 
> languages in a buffer.

AFAICT, tree-sitter supports many languages already.  I know less
about LSP, but I'm guessing they are not very far of that, either.

> A much simpler approach I've also had in mind is providing a C-assisted 
> incremental parser combinators facility to Lisp --- something like the 
> venerable pyparsing. Parser combinators make it pretty easy to incorporate 
> error recovery rules, and the C code can use approaches like current 
> syntax-ppss to keep the parse up to date and maintain, cheaply, an AST.

I'm sure more than one alternative exist, and maybe we should support
more than one.

Thanks.

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)

[João Távora]

On Sat, May 9, 2020 at 5:02 PM Eli Zaretskii <eliz@gnu.org> wrote:

> AFAICT, tree-sitter supports many languages already.  I know less
> about LSP, but I'm guessing they are not very far of that, either.

Just to note that LSP by itself, doesn't do any parsing.  It is just a
a protocol for editors and "language servers" to exchange information
about source in a standard fashion.  For all we know, the LSP server
can be using tree-sitter itself.

Even Emacs can become an LSP server and serve its 40-year old
hard earned intelligence  in many language to the world.  I think Richard
once supported this idea. There's a jsonrpc.el library in the core that
could make it easier to do that.

João

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 9 May 2020 17:08:21 +0100
> Cc: Daniel Colascione <dancol@dancol.org>, emacs-devel <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Dmitry Gutov <dgutov@yandex.ru>
> 
> On Sat, May 9, 2020 at 5:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > AFAICT, tree-sitter supports many languages already.  I know less
> > about LSP, but I'm guessing they are not very far of that, either.
> 
> Just to note that LSP by itself, doesn't do any parsing.  It is just a
> a protocol for editors and "language servers" to exchange information
> about source in a standard fashion.  For all we know, the LSP server
> can be using tree-sitter itself.

Yes, I meant LSP servers.  Sorry for sloppy wording.

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)

[Daniel Colascione]

On May 9, 2020 9:02:43 AM Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Daniel Colascione <dancol@dancol.org>
>> CC: <emacs-devel@gnu.org>, <monnier@iro.umontreal.ca>, <dgutov@yandex.ru>
>> Date: Sat, 09 May 2020 08:50:45 -0700
>>
>>> Please someone start working on this ASAP.  We sorely need that, just
>>> look at the recent discussions on Reddit that underline these
>>> deficiencies in Emacs.
>>
>> It's a hard problem. A mode based on a real parser must be fast,
>> incremental, and robust against transient errors that arise in the normal
>> course of editing.
>
> I agree.  But other IDE's have the same problem, don't they?  And
> AFAIU incremental parsers such as tree-sitter are explicitly targeting
> such use patterns, and their documentation says they are tolerant to
> temporarily incorrect source.

They do have this problem, and they usually address it with hand written 
fix-up and glue code. (See the IntelliJ family.) I really want modes (and 
multi-modes) driven entirely by declarative (and customizable!) grammars 
--- with everything else figured out automatically. Maybe this goal isn't 
practical and we should start with the parser combinator C acceleration.


>
>
>> We'd also want the ability to parse complex languages
>> (far beyond LALR) and incorporate out-of-band information in order to
>> resolve semantic ambiguities --- e.g. the C++ template problem. On top of
>> all that, the parser would need to be highly malleable to make it easy to
>> adjust to slight differences in dialect as well as deal with multiple
>> languages in a buffer.
>
> AFAICT, tree-sitter supports many languages already.  I know less
> about LSP, but I'm guessing they are not very far of that, either.
>
>> A much simpler approach I've also had in mind is providing a C-assisted
>> incremental parser combinators facility to Lisp --- something like the
>> venerable pyparsing. Parser combinators make it pretty easy to incorporate
>> error recovery rules, and the C code can use approaches like current
>> syntax-ppss to keep the parse up to date and maintain, cheaply, an AST.
>
> I'm sure more than one alternative exist, and maybe we should support
> more than one.
>
> Thanks.

Re: PL support

[Stefan Monnier]

> They do have this problem, and they usually address it with hand written
> fix-up and glue code. (See the IntelliJ family.) I really want modes (and 
> multi-modes) driven entirely by declarative (and customizable!) grammars ---

tree-sitter is basically doing just that.
LSP is different because it usually goes further than just the grammar,
providing information based on scoping and typing rules rules.

Type checking is much less standardized than parsing.  For parsing we
know that a GLR engine should be able to handle the vast majority of
circumstances fairly efficiently.  For type checking every compiler
implements basically its own approach by hand, and the algorithms and
data-structures can be fairly different between a C++ compiler, a Rust
compiler, and a Haskell compiler (and while parsing-time is usually
negligible and linear in complexity, time to perform type checking is
something at which engineering efforts are throw to keep it in check
because it can blow up in complexity).

So, I think the current state of the art is pretty far from knowing what
would be a good *declarative* specification of typing rules for use by
a generic tool providing the same kind of functionality as LSP servers.


        Stefan


PS: We do know fairly well how to specify typing rules declaratively on
    paper (where efficiency is not a concern), tho, so there's hope.

Re: PL support

[Dmitry Gutov]

On 09.05.2020 18:34, Eli Zaretskii wrote:
> Not only desirable: long overdue.  Emacs must learn to use the latest
> technologies of supporting programming languages based on real
> parsing, because the time when it could be done with regular
> expressions and similar techniques has come and gone.  We cannot
> enable significant new IDE-like features if we don't acquire these
> technologies.

Cannot enable what? Eglot is in ELPA. Have you tried it?

> Please someone start working on this ASAP.  We sorely need that, just
> look at the recent discussions on Reddit that underline these
> deficiencies in Emacs.

None of these discussions say "oh, if only Eglot was in the core instead 
of GNU ELPA, that would solve my problems". I haven't seen a single 
opinion like that.

So maybe you could point out a specific issues or set of problems, and 
we could discus whether each particular one would be fixed by moving 
Eglot to the core, or simply improving Eglot, or by some other means.

Adding some integration in Emacs that wouldn't import Eglot but would 
increase its discoverability is also an option, and a worthy goal IMO.

Re: PL support

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 9 May 2020 18:53:10 +0300
> 
> Cannot enable what?

Font-lock and indentation based on those capabilities, for one.

> Eglot is in ELPA. Have you tried it?

No.  Not enough time, sorry.

> > Please someone start working on this ASAP.  We sorely need that, just
> > look at the recent discussions on Reddit that underline these
> > deficiencies in Emacs.
> 
> None of these discussions say "oh, if only Eglot was in the core instead 
> of GNU ELPA, that would solve my problems". I haven't seen a single 
> opinion like that.

I said nothing about moving Eglot to the core.  It was João, not
myself.  I'd be happy if we could have these capabilities that
depended on Eglot (or any other package, really) being installed.  We
could figure out the rest later.

Re: PL support

[João Távora]

On Sat, May 9, 2020 at 5:06 PM Eli Zaretskii <eliz@gnu.org> wrote:

> I said nothing about moving Eglot to the core.  It was João, not
> myself.  I'd be happy if we could have these capabilities that
> depended on Eglot (or any other package, really) being installed.  We
> could figure out the rest later.

You said you'd like to see "more of Eglot's LSP support" in the core, two
years ago:

   https://lists.gnu.org/archive/html/emacs-devel/2018-05/msg00419.html

At the time, I tore off a big chunk of it, jsonrpc.el to put in the core, and
and made it a :core package. I'm opening to tearing eglot.el gain, i.e. to
extract again, say an lsp.el and make that a :core thing.  This would
advance the "LSP in Emacs" goal. On thing that would fit that fill is a
set of Elisp macros that allow for compile-time and run-time checking
of LSP messages, among other LSP-specific but interface-agnostic
details.

Shall I start working on that?

Eventually though, eglot.el will become pretty thin, be dilluted in Emacs,
maybe disappear completely. I have no problems with that.

João

Re: PL support

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 9 May 2020 17:30:58 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> On Sat, May 9, 2020 at 5:06 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I said nothing about moving Eglot to the core.  It was João, not
> > myself.  I'd be happy if we could have these capabilities that
> > depended on Eglot (or any other package, really) being installed.  We
> > could figure out the rest later.
> 
> You said you'd like to see "more of Eglot's LSP support" in the core, two
> years ago:
> 
>    https://lists.gnu.org/archive/html/emacs-devel/2018-05/msg00419.html

I very much doubt Dmitry was replying to that 2-year old message.  He
was replying to what I said today.

> At the time, I tore off a big chunk of it, jsonrpc.el to put in the core, and
> and made it a :core package. I'm opening to tearing eglot.el gain, i.e. to
> extract again, say an lsp.el and make that a :core thing.  This would
> advance the "LSP in Emacs" goal. On thing that would fit that fill is a
> set of Elisp macros that allow for compile-time and run-time checking
> of LSP messages, among other LSP-specific but interface-agnostic
> details.
> 
> Shall I start working on that?

What I'd like to see is a way to switch language-specific features in
CC Mode to LSP or some other similar facility.  Assuming that doing so
will make CC Mode faster and more accurate, that is.

If you (and/or someone else) can start working on that, please do, and
thanks in advance.  I presume that we are still a long way from that
goal, but if I'm mistaken, so much the better.

Re: PL support

[João Távora]

On Sat, May 9, 2020 at 5:38 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > You said you'd like to see "more of Eglot's LSP support" in the core, two
> > years ago:
> >
> >    https://lists.gnu.org/archive/html/emacs-devel/2018-05/msg00419.html
>
> I very much doubt Dmitry was replying to that 2-year old message.  He
> was replying to what I said today.

I didn't say he was. I just pasted the message to give you context
about what my perception of the plan was.

> > set of Elisp macros that allow for compile-time and run-time checking
> > of LSP messages, among other LSP-specific but interface-agnostic
> > details.
> >
> > Shall I start working on that?
>
> What I'd like to see is a way to switch language-specific features in
> CC Mode to LSP or some other similar facility.

I was only speaking of the LSP facility.  If you have reasons to think
that tree-sitter completely obviates the need for LSP in Emacs (I don't),
then you should let me know to prevent me from doing unnecessary work.

> Assuming that doing so
> will make CC Mode faster and more accurate, that is.

Be aware that that depends on an external server program, and I we
don't control that now and likely for some time. Also be aware
syntax-highlighting support is still being finished in the protocol (but so
close to it that  LSP's maintainer said days ago they are "in endgame").

Now, I have to address what I believe is a misperception of how LSP
can work in Emacs.  eglot.el delivers a minor mode that works
independently of the major mode.  In contrast to lsp-mode.el, there
is no language-specific code in eglot.el (apart from 2 minor exceptions
which we'll soon dispose of). Anyway the only thing that eglot/LSP
can do for cc-mode.el specifically is ask it to define the file-name of a
preferred language server program and enable eglot-managed-mode
by default.  Nothing more. Then we have to work on eglot.el (or
wherever the choice befalls) to start supporting the syntax
highlighting features whereby font-locking information are
gathered from the server.   Since exchanging information about
source-file changes is largely a solved problem, as soon as servers
start declaring support the new syntax highlighting extensions, it's
is a question of applying the text properties in an efficient manner.

Anyway, it is is because of this loose coupling that Dmitry says
that Eglot could live "forever" outside of the core.  And it's mostly
true.  But I do believe that if it were in the core (like if company.el
or an equivalent library was in the core) that would help even
more CC Mode users (or Foo Mode users) discover LSP's advantages,
especially if Emacs also started distributing an LSP server program
for C or FOO.

João

Re: PL support

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 9 May 2020 18:08:52 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> > What I'd like to see is a way to switch language-specific features in
> > CC Mode to LSP or some other similar facility.
> 
> I was only speaking of the LSP facility.  If you have reasons to think
> that tree-sitter completely obviates the need for LSP in Emacs (I don't),
> then you should let me know to prevent me from doing unnecessary work.

I didn't mention tree-sitter in my message.  So why are you talking
about it?

> > Assuming that doing so
> > will make CC Mode faster and more accurate, that is.
> 
> Be aware that that depends on an external server program, and I we
> don't control that now and likely for some time. Also be aware
> syntax-highlighting support is still being finished in the protocol (but so
> close to it that  LSP's maintainer said days ago they are "in endgame").
> 
> Now, I have to address what I believe is a misperception of how LSP
> can work in Emacs.  eglot.el delivers a minor mode that works
> independently of the major mode.  In contrast to lsp-mode.el, there
> is no language-specific code in eglot.el (apart from 2 minor exceptions
> which we'll soon dispose of). Anyway the only thing that eglot/LSP
> can do for cc-mode.el specifically is ask it to define the file-name of a
> preferred language server program and enable eglot-managed-mode
> by default.  Nothing more. Then we have to work on eglot.el (or
> wherever the choice befalls) to start supporting the syntax
> highlighting features whereby font-locking information are
> gathered from the server.   Since exchanging information about
> source-file changes is largely a solved problem, as soon as servers
> start declaring support the new syntax highlighting extensions, it's
> is a question of applying the text properties in an efficient manner.

I understand all this, albeit not on the same level of detail as you
do.  What I'm saying is that from my POV our goal is to go all the way
towards bringing this technology to major modes.  The instructions to
turn on this support should include everything that's needed:
installing packages, running the LSP server, customizing the major
mode, etc. etc. -- everything that's needed to have the mode run with
LSP as its backend for these language-dependent features.

IOW, just having a mode that can talk to the LSP server is good
progress, but it stops short of the goal I think we should target.

> Anyway, it is is because of this loose coupling that Dmitry says
> that Eglot could live "forever" outside of the core.  And it's mostly
> true.  But I do believe that if it were in the core (like if company.el
> or an equivalent library was in the core) that would help even
> more CC Mode users (or Foo Mode users) discover LSP's advantages,
> especially if Emacs also started distributing an LSP server program
> for C or FOO.

I'm aware of the controversy regarding what should be in core and what
should be left on ELPA.  Heck, I'm part of that controversy.  But I
don't think we will ever be able to come close to resolving it
regarding Eglot unless we have support for it in major modes ready to
be turned on.  Only then will people be able to try it, see if they
like it, and then have some real basis for opining whether it should
or shouldn't be in core.  IOW, the level of success in having the
related features beefed up using Eglot is IMO a very significant
factor in forming people's opinions about making it part of core.

Re: PL support

[João Távora]

On Sat, May 9, 2020 at 6:23 PM Eli Zaretskii <eliz@gnu.org> wrote:
> I didn't mention tree-sitter in my message.  So why are you talking
> about it?

Because you said "or similar facility".  I assumed it would be tree-sitter.

> I understand all this, albeit not on the same level of detail as you
> do.  What I'm saying is that from my POV our goal is to go all the way
> towards bringing this technology to major modes.  The instructions to
> turn on this support should include everything that's needed:
> installing packages, running the LSP server, customizing the major
> mode, etc. etc. -- everything that's needed to have the mode run with
> LSP as its backend for these language-dependent features.
>
> IOW, just having a mode that can talk to the LSP server is good
> progress, but it stops short of the goal I think we should target.

OK, sounds reasonable. In that case I put it to you that the best
way to make it happen is to import eglot.el into the core, help me
convince the maintainers of the major modes to add a few lines
to their code, and enhance eglot.el to automatically download
server programs.

We _can_ do this without importing eglot.el into the core, by
adding to hooks and having and/or having a few defvars and
maybe cl-defgeneric.  But adding it to the core is a simpler
way, IMO.  eglot.el is a single file library, by the way.

> > Anyway, it is is because of this loose coupling that Dmitry says
> > that Eglot could live "forever" outside of the core.  And it's mostly
> > true.  But I do believe that if it were in the core (like if company.el
> > or an equivalent library was in the core) that would help even
> > more CC Mode users (or Foo Mode users) discover LSP's advantages,
> > especially if Emacs also started distributing an LSP server program
> > for C or FOO.
> I'm aware of the controversy regarding what should be in core and what
> should be left on ELPA.  Heck, I'm part of that controversy.  But I
> don't think we will ever be able to come close to resolving it
> regarding Eglot unless we have support for it in major modes ready to
> be turned on.  Only then will people be able to try it, see if they
> like it, and then have some real basis for opining whether it should
> or shouldn't be in core.  IOW, the level of success in having the
> related features beefed up using Eglot is IMO a very significant
> factor in forming people's opinions about making it part of core.

I agree I think.  We that people like you try it  (and eventually contribute
to it, i.e. by fixing bugs, or pointing flaws) with little "pain".  I think
the easiest way is to do what I described above.

João

Re: PL support

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 9 May 2020 18:36:53 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> OK, sounds reasonable. In that case I put it to you that the best
> way to make it happen is to import eglot.el into the core, help me
> convince the maintainers of the major modes to add a few lines
> to their code, and enhance eglot.el to automatically download
> server programs.
> 
> We _can_ do this without importing eglot.el into the core, by
> adding to hooks and having and/or having a few defvars and
> maybe cl-defgeneric.  But adding it to the core is a simpler
> way, IMO.  eglot.el is a single file library, by the way.

You are probably right.  But Eglot is in ELPA for some time, and I
don't yet see a campaign to bring it into core; I do see some opinions
to the contrary.  So I think it will be much easier to convince more
people if we had this working.  I cannot be sure, of course, and you
will do the work, so it is still your call.

Or maybe we will have a flood of messages tomorrow saying they'd like
to have Eglot in core ;-)

Re: PL support

[Yuan Fu]

> On May 9, 2020, at 1:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: João Távora <joaotavora@gmail.com>
>> Date: Sat, 9 May 2020 18:36:53 +0100
>> Cc: Dmitry Gutov <dgutov@yandex.ru>, Stefan Monnier <monnier@iro.umontreal.ca>, 
>> 	emacs-devel <emacs-devel@gnu.org>
>> 
>> OK, sounds reasonable. In that case I put it to you that the best
>> way to make it happen is to import eglot.el into the core, help me
>> convince the maintainers of the major modes to add a few lines
>> to their code, and enhance eglot.el to automatically download
>> server programs.
>> 
>> We _can_ do this without importing eglot.el into the core, by
>> adding to hooks and having and/or having a few defvars and
>> maybe cl-defgeneric.  But adding it to the core is a simpler
>> way, IMO.  eglot.el is a single file library, by the way.
> 
> You are probably right.  But Eglot is in ELPA for some time, and I
> don't yet see a campaign to bring it into core; I do see some opinions
> to the contrary.  So I think it will be much easier to convince more
> people if we had this working.  I cannot be sure, of course, and you
> will do the work, so it is still your call.
> 
> Or maybe we will have a flood of messages tomorrow saying they'd like
> to have Eglot in core ;-)
> 

What advantage would splitting and “diluting” eglot into Emacs give tho? I think eglot works pretty well already, one just installs eglot and a server and everything works.

Yuan

Re: PL support

[João Távora]

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

On Sat, May 9, 2020 at 6:58 PM Yuan Fu <casouri@gmail.com> wrote:

>
> What advantage would splitting and “diluting” eglot into Emacs give tho? I
> think eglot works pretty well already, one just installs eglot and a server
> and everything works.


Not many immediate "killer" advantages, Yuan Fu, but:

- eglot.el would be simplified, tho maybe only slightly.  That is good.

- language specific quirks (that do exist despite LSP) would be dealt
  with in the corresponding mode, not Eglot, by using Eglot's
  existing interfaces.

- Eglot could grow _more_ programmatic interfaces for that
  to happen. It doesn't have them because it's the chicken and
  the egg.

- More importantly, many bugs that target Eglot's UI but are actually
  Emacs's would come here. Discussing them in Github and hailing (mostly)
  Stefan and Dmitry there works, sort of, but it would be better if we
used  the
  Emacs bug tracker (yes I know there are strong opinions on this).  But at
  the very least people like Eli and Richard would be able to participate
  regularly in those discussions, and provide insight that just doesn't
  reach the Github-sphere.

  The dev version of eglot would have always nicer integration with
  eldoc.el, flymake.el, xref.el, project.el, so it would become a much
  better program.  And it could still be distributed in GNU Elpa, for
  older versions of Emacs to use.

Let me give you an example: didn't your eglot-box thing end up being
an eldoc-box instead?  It should be in eldoc.el, it's a pretty good idea!
Well if eglot was in the core, you'd just automatically do it for eldoc.el
and  get help on how to do it from seasoned Elispers who hang around
here and not Github.

João

[-- Attachment #2: Type: text/html, Size: 2457 bytes --]

Re: PL support

[Dmitry Gutov]

On 09.05.2020 21:19, João Távora wrote:

> Not many immediate "killer" advantages, Yuan Fu, but:
> 
> - eglot.el would be simplified, tho maybe only slightly.  That is good.

Splitting a program would simplify it? I'm somewhat skeptical so far.

> - language specific quirks (that do exist despite LSP) would be dealt
>    with in the corresponding mode, not Eglot, by using Eglot's
>    existing interfaces.

That sounds fine, but then you'd have to convince major mode authors to 
set these settings. And educate them on what values they should use.

Considering you likely know more about C/C++ LSP servers than Alan, for 
example, that doesn't sound productive. And python-mode is 
unmaintained... js-mode hasn't seen a lot of dedicated development 
either. You get my drift.

> - Eglot could grow _more_ programmatic interfaces for that
>    to happen. It doesn't have them because it's the chicken and
>    the egg.

We'll have to discuss those.

> - More importantly, many bugs that target Eglot's UI but are actually
>    Emacs's would come here. Discussing them in Github and hailing (mostly)
>    Stefan and Dmitry there works, sort of, but it would be better if we 
> used  the
>    Emacs bug tracker (yes I know there are strong opinions on this).  But at
>    the very least people like Eli and Richard would be able to participate
>    regularly in those discussions, and provide insight that just doesn't
>    reach the Github-sphere.

Umm. As a person with a fairly opinionated approach to package 
development yourself, I think you might underestimate certain downsides 
in sharing this responsibility like that.

And it doesn't look like Eli and Richard have a lot of free time to get 
into the particulars, or fix Eglot's bugs. I don't either (so far).

> Let me give you an example: didn't your eglot-box thing end up being
> an eldoc-box instead?  It should be in eldoc.el, it's a pretty good idea!
> Well if eglot was in the core, you'd just automatically do it for eldoc.el
> and  get help on how to do it from seasoned Elispers who hang around
> here and not Github.

How would that help? Eldoc has a defined interface. If eglot-box could 
be based on that, it could just be considered for contribution on its own.

Re: PL support

[João Távora]

On Sat, May 9, 2020 at 7:44 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> How would that help? Eldoc has a defined interface. If eglot-box could
> be based on that, it could just be considered for contribution on its own.

A pretty bad one, as we know.  It's much better do deal with it in one
place, Emacs, rather then the user complaining to Eglot issue tracker
then I have to explain the problem or desired feature is in eldoc,
then agree on an interface betweent he two files.  In Emacs I just
submit a patch to both files and both maintainers look at it. The reason
fido-mode was so easy is that icomplete.el and minibuffer.el are in
the same repo.  I don't find this logic very hard to follow.

Rather what I find hard to follow is the "not in core" stance. It seems
like you want to protect lsp-mode mode, or not condemn it to
irrelevance.  That's perfectly fine, mind you: perfectly fine.  But
exactly how would Eglot in core hurt that?

João Távora

Re: PL support

[Dmitry Gutov]

On 09.05.2020 21:56, João Távora wrote:
> On Sat, May 9, 2020 at 7:44 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
>> How would that help? Eldoc has a defined interface. If eglot-box could
>> be based on that, it could just be considered for contribution on its own.
> 
> A pretty bad one, as we know.

So? Make it better. Having Eglot in there wouldn't help, since you have 
to improve the interface while keeping in mind *all* possible uses, 
existing ones and potential future ones.

> It's much better do deal with it in one
> place, Emacs, rather then the user complaining to Eglot issue tracker
> then I have to explain the problem or desired feature is in eldoc,
> then agree on an interface betweent he two files.  In Emacs I just
> submit a patch to both files and both maintainers look at it.

You would submit a patch for eldoc.el with a short description why it's 
an improvement, and that's that. Maybe link to the original report.

The first step would be necessary anyway, as a part of the bug report 
discussion.

It's not like we never have long, unproductive discussions in bug 
reports here.

> Rather what I find hard to follow is the "not in core" stance. It seems
> like you want to protect lsp-mode mode, or not condemn it to
> irrelevance.

That's some part of it, but I'm more on the side of "lean core, rich set 
of plugins" approach to Emacs architecture. So I'd rather move more 
stuff out than add to it.

Also I hate mistargeted solutions: this discussion came out of "how make 
Emacs more popular" discussion, right? Initial user experience, etc. And 
such a move will do little to help either.

Re: PL support

[João Távora]

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

On Sat, May 9, 2020 at 6:46 PM Eli Zaretskii <eliz@gnu.org> wrote:

> You are probably right.  But Eglot is in ELPA for some time, and I
> don't yet see a campaign to bring it into core; I do see some opinions
> to the contrary.  So I think it will be much easier to convince more
> people if we had this working.  I cannot be sure, of course, and you
> will do the work, so it is still your call.
>

I can make a minimal eglot-interfaces.el file for Emacs core
that defines some hooks, has some docstrings, etc, make _that_
a :core package and keep business as usual in Eglot in
Github/Elpa.


> Or maybe we will have a flood of messages tomorrow saying they'd like
> to have Eglot in core ;-)
>

(More likely you'll have a silly eglot.el vs lsp-mode.el debate, and
more draining bikeshedding.  I'll try to spend my time typing code
instead.)

João

[-- Attachment #2: Type: text/html, Size: 1483 bytes --]

Re: PL support

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 9 May 2020 18:58:54 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> (More likely you'll have a silly eglot.el vs lsp-mode.el debate, and
> more draining bikeshedding.  I'll try to spend my time typing code
> instead.)

Exactly why I think a working end-to-end solution will have a much
better chance of resolving the dispute.

Re: PL support

[Clément Pit-Claudel]

On 09/05/2020 14.03, Eli Zaretskii wrote:
>> From: João Távora <joaotavora@gmail.com>
>> Date: Sat, 9 May 2020 18:58:54 +0100
>> Cc: Dmitry Gutov <dgutov@yandex.ru>, Stefan Monnier <monnier@iro.umontreal.ca>, 
>> 	emacs-devel <emacs-devel@gnu.org>
>>
>> (More likely you'll have a silly eglot.el vs lsp-mode.el debate, and
>> more draining bikeshedding.  I'll try to spend my time typing code
>> instead.)
> 
> Exactly why I think a working end-to-end solution will have a much
> better chance of resolving the dispute.

Let's not be too hasty with calling the debate silly.  I don't use either lsp-mode or eglot but I do see strong opinions in favor of both, and "blessing" one as official, especially a (currently) less popular one, can cause sour feelings and give the perception that emacs-devel is being insular.

AFAICT, eglot and lsp-mode both already work very well, but for FSF reasons we can only recommend eglot.  Is that right?

If there are two great options and both are one click away after starting Emacs, is there really a problem in need of solving?  

Re: PL support

[João Távora]

On Sat, May 9, 2020 at 8:55 PM Clément Pit-Claudel
<cpitclaudel@gmail.com> wrote:
> > Exactly why I think a working end-to-end solution will have a much
> > better chance of resolving the dispute.
>
> Let's not be too hasty with calling the debate silly.

Sorry, I _will_ call this debate silly here and now, because this is
not an adversarial situation at all. This is about making a package
that is in GNU Elpa and works tightly with packages in Emacs
easier to develop _for its developers_: not about "recommending"
one over the other because it's "better" or more popular. It's
not like this will make life any harder for lsp-mode lovers or
developers, or anyone.  That just doesn't make sense. In fact,
the presence of LSP code in the core, if done correctly, can
even benefit them.

You want to add lsp-mode to core, be my guest: if the
developers think that will be beneficial to both.

> If there are two great options and both are one click away
> after starting Emacs, is there really a problem in need of solving?

As a user (or rather a not-yet-user-of-neither as you say)
you see no problem. And you will continue to see no problems.
But for this developer, there is a problem.

João

Re: PL support

[Dmitry Gutov]

On 09.05.2020 22:55, Clément Pit-Claudel wrote:
> Let's not be too hasty with calling the debate silly.  I don't use either lsp-mode or eglot but I do see strong opinions in favor of both, and "blessing" one as official, especially a (currently) less popular one, can cause sour feelings and give the perception that emacs-devel is being insular.

In principle, I disagree: as long as Eglot is maintained and works well, 
we *should* present it as "blessed", and we can do that in introduction 
videos, documentation, tutorials, etc.

After all, adding it to GNU ELPA was a good move, one that will benefit 
Emacs users at large.

Re: PL support

[Clément Pit-Claudel]

On 09/05/2020 17.49, Dmitry Gutov wrote:
> On 09.05.2020 22:55, Clément Pit-Claudel wrote:
>> Let's not be too hasty with calling the debate silly.  I don't use either lsp-mode or eglot but I do see strong opinions in favor of both, and "blessing" one as official, especially a (currently) less popular one, can cause sour feelings and give the perception that emacs-devel is being insular.
> 
> In principle, I disagree: as long as Eglot is maintained and works well, we *should* present it as "blessed", and we can do that in introduction videos, documentation, tutorials, etc.

But why more than lsp-mode?

Re: PL support

[Dmitry Gutov]

On 10.05.2020 01:23, Clément Pit-Claudel wrote:
> On 09/05/2020 17.49, Dmitry Gutov wrote:
>> On 09.05.2020 22:55, Clément Pit-Claudel wrote:
>>> Let's not be too hasty with calling the debate silly.  I don't use either lsp-mode or eglot but I do see strong opinions in favor of both, and "blessing" one as official, especially a (currently) less popular one, can cause sour feelings and give the perception that emacs-devel is being insular.
>> In principle, I disagree: as long as Eglot is maintained and works well, we*should*  present it as "blessed", and we can do that in introduction videos, documentation, tutorials, etc.
> But why more than lsp-mode?

Because they choose to participate in the "core" Emacs development very 
little?

And because they chose not to get included in GNU ELPA, which would be a 
"reward" in itself (oob availability for new users). We couldn't mention 
packages not in GNU ELPA in documentation as prominently anyway.

Re: PL support

[Clément Pit-Claudel]

On 09/05/2020 19.19, Dmitry Gutov wrote:
> On 10.05.2020 01:23, Clément Pit-Claudel wrote:
>> On 09/05/2020 17.49, Dmitry Gutov wrote:
>>> On 09.05.2020 22:55, Clément Pit-Claudel wrote:
>>>> Let's not be too hasty with calling the debate silly.  I don't use either lsp-mode or eglot but I do see strong opinions in favor of both, and "blessing" one as official, especially a (currently) less popular one, can cause sour feelings and give the perception that emacs-devel is being insular.
>>> In principle, I disagree: as long as Eglot is maintained and works well, we*should*  present it as "blessed", and we can do that in introduction videos, documentation, tutorials, etc.
>> But why more than lsp-mode?
> 
> Because they choose to participate in the "core" Emacs development very little?

Oh? I thought we chose to exclude them by writing a competing package instead of trying to bring them aboard.
What does it mean for an external package to participate in the core Emacs development?

> And because they chose not to get included in GNU ELPA, which would be a "reward" in itself (oob availability for new users). We couldn't mention packages not in GNU ELPA in documentation as prominently anyway.

Really?  The only thing I could find is https://github.com/emacs-lsp/lsp-mode/issues/83, where the general opinion is that it would be good for lsp-mode to be in core, until they (mistakenly) seem to conclude that eglot is in core already.  What am I missing?

> We couldn't mention packages not in GNU ELPA in documentation as prominently anyway.

Why?  Is the policy that it's bad to endorse code not *owned* by the FSF?

Re: PL support

[Dmitry Gutov]

On 10.05.2020 07:08, Clément Pit-Claudel wrote:

>>>> In principle, I disagree: as long as Eglot is maintained and works well, we*should*  present it as "blessed", and we can do that in introduction videos, documentation, tutorials, etc.
>>> But why more than lsp-mode?
>>
>> Because they choose to participate in the "core" Emacs development very little?
> 
> Oh? I thought we chose to exclude them by writing a competing package instead of trying to bring them aboard.

We did what? I didn't write anything like that.

Only one person did, on his own volition. Then the package got added to 
ELPA on usual conditions.

> What does it mean for an external package to participate in the core Emacs development?

Well, um, that would mean for individual authors to participate, I 
guess. Maybe contribute useful code as libraries. Example of another 
failed discussion: https://github.com/emacs-lsp/lsp-ui/issues/50

And for packages to be contributed to GNU ELPA, with the subsequent 
possibility of having useful bits extracted and generalized.

>> And because they chose not to get included in GNU ELPA, which would be a "reward" in itself (oob availability for new users). We couldn't mention packages not in GNU ELPA in documentation as prominently anyway.
> 
> Really?  The only thing I could find is https://github.com/emacs-lsp/lsp-mode/issues/83, where the general opinion is that it would be good for lsp-mode to be in core, until they (mistakenly) seem to conclude that eglot is in core already.  What am I missing?

You're missing the first sentence in the message you are looking at.

What do you expect? I'm tired of chasing people and asking them to 
contribute. Do you fault me not going there and asking again?

>> We couldn't mention packages not in GNU ELPA in documentation as prominently anyway.
> 
> Why?  Is the policy that it's bad to endorse code not *owned* by the FSF?

We can't make adding MELPA to the archives list a part of an official 
tutorial. For multiple reasons, code ownership only one of them.

Re: PL support

[João Távora]

On Sun, May 10, 2020 at 2:28 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> > Oh? I thought we chose to exclude them by writing a competing package instead of trying to bring them aboard.
> Only one person did, on his own volition. Then the package got added to
> ELPA on usual conditions.

Also, it's a preposterous untruth, to use a bland word, to imply
that I did nothing to work with what was then the contemporary
lsp-mode.el and its maintainers simply abandoned that goal.
Also I stated many many times over the motivation for starting
and developing Eglot, I'm not going to do that again.

João

Re: PL support

[Stefan Monnier]

> We can't make adding MELPA to the archives list a part of an official
> tutorial.  For multiple reasons, code ownership only one of them.

Code ownership is not one of them, actually.
We can and do recommend things we don't "own".


        Stefan

Re: PL support

[Dmitry Gutov]

On 10.05.2020 19:34, Stefan Monnier wrote:
>> We can't make adding MELPA to the archives list a part of an official
>> tutorial.  For multiple reasons, code ownership only one of them.
> Code ownership is not one of them, actually.
> We can and do recommend things we don't "own".

On a personal note, I'd also support not requiring copyright assignments 
for ELPA packages.

Just today I had a related discussion in yaml-mode, with some former 
authors unavailable, and one outright reticent to sign.

Re: PL support

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

  > On a personal note, I'd also support not requiring copyright assignments 
  > for ELPA packages.

Here is why we must not do that.

In general, when we put a package into GNU ELPA, we want to be able
to move it into the core.  Putting off getting assignments would be
asking for trouble, for reasons you have just encountered yourself.
The policy of getting assignments at the earlier time, when we put
the package into GNU ELPA, keeps is from putting it off.

If there were ever some package we want to refer people to
but certainly would never want to move it into the core,
this issue would not arise.

But how could we be sure of that?

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

Re: PL support

[조성빈]

Richard Stallman <rms@gnu.org> 작성:

> [[[ 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. ]]]
>
>> On a personal note, I'd also support not requiring copyright assignments
>> for ELPA packages.
>
> Here is why we must not do that.
>
> In general, when we put a package into GNU ELPA, we want to be able
> to move it into the core.  Putting off getting assignments would be
> asking for trouble, for reasons you have just encountered yourself.
> The policy of getting assignments at the earlier time, when we put
> the package into GNU ELPA, keeps is from putting it off.

You can mark a package whether it will be able to move into core or not.
Having a package on ELPA is not as good as having it in the core (for example
Magit), but it’s much better than having the user to force them to use MELPA
as soon as they start using Emacs.

> If there were ever some package we want to refer people to
> but certainly would never want to move it into the core,
> this issue would not arise.
>
> But how could we be sure of that?

For one example, no one would want s.el, dash.el, f.el directly into the  
core.
But a vast majority of people outside this mailing list wants them in ELPA.

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

Re: PL support

[Alfred M. Szmidt]

   You can mark a package whether it will be able to move into core or
   not.  Having a package on ELPA is not as good as having it in the
   core (for example Magit), but it's much better than having the user
   to force them to use MELPA as soon as they start using Emacs.

Nobody can foresee the future, so what might be included or not is far
to early to see.  It would also be unfair to those who contribute a
package to ELPA from the start tell them that they are not welcome to
include their package in Emacs -- which is the situation that will
occur if one ignores collection of copyright assignments.

   > If there were ever some package we want to refer people to but
   > certainly would never want to move it into the core, this issue
   > would not arise.
   >
   > But how could we be sure of that?

   For one example, no one would want s.el, dash.el, f.el directly
   into the core.

Several people have already suggested features that are provided by
s.el, dash.el that could be a welcome addition to Emacs.  By skipping
copyright assignments from the onset, one cannot take the existing
code that is part of the Emacs project and include it in Emacs proper.

That would be a terrible loss.

Re: PL support

[Stefan Kangas]

ams@gnu.org (Alfred M. Szmidt) writes:

>    You can mark a package whether it will be able to move into core or
>    not.  Having a package on ELPA is not as good as having it in the
>    core (for example Magit), but it's much better than having the user
>    to force them to use MELPA as soon as they start using Emacs.
>
> Nobody can foresee the future, so what might be included or not is far
> to early to see.  It would also be unfair to those who contribute a
> package to ELPA from the start tell them that they are not welcome to
> include their package in Emacs -- which is the situation that will
> occur if one ignores collection of copyright assignments.

How would it be "unfair" exactly?  AFAIU, the requirements for getting
code into Emacs would be exactly the same as today.

Best regards,
Stefan Kangas

Re: PL support

[Alfred M. Szmidt]

If you contribute a package from the start, and then are not
collecting papers, it can never be included without going through the
whole process of collecting papers later.  

That is unfair to both the person contributing the package, but also
to future maintainers the package who would expect that since ELPA is
part Emacs, one could just put that code into Emacs at some point.

Now they have to find any previous contributors, get them assign
copyright, or in the worst case -- rewrite the code.

Compare this to the minor inconvience of getting a nice set of
GNU stickers.

Re: PL support

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Date: Mon, 11 May 2020 11:49:38 +0900
> Cc: Dmitry Gutov <dgutov@yandex.ru>, cpitclaudel@gmail.com,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> Having a package on ELPA is not as good as having it in the core (for example
> Magit), but it’s much better than having the user to force them to use MELPA
> as soon as they start using Emacs.

Why? what's wrong with using MELPA?

> For one example, no one would want s.el, dash.el, f.el directly into the  
> core.

Wonna bet?

> But a vast majority of people outside this mailing list wants them in ELPA.

Why? they already have it in MELPA.

Re: PL support

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Having a package on ELPA is not as good as having it in the core (for example
>> Magit), but it’s much better than having the user to force them to use MELPA
>> as soon as they start using Emacs.
>
> Why? what's wrong with using MELPA?

The main problem for me flows from the fact that we can't configure
MELPA by default nor even recommend it prominently in the manual and on
the website.  There are packages on MELPA which IMHO could be extremely
beneficial to install for beginning users, for example, but we can't
tell our users about them.[1]

For many users (me included), using Emacs without packages from MELPA
would mean missing out on functionality you depend on for carrying out
your daily work.  We are not really delivering the "full Emacs package"
as is, nor do we tell our users how to get there.  Instead, we ask them
to rely on third-party sources, wikis, blogs and chat rooms to fill in
the blanks left by our documentation and default configuration.

I also think it's strategically bad if we want more people assign their
code and get more people involved in Emacs development.  The way to do
that is surely to do everything we can to pull package developers closer
to us, not just tell them to stay in MELPA.

(I don't think the best option is to start recommending MELPA, by the
way.  We would be better off if we distributed certain packages from an
official GNU archive, such as "ELPA" or "ELPA-contrib" as I suggested
before.)

Best regards,
Stefan Kangas

Footnotes:
[1] For me, this is also connected to the discussion about better
     onboarding, which could be improved by recommending certain
     packages for your use-case.  For example, if you tell Emacs you
     want to code PHP, you should probably be pointed to `php-mode'
     (only available on MELPA).  Or: "If you want to use git, why not
     try the built-in 'vc' or the third-party package 'magit' (or use
     both)."

Re: PL support

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 11 May 2020 14:08:09 -0700
> Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org, rms@gnu.org, 
> 	monnier@iro.umontreal.ca, dgutov@yandex.ru
> 
> > Why? what's wrong with using MELPA?
> 
> The main problem for me flows from the fact that we can't configure
> MELPA by default nor even recommend it prominently in the manual and on
> the website.

I already asked why is this an issue.  Emacs needs configuration for
many purposes, for example for sending and receiving email.  There is
no need to have every wish of every user be available by default OOTB.

> For many users (me included), using Emacs without packages from MELPA
> would mean missing out on functionality you depend on for carrying out
> your daily work.

Emacs lets you do whatever you want.  You don't need any blessing from
the project.

> I also think it's strategically bad if we want more people assign their
> code and get more people involved in Emacs development.  The way to do
> that is surely to do everything we can to pull package developers closer
> to us, not just tell them to stay in MELPA.

We welcome anyone who wants to become involved and wants to
contribute.  But as a project, we have our conventions and standards,
and contributors are kindly requested to follow them when they
contribute to Emacs.  Every project does that, and there's nothing
wrong with such requirements.  Those requirements are meant to keep
the quality of Emacs high enough.

Re: PL support

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> The main problem for me flows from the fact that we can't configure
>> MELPA by default nor even recommend it prominently in the manual and on
>> the website.
>
> I already asked why is this an issue.  Emacs needs configuration for
> many purposes, for example for sending and receiving email.  There is
> no need to have every wish of every user be available by default OOTB.

It is a problem that basic functionality for several important use-cases
is missing OOTB.  Some examples have been given in this thread.

It is also a clear drawback that we can't include nice-to-have
functionality such as Magit (one of our "killer apps").

> Emacs lets you do whatever you want.  You don't need any blessing from
> the project.

So then why do we ship any ELisp code in core?  Or even provide a
default configuration?

AFAIU, we do that to improve the user experience.  And here is a
low-hanging fruit which would improve it tremendously.

>              But as a project, we have our conventions and standards,
> and contributors are kindly requested to follow them when they
> contribute to Emacs.  Every project does that, and there's nothing
> wrong with such requirements.  Those requirements are meant to keep
> the quality of Emacs high enough.

We would not need to lower our standards by introducing "ELPA Contrib"
or "MELPA-libre".  We could still choose which packages to include, and
the conditions for doing so.

Best regards,
Stefan Kangas

Re: PL support

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 12 May 2020 10:04:05 -0400
> Cc: pcr910303@icloud.com, cpitclaudel@gmail.com, emacs-devel@gnu.org, 
> 	rms@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru
> 
> It is a problem that basic functionality for several important use-cases
> is missing OOTB.  Some examples have been given in this thread.
> 
> It is also a clear drawback that we can't include nice-to-have
> functionality such as Magit (one of our "killer apps").

I agree that these are voids in the Emacs functionality.  The argument
is not about whether there are voids, but about the ways to fill them.

> >              But as a project, we have our conventions and standards,
> > and contributors are kindly requested to follow them when they
> > contribute to Emacs.  Every project does that, and there's nothing
> > wrong with such requirements.  Those requirements are meant to keep
> > the quality of Emacs high enough.
> 
> We would not need to lower our standards by introducing "ELPA Contrib"
> or "MELPA-libre".  We could still choose which packages to include, and
> the conditions for doing so.

I don't know what are MELPA-libre or ELPA Contrib.  It sounds like
they are ideas, not real repositories.  If the intent is to create
package repositories that are not part of the Emacs project, I have no
objections (and even if I did, people could rightfully ignore them).

Re: PL support

[Stefan Monnier]

> I don't know what are MELPA-libre or ELPA Contrib.

I proposed "MELPA-Libre" to mean a hypothetical archive, presumably
managed under `melpa.org` which would contain a subset of MELPA limited
to packages that do not promote proprietary software.
Whether this can be arranged with the MELPA guys, I have no idea, nor do
I know who would curate it.

"ELPA-Contrib" was proposed to mean a hypothetical archive alongside GNU
ELPA, with no copyright paperwork requirement (and basically no abiding
by our coding convention either).

The difference between the two is largely that "ELPA-Contrib" would be
under `elpa.gnu.org` whereas "MELPA-Libre" would be under `melpa.org`.

> It sounds like they are ideas, not real repositories.

Indeed, they're proposals.

> If the intent is to create package repositories that are not part of
> the Emacs project, I have no objections (and even if I did, people
> could rightfully ignore them).

That's not how this works: the only reason for repositories like
"ELPA-Contrib" or "MELPA-Libre" to exist would be that contrary to MELPA
they'd be included in `package-archives` by default.

So if you refuse to include them in `package-archives`, then the
hypothetical repositories won't exist: people can't just ignore
your objections.


        Stefan

Re: PL support

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  pcr910303@icloud.com,
>   cpitclaudel@gmail.com,  emacs-devel@gnu.org,  rms@gnu.org,
>   dgutov@yandex.ru
> Date: Tue, 12 May 2020 13:54:04 -0400
> 
> > If the intent is to create package repositories that are not part of
> > the Emacs project, I have no objections (and even if I did, people
> > could rightfully ignore them).
> 
> That's not how this works: the only reason for repositories like
> "ELPA-Contrib" or "MELPA-Libre" to exist would be that contrary to MELPA
> they'd be included in `package-archives` by default.

If these are free software repositories, is there any reason for us
not to include them?  A have a feeling that I'm missing something, but
I don't know why.

> So if you refuse to include them in `package-archives`, then the
> hypothetical repositories won't exist: people can't just ignore
> your objections.

Given what Phillip just wrote, I'm no longer sure my opinions are
relevant at all.

Re: PL support

[Dmitry Gutov]

On 12.05.2020 21:01, Eli Zaretskii wrote:
>>> If the intent is to create package repositories that are not part of
>>> the Emacs project, I have no objections (and even if I did, people
>>> could rightfully ignore them).
>> That's not how this works: the only reason for repositories like
>> "ELPA-Contrib" or "MELPA-Libre" to exist would be that contrary to MELPA
>> they'd be included in `package-archives` by default.
> If these are free software repositories, is there any reason for us
> not to include them?  A have a feeling that I'm missing something, but
> I don't know why.

MELPA is already a free software repository (it has to be anyway, since 
packages "link" to Emacs). But some packages these integrate with 
non-free external programs, or otherwise recommend them.

Is that an issue for us?

Re: PL support

[Alfred M. Szmidt]

   MELPA is already a free software repository (it has to be anyway, since 
   packages "link" to Emacs). But some packages these integrate with 
   non-free external programs, or otherwise recommend them.

   Is that an issue for us?

It is an issue for any GNU project.  MELPA is also hosted on Github,
that too is an issue.

Re: PL support

[Stefan Monnier]

> If these are free software repositories, is there any reason for us
> not to include them?

I thought that's the question I was asking you (and Richard).


        Stefan

Re: PL support

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

  > AFAIU, we do that to improve the user experience.  And here is a
  > low-hanging fruit which would improve it tremendously.

The crucial question is whether we CAN pluck and use that particular
fruit.  Is it poisonous?  Is it covered with thorns?  Is it so firmly
attached that we can't pluck it?

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

Re: PL support

[Dmitry Gutov]

On 11.05.2020 05:40, Richard Stallman wrote:

> In general, when we put a package into GNU ELPA, we want to be able
> to move it into the core.  Putting off getting assignments would be
> asking for trouble, for reasons you have just encountered yourself.
> The policy of getting assignments at the earlier time, when we put
> the package into GNU ELPA, keeps is from putting it off.
> 
> If there were ever some package we want to refer people to
> but certainly would never want to move it into the core,
> this issue would not arise.

We don't want to move every package to the core. Quite the opposite, a 
most of them can live quite comfortably outside, when they're 
self-contained features. And the more packages we add to GNU ELPA, the 
bigger fraction of such packages will be.

So I think deferring the step of asking for copyright assignment until 
we actually want to do the move to the core. We can track the packages 
without assignments the same way we've been tracking the "excepted" 
files in the repository.

The clear benefit is the bigger choice of packages, vetted by us, and 
available for users to install right away.

Re: PL support

[Stefan Monnier]

> So I think deferring the step of asking for copyright assignment until
> we actually want to do the move to the core.

I don't think we'd want to defer that late.  Instead, we should seek
assignments eagerly but in a non-blocking way.  Also, we still wouldn't
give push rights to people who haven't signed the copyright paperwork.


        Stefan

Re: PL support

[Dmitry Gutov]

On 11.05.2020 06:39, Stefan Monnier wrote:
>> So I think deferring the step of asking for copyright assignment until
>> we actually want to do the move to the core.
> I don't think we'd want to defer that late.  Instead, we should seek
> assignments eagerly but in a non-blocking way.  Also, we still wouldn't
> give push rights to people who haven't signed the copyright paperwork.

Even better. A well-considered position.

Re: PL support

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 10 May 2020 23:39:49 -0400
> Cc: cpitclaudel@gmail.com, rms@gnu.org, emacs-devel@gnu.org
> 
> we should seek assignments eagerly but in a non-blocking way

What does it mean in practice?  If you accept code without the
assignment, why would anyone make the effort to see the legal
paperwork through, or even start it?  It's an annoyance, and people
tend to avoid annoyances as much as they can.

It won't work.

Re: PL support

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 06:06:49 +0300
> Cc: cpitclaudel@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
>     If there were ever some package we want to refer people to
>     but certainly would never want to move it into the core,
>     this issue would not arise.
> 
> We don't want to move every package to the core.

If by "we" you mean the Emacs project, then we don't actually have a
common shared view of this.  You evidently want to keep most of the
packages on ELPA, and maybe even move out to ELPA packages already in
core.  My opinion is almost the exact opposite, Stefan is in-between
(perhaps closer to your opinion than to mine), and there are a
plethora of other opinions.  these differences of opinion between us
are well known, and we are still debating.  In fact, at least for me,
we are now farther from an agreement than I thought, given the
copyright assignment controversy and the fact that we waive our coding
standards for ELPA packages.

> So I think deferring the step of asking for copyright assignment until we actually want to do the move to the core. We can track the packages without assignments the same way we've been tracking the "excepted" files in the repository.

We can maybe "track" them in the sense that we will know that
copyright assignments are not being collected for certain packages,
but in practice this makes it impossible to ever include such
packages, because getting the legal papers signed many moons after the
contribution becomes harder and harder as time passes.  We have live
examples of such difficulties, and had a lot of them in the past.
Given that experience, I don't see how we can in good faith expect to
succeed in getting the assignments in some distant future unless we
collect them today.  It sounds to me like burying our heads in the
sand.

> The clear benefit is the bigger choice of packages, vetted by us, and available for users to install right away.

Given that the proposal is not to ask for copyright assignment, the
coding standards are already "not imposed" but only "recommended"
(read: waived), and Stefan and others seem to say that even cleanness
of design and implementation and compatibility with the overall Emacs
design are out of our hands, I really fail to see what would be the
meaning of "vetted by us" in this context.  That "us" is certainly not
the Emacs project.  To me, it sounds like we are being asked to open a
MELPA clone, which makes no sense to me.

Re: PL support

[Dmitry Gutov]

On 11.05.2020 19:40, Eli Zaretskii wrote:
> If by "we" you mean the Emacs project, then we don't actually have a
> common shared view of this.  You evidently want to keep most of the
> packages on ELPA, and maybe even move out to ELPA packages already in
> core.  My opinion is almost the exact opposite, Stefan is in-between
> (perhaps closer to your opinion than to mine), and there are a
> plethora of other opinions.  these differences of opinion between us
> are well known, and we are still debating.

Seems so.

> We can maybe "track" them in the sense that we will know that
> copyright assignments are not being collected for certain packages,
> but in practice this makes it impossible to ever include such
> packages,

Probably, yes.

> because getting the legal papers signed many moons after the
> contribution becomes harder and harder as time passes.  We have live
> examples of such difficulties, and had a lot of them in the past.

We have examples of such difficulties when getting a package into the 
ELPA archive. Many of them. Out of those, I believe we would only 
consider incorporating a single-digit number of packages into "vanilla" 
Emacs. In the meantime, we're losing out on nearly-built-in support for 
many file types, e.g. yaml-mode.

> Given that the proposal is not to ask for copyright assignment, the
> coding standards are already "not imposed" but only "recommended"
> (read: waived),

Copyright assignment is an organizational standard, rather. But 
honestly, yes, it's difficult for us to impose hard coding standards. 
MELPA admins are doing this much more effectively, being #1 popular 
package repository.

I *would* support some sort of choosing criteria why we would want to 
accept some packages but not others, but "follows Emacs coding standards 
to a T" is unlikely to work. Or be useful, really.

> and Stefan and others seem to say that even cleanness
> of design and implementation and compatibility with the overall Emacs
> design are out of our hands, I really fail to see what would be the
> meaning of "vetted by us" in this context.

One obvious thing: every package is highly unlikely to nuke your 
machine, or steal your credentials. We can vet package releases, at 
least to some extent. MELPA admins can't do that, they don't have enough 
manpower or technical ability, given that they build every update of 
every package as soon as it hits the repository. Not even waiting for 
version bumps.

> That "us" is certainly not
> the Emacs project.  To me, it sounds like we are being asked to open a
> MELPA clone, which makes no sense to me.

We could also have other differentiating features. For example, asking 
authors of "external" packages to sign commits that bump the version number.

Re: PL support

[Eli Zaretskii]

> Cc: rms@gnu.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 19:54:29 +0300
> 
> In the meantime, we're losing out on nearly-built-in support for
> many file types, e.g. yaml-mode.

What do you mean by "nearly-built-in support"?  And how are we losing
it?

> > and Stefan and others seem to say that even cleanness
> > of design and implementation and compatibility with the overall Emacs
> > design are out of our hands, I really fail to see what would be the
> > meaning of "vetted by us" in this context.
> 
> One obvious thing: every package is highly unlikely to nuke your 
> machine, or steal your credentials.

Sorry, but this is not our problem.  We cannot fix the entire world.
If Emacs users who install packages from MELPA have fears about their
security, let them take this up with MELPA admins, or fork MELPA and
make their own site, or do anything else.  This isn't part of the
problem that the Emacs project should tackle.

> We could also have other differentiating features. For example, asking 
> authors of "external" packages to sign commits that bump the version number.

Again, not our problem.  We have enough on our plate already.

Re: PL support

[Stefan Monnier]

> Sorry, but this is not our problem.  We cannot fix the entire world.
> If Emacs users who install packages from MELPA have fears about their
> security, let them take this up with MELPA admins, or fork MELPA and
> make their own site, or do anything else.  This isn't part of the
> problem that the Emacs project should tackle.

The way I see it, currently Emacs de-facto recommends to most of its
users to add MELPA to their `package-archives`.

Now, I actually think MELPA is pretty good (modulo the few packages in
it which end up recommending/advertizing proprietary tools), so maybe
a better solution is to be honest about this de-facto situation and
actually add MELPA to the default value of `package-archives`.

Of course, those few not-quite-libre packages could pose problems for
that since they go against some of our values, so maybe we should not
add MELPA itself, but the "libre-MELPA" subset (which someone will have
to create and maintain).

WDYT?


        Stefan

Re: PL support

[Dmitry Gutov]

On 11.05.2020 21:05, Stefan Monnier wrote:
> but the "libre-MELPA" subset (which someone will have
> to create and maintain)

...one probably based on MELPA Stable as well (which has fewer packages, 
but still).

Re: PL support

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  rms@gnu.org,  cpitclaudel@gmail.com,
>   emacs-devel@gnu.org
> Date: Mon, 11 May 2020 14:05:57 -0400
> 
> The way I see it, currently Emacs de-facto recommends to most of its
> users to add MELPA to their `package-archives`.

No, we do nothing of the kind.  Just because everybody and their dog
know what MELPA is and how to configure Emacs to use it, doesn't mean
_we_ told them.  Exactly like we don't "recommend" using MS-Windows,
although quite a few of Emacs users do, witness the discussions on
Reddit as one example.

Anything that Emacs doesn't do OOTB the users who need that will go
out and find a way of doing it.  But it doesn't mean we "recommended"
that, it just means we don't (yet) have a solution for that problem
OOTB.

> Now, I actually think MELPA is pretty good (modulo the few packages in
> it which end up recommending/advertizing proprietary tools), so maybe
> a better solution is to be honest about this de-facto situation and
> actually add MELPA to the default value of `package-archives`.

Why in the world is that important?  Configuring Emacs to work with
MELPA is exceedingly simple, and the way to do that for any random
SITE is in the manual.  Why would anyone need that we say the M-word??

> WDYT?

I still don't understand the motivation.  I cannot understand why we
need to argue and quarrel so much on behalf of some site about which
everyone already knows.  Why does it matter to anyone that the word
"MELPA" is written in some place in our docs?  It all seems a waste of
breath to me.

Re: PL support

[Stefan Monnier]

>> The way I see it, currently Emacs de-facto recommends to most of its
>> users to add MELPA to their `package-archives`.
> No, we do nothing of the kind.

We don't say the words, but by only distributing a very small subset of
the Elisp packages (virtually all of which are available on MELPA),
the end result is the same: we merely let *other* people tell our users
where the Elisp packages are.

> Just because everybody and their dog know what MELPA is and how to
> configure Emacs to use it, doesn't mean _we_ told them.  Exactly like
> we don't "recommend" using MS-Windows, although quite a few of Emacs
> users do, witness the discussions on Reddit as one example.

MS-Windows?  Really?

Do you really think some people have installed MS-Windows in order to be
able to use Emacs?

> Why in the world is that important?  Configuring Emacs to work with
> MELPA is exceedingly simple, and the way to do that for any random
> SITE is in the manual.  Why would anyone need that we say the M-word??

Here's how it works for a beginning user of Emacs, in my experience:

1- Install Emacs.
2- Try it out.
3- It doesn't handle their OCaml code, doesn't give them any
   completions while they type, nothing.
4- They search the web for an answer.
5- The answer tells them to install those things from MELPA.
6- They wonder why on earth it's not enabled by default since it's
   a matter of a couple lines and you can't do anything without it.
7- Now it's enabled, so they have direct easy access to some packages
   that recommend proprietary software.

In which sense does this better promote Emacs and Free Software than if
we enabled a MELPA-Libre by default in `package-archives`?

> I still don't understand the motivation.  I cannot understand why we
> need to argue and quarrel so much on behalf of some site about which
> everyone already knows.

I don't understand either.  The current situation seems so obviously
sub-optimal and so easy to fix.


        Stefan

Re: PL support

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru,  rms@gnu.org,  cpitclaudel@gmail.com,
>   emacs-devel@gnu.org
> Date: Mon, 11 May 2020 15:49:11 -0400
> 
> 1- Install Emacs.
> 2- Try it out.
> 3- It doesn't handle their OCaml code, doesn't give them any
>    completions while they type, nothing.
> 4- They search the web for an answer.
> 5- The answer tells them to install those things from MELPA.
> 6- They wonder why on earth it's not enabled by default since it's
>    a matter of a couple lines and you can't do anything without it.
> 7- Now it's enabled, so they have direct easy access to some packages
>    that recommend proprietary software.
> 
> In which sense does this better promote Emacs and Free Software than if
> we enabled a MELPA-Libre by default in `package-archives`?

Does MELPA-Libre exist, or is it just an idea?

I have nothing against MELPA-Libre, whether it exists or will be
created at some future point, as long as it is not GNU ELPA, i.e. as
long as it is not perceived as part of the GNU Emacs project.  If it
wants to be part of the Emacs project, and the packages are supposed
to be movable between Emacs and MELPA-Libre, I will insist of applying
the same rules and basic requirements to it that we apply to code in
Emacs.

Yes, this may mean that some features will not be part of Emacs OOTB,
but I don't think that is a reason good enough to waive our
development standards.

Re: PL support

[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 have nothing against MELPA-Libre, whether it exists or will be
  > created at some future point, as long as it is not GNU ELPA, i.e. as
  > long as it is not perceived as part of the GNU Emacs project.  If it
  > wants to be part of the Emacs project, and the packages are supposed
  > to be movable between Emacs and MELPA-Libre, I will insist of applying
  > the same rules and basic requirements to it that we apply to code in
  > Emacs.

That is how it must be.

People have suggested the idea of a MELPA-Libre.  People have
suggested the idea of including some packages in GNU ELPA without
copyright assignments.  How are these different?

The meaning of "MELPA-Libre" is not entirely precise -- there are
various possibilities for what it might be.  So the answer cannot be
precise.

I think the basic idea is that others would maintain it, not us, but
that they would commit to follow some part of our criteria for GNU
ELPA.  For instance, we presume they would reject references to nonfree
software.  Clearly they would not get copyright assignments.
I suppose they would not ask for coherence of design with Emacs.

That leaves a lot of room for variation.  We can't say whether we
would want to refer to MELPA-Libre until we know what it would be.

I find proposal of broadening GNU ELPA more plausible because (1) we
could decide how to handle it and (2) it would probably come closer to
following our standards.

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

Re: PL support

[Stefan Monnier]

> That leaves a lot of room for variation.  We can't say whether we
> would want to refer to MELPA-Libre until we know what it would be.

Then tell us what it is you would find acceptable (in the sense that we
could add it to the default value of `package-archives`).

The crucial 2 constraints would be:
- It would not require copyright paperwork.
- It would not impose our own coding conventions and would hence happily
  accept `s.el`.


        Stefan

Re: PL support

[Dmitry Gutov]

On 14.05.2020 16:36, Stefan Monnier wrote:
> - It would not impose our own coding conventions and would hence happily
>    accept `s.el`.

Note: we most likely can ask s.el's author to better follow _some_ of 
our conventions, if that's what it takes to accept it for GNU ELPA.

But renaming the package (with 400+ dependencies out there) would be 
impractical.

Re: PL support

[Stefan Monnier]

>> - It would not impose our own coding conventions and would hence happily
>>    accept `s.el`.
> Note: we most likely can ask s.el's author to better follow _some_ of our
> conventions, if that's what it takes to accept it for GNU ELPA.
> But renaming the package (with 400+ dependencies out there) would
>  be impractical.

The issue is not `s.el`, but any other package with comparable (tho not
necessarily identical) issues w.r.t coding convention.  I mention `s.el`
as an example of a package where the breakage of coding-convention seems
severe enough (contrary to my own judgment, FWIW) to disallow it into
GNU ELPA even though everyone agrees it is technically fine.


        Stefan

Re: PL support

[João Távora]

On Thu, May 14, 2020 at 6:41 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> >> - It would not impose our own coding conventions and would hence happily
> >>    accept `s.el`.
> > Note: we most likely can ask s.el's author to better follow _some_ of our
> > conventions, if that's what it takes to accept it for GNU ELPA.
> > But renaming the package (with 400+ dependencies out there) would
> >  be impractical.
>
> The issue is not `s.el`, but any other package with comparable (tho not
> necessarily identical) issues w.r.t coding convention.  I mention `s.el`
> as an example of a package where the breakage of coding-convention seems
> severe enough (contrary to my own judgment, FWIW) to disallow it into
> GNU ELPA even though everyone agrees it is technically fine.

What are the top 5 (3?) most worrisome violations of coding
convention by s.el?  I suppose namespacing is at the top of
that list, but what are the other ones, ranked and summarized,
if possible?  Aren't we willing to live with some of them, for a
while, especially if they are neatly packed inside a clearly
identified namespace?

João

Re: PL support

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

  > What are the top 5 (3?) most worrisome violations of coding
  > convention by s.el?  I suppose namespacing is at the top of
  > that list, but what are the other ones, ranked and summarized,
  > if possible?  Aren't we willing to live with some of them, for a
  > while, especially if they are neatly packed inside a clearly
  > identified namespace?

The problems I know of are the namespace problem, and some functions
that are inconsistent with Emacs Lisp, such as s-prepend and s-trim.

I have not read the code, so I won't claim it has other problems.
But any problems in the implementation would not be a big deal,
since we could surely fix them.

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

Re: PL support

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

  > > That leaves a lot of room for variation.  We can't say whether we
  > > would want to refer to MELPA-Libre until we know what it would be.

  > Then tell us what it is you would find acceptable (in the sense that we
  > could add it to the default value of `package-archives`).

Coming to a conclusion about that broad question would be work.  If
someone wants to set up and maintain an alternate archive, it would be
useful to do that work.  Until then, we don't need an answer.

Whether we could have some packages in GNU ELPA without legal
papers is a much more bounded question.  Let's think about that first.

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

Re: PL support

[Stefan Monnier]

> Coming to a conclusion about that broad question would be work.  If
> someone wants to set up and maintain an alternate archive, it would be
> useful to do that work.  Until then, we don't need an answer.

So, I will have to keep recommending the use of MELPA, I guess.

Creating such a new archive without knowing beforehand if it will be
accepted in the default value of `package-archive` is much too risky.


        Stefan

Re: PL support

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: eliz@gnu.org,  emacs-devel@gnu.org,  cpitclaudel@gmail.com,
>   dgutov@yandex.ru
> Date: Thu, 14 May 2020 23:44:41 -0400
> 
> > Coming to a conclusion about that broad question would be work.  If
> > someone wants to set up and maintain an alternate archive, it would be
> > useful to do that work.  Until then, we don't need an answer.
> 
> So, I will have to keep recommending the use of MELPA, I guess.
> 
> Creating such a new archive without knowing beforehand if it will be
> accepted in the default value of `package-archive` is much too risky.

Richard didn't say you actually had to _create_ a new archive, he said
you (or someone else) just needs to say they _intend_ to, and describe
the details.

A new archive, halfway between GNU ELPA and MELPA

[Stefan Monnier]

>> > Coming to a conclusion about that broad question would be work.  If
>> > someone wants to set up and maintain an alternate archive, it would be
>> > useful to do that work.  Until then, we don't need an answer.
>> So, I will have to keep recommending the use of MELPA, I guess.
>> Creating such a new archive without knowing beforehand if it will be
>> accepted in the default value of `package-archive` is much too risky.
> Richard didn't say you actually had to _create_ a new archive, he said
> you (or someone else) just needs to say they _intend_ to, and describe
> the details.

Then I guess we misunderstood each other:

I do want to setup and maintain such an archive, and I'm pretty sure
several other people would be interested in helping.
That's why I asked the question in the first place.

So here's the question again:

What would be required of a new ELPA archive for it be acceptable in the
default value of `package-archives`, given the following following main
constraints:
- It would not require copyright paperwork.
- It would not impose our own coding conventions and would hence happily
  accept `s.el`.
- The understanding that it will significantly reduce the incentive for
  authors to include their package in GNU ELPA.


        Stefan

Re: A new archive, halfway between GNU ELPA and MELPA

[Stefan Monnier]

> What would be required of a new ELPA archive for it be acceptable in the
> default value of `package-archives`, given the following following main
                                                          ^
                                                      following

Sorry 'bout that,


        Stefan

Re: PL support

[chad]

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

Because it seems like it might have been lost in the (unavoidable,
understandable) lag time and overlapping threads:

The vast majority of the software on MELPA that we're talking about *is*
free (open, libre, beer-and-speech, etc.) software - most of it GPL. This
is why so many people who care about both emacs and free software decide,
in the end, to use and/or recommend MELPA to users. For example: Tuareg was
mentioned earlier. It's GPL software for editing OCaml in Emacs. This is
why at least some people don't think that it's poisonous, thorny, or
otherwise "bad fruit". Unfortunately, it's "good fruit" hanging from a tree
that grows in an orchard that also has some trees with bad fruit, to push
the analogy too far.

I hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 875 bytes --]

Re: PL support

[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 could agree to that, but I wouldn't agree to drop all of the
  > requirements.  And even if we loosen some of them, it's already
  > problematic: the contributors of code for the core, which are
  > generally required to adhere to all of the requirements, could
  > rightfully feel they are treated unfairly, even though developing the
  > core benefits Emacs more than an unbundled package.

That is an important point.  Relaxing any standard for part of the
spectrum tends to lead to pressure to relax it elsewhere too.
But there may be ways we can reduce that pressure.

One idea is to make a clearer distinction between packages.
For instance, we could divide GNU ELPA packages into two repos, or two
classes of inclusion, with different standards.  There are various
ways to work out the details.

Another idea is to recruit someone to promise to clean the package up,
before installing it.  Then we would install the package tentatively.
If the person who promised does not do the work, we could say, "We
tentatively added XYZ to GNU ELPA after someone promised to clean it
up, but perse didn't do the work.  We can keep it tentatively in GNU
ELPA if someone else commits to do that work."

For cleanups that are purely technical, this could be effective to get
them done.

It would be useful to record, with each tentative package, a target date
for the work, and a deadline further away, at which point we would recruit
someone else or delete it.

Vital for either of these ideas to be effective is to _show_ users
these facts reasonably often if they use GNU ELPA.  Information in a
page they can look at if they are curious will not do the job.

One idea is to make package.el show the information to anyone who
installs the package.  Also, it could ask for confirmation on
installing a tentative package.  Is there a way to ask for confirmation
more often than that, but not too often?

WDYT?

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

Re: PL support

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

  > No, we do nothing of the kind.  Just because everybody and their dog
  > know what MELPA is and how to configure Emacs to use it, doesn't mean
  > _we_ told them.  Exactly like we don't "recommend" using MS-Windows,
  > although quite a few of Emacs users do, witness the discussions on
  > Reddit as one example.

We exist in a world in which lots of people willingly accept
practices that our goal is to eliminate.  That means we walk
a narrow ridge.  On one side, we could risk endorsing and
supporting exactly the wrongs we denounce.  On the other side,
we risk becoming less popular.

We want to avoid the latter, but we abolutely must avoid
the former.  Popularity is not success if it comes at the cost
of abandoning our goal.

Therefore we do not recommend MELPA.  We do not mention the existence
of about MELPA.  If people know about it anyway, that is not our doing
so we are not morally responsible.

Eli explained the details what this means.

Stefan wrote:

  > The way I see it, currently Emacs de-facto recommends to most of its
  > users to add MELPA to their `package-archives`.

To balance between the two cliff edges, we have to recognize both edges.
The expression "de facto recommends" denies one of them; it equates
staying on the ridge with falling off.  That would be self-defeating,
so we insist on the distinction and do not equate those.

  > Of course, those few not-quite-libre packages could pose problems for
  > that since they go against some of our values, so maybe we should not
  > add MELPA itself, but the "libre-MELPA" subset (which someone will have
  > to create and maintain).

That would not go against or morals.  It is not absolutely out of the
question.  But it would have a big drawback of a different kind: we
would effectively lose control over an aspect Emacs development.  We
want to keep some control over that, so we should not do this.

If the shorthand.el approach does enable us to fix our namespace problems,
that problem would be somewhat smaller; there would be a limit to
how bad it could get.

The other thing we try to achieve by recommending GNU ELPA and not
other ELPAs is to motivate package developers to do the two things
that enable us to put the packages into Emacs itself: sign
assignments, and rework them to fit our non-moral standards.
I think this is important.

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

Re: PL support

[Stefan Monnier]

> We exist in a world in which lots of people willingly accept
> practices that our goal is to eliminate.  That means we walk
> a narrow ridge.  On one side, we could risk endorsing and
> supporting exactly the wrongs we denounce.  On the other side,
> we risk becoming less popular.
>
> We want to avoid the latter, but we abolutely must avoid
> the former.  Popularity is not success if it comes at the cost
> of abandoning our goal.
>
> Therefore we do not recommend MELPA.  We do not mention the existence
> of about MELPA.  If people know about it anyway, that is not our doing
> so we are not morally responsible.

If I were a maintainer or contributor of MELPA, I'd be offended by what
you wrote.  While MELPA does contains a few Free Software packages which
only work when coupled with proprietary software, the *vast* majority of
the packages are nothing but Free Software.

>   > The way I see it, currently Emacs de-facto recommends to most of its
>   > users to add MELPA to their `package-archives`.
> To balance between the two cliff edges, we have to recognize both edges.
> The expression "de facto recommends" denies one of them; it equates
> staying on the ridge with falling off.  That would be self-defeating,
> so we insist on the distinction and do not equate those.

Our unwillingness to make Free Software packages like Magit or Tuareg
easily installable into Emacs with no extra configuration forces many
of our users to add MELPA to their `package-archives`.

So, I stand by my claim that we de facto recommend to most of our
users to add MELPA to their `package-archives`, and if you think we
don't, I think you're just deluding yourself.

>   > Of course, those few not-quite-libre packages could pose problems for
>   > that since they go against some of our values, so maybe we should not
>   > add MELPA itself, but the "libre-MELPA" subset (which someone will have
>   > to create and maintain).
> That would not go against or morals.  It is not absolutely out of the
> question.  But it would have a big drawback of a different kind: we
> would effectively lose control over an aspect Emacs development.

I think your judgment is quite faulty here, for the simple reason that
you don't understand the extent of the amount of development that's
taking place outside of emacs-devel and over which we hence already have
no control.


        Stefan

Re: PL support

[Alfred M. Szmidt]

   Our unwillingness to make Free Software packages like Magit or Tuareg
   easily installable into Emacs with no extra configuration forces many
   of our users to add MELPA to their `package-archives`.

I'm sure that Magit or Tuareg are most welcome to be part of Emacs if
the the needed paper work is done.  

An idea maybe e.g., Magit could join as a a GNU project, and followed
the needed rules for a GNU project but without copyright assignments
to the FSF.  Then Magit could be listed in the package-archives list.
It would not be part of Emacs, but it would safeguard the situation of
not falling into a trap of recommending non-free software, etc.

The unwillingness you speak of is falling into a trap of recommending
things that the GNU project is activley working against -- non-free
software.  Not an unwillingness to add things.

Re: PL support

[Stefan Monnier]

>    Our unwillingness to make Free Software packages like Magit or Tuareg
>    easily installable into Emacs with no extra configuration forces many
>    of our users to add MELPA to their `package-archives`.
>
> I'm sure that Magit or Tuareg are most welcome to be part of Emacs if
> the the needed paper work is done.  
>
> An idea maybe e.g., Magit could join as a a GNU project, and followed
> the needed rules for a GNU project but without copyright assignments
> to the FSF.  Then Magit could be listed in the package-archives list.
> It would not be part of Emacs, but it would safeguard the situation of
> not falling into a trap of recommending non-free software, etc.
>
> The unwillingness you speak of is falling into a trap of recommending
> things that the GNU project is activley working against -- non-free
> software.  Not an unwillingness to add things.

Just like RMS you conflate "hasn't signed copyright paperwork and is not
interested in following our coding rules" with "things that the GNU
project is activley working against -- non-free software".

You're describing as enemies people who simply want to write their Free
Software under a different set of rules.  That ends up playing in the
hands of those who really don't care about Free Software.


        Stefan

Re: PL support

[Alfred M. Szmidt]

   >    Our unwillingness to make Free Software packages like Magit or Tuareg
   >    easily installable into Emacs with no extra configuration forces many
   >    of our users to add MELPA to their `package-archives`.
   >
   > I'm sure that Magit or Tuareg are most welcome to be part of Emacs if
   > the the needed paper work is done.  
   >
   > An idea maybe e.g., Magit could join as a a GNU project, and followed
   > the needed rules for a GNU project but without copyright assignments
   > to the FSF.  Then Magit could be listed in the package-archives list.
   > It would not be part of Emacs, but it would safeguard the situation of
   > not falling into a trap of recommending non-free software, etc.
   >
   > The unwillingness you speak of is falling into a trap of recommending
   > things that the GNU project is activley working against -- non-free
   > software.  Not an unwillingness to add things.

   Just like RMS you conflate "hasn't signed copyright paperwork and is not
   interested in following our coding rules" with "things that the GNU
   project is activley working against -- non-free software".

I do not think I have and I do not think RMS did so either.  You are
raising a tanget and not addressing the point I was trying to make.

It shouldn't be a suprise that if something is part of Emacs, the same
rules should apply -- whatever those are for that specific project.
You've are suggesting that Emacs should neglect to follow its own
rules.  

I suggested how a package (it could also be as some have suggested a
non(?)-GNU not-part-of-EmacsLPA repository) could be made easily
installable which was part of your goal, but still able to follow its
own technical guidelines and still be acceptable to be directly
recommend since it would follow the overall guideline of the GNU
project in rejecting non-free software.

That is assuming that the e.g. Magit developers want their software to
be part of Emacs.

The most impotant goal of GNU Emacs and the GNU project is that of
free software.  So if there is something that would work against those
goals even slightly it will be rejected -- you called this an
unwillingness, but it is a matter of upholding the project mission and
goals.

   You're describing as enemies people who simply want to write their Free
   Software under a different set of rules.  That ends up playing in the
   hands of those who really don't care about Free Software.

Sorry, but that is a immense misintepretation of what I wrote, and I
think you are quite aware of that.  Nobody is describing anyone as an
enemy.

Re: PL support

[Stefan Kangas]

ams@gnu.org (Alfred M. Szmidt) writes:

> An idea maybe e.g., Magit could join as a a GNU project, and followed
> the needed rules for a GNU project but without copyright assignments
> to the FSF.  Then Magit could be listed in the package-archives list.
> It would not be part of Emacs, but it would safeguard the situation of
> not falling into a trap of recommending non-free software, etc.

That's perhaps not such a bad idea, only you need to convince the Magit
maintainers to agree to that.  And then do the same again and again for
every single package that we are interested in.

Why not create something like "GNU ELPA Contrib" or "MELPA-libre", or
even "Non-GNU ELPA"?  We would maintain full control of the included
packages, ban recommending non-free software, maintain the coding
standards we think are important, and all the rest of it.

Best regards,
Stefan Kangas

Re: PL support

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

  > Our unwillingness to make Free Software packages like Magit or Tuareg
  > easily installable into Emacs with no extra configuration forces many
  > of our users to add MELPA to their `package-archives`.

It doesn't force anyone to do anything.  Please stop the
exaggeration; that is not valid reasoning, just venting.

As it happens, we are working on putting Magit into Emacs.
We want to do so.  But that is a different issue.

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

Re: PL support

[조성빈]

> 2020. 5. 13. 오후 12:59, Richard Stallman <rms@gnu.org> 작성:
>
> [[[ 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. ]]]
>
>> Our unwillingness to make Free Software packages like Magit or Tuareg
>> easily installable into Emacs with no extra configuration forces many
>> of our users to add MELPA to their `package-archives`.
>
> It doesn't force anyone to do anything.  Please stop the
> exaggeration; that is not valid reasoning, just venting.

That’s not exaggeration. That’s the current status quo. MELPA is ubiquitous.
It’s not optional if you want a not-shit Emacs environment. Almost all
package.el users have MELPA added — I think that would apply to the members  
of
this mailing list too. Dismissing a valid argument as ‘exaggeration’ when you
don’t know what is happening on GitHub or /r/emacs/ (with valid reasons)  
looks
more like venting to me.

> As it happens, we are working on putting Magit into Emacs.
> We want to do so.  But that is a different issue.
>
> -- 
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>

Re: PL support

[tomas]

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

On Wed, May 13, 2020 at 07:02:38PM +0900, 조성빈 wrote:

[...]

> That’s not exaggeration. That’s the current status quo. MELPA is ubiquitous.
> It’s not optional if you want a not-shit Emacs environment [...]

Please stop this hostility. My Emacs environment is "not-shit" without any
of MELPA. Your world isn't necessarily other people's world (and vice-versa).

I don't call your environment "shit", so please stop calling mine that.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: PL support

[João Távora]

On Wed, May 13, 2020 at 1:29 PM <tomas@tuxteam.de> wrote:

> > That’s not exaggeration. That’s the current status quo. MELPA is ubiquitous.
> > It’s not optional if you want a not-shit Emacs environment [...]
> Please stop this hostility. My Emacs environment is "not-shit" without any
> of MELPA. Your world isn't necessarily other people's world (and vice-versa).

I agree.  Some of this discussion is based on the presumption that
popularity somehow equals quality, much like Reddit likes to equate
it with truth.

João

Re: PL support

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > Our unwillingness to make Free Software packages like Magit or Tuareg
>   > easily installable into Emacs with no extra configuration forces many
>   > of our users to add MELPA to their `package-archives`.
>
> It doesn't force anyone to do anything.  Please stop the
> exaggeration; that is not valid reasoning, just venting.

According to Merriam-Webster, "forced" means "compelled by force or
necessity : involuntary".  I'm not sure I understand why using that word
is exaggerating.

Users have no other choice than adding MELPA to `package-archives' if
they want to use Emacs for certain things.  For example editing some
popular programming languages and using certain tools effectively.

The other alternative is of course to not use Emacs for that.  But
arguably that's not much of a choice.

Best regards,
Stefan Kangas

Re: PL support

[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 don't know anything about Tuareg, but it is not necessary to use
Magit.  Please don't exaggerate.


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

Re: PL support

[Dmitry Gutov]

On 11.05.2020 20:11, Eli Zaretskii wrote:

>> In the meantime, we're losing out on nearly-built-in support for
>> many file types, e.g. yaml-mode.
> 
> What do you mean by "nearly-built-in support"?  And how are we losing
> it?

If some wants to edit some ML files, they can 'M-x package-install 
sml-mode'. If they want a popup based completion interface, then can 
'M-x package-install company' (and M-x global-company-mode, okay). All 
fast, without a need to customize anything.

For YAML, for example, this is not an option. But it could be.

>> One obvious thing: every package is highly unlikely to nuke your
>> machine, or steal your credentials.
> 
> Sorry, but this is not our problem.  We cannot fix the entire world.
> If Emacs users who install packages from MELPA have fears about their
> security, let them take this up with MELPA admins, or fork MELPA and
> make their own site, or do anything else.  This isn't part of the
> problem that the Emacs project should tackle.

So we don't recommend MELPA in our docs.

>> We could also have other differentiating features. For example, asking
>> authors of "external" packages to sign commits that bump the version number.
> 
> Again, not our problem.  We have enough on our plate already.

You're probably talking about yourself. GNU ELPA has largely been 
Stefan's project (though other people helped).

Project.el, xref.el and eldoc.el in GNU ELPA (Was: PL support)

[João Távora]

On Mon, May 11, 2020 at 7:12 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> > Again, not our problem.  We have enough on our plate already.
>
> You're probably talking about yourself. GNU ELPA has largely been
> Stefan's project (though other people helped).

And I just want to point out, again (diverting the subject a little bit)
that it is very useful, particularly because of the :core package
feature that allows it to distribute reasonably stable parts of the
slow-to-release Emacs version in much quicker fashion. This
is kind of a game-changer, at least in my opinion, and we should
be very very thankful to Stefan (and those other people :-) )

Speaking of that, as discussed earlier with Stefan and Dmitry I'm
planning on making project.el, xref.el and eldoc.el be GNU ELPA
:core packages, and making the Eglot package depend on them.
Any objection?

João

PS: back to the topic of GNU ELPA, it is true that it also has
what I now see as a secondary mission, to distribute
commonly used packages which the core doesn't depend
on.  That goal is arguably being fulfilled better by MELPA,
I believe.  If all that's blocking passage of a package from
MELPA into ELPA is the use of s.el and similar stuff,
my opinion is that  we focus on a technical solution to
that.

Re: PL support

[Eli Zaretskii]

> Cc: rms@gnu.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 21:11:50 +0300
> 
> > What do you mean by "nearly-built-in support"?  And how are we losing
> > it?
> 
> If some wants to edit some ML files, they can 'M-x package-install 
> sml-mode'. If they want a popup based completion interface, then can 
> 'M-x package-install company' (and M-x global-company-mode, okay). All 
> fast, without a need to customize anything.
> 
> For YAML, for example, this is not an option. But it could be.

I don't see how a one-time addition of a simple customization could be
characterized as "losing".

> GNU ELPA has largely been Stefan's project

That's news to me.  Last I heard, Stefan stepped down from maintaining
Emacs some time ago.

Re: PL support

[Dmitry Gutov]

On 11.05.2020 21:43, Eli Zaretskii wrote:

>> If some wants to edit some ML files, they can 'M-x package-install
>> sml-mode'. If they want a popup based completion interface, then can
>> 'M-x package-install company' (and M-x global-company-mode, okay). All
>> fast, without a need to customize anything.
>>
>> For YAML, for example, this is not an option. But it could be.
> 
> I don't see how a one-time addition of a simple customization could be
> characterized as "losing".

See my other messages. Also discussions on initial user experience and 
better getting-started documentation.

>> GNU ELPA has largely been Stefan's project
> 
> That's news to me.  Last I heard, Stefan stepped down from maintaining
> Emacs some time ago.

I don't see what that has to do with it.

Re: PL support

[Eli Zaretskii]

> Cc: rms@gnu.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 22:08:07 +0300
> 
> >> GNU ELPA has largely been Stefan's project
> > 
> > That's news to me.  Last I heard, Stefan stepped down from maintaining
> > Emacs some time ago.
> 
> I don't see what that has to do with it.

It's a GNU project.

Re: PL support

[Alfred M. Szmidt]

   > >> GNU ELPA has largely been Stefan's project
   > > 
   > > That's news to me.  Last I heard, Stefan stepped down from maintaining
   > > Emacs some time ago.
   > 
   > I don't see what that has to do with it.

   It's a GNU project.

Specifically, it is part of the GNU Emacs.

Re: PL support

[Dmitry Gutov]

On 11.05.2020 22:32, Alfred M. Szmidt wrote:
>     > >> GNU ELPA has largely been Stefan's project
>     > >
>     > > That's news to me.  Last I heard, Stefan stepped down from maintaining
>     > > Emacs some time ago.
>     >
>     > I don't see what that has to do with it.
> 
>     It's a GNU project.
> 
> Specifically, it is part of the GNU Emacs.

So what does the lead maintainer being strapped for time have to do with 
it? Other people routinely work on GNU Emacs and various related projects.

Re: PL support

[Alfred M. Szmidt]

It means that GNU ELPA isn't a single person's project, rather it is a
project by the GNU project, specifically a part of GNU Emacs.

Re: PL support

[Eli Zaretskii]

> Cc: rms@gnu.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 23:02:33 +0300
> 
> >     It's a GNU project.
> > 
> > Specifically, it is part of the GNU Emacs.
> 
> So what does the lead maintainer being strapped for time have to do with 
> it? Other people routinely work on GNU Emacs and various related projects.

They do, and everyone's contributions are greatly appreciated.  But
our standards and conventions, and our procedures are common and
should be agreed upon, regardless of who personally does what.
Otherwise we will cease to be a coherent project with common goals and
practices.

Re: PL support

[Dmitry Gutov]

On 12.05.2020 05:27, Eli Zaretskii wrote:
>> Cc:rms@gnu.org,cpitclaudel@gmail.com,monnier@iro.umontreal.ca,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov<dgutov@yandex.ru>
>> Date: Mon, 11 May 2020 23:02:33 +0300
>>
>>>      It's a GNU project.
>>>
>>> Specifically, it is part of the GNU Emacs.
>> So what does the lead maintainer being strapped for time have to do with
>> it? Other people routinely work on GNU Emacs and various related projects.
> They do, and everyone's contributions are greatly appreciated.  But
> our standards and conventions, and our procedures are common and
> should be agreed upon, regardless of who personally does what.
> Otherwise we will cease to be a coherent project with common goals and
> practices.

Sorry, I'm not sure what this is going to mean in practice. And you 
going to dismiss an existing sub-project of Emacs (GNU ELPA) because you 
don't have enough time AND because people haven't been formatting their 
commit messages correctly?

Re: PL support

[Eli Zaretskii]

> Cc: ams@gnu.org, rms@gnu.org, cpitclaudel@gmail.com,
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 12 May 2020 16:55:17 +0300
> 
> >> So what does the lead maintainer being strapped for time have to do with
> >> it? Other people routinely work on GNU Emacs and various related projects.
> > They do, and everyone's contributions are greatly appreciated.  But
> > our standards and conventions, and our procedures are common and
> > should be agreed upon, regardless of who personally does what.
> > Otherwise we will cease to be a coherent project with common goals and
> > practices.
> 
> Sorry, I'm not sure what this is going to mean in practice. And you 
> going to dismiss an existing sub-project of Emacs (GNU ELPA) because you 
> don't have enough time AND because people haven't been formatting their 
> commit messages correctly?

Sorry, I cannot parse this.  I didn't mention dismissing anything, and
I don't see how my lack of time and formatting of commit messages have
any relation to what I wrote (or to the general issue at hand,
really).

Re: PL support

[Dmitry Gutov]

On 12.05.2020 20:04, Eli Zaretskii wrote:
>> Cc: ams@gnu.org, rms@gnu.org, cpitclaudel@gmail.com,
>>   monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Tue, 12 May 2020 16:55:17 +0300
>>
>>>> So what does the lead maintainer being strapped for time have to do with
>>>> it? Other people routinely work on GNU Emacs and various related projects.
>>> They do, and everyone's contributions are greatly appreciated.  But
>>> our standards and conventions, and our procedures are common and
>>> should be agreed upon, regardless of who personally does what.
>>> Otherwise we will cease to be a coherent project with common goals and
>>> practices.
>>
>> Sorry, I'm not sure what this is going to mean in practice. And you
>> going to dismiss an existing sub-project of Emacs (GNU ELPA) because you
>> don't have enough time AND because people haven't been formatting their
>> commit messages correctly?
> 
> Sorry, I cannot parse this.  I didn't mention dismissing anything, and
> I don't see how my lack of time and formatting of commit messages have
> any relation to what I wrote (or to the general issue at hand,
> really).

A reminder, then: I gave an argument for keeping GNU ELPA around, and 
you responded with "have enough on our plate already".

I wasn't asking for an immediate fix to that problem, but pointing out 
that, to my knowledge, GNU ELPA might be the best positioned to tackle 
this problem, now or later, among all existing popular package archives 
for Emacs.

Anyway, since you (or RMS) don't seem to support the goals with which 
apparently Stefan created it, and some people contributed to it, these 
arguments may be moot now.

Going back to the question of coding standards: I don't see anything 
outrageous in the idea that some parts of Emacs (e.g. the "main core", 
however we would define that) could be subject to more strict 
documentation requirements that some other, more faster-moving parts. As 
long as everybody is clear on the criteria.

Re: PL support

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

  > So I think deferring the step of asking for copyright assignment until 
  > we actually want to do the move to the core.

If getting copyright assignments were a matter of simply doing work,
this would make sense: don't do the work until we know we need it.
But that's not how it is.

The passage of years makes convincing contributors more difficult.
Occasionally even impossible, if the contributor is unreachable.
Therefore, postponing it is unwise.

Stefan responded:

  > I don't think we'd want to defer that late.  Instead, we should seek
  > assignments eagerly but in a non-blocking way.

That avoids substantial gratuitous delay on our part.  However, we would
give up an important way of convincing contributors: "Please do this
so we can put the package in GNU ELPA."

						    Also, we still wouldn't
  > give push rights to people who haven't signed the copyright paperwork.

That would help convince those who are still contributing, but would
not help with past contributors who have stopped.  Also, we would have
to verify that there are no significant unreachable contributors of
that we can delete or replace their code.

In some cases it could be ok to decide, finally, "We won't ever
particularly want to put this in core Emacs," and put it in GNU ELPA
labeled "Never core".  But that is not necessarily a solution.
What if some people start pressuring us to put it in the core,
demanding that we change our rules for the core, saying that
we don't care about making Emacs more powerful, etc?

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

Re: PL support

[Dmitry Gutov]

On 13.05.2020 06:53, Richard Stallman wrote:
> That would help convince those who are still contributing, but would
> not help with past contributors who have stopped.  Also, we would have
> to verify that there are no significant unreachable contributors of
> that we can delete or replace their code.

It would help convince the current maintainers of any given package, who 
are usually among the most prolific contributors. Which is good.

"Past contributors who have stopped" often can't be convinced at all. If 
they stopped, they often do not particularly care about what happens to 
that code now.

> In some cases it could be ok to decide, finally, "We won't ever
> particularly want to put this in core Emacs," and put it in GNU ELPA
> labeled "Never core".  But that is not necessarily a solution.
> What if some people start pressuring us to put it in the core,
> demanding that we change our rules for the core, saying that
> we don't care about making Emacs more powerful, etc?

We have a lot of practice saying no. We'll do that again.

More to the point, I haven't seem anybody demanding (or even strongly 
asking) to put their code in the core. If such conflicts arose in the 
past, it seems package.el mostly solved them.

The heated discussions of the present day are mostly about defaults, 
workflows and policy decisions. People ask for features too, I guess, 
but only when none of existing packages fit the bill.

Re: PL support

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> In general, when we put a package into GNU ELPA, we want to be able
> to move it into the core.

Has it ever been discussed to have two tiers?

That is, keeping the current "ELPA" for code with copyright assignments
only, but opening up a new "ELPA-contrib" where we don't require an
assignment.  The default value of `package-archives' could then be:

   '(("gnu" . "https://elpa.gnu.org/packages/")
     ("gnu-contrib" . "https://elpa.org/packages-contrib/"))

We could work on getting packages moved over to "ELPA proper" at the
rate we decide.

I see great benefits with having some packages being distributed by us
instead of a third party (MELPA).  In particular, we would not have to
worry about recommending and promoting such a repository, since it would
be fully within our control.

Best regards,
Stefan Kangas

Re: PL support

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 11 May 2020 13:11:38 -0700
> Cc: cpitclaudel@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> Has it ever been discussed to have two tiers?

What for?  Other sources for the "other" tier already exist.

Re: PL support

[Dmitry Gutov]

On 09.05.2020 20:58, João Távora wrote:
> I can make a minimal eglot-interfaces.el file for Emacs core
> that defines some hooks, has some docstrings, etc, make _that_
> a :core package and keep business as usual in Eglot in
> Github/Elpa.

That doesn't sound too bad. Bonus points if the same hooks could be 
universal for the LSP protocol, i.e. if lsp-mode could conceivably use 
them too.

Re: PL support

[João Távora]

On Sat, May 9, 2020 at 7:36 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 09.05.2020 20:58, João Távora wrote:
> > I can make a minimal eglot-interfaces.el file for Emacs core
> > that defines some hooks, has some docstrings, etc, make _that_
> > a :core package and keep business as usual in Eglot in
> > Github/Elpa.
>
> That doesn't sound too bad. Bonus points if the same hooks could be
> universal for the LSP protocol, i.e. if lsp-mode could conceivably use
> them too.

The thing is, you haven't exactly explained why Eglot in core sounds
bad, either.  You say Eglot in GNU Elpa is decent already and I agree.

But having it in core would bring some advantages, particularly for
me, I admit.  Having to jump back and forth between xref.el, project.el,
eldoc.el, flymake.el, jsonrpc.el and eglot.el in different repos is not
much fun. I really wish I could do it here: a holistic approach is much
better.

And you would _still_ have it in GNU Elpa for older Emacsen to use.

João

Re: PL support

[Dmitry Gutov]

On 09.05.2020 21:47, João Távora wrote:

>> That doesn't sound too bad. Bonus points if the same hooks could be
>> universal for the LSP protocol, i.e. if lsp-mode could conceivably use
>> them too.
> 
> The thing is, you haven't exactly explained why Eglot in core sounds
> bad, either.  You say Eglot in GNU Elpa is decent already and I agree.

Imagine taking the whole of MELPA and putting it inside the Emacs 
repository. Why would it be a bad idea? Lots of different codebases 
developed by different people with different responsibilities.

Our bug tracker and development workflow has no solutions to this 
problem: everybody has to read every bug report and every commit message.

> But having it in core would bring some advantages, particularly for
> me, I admit.  Having to jump back and forth between xref.el, project.el,
> eldoc.el, flymake.el, jsonrpc.el and eglot.el in different repos is not
> much fun.

These are just two repositories between these packages.

Making concerted changes could become easier sometimes, but it would 
also become easier to break backward compatibility. All of these 
packages don't serve Eglot only, and making a change in Emacs separately 
is a good reminder of that separation.

Re: PL support

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>,
>  emacs-devel <emacs-devel@gnu.org>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 9 May 2020 22:12:06 +0300
> 
> On 09.05.2020 21:47, João Távora wrote:
> 
> >> That doesn't sound too bad. Bonus points if the same hooks could be
> >> universal for the LSP protocol, i.e. if lsp-mode could conceivably use
> >> them too.
> > 
> > The thing is, you haven't exactly explained why Eglot in core sounds
> > bad, either.  You say Eglot in GNU Elpa is decent already and I agree.
> 
> Imagine taking the whole of MELPA and putting it inside the Emacs 
> repository.

Adding a couple of packages doesn't mean we want or need to add all of
them.  This is the case where redictio ad absurdum is NOT a good
argument.

Re: PL support

[Dmitry Gutov]

On 09.05.2020 22:23, Eli Zaretskii wrote:
> Adding a couple of packages doesn't mean we want or need to add all of
> them.  This is the case where redictio ad absurdum is NOT a good
> argument.

I'm arguing for the general principle, though: only adding when there's 
clear advantage.

Re: PL support

[Eli Zaretskii]

> Cc: joaotavora@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 9 May 2020 22:38:52 +0300
> 
> On 09.05.2020 22:23, Eli Zaretskii wrote:
> > Adding a couple of packages doesn't mean we want or need to add all of
> > them.  This is the case where redictio ad absurdum is NOT a good
> > argument.
> 
> I'm arguing for the general principle, though: only adding when there's 
> clear advantage.

Everyone will agree with that, the disagreements are about whether
there is or isn't a clear advantage.

Re: PL support

[Dmitry Gutov]

On 09.05.2020 22:45, Eli Zaretskii wrote:

>> I'm arguing for the general principle, though: only adding when there's
>> clear advantage.
> 
> Everyone will agree with that, the disagreements are about whether
> there is or isn't a clear advantage.

Yes, the argument is obvious, hence I only made it when pressed with the 
question.

Re: PL support

[João Távora]

On Sat, May 9, 2020 at 8:12 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> Our bug tracker and development workflow has no solutions to this
> problem: everybody has to read every bug report and every commit message.

This is good.  I for one would like to spend a lot less time on Github.

> Making concerted changes could become easier sometimes, but it would
> also become easier to break backward compatibility.

Really? Am I breaking backward compatibility all the time in Emacs?
Don't we have tests? Don't we have a (crude) namespacing system
for those libraries?  Don't we have Eli, the ever-vigilant? And Stefan
and everybody else?  And weren't you the one the one who told me
not to worry about that when refactoring Flymake?

https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00415.html

> and making a change in Emacs separately is a good reminder of that separation.

Really, are you telling me this?  Do you really think I (and other
developers) need
to be actively annoyed to be reminded of that? A file isn't enough separation?
That's not the point of GNU ELPA at all.

João

Re: PL support

[Dmitry Gutov]

On 09.05.2020 22:49, João Távora wrote:
> On Sat, May 9, 2020 at 8:12 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
>> Our bug tracker and development workflow has no solutions to this
>> problem: everybody has to read every bug report and every commit message.
> 
> This is good.  I for one would like to spend a lot less time on Github.

You might be happy with the reduced volume of bug report reaching you 
after such a move.

Maybe less happy later to see people complaining about some problems in 
Eglot on Twitter, Reddit, their blogs, etc. And yet never bothering to 
'M-x report-emacs-bug' them, for whatever reasons. I wonder what your 
choice in such a situation is going to be: ignore the problems (not 
reported = not a bug), or go out anyway and search for such negative 
feedback and ask people to "please M-x report-emacs-bug already". 
Because we have had been doing a lot of the latter.

In any case, if you like debbugs, you could just move Eglot's 
development to GNU ELPA.

>> Making concerted changes could become easier sometimes, but it would
>> also become easier to break backward compatibility.
> 
> Really? Am I breaking backward compatibility all the time in Emacs?

Not really. But that's the only conceptual advantage I could see: 
changing things in tandem. To *not* break things, at least for me, 
packages have to be considered separately... and then having them in the 
same repo is not so big an advantage.

In any case, it's not my main demotivator. Increased debbugs and 
emacs-diffs traffic is. I'd rather much work on code that sorting 
through email not related to me. There is nothing at all personal in this.

> Don't we have tests? Don't we have a (crude) namespacing system
> for those libraries?  Don't we have Eli, the ever-vigilant? And Stefan
> and everybody else?  And weren't you the one the one who told me
> not to worry about that when refactoring Flymake?

Eli who hasn't found time to try out Eglot yet. Same for Stefan, I imagine.

Going back to xref and project.el, for instance, it wouldn't be 
sufficient to submit a patch and, in the explanation, assume my 
familiarity with Eglot's code. So I kind of doubt it will help you a lot.

> https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00415.html

Yup, it was a big rewrite, and Flymake was not used as much as e.g. 
Eldoc is. I'm not saying you can never break backward compatibility, 
just that you *usually* cannot break it.

>> and making a change in Emacs separately is a good reminder of that separation.
> 
> Really, are you telling me this?  Do you really think I (and other
> developers) need
> to be actively annoyed to be reminded of that? A file isn't enough separation?
> That's not the point of GNU ELPA at all.

Um, of course not. GNU ELPA is our repository of recommended packages.

Re: PL support

[João Távora]

On Sat, May 9, 2020 at 9:09 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> >> problem: everybody has to read every bug report and every commit message.
> > This is good.  I for one would like to spend a lot less time on Github.
> Maybe less happy later to see people complaining about some problems in
> Eglot on Twitter, Reddit, their blogs, etc.

I don't use those.  People know where to reach me.  If you frequent
those places, tell them I'm an email away. If they prefer to complain
in public in places I don't frequent, how is that my fault?

> > Really? Am I breaking backward compatibility all the time in Emacs?
> Not really. But that's the only conceptual advantage I could see:
> changing things in tandem. To *not* break things, at least for me,
> packages have to be considered separately... and then having them in the
> same repo is not so big an advantage.
>
> In any case, it's not my main demotivator. Increased debbugs and
> emacs-diffs traffic is. I'd rather much work on code that sorting
> through email not related to me. There is nothing at all personal in this.

Huh? Are you saying we make too many commits to Emacs?
Then make an email filter for emacs-diffs that checks the files touches,
surely you can do that. Same for debbugs.

> > Don't we have tests? Don't we have a (crude) namespacing system
> > for those libraries?  Don't we have Eli, the ever-vigilant? And Stefan
> > and everybody else?  And weren't you the one the one who told me
> > not to worry about that when refactoring Flymake?
>
> Eli who hasn't found time to try out Eglot yet. Same for Stefan, I imagine.

I thought you were concerned about protecting xref and eldoc and such.
so what has that got to do with it?

> Going back to xref and project.el, for instance, it wouldn't be
> sufficient to submit a patch and, in the explanation, assume my
> familiarity with Eglot's code.  So I kind of doubt it will help you a lot.

It wouldn't be indeed.  And it would not be necessary, either. This is
how it goes.  I tell you: "we need this interface in eglot.el, here is a
patch that opens it.  And you check it on its merits. And you get to
see it in action, and compiled in the same test run, even.". It's
really standard stuff.

? > https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00415.html
>
> Yup, it was a big rewrite, and Flymake was not used as much as e.g.
> Eldoc is. I'm not saying you can never break backward compatibility,
> just that you *usually* cannot break it.

But I _didn't_ break it, is what I'm saying (in fact flymake-proc.el
should still work as far as I can tell) I'm just pointing out you weren't
as concerned about it then, to the point of encouraging me not to
worry about it.

> > Really, are you telling me this?  Do you really think I (and other
> > developers) need
> > to be actively annoyed to be reminded of that? A file isn't enough separation?
> > That's not the point of GNU ELPA at all.
> Um, of course not. GNU ELPA is our repository of recommended packages.

Right, so you agree with me.  GNU ELPA It's not a way to "remind developers"
of the need for modularity.

Maybe you missed this: Eglot will always _also_ be in GNU ELPA.
And it has to be compatible with Emacs 26.3 so it cannot abuse new
interfaces.

João

Re: PL support

[Dmitry Gutov]

On 09.05.2020 23:25, João Távora wrote:

>>>> problem: everybody has to read every bug report and every commit message.
>>> This is good.  I for one would like to spend a lot less time on Github.
>> Maybe less happy later to see people complaining about some problems in
>> Eglot on Twitter, Reddit, their blogs, etc.
> 
> I don't use those.  People know where to reach me.  If you frequent
> those places, tell them I'm an email away.

I certainly don't frequent *all* of these places.

> If they prefer to complain
> in public in places I don't frequent, how is that my fault?

You could just go away and do nothing, and any bug reports still 
wouldn't be "your fault" (we promise NO WARRANTY, after all).

But Emacs would be poorer for it.

>>> Really? Am I breaking backward compatibility all the time in Emacs?
>> Not really. But that's the only conceptual advantage I could see:
>> changing things in tandem. To *not* break things, at least for me,
>> packages have to be considered separately... and then having them in the
>> same repo is not so big an advantage.
>>
>> In any case, it's not my main demotivator. Increased debbugs and
>> emacs-diffs traffic is. I'd rather much work on code that sorting
>> through email not related to me. There is nothing at all personal in this.
> 
> Huh? Are you saying we make too many commits to Emacs?
> Then make an email filter for emacs-diffs that checks the files touches,
> surely you can do that. Same for debbugs.

I wouldn't say I can. It's especially not easy with the set of packages 
I take interest it being more than a handful of files already.

>>> Don't we have tests? Don't we have a (crude) namespacing system
>>> for those libraries?  Don't we have Eli, the ever-vigilant? And Stefan
>>> and everybody else?  And weren't you the one the one who told me
>>> not to worry about that when refactoring Flymake?
>>
>> Eli who hasn't found time to try out Eglot yet. Same for Stefan, I imagine.
> 
> I thought you were concerned about protecting xref and eldoc and such.
> so what has that got to do with it?

You misunderstood me, then. Thought I clarified that in subsequent messages.

>> Going back to xref and project.el, for instance, it wouldn't be
>> sufficient to submit a patch and, in the explanation, assume my
>> familiarity with Eglot's code.  So I kind of doubt it will help you a lot.
> 
> It wouldn't be indeed.  And it would not be necessary, either. This is
> how it goes.  I tell you: "we need this interface in eglot.el, here is a
> patch that opens it.  And you check it on its merits. And you get to
> see it in action, and compiled in the same test run, even.". It's
> really standard stuff.

Like we do now already, right?

> ? > https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00415.html
>>
>> Yup, it was a big rewrite, and Flymake was not used as much as e.g.
>> Eldoc is. I'm not saying you can never break backward compatibility,
>> just that you *usually* cannot break it.
> 
> But I _didn't_ break it, is what I'm saying (in fact flymake-proc.el
> should still work as far as I can tell) I'm just pointing out you weren't
> as concerned about it then, to the point of encouraging me not to
> worry about it.

I'm saying the backward compatibility concerns and the necessity to 
consider of packages on their own pretty much negate the ability to make 
changes in concert. That's my view, of course.

Re: PL support

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>,
>  emacs-devel <emacs-devel@gnu.org>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 9 May 2020 23:09:36 +0300
> 
> Eli who hasn't found time to try out Eglot yet

I will if you agree to take some of my duties upon yourself.  Deal?

Re: PL support

[Dmitry Gutov]

On 10.05.2020 05:30, Eli Zaretskii wrote:
>> Cc: Eli Zaretskii<eliz@gnu.org>, Stefan Monnier<monnier@iro.umontreal.ca>,
>>   emacs-devel<emacs-devel@gnu.org>
>> From: Dmitry Gutov<dgutov@yandex.ru>
>> Date: Sat, 9 May 2020 23:09:36 +0300
>>
>> Eli who hasn't found time to try out Eglot yet
> I will if you agree to take some of my duties upon yourself.  Deal?

Maybe I should clarify that it wasn't a criticism of you, but of the 
intention to rely on you for extra design/development/review help.

Re: PL support

[Eli Zaretskii]

On May 10, 2020 6:33:11 AM GMT+03:00, Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 10.05.2020 05:30, Eli Zaretskii wrote:
> >> Cc: Eli Zaretskii<eliz@gnu.org>, Stefan
> Monnier<monnier@iro.umontreal.ca>,
> >>   emacs-devel<emacs-devel@gnu.org>
> >> From: Dmitry Gutov<dgutov@yandex.ru>
> >> Date: Sat, 9 May 2020 23:09:36 +0300
> >>
> >> Eli who hasn't found time to try out Eglot yet
> > I will if you agree to take some of my duties upon yourself.  Deal?
> 
> Maybe I should clarify that it wasn't a criticism of you, but of the 
> intention to rely on you for extra design/development/review help.

You could have fooled me regarding the non-criticism.  And now you are effectively saying I cannot be relied upon to do my job well enough.  Based on what facts?

Re: PL support

[João Távora]

On Sun, May 10, 2020 at 4:33 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 10.05.2020 05:30, Eli Zaretskii wrote:
> >> Cc: Eli Zaretskii<eliz@gnu.org>, Stefan Monnier<monnier@iro.umontreal.ca>,
> >>   emacs-devel<emacs-devel@gnu.org>
> >> From: Dmitry Gutov<dgutov@yandex.ru>
> >> Date: Sat, 9 May 2020 23:09:36 +0300
> >>
> >> Eli who hasn't found time to try out Eglot yet
> > I will if you agree to take some of my duties upon yourself.  Deal?
> Maybe I should clarify that it wasn't a criticism of you, but of the
> intention to rely on you for extra design/development/review help.

I didn't say I was going to _rely_ on Eli, just that the lead maintainer's
eye is a very good thing to have, yes.  And, FTR, for all the disagreements
I've had with him, I never ever found him uninterested or unwilling to
participate in a technical discussion, and work on with me on very tricky
bugs, (bug#34394 comes to mind) even for things that don't affect him
in the immediate.  And, I'm happy to say, same goes for many in this list.

Maybe some see emacs-devel as a place of naysayers, as if Github
was magically exempted from that.  It's not, it's just mostly exempted
from the scrutiny that goes on here, and this scrutiny is a good thing.
This is why so many things diverge into directions that tear them
far away from Emacs (in the technical or legal aspects) and then find
it unacceptable and surprising that Emacs won't take them back
just like that.

João

Re: PL support

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

  > Our bug tracker and development workflow has no solutions to this 
  > problem: everybody has to read every bug report and every commit message.

We have one common bug database because we have one email address for
reporting bugs.  But that is not the only way we could do it.  We
could subdivide this and have separate bug databases fed by separate
email addresses, if that is better.

In order for it to be better, users need to be able to tell which
place to send each bug report.  There should not be too many places.

We would need to work out a way to pass the bug from one database to
another.

I don't know how hard this is.


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

Re: PL support

[Dmitry Gutov]

On 11.05.2020 05:35, Richard Stallman wrote:
>    > Our bug tracker and development workflow has no solutions to this
>    > problem: everybody has to read every bug report and every commit message.
> 
> We have one common bug database because we have one email address for
> reporting bugs.  But that is not the only way we could do it.  We
> could subdivide this and have separate bug databases fed by separate
> email addresses, if that is better.
> 
> In order for it to be better, users need to be able to tell which
> place to send each bug report.  There should not be too many places.

The frequent approach in big projects is "forwarding" bug reports to 
people responsible for respective piece of code.

Then not everybody has to be subscribed to all bug reports.

Splitting big subprojects (like Gnus) to separate mailboxes could help 
as well, though.

RE: PL support

[Drew Adams]

> > In order for it to be better, users need to be able to tell which
> > place to send each bug report.  There should not be too many places.

And interested users need to be able to subscribe
to those mailing lists, to comment or contribute
in other ways.

> The frequent approach in big projects is "forwarding" bug reports to
> people responsible for respective piece of code.
> Then not everybody has to be subscribed to all bug reports.

As long as there are mailing lists users can subscribe
to, as opposed to bug reports just getting forwarded
to the "people responsible for respective piece of code".

If it's just user-reports-bug-to-maintainer-of-code
then that leaves other users who might be interested
in the problem or solutions out of the loop.

Re: PL support

[Eli Zaretskii]

> Cc: joaotavora@gmail.com, eliz@gnu.org, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 06:01:48 +0300
> 
> The frequent approach in big projects is "forwarding" bug reports to 
> people responsible for respective piece of code.

Most of the code in Emacs doesn't have an "owner", so this cannot work
for us.  Heck, we don't even have appointed few who'd triage every
report quickly and efficiently (which would be one way of preventing
too many people from reading too many email messages).

In general, methods that work well in small projects don't scale when
you try bringing them to Emacs, both because Emacs is much larger (not
just in code size, but also in the number of widely different
expertise domains on which it is based and without understanding which
you cannot efficiently maintain the relevant parts of the code), and
because the number of people who actively track the bug list is so
small.

> Then not everybody has to be subscribed to all bug reports.
> 
> Splitting big subprojects (like Gnus) to separate mailboxes could help 
> as well, though.

It is not easy to track issues for a large project such as ours,
that's true.  But let's please not represent the situation as a total
catastrophe: debbugs does have keywords and sub-projects, and we have
the debbugs package that allows to use those to read only those
reports in which you are interested.  Some of us do use that package.

Re: PL support

[Dmitry Gutov]

On 11.05.2020 18:08, Eli Zaretskii wrote:

>> The frequent approach in big projects is "forwarding" bug reports to
>> people responsible for respective piece of code.
> 
> Most of the code in Emacs doesn't have an "owner", so this cannot work
> for us.  Heck, we don't even have appointed few who'd triage every
> report quickly and efficiently (which would be one way of preventing
> too many people from reading too many email messages).

These are the main reasons why I'm wary of adding more packages to Emacs 
core without solid justification.

Having more core developers should be a plus for sure, but the extra 
cognitive load for everyone else seems unavoidable either way.

> In general, methods that work well in small projects don't scale when
> you try bringing them to Emacs, both because Emacs is much larger (not
> just in code size, but also in the number of widely different
> expertise domains on which it is based and without understanding which
> you cannot efficiently maintain the relevant parts of the code), and
> because the number of people who actively track the bug list is so
> small.

The methods I was referring to are used for big projects (e.g. Mozilla 
Firefox), as well as commercial projects of varied size with enough 
manpower to do the triage work.

Emacs, on the other hand, uses a "small project" workflow despite being, 
let's say, medium-size. And changing the workflows seems to be not in 
the cards right now.

So it seems to me that the logical thing would be to try to slim it down 
where feasible rather than simply keep growing.

>> Then not everybody has to be subscribed to all bug reports.
>>
>> Splitting big subprojects (like Gnus) to separate mailboxes could help
>> as well, though.
> 
> It is not easy to track issues for a large project such as ours,
> that's true.  But let's please not represent the situation as a total
> catastrophe: debbugs does have keywords and sub-projects, and we have
> the debbugs package that allows to use those to read only those
> reports in which you are interested.  Some of us do use that package.

I suppose it would help if somebody actually used the 
keywords/sub-projects to forward bugs to other people.

Re: PL support

[Eli Zaretskii]

> Cc: rms@gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 12 May 2020 02:03:58 +0300
> 
> On 11.05.2020 18:08, Eli Zaretskii wrote:
> 
> >> The frequent approach in big projects is "forwarding" bug reports to
> >> people responsible for respective piece of code.
> > 
> > Most of the code in Emacs doesn't have an "owner", so this cannot work
> > for us.  Heck, we don't even have appointed few who'd triage every
> > report quickly and efficiently (which would be one way of preventing
> > too many people from reading too many email messages).
> 
> These are the main reasons why I'm wary of adding more packages to Emacs 
> core without solid justification.

I don't think adding a few more will cause any tangible changes.  We
are also regularly retire packages to lisp/obsolete/.

> Having more core developers should be a plus for sure, but the extra 
> cognitive load for everyone else seems unavoidable either way.

Of course.  But adding packages also tends to add core developers,
albeit slowly.

> So it seems to me that the logical thing would be to try to slim it down 
> where feasible rather than simply keep growing.

Unless we are going to move a significant fraction, it won't help.  To
say nothing of the fact that ELPA packages shouldn't be abandoned,
they should still be maintained.  And moving a package to ELPA doesn't
cause someone outside of the core team to take ownership on that
package, so the overall burden will not be affected.


> > It is not easy to track issues for a large project such as ours,
> > that's true.  But let's please not represent the situation as a total
> > catastrophe: debbugs does have keywords and sub-projects, and we have
> > the debbugs package that allows to use those to read only those
> > reports in which you are interested.  Some of us do use that package.
> 
> I suppose it would help if somebody actually used the 
> keywords/sub-projects to forward bugs to other people.

Indeed.  Any volunteers?

Re: PL support

[Dmitry Gutov]

On 12.05.2020 17:44, Eli Zaretskii wrote:

>>> Most of the code in Emacs doesn't have an "owner", so this cannot work
>>> for us.  Heck, we don't even have appointed few who'd triage every
>>> report quickly and efficiently (which would be one way of preventing
>>> too many people from reading too many email messages).
>>
>> These are the main reasons why I'm wary of adding more packages to Emacs
>> core without solid justification.
> 
> I don't think adding a few more will cause any tangible changes.

True, but I'd rather we took the steps in the other direction.

It also seems like a missed opportunity to show that the Emacs 
leadership takes GNU ELPA seriously, that it *is* "almost part of Emacs" 
it has been touted to be rather than a collection of toys somewhere in 
the backyard.

That would mean incorporating the use of it in some official 
documentation. And what better examples to start with than Eglot and 
Company (or something else, maybe).

> We
> are also regularly retire packages to lisp/obsolete/.

We generally do that only when we're fairly sure the package has very 
little users, and/or its functionality has been superseded by other 
packages. Meaning the case where we already have no expectations of it 
ever being picked up.

But in cases where we think a package is still useful for some, just not 
important enough for us to carefully maintain, we could move it 
"somewhere visible" (and GNU ELPA is better for that than 
lisp/obsolete/) with an explanation, and with the hope that, if there 
are enough users, someone will pick up the responsibility.

I would also like to move out Gnus/Org/Tramp/CEDET personally, but all 
of these sounds like separate, difficult discussions.

>> Having more core developers should be a plus for sure, but the extra
>> cognitive load for everyone else seems unavoidable either way.
> 
> Of course.  But adding packages also tends to add core developers,
> albeit slowly.

And then the developers leave, and we end up maintaining the packages 
more or less indefinitely. CEDET would be one example.

>> So it seems to me that the logical thing would be to try to slim it down
>> where feasible rather than simply keep growing.
> 
> Unless we are going to move a significant fraction, it won't help.  To
> say nothing of the fact that ELPA packages shouldn't be abandoned,
> they should still be maintained.  And moving a package to ELPA doesn't
> cause someone outside of the core team to take ownership on that
> package, so the overall burden will not be affected.

People read package description more often than they read the contents 
of lisp/obsolete.

We don't have to entirely un-maintain the "moved out" packages, the 
degree of continual involvement could be a subject of discussion, or it 
could be decided on a case-by-case basis.

Re: PL support

[Stefan Monnier]

> But having it in core would bring some advantages, particularly for
> me, I admit.  Having to jump back and forth between xref.el, project.el,
> eldoc.el, flymake.el, jsonrpc.el and eglot.el in different repos is not
> much fun. I really wish I could do it here: a holistic approach is much
> better.

Oh, I thought having it elpa.git for more convenient for you (less tied
to Emacs's development cycle).  If you think it's more convenient to
have it in emacs.git, I'm all for it.


        Stefan

Re: PL support

[João Távora]

On Sat, May 9, 2020 at 9:40 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > But having it in core would bring some advantages, particularly for
> > me, I admit.  Having to jump back and forth between xref.el, project.el,
> > eldoc.el, flymake.el, jsonrpc.el and eglot.el in different repos is not
> > much fun. I really wish I could do it here: a holistic approach is much
> > better.
>
> Oh, I thought having it elpa.git for more convenient for you (less tied
> to Emacs's development cycle).  If you think it's more convenient to
> have it in emacs.git, I'm all for it.

Indeed, that's exactly what I'm saying. Because two other libraries
I already maintain and that Eglot depends on are already there
(flymake.el and jsonrpc.el) as :core GNU ELPA  packages,
having eglot.el in emacs.git as a :core package makes perfect
sense to me, as developer.

As I said, I would also see advantages in coordinating with project.el,
xref.el and eldoc.el, especially if they also become :core GNU ELPA
packages (we discussed elsewhere that would have no adverse
effects).

João

Re: PL support

[Sébastien G]

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

Le samedi 09 mai 2020 à 20:46 +0300, Eli Zaretskii a écrit :
> Or maybe we will have a flood of messages tomorrow saying they'd like
> 
> to have Eglot in core ;-)


I'd like to have Eglot in core ;-)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: PL support

[Sébastien G]

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

Le samedi 09 mai 2020 à 18:36 +0100, João Távora a écrit :
> enhance eglot.el to automatically download server programs.


Maybe downloading and installing server programs can be delegate to a
new "external-tools.el" library. Something that can manage not only
language server, but any extrnal tools requested by a mode.

This library could provide an API to:
- Declare, in a single elisp function call, an external tool with a
  name and how install it (which pkg and pkg manager to use)
- Let modes request the presence of specific external tool with a
  single elisp function call
- Modes can, optionnaly, request the latest version of the external
  tool to be present

When an external tools is requested:
- If the tool is not installed: Install it
- If the tool is already installed and latest version is required:
  Update it
- If the tool is already installed and latest version is not required:
  Do nothing
- When installing or updating something, ask user confirmation before
  do it
- If the tool requested cannot be installed, the mode can know it and
  desactivate some of its features.


"external-tools" could be useful to many modes and elisp functions.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: PL support

[Yuan Fu]

> On May 9, 2020, at 3:26 PM, Sébastien G <seb@k-7.ch> wrote:
> 
> Le samedi 09 mai 2020 à 18:36 +0100, João Távora a écrit :
>> enhance eglot.el to automatically download server programs.
> 
> 
> Maybe downloading and installing server programs can be delegate to a
> new "external-tools.el" library. Something that can manage not only
> language server, but any extrnal tools requested by a mode.
> 
> This library could provide an API to:
> - Declare, in a single elisp function call, an external tool with a
>  name and how install it (which pkg and pkg manager to use)
> - Let modes request the presence of specific external tool with a
>  single elisp function call
> - Modes can, optionnaly, request the latest version of the external
>  tool to be present
> 
> When an external tools is requested:
> - If the tool is not installed: Install it
> - If the tool is already installed and latest version is required:
>  Update it
> - If the tool is already installed and latest version is not required:
>  Do nothing
> - When installing or updating something, ask user confirmation before
>  do it
> - If the tool requested cannot be installed, the mode can know it and
>  desactivate some of its features.
> 
> 
> "external-tools" could be useful to many modes and elisp functions.

I have thought about a similar facility. While convenient for package authors and users, maintaining the sources and installation of these programs is a non-trivial maintenance burden and could come with security risks. I’m not sure if Emacs has enough man-power for that.

Yuan

Re: PL support

[Stefan Monnier]

> I have thought about a similar facility. While convenient for package
> authors and users, maintaining the sources and installation of these
> programs is a non-trivial maintenance burden and could come with security
> risks. I’m not sure if Emacs has enough man-power for that.

I don't think it fundamentally needs more maintenance than when that
information is inside a README/INSTALL file.


        Stefan

Re: PL support

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

Some contributors are eagerly planning a sort of automatic facility to
"install external tools."  I'm disappointed to have to say that this
raises problems at various levels.  I doubt there is an acceptable way
to do it.

At the practical level, different distros have different methods of
installing packages.  Installing a package usually requires being
root.  And that's just the first-order run-down of the issue.  This is
a can of worms.

At the moral level, we have to make sure that Emacs is not being used
to install external packages we have not vetted based on our moral and
political criteria.  We must not let "convenience" lead us into
actions that implicitly work against what we stand for.  We would be
like a campaign for workers' rights that raises funds by selling on
Amazon.

It strikes me that this is also a system security issue.  I would have
to talk with the security advisors I trust about that question and see
what they think.

This issue may apply to programs other than Emacs.  If it does, I
think the GNU Project needs to draw up a general policy about the idea
of one package's automatically installing another.

The right way to draw this up is in discussions with the GNU Advisory
Committee, then with GNU developers on gnu-prog-discuss.  This process
must not be rushed.

Depending on the outcome of that, it might be wise to have a
subsequent discussion about what policy free distros should have about
packages that try to install other packages.  Specifically, whether
they should allow such packages.

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

Re: PL support

[Daniel Colascione]

On 5/10/20 7:35 PM, Richard Stallman wrote:
> [[[ 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. ]]]
> 
> Some contributors are eagerly planning a sort of automatic facility to
> "install external tools."  I'm disappointed to have to say that this
> raises problems at various levels.  I doubt there is an acceptable way
> to do it.

And more and more, a modern editing experience requires working with 
shared infrastructure like LSP servers. If someone downloads Emacs and 
it doesn't even approximate a modern editing experience out-of-the-box, 
people are going to use other, less-free or non-free tools. The moral 
purity of a program doesn't matter if it has no impact, and a program 
with no users has no impact.

You seem to be imagining a world in which Emacs installing external 
software means that it runs distribution package manager tools or plops 
binaries in /usr/bin. You can instead bundle known-good versions of 
external tools with Emacs and run them in a controlled way from 
filesystem locations that Emacs controls. Downloading revisions of these 
tools that hash to entries on an Emacs whitelist is equivalent.

Re: PL support

[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 someone downloads Emacs and 
  > it doesn't even approximate a modern editing experience out-of-the-box, 
  > people are going to use other, less-free or non-free tools.

Just because a different way is "modern" does not make it morally
legitimate.  Especially not in computing!  The modern way of doing
computing is to use apps on a smartphone, each spying on you for a
server -- and that is almost always unjust.  It takes special care
to do it in a way that isn't unjust.

  >  The moral 
  > purity of a program doesn't matter if it has no impact, and a program 
  > with no users has no impact.

The assumptions in the concept of "impact" do not fit the free
software movement.  That word assumes that we accumulate a certain
amount of capacity to have impact, which we can then use against
against whatever target we choose -- like ammunition in a shooter
game.

That may be valid for some kinds of goals.  Especially those, such as
profit, that can be achieved with popularity regardless of how that
popularity is achieved.  But it is not valid for what we do.

The impact we aim for in the GNU Project consists of leading people to
move away from nonfree software and to understand how it is unjust.
To achieve this, we have to act in accord with our moral stand, in a
way that is visibly firm and sincere.

To attract more users by yielding on the moral plane would be
self-defeating, since that would undermine our fitness to teach what
we aim to teach them.  If we yield partially, we have to do that in
a way compatible with purity.  

Therefore, we need to be very careful about tolerating nonfree
software in any way.  Even tolerating supporting Emacs on nonfree
systems is problematical.  We do it, but we had to design careful
limits for it, so that we can yield in ways that dont cancel our
moral purity, rather than in ways that would do so.

I address that in another message, posted with this one, which talks
about walking the ridge between two cliffs.

  > You can instead bundle known-good versions of 
  > external tools with Emacs and run them in a controlled way from 
  > filesystem locations that Emacs controls. Downloading revisions of these 
  > tools that hash to entries on an Emacs whitelist is equivalent.

This is ok in carefully chosen cases, precisely because it is controlled.

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

Re: PL support

[Daniel Colascione]

On 5/11/20 8:21 PM, Richard Stallman wrote:
> [[[ 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 someone downloads Emacs and
>    > it doesn't even approximate a modern editing experience out-of-the-box,
>    > people are going to use other, less-free or non-free tools.
> 
> Just because a different way is "modern" does not make it morally
> legitimate.  Especially not in computing!  The modern way of doing
> computing is to use apps on a smartphone, each spying on you for a
> server -- and that is almost always unjust.  It takes special care
> to do it in a way that isn't unjust.

Supporting jump-to-definition is not tantamount to supporting a 
surveillance state.

>    >  The moral
>    > purity of a program doesn't matter if it has no impact, and a program
>    > with no users has no impact.
> 
> The assumptions in the concept of "impact" do not fit the free
> software movement.  

The opposite of impact is irrelevance. Do you want free software to be 
relevant? If something makes a difference, that means that it has 
impact. If something doesn't make a difference, it's not worth anyone's 
time to keep doing it. If purity and not impact is the goal, why bother 
with continued development? Emacs is already pure.

> That word assumes that we accumulate a certain
> amount of capacity to have impact, which we can then use against
> against whatever target we choose -- like ammunition in a shooter
> game.

No, it doesn't.

> That may be valid for some kinds of goals.  Especially those, such as
> profit, that can be achieved with popularity regardless of how that
> popularity is achieved.  But it is not valid for what we do.
> 
> The impact we aim for in the GNU Project consists of leading people to
> move away from nonfree software and to understand how it is unjust.
> To achieve this, we have to act in accord with our moral stand, in a
> way that is visibly firm and sincere.

Who's going to use software that's inferior to alternatives? When the 
pursuit of purity prompts you make free software worse on purpose, all 
you do is teach people that free software is worse software. I hope 
that's not the lesson that you want people to take away from the 
experience of trying Emacs.

Besides: it's not as if we're talking about adding a button that 
purchases Microsoft Visual Studio (or, heaven forbid, that renders emoji 
using multiple colors). We're talking about one piece of free software 
using and recommending another other piece of free software. You're 
worried that this other free software might through some chain of 
references lead users to non-free software. The same concern says we 
shouldn't make free software web browsers lest we lead users into 
temptation. The culpability for that is too speculative to attach itself 
to Emacs.

Re: PL support

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

  > Supporting jump-to-definition is not tantamount to supporting a 
  > surveillance state.

That is true.  I cited the example of "modern" computing
to refute the supposition that "modern" means better
and "not modern" is bad.

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

Re: PL support

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

  > The opposite of impact is irrelevance. Do you want free software to be 
  > relevant?

Only if it is relevant in the right way.  We are bombarded with
pressure to make our work "relevant" by someone else's standards.

  > Who's going to use software that's inferior to alternatives?

What does "inferior" mean?  How do we judge superiority?

In the free software movement, we judge by freedom first; I think you
are judging by convenience first.  At least it looks that way.

Who's going to use [free] software that is inferior [in convenience]
to [nonfree] alternatives?  I will!  Free software activists will.
Because running the nonfree programs is out of the question.

A nonfree program is no program at all.  A free program is better
than no program.

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

Re: PL support

[Stefan Monnier]

Richard wrote:
> Some contributors are eagerly planning a sort of automatic facility to
> "install external tools."  I'm disappointed to have to say that this
> raises problems at various levels.  I doubt there is an acceptable way
> to do it.

There is no doubt that acceptable ways to do it exist.

As a matter of fact, we *already* do that, typically in the form of
instructions in `Commentary:`, `INSTALL`, manuals, messages in
mailing-lists, etc...

These instructions raise various problems, indeed.

Other ways to "do that" would solve some of those problems, preserve
some of them, and introduce yet new ones.

There's a vast design space here, with many points in there which should
be very much acceptable to our usually conservative sensitivity of
"don't do anything without a very explicit user consent".

Daniel wrote:
> You seem to be imagining a world in which Emacs installing external software
> means that it runs distribution package manager tools or plops binaries in
> /usr/bin. You can instead bundle known-good versions of external tools with
> Emacs and run them in a controlled way from filesystem locations that Emacs
> controls. Downloading revisions of these tools that hash to entries on an
> Emacs whitelist is equivalent.

FWIW, I probably wouldn't like a solution where we bundle binaries of
external tools, since then we'd be bound (either by the license, or
morally anyway) to include the source as well, and then we'd have to
keep it up-to-date (and deal with somewhat automatic updates and
whatnot).

This said, that is still a very much acceptable point in the
design space for some cases.

A very different design point might be to try to guess the kind of
"package management" in use (msys, apt, guix, ...), then build
a sequence of commands to pass to that package management, show it to
the user, and ask them to run them (or to confirm that they want Emacs
to run them).

Another design point is to display to the user a text box explaining
what they need to install and where they can find instructions to do so.

...


        Stefan

Re: PL support

[Fu Yuan]

> 在 2020年5月10日，下午11:56，Stefan Monnier <monnier@iro.umontreal.ca> 写道：
> 
> Richard wrote:
>> Some contributors are eagerly planning a sort of automatic facility to
>> "install external tools."  I'm disappointed to have to say that this
>> raises problems at various levels.  I doubt there is an acceptable way
>> to do it.
> 
> There is no doubt that acceptable ways to do it exist.
> 
> As a matter of fact, we *already* do that, typically in the form of
> instructions in `Commentary:`, `INSTALL`, manuals, messages in
> mailing-lists, etc...
> 
> These instructions raise various problems, indeed.
> 
> Other ways to "do that" would solve some of those problems, preserve
> some of them, and introduce yet new ones.
> 
> There's a vast design space here, with many points in there which should
> be very much acceptable to our usually conservative sensitivity of
> "don't do anything without a very explicit user consent".
> 
> Daniel wrote:
>> You seem to be imagining a world in which Emacs installing external software
>> means that it runs distribution package manager tools or plops binaries in
>> /usr/bin. You can instead bundle known-good versions of external tools with
>> Emacs and run them in a controlled way from filesystem locations that Emacs
>> controls. Downloading revisions of these tools that hash to entries on an
>> Emacs whitelist is equivalent.
> 
> FWIW, I probably wouldn't like a solution where we bundle binaries of
> external tools, since then we'd be bound (either by the license, or
> morally anyway) to include the source as well, and then we'd have to
> keep it up-to-date (and deal with somewhat automatic updates and
> whatnot).
> 
> This said, that is still a very much acceptable point in the
> design space for some cases.
> 
> A very different design point might be to try to guess the kind of
> "package management" in use (msys, apt, guix, ...), then build
> a sequence of commands to pass to that package management, show it to
> the user, and ask them to run them (or to confirm that they want Emacs
> to run them).
> 
> Another design point is to display to the user a text box explaining
> what they need to install and where they can find instructions to do so.
> 
> ...
> 
> 
>        Stefan
> 

Does that mean a external-tool.el that automatically downloads executables is not viable?

Yuan

Re: PL support

[Stefan Monnier]

> Does that mean a external-tool.el that automatically downloads executables is not viable?

No (after all, that's exactly what `gnu-elpa` does with GNU ELPA packages).

I wouldn't want such a download to happen completely transparently, no,
but it could definitely be an option after asking the user if they want
to do that (where the question makes it clear what is being downloaded
and from where).


        Stefan

Re: PL support

[T.V Raman]

Also, note for many of the newer language environments, you dont need
root to install executables,

cargo, go, npm all prefer installation under the user's home directory.
-- 

Re: PL support

[Daniel Colascione]

On 5/10/20 8:56 PM, Stefan Monnier wrote:
> Richard wrote:
>> Some contributors are eagerly planning a sort of automatic facility to
>> "install external tools."  I'm disappointed to have to say that this
>> raises problems at various levels.  I doubt there is an acceptable way
>> to do it.
> 
> There is no doubt that acceptable ways to do it exist.
> 
> As a matter of fact, we *already* do that, typically in the form of
> instructions in `Commentary:`, `INSTALL`, manuals, messages in
> mailing-lists, etc...
> 
> These instructions raise various problems, indeed.
> 
> Other ways to "do that" would solve some of those problems, preserve
> some of them, and introduce yet new ones.
> 
> There's a vast design space here, with many points in there which should
> be very much acceptable to our usually conservative sensitivity of
> "don't do anything without a very explicit user consent".
> 
> Daniel wrote:
>> You seem to be imagining a world in which Emacs installing external software
>> means that it runs distribution package manager tools or plops binaries in
>> /usr/bin. You can instead bundle known-good versions of external tools with
>> Emacs and run them in a controlled way from filesystem locations that Emacs
>> controls. Downloading revisions of these tools that hash to entries on an
>> Emacs whitelist is equivalent.
> 
> FWIW, I probably wouldn't like a solution where we bundle binaries of
> external tools, since then we'd be bound (either by the license, or
> morally anyway) to include the source as well, and then we'd have to
> keep it up-to-date (and deal with somewhat automatic updates and
> whatnot).

Why not? We don't even need to distribute binaries, really. We can just 
vendor any external tool that we need for core functionality and allow 
users (or, doubtlessly, distributions) to override our bundled tools 
with system-provided ones as desired. GCC does this already: consider 
how GCC vendors things like libquadmath andlibffi already. Would 
anything be wrong with our vendoring TreeSitter or some LSP servers, as 
source and free software?

If our vendored program gets a little out of date, so what? We'd install 
that vendored program in an Emacs-private location where it wouldn't do 
any harm to the rest of the system.

> This said, that is still a very much acceptable point in the
> design space for some cases.
> 
> A very different design point might be to try to guess the kind of
> "package management" in use (msys, apt, guix, ...), then build
> a sequence of commands to pass to that package management, show it to
> the user, and ask them to run them (or to confirm that they want Emacs
> to run them).

I'm not really in favor of this approach. I don't believe Emacs should 
try to be making system-wide changes, especially since it's not 
necessarily even installed system-wide.

> Another design point is to display to the user a text box explaining
> what they need to install and where they can find instructions to do so.

I think advanced functionality should Just Work out of the box. "Some 
assembly required" is a lot of friction.

Re: PL support

[Stefan Monnier]

> I'm not really in favor of this approach.

I'm not in favor of any approach in particular either.

But it's not like we can avoid the issue.  The issue already exists and
has existed for years.  We currently solve it with READMEs and things
like that.  There's a lot of room for improvement.

> I don't believe Emacs should try to be making system-wide changes,
> especially since it's not necessarily even installed system-wide.

Then you'll configure that installation-library accordingly (or maybe
it'll even figure that out for itself).

> I think advanced functionality should Just Work out of the box.

Should we distribute within Emacs's tarball Git, GCC, and Texlive, plus
a healthy dose of LSP servers for good measure?


        Stefan

Re: PL support

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

  > > Some contributors are eagerly planning a sort of automatic facility to
  > > "install external tools."  I'm disappointed to have to say that this
  > > raises problems at various levels.  I doubt there is an acceptable way
  > > to do it.

  > There is no doubt that acceptable ways to do it exist.

My doubts remain.

  > As a matter of fact, we *already* do that, typically in the form of
  > instructions in `Commentary:`, `INSTALL`, manuals, messages in
  > mailing-lists, etc...

Those are suggestions, not automatic, but they may indeed raise problems.
I hope we have checked all the suggestions in the Emacs distribution.


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

Re: PL support

[Stefan Monnier]

>   > As a matter of fact, we *already* do that, typically in the form of
>   > instructions in `Commentary:`, `INSTALL`, manuals, messages in
>   > mailing-lists, etc...
> Those are suggestions, not automatic,

I don't know what you mean by "automatic".
Would displaying those same instructions qualify as "automatic"?


        Stefan

Re: PL support

[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 don't know what you mean by "automatic".
  > Would displaying those same instructions qualify as "automatic"?

Questions in the spirit of cross-examination are not a way to work
together.

We seem to be finding it difficult to communicate.  How about waiting
a week and talking with me privately?  We may find it easier to
understand each other then.


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

Re: PL support

[Stefan Monnier]

> Maybe downloading and installing server programs can be delegate to a
> new "external-tools.el" library.

I hope someone already started working on such a thing.
I'll be very happy to add it to GNU ELPA.

That would be handy for things like packages that use an "emacs module",
such as emacs-tree-sitter, but also for things like pdf-tools or
ada-mode which come with their own external program (not written in
Elisp), for the native compiler, and it could go further (e.g. the `ag`
package could install the `ag` executable, the `diff` command could
request installation of a `diff` executable, ...).

Yes, it would be *very* useful,


        Stefan

Re: PL support

[Sébastien Gendre]

The initial problematic that the suggestion of `external-tools.el`
wanted to solve is how to install external tools, used by some Elisp
code (whether this code is included in Emacs or as an package), while
being easy to use to user and developer.

Today, this problem can be fixed in 2 possible way:
- List all external tools needed on a README/INSTALL file and let the
  user install them
- Automatically download and install the external tools with some
  Elisp code that call `wget` or a packages manager

For the second way, it is already used by some third party Emacs
packages like `anaconda-mode` (download and install Jedi) or
`flycheck-grammalecte` (not fully automatic, need to call one Elisp
function to download grammalecte).

If we look at the ethic problematic of the situation, today we cannot
prevent third party Emacs packages to automatically download external
tools. But by providing something like `external-tools.el` we can
provide an easy and unified way to install external tools, a way that:
- Will always ask confirmation of the user before download and install
  anything
- Could list all tools that would be installed (maybe with the licence
  name) before download them
- Could explain to the user the risk when using proprietary software

This way will not prevent third party packages to use
`external-tools.el` to declare and download proprietary software, but
the actual situation can't either when Elisp code call the `wget`
command to download proprietary software. We can still prohibit
Emacs built-in and ELPA packages to declare and download proprietary
software.

The question is: Can we provide something with the goal to simplify
the download and the installation of Free Softwares as external tools
when this can be also used by third party dev to download and install
proprietary software?

But this question can also arise for the package manager of Emacs that
can be used with a third party repository that would providing
proprietary software.


Le samedi 09 mai 2020 à 21:26 +0200, Sébastien G a écrit :
> Le samedi 09 mai 2020 à 18:36 +0100, João Távora a écrit :
> > enhance eglot.el to automatically download server programs.
> 
> Maybe downloading and installing server programs can be delegate to a
> new "external-tools.el" library. Something that can manage not only
> language server, but any extrnal tools requested by a mode.
> 
> This library could provide an API to:
> - Declare, in a single elisp function call, an external tool with a
>   name and how install it (which pkg and pkg manager to use)
> - Let modes request the presence of specific external tool with a
>   single elisp function call
> - Modes can, optionnaly, request the latest version of the external
>   tool to be present
> 
> When an external tools is requested:
> - If the tool is not installed: Install it
> - If the tool is already installed and latest version is required:
>   Update it
> - If the tool is already installed and latest version is not
> required:
>   Do nothing
> - When installing or updating something, ask user confirmation before
>   do it
> - If the tool requested cannot be installed, the mode can know it and
>   desactivate some of its features.
> 
> 
> "external-tools" could be useful to many modes and elisp functions.

Re: PL support

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

  > Today, this problem can be fixed in 2 possible way:
  > - List all external tools needed on a README/INSTALL file and let the
  >   user install them

That is the right way to handle this, because it gives the user
a chance to think about the matter.

  > - Automatically download and install the external tools with some
  >   Elisp code that call `wget` or a packages manager

I've explained previously why that is bad.

  > For the second way, it is already used by some third party Emacs
  > packages

Indeed, some users and developers do things we think are misguided.
We can't tell them what to do.

  > If we look at the ethic problematic of the situation, today we cannot
  > prevent third party Emacs packages to automatically download external
  > tools.

Indeed, we can't stop them from disregarding those other values.  What
we can do, and must do, is to draw a clear line between them and us,
and put up a sort of a fence there.

Having GNU ELPA, and not recommending packages outside of it, is the
way we do it.

  > But this question can also arise for the package manager of Emacs that
  > can be used with a third party repository that would providing
  > proprietary software.

That is why we don't enable any third-part repos by default.

This way of making the fence is not the only possible way.  It has
some problems.  People are citing those problems as arguments that we
should put the fence further out, or not as high.

But the other ways would have similar problems, and other problems
too.  We we consider changing the details, we need to consider the
drawbacks of the alternatives, not only the drawbacks of the current
way.

I will talk more about this in another message.

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

Re: PL support

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


Stefan Monnier wrote:

> 3- It doesn't handle their OCaml code, doesn't give them any
>    completions while they type, nothing.
> 4- They search the web for an answer.
> 5- The answer tells them to install those things from MELPA.
> 6- They wonder why on earth it's not enabled by default since it's
>    a matter of a couple lines and you can't do anything without it.
> 7- Now it's enabled, so they have direct easy access to some packages
>    that recommend proprietary software.

This does happen, and it is a problem.  The question is, what should we
do about it?

Let's start by noting the overall situation.  Our mission is to lead
people away from the injustice of nonfree software.  That mainly means
the people who disagree with us, plus the larger number who have never
thought about the issue.  When they hear about our work, they are
usually told that it is "open source", which means that our message is
entirely edited out of what they see.

How can we make our message reach them?  One important method is to
draw a line against nonfree software.  Then we have to wave it in
front of Emacs users so that they notice it and think about it.

In other words, we have to put up an obstacle that will slow down people's
passage from Emacs to nonfree software.  If it doesn't slow them down,
they won't notice it.

When we have such an obstacle, in a world where most people would like
to make the passage from Emacs to nonfree programs as smooth as
possible, some of them will "help" others do that by posting pages
that lead people to nonfree software.  That weakens the effect; it
undermines the obstacle.

This unfortunate effect will happen no matter where we put the
obstacle.  When someone argues for moving the obstacle further out
because it is being undermined, we must keep in mind that an obstacle
further out will be undermined too.

Meanwhile, moving the obstacle further out has the effect of increasing
our visible toleration of nonfree software, and that weakens our
message.  People could see it and not realize that we call nonfree
software an injustice.

We have to consider carefully the best place to put the obstacle,
keeping in mind that the place that offers the most convenience
is surely too far out.


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

Re: PL support

[Dmitry Gutov]

On 09.05.2020 20:23, Eli Zaretskii wrote:
> But I
> don't think we will ever be able to come close to resolving it
> regarding Eglot unless we have support for it in major modes ready to
> be turned on.

M-x package-install eglot
M-x find-file .../abc/def/xyz.c
M-x eglot

That's how ready it is to turn on already, without any dedicated support 
in major modes.

Now, the above scenario does not include the installation of an LS 
server program. Eglot doesn't do that automatically yet, but it could.

Also, C/C++ packages might require some "compilation database" file in 
the project root. But that's not tied to the major mode either.

Re: PL support

[Dmitry Gutov]

On 09.05.2020 20:08, João Távora wrote:
> cc-mode.el specifically is ask it to define the file-name of a
> preferred language server program and enable eglot-managed-mode
> by default

Why would CC Mode define the preferred LSP program? How would that help 
users?

Do you imagine Alan has a strong opinion on that?

 > ...especially if Emacs also started distributing an LSP server program
for C or FOO

Should I point out that all current LSP servers for C and C++ are based 
on Clang? Sorry if that was below the belt.

Re: PL support

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

  > Should I point out that all current LSP servers for C and C++ are based 
  > on Clang? Sorry if that was below the belt.

That is a very important issue which I haven't figured out the right
approach to.  Currently I am trying to find out whether Clang
has caused dictation software to be impossible in the free world.

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

Re: PL support

[Dmitry Gutov]

On 09.05.2020 19:30, João Távora wrote:
> At the time, I tore off a big chunk of it, jsonrpc.el to put in the core, and
> and made it a :core package.

jsonrpc.el is an implementation of a popular protocol. It's a good thing 
to have in Emacs. It's also not much of a maintenance burden (since its 
users are people who will most likely send patches themselves).

lsp-mode might have decided against using it, but they can still come 
around.

> On thing that would fit that fill is a
> set of Elisp macros that allow for compile-time and run-time checking
> of LSP messages, among other LSP-specific but interface-agnostic
> details.

Could you clarify how that's dependent on Eglot being in Emacs?

Re: PL support

[João Távora]

On Sat, May 9, 2020 at 7:26 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> > On thing that would fit that fill is a
> > set of Elisp macros that allow for compile-time and run-time checking
> > of LSP messages, among other LSP-specific but interface-agnostic
> > details.
>
> Could you clarify how that's dependent on Eglot being in Emacs?

It's not. It's like jsonrpc.el, but for LSP.  A library for easier writing
of other programs that want to "speak"LSP. Including, but not limited to,
Eglot.  An ELSP server in Elisp could use it.  Or lsp-mode could
"still come around" :-)

João

Re: PL support

[Dmitry Gutov]

On 09.05.2020 19:05, Eli Zaretskii wrote:
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 9 May 2020 18:53:10 +0300
>>
>> Cannot enable what?
> 
> Font-lock and indentation based on those capabilities, for one.

Neither is part of the LSP protocol, so Eglot doesn't do this (yet).

LSP at the moment provides more "advances" features: code completion, 
navigation and documentation. In short, it's a replacement for etags and 
the manual. For all supported languages.

For these two features in particular, we might want to pick a TreeSitter 
based solution anyway, because that one at least could allow us to 
continue writing grammars in Emacs, instead of entirely relying on 
external programs to keep up-to-date and complete grammars.

>> Eglot is in ELPA. Have you tried it?
> 
> No.  Not enough time, sorry.

It shouldn't take a lot of time. There's no hurry, though.

>> None of these discussions say "oh, if only Eglot was in the core instead
>> of GNU ELPA, that would solve my problems". I haven't seen a single
>> opinion like that.
> 
> I said nothing about moving Eglot to the core.  It was João, not
> myself.  I'd be happy if we could have these capabilities that
> depended on Eglot (or any other package, really) being installed.  We
> could figure out the rest later.

Eglot is as feature-rich now when installed as a package as it could be, 
I think. And it's worth taking a look.

Re: PL support

[Daniel Colascione]

On 5/9/20 11:23 AM, Dmitry Gutov wrote:
> On 09.05.2020 19:05, Eli Zaretskii wrote:
>>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>> From: Dmitry Gutov <dgutov@yandex.ru>
>>> Date: Sat, 9 May 2020 18:53:10 +0300
>>>
>>> Cannot enable what?
>>
>> Font-lock and indentation based on those capabilities, for one.
> 
> Neither is part of the LSP protocol, so Eglot doesn't do this (yet).
> 
> LSP at the moment provides more "advances" features: code completion, 
> navigation and documentation. In short, it's a replacement for etags and 
> the manual. For all supported languages.
> 
> For these two features in particular, we might want to pick a TreeSitter 
> based solution anyway, because that one at least could allow us to 
> continue writing grammars in Emacs, instead of entirely relying on 
> external programs to keep up-to-date and complete grammars.

TreeSitter requires NPM for customization and compiles to C, right? I 
don't want people to require either to customize Emacs. Why not just 
port the tree sitter parser generator to elisp?

Re: PL support

[Dmitry Gutov]

On 09.05.2020 21:41, Daniel Colascione wrote:
> TreeSitter requires NPM for customization and compiles to C, right? I 
> don't want people to require either to customize Emacs. Why not just 
> port the tree sitter parser generator to elisp?

You might want to pop to the previous discussion of TreeSitter on this 
mailing list.

I made these points there already, you're welcome to read the responses.

Bottom line is: if someone implements this, we can talk.

Re: PL support

[Daniel Colascione]

On 5/9/20 12:01 PM, Dmitry Gutov wrote:
> On 09.05.2020 21:41, Daniel Colascione wrote:
>> TreeSitter requires NPM for customization and compiles to C, right? I 
>> don't want people to require either to customize Emacs. Why not just 
>> port the tree sitter parser generator to elisp?
> 
> You might want to pop to the previous discussion of TreeSitter on this 
> mailing list.
> 
> I made these points there already, you're welcome to read the responses.

I should go back and reread that. (I declared emacs-devel unread email 
bankruptcy recently.)

> Bottom line is: if someone implements this, we can talk. 

Does anyone need to implement it? Looking at TreeSitter's repository, it 
looks like the parser generator itself is written in Rust (which could 
be linked directly into Emacs), the JS-specific grammar bit is pretty 
small and directly translatable to elisp [1], and the output of the 
parser generator is a bunch of tables that could, in principle, be used 
directly instead of having to round-trip through a C compiler.

If TreeSitter works as well as described, it'd be worth just making it a 
build requirement for Emacs so that --- at long last --- the core modes 
could be grammar-based. Doing that would require ditching platforms that 
Rust doesn't support, but I'm okay with that. It looks technically doable.

Sure, integrating TS this way would require taking a dependency on LLVM 
--- at least for the moment, since gccrs is still immature. It'd be a 
political shift. But is it more important to catch up with the rest of 
the editingworld or to keep shunning LLVM (which is free software!) for 
some reason?

[1] 
https://github.com/tree-sitter/tree-sitter/blob/master/cli/src/generate/dsl.js

Re: PL support

[Dmitry Gutov]

On 09.05.2020 22:28, Daniel Colascione wrote:
> On 5/9/20 12:01 PM, Dmitry Gutov wrote:
>> On 09.05.2020 21:41, Daniel Colascione wrote:
>>> TreeSitter requires NPM for customization and compiles to C, right? I 
>>> don't want people to require either to customize Emacs. Why not just 
>>> port the tree sitter parser generator to elisp?
>>
>> You might want to pop to the previous discussion of TreeSitter on this 
>> mailing list.
>>
>> I made these points there already, you're welcome to read the responses.
> 
> I should go back and reread that. (I declared emacs-devel unread email 
> bankruptcy recently.)

I sympathize.

>> Bottom line is: if someone implements this, we can talk. 
> 
> Does anyone need to implement it?

It doesn't work yet, does it?

> Looking at TreeSitter's repository, it 
> looks like the parser generator itself is written in Rust (which could 
> be linked directly into Emacs), the JS-specific grammar bit is pretty 
> small and directly translatable to elisp [1], and the output of the 
> parser generator is a bunch of tables that could, in principle, be used 
> directly instead of having to round-trip through a C compiler.

I guess the question is how fast this is going to work, compared to the 
original. Then the details of the Elisp interface. And also our ability 
to keep up with the grammars and TreeSitter's development (new features, 
api changes, etc).

In the meantime you can try out 
https://github.com/ubolonton/emacs-tree-sitter/ (they seem to have 
gotten syntax highlighting working now). That's a straightforward 
integration, though.

> If TreeSitter works as well as described, it'd be worth just making it a 
> build requirement for Emacs so that --- at long last --- the core modes 
> could be grammar-based. Doing that would require ditching platforms that 
> Rust doesn't support, but I'm okay with that. It looks technically doable.

Um, well... That sounds like a beginning of the "Rust in Emacs core" 
project as well. :)

> Sure, integrating TS this way would require taking a dependency on LLVM 
> --- at least for the moment, since gccrs is still immature. It'd be a 
> political shift. But is it more important to catch up with the rest of 
> the editingworld or to keep shunning LLVM (which is free software!) for 
> some reason?

I wouldn't want to rain on this parade, but I think we might need strong 
practical evidence of this approach before such a move would be considered.

Re: PL support

[Dmitry Gutov]

On 09.05.2020 22:49, Dmitry Gutov wrote:
>> Looking at TreeSitter's repository, it looks like the parser generator 
>> itself is written in Rust (which could be linked directly into Emacs), 
>> the JS-specific grammar bit is pretty small and directly translatable 
>> to elisp [1], and the output of the parser generator is a bunch of 
>> tables that could, in principle, be used directly instead of having to 
>> round-trip through a C compiler.
> 
> I guess the question is how fast this is going to work, compared to the 
> original. Then the details of the Elisp interface. And also our ability 
> to keep up with the grammars and TreeSitter's development (new features, 
> api changes, etc).

Just something I have stumbled on by chance:

https://marijnhaverbeke.nl/blog/lezer.html

Lezer is a parser system that compiles to JavaScript (an interpreted 
language closer Emacs Lisp than C), inspired by TreeSitter but making 
some different tradeoffs WRT performance and memory use.

It uses its own grammars, however: 
https://github.com/lezer-parser/lezer/issues/7

Re: PL support

[Stefan Monnier]

> Adding some integration in Emacs that wouldn't import Eglot but would
> increase its discoverability is also an option, and a worthy goal IMO.

FWIW, if you install the `gnu-elpa` package, then `eglot` will be
autoload-installed (i.e. calling it will prompt the user to install the
`eglot` package and if accepted will then continue calling the
function).

My hope is to distribute `gnu-elpa` "pre-installed" with Emacs-28.


        Stefan


PS: And no, currently `company` is not autoload-installed like that by
    `gnu-elpa` because it has more than 10 autoloads and `gnu-elpa` uses
    10 as arbitrary per-package threshold to avoid adding too
    many autoloads.

Re: PL support

[Dmitry Gutov]

On 09.05.2020 23:17, Stefan Monnier wrote:
>> Adding some integration in Emacs that wouldn't import Eglot but would
>> increase its discoverability is also an option, and a worthy goal IMO.
> 
> FWIW, if you install the `gnu-elpa` package, then `eglot` will be
> autoload-installed (i.e. calling it will prompt the user to install the
> `eglot` package and if accepted will then continue calling the
> function).
> 
> My hope is to distribute `gnu-elpa` "pre-installed" with Emacs-28.

I'm sure it will be beneficial, but most of the upside will come from 
offering to install packages with corresponding major modes when one 
opens a file with a particular extension.

For the user to type 'M-x eglot', or 'M-x global-company-mode', they'd 
have to be aware of either first, don't they?

And 'M-x package-install', by itself, is not hard.

Re: PL support

[Stefan Monnier]

>> My hope is to distribute `gnu-elpa` "pre-installed" with Emacs-28.
> I'm sure it will be beneficial, but most of the upside will come from
> offering to install packages with corresponding major modes when one 
> opens a file with a particular extension.

Agreed.

> For the user to type 'M-x eglot', or 'M-x global-company-mode', they'd have
> to be aware of either first, don't they?

Yes.  I'm not sure yet how to "advertize" these things.  I guess we
could add them to the menubar, but I'm not completely sold on the idea.


        Stefan

Re: PL support

[Dmitry Gutov]

On 10.05.2020 15:44, Stefan Monnier wrote:

>> For the user to type 'M-x eglot', or 'M-x global-company-mode', they'd have
>> to be aware of either first, don't they?
> 
> Yes.  I'm not sure yet how to "advertize" these things.  I guess we
> could add them to the menubar, but I'm not completely sold on the idea.

Using the most difficult way known to programmers: documentation. :-)

An official "how to IDE" tutorial would go a long way.

Re: PL support

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  João Távora
>  <joaotavora@gmail.com>,
>   emacs-devel@gnu.org
> Date: Sat, 09 May 2020 16:17:47 -0400
> 
> My hope is to distribute `gnu-elpa` "pre-installed" with Emacs-28.

With or without the packages for which we don't have copyright
assignment and that don't adhere to our coding conventions?

Re: PL support

[Stefan Monnier]

>> My hope is to distribute `gnu-elpa` "pre-installed" with Emacs-28.
> With or without the packages for which we don't have copyright
> assignment and that don't adhere to our coding conventions?

`gnu-elpa` is a package (in GNU ELPA).


        Stefan

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)

[조성빈]

Eli Zaretskii <eliz@gnu.org> 작성:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Sat, 9 May 2020 16:25:36 +0100
>> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier  
>> <monnier@iro.umontreal.ca>,
>> 	emacs-devel <emacs-devel@gnu.org>
>>
>> I think Eli has indicated that LSP support in the core is desirable
>> at some point
>
> Not only desirable: long overdue.  Emacs must learn to use the latest
> technologies of supporting programming languages based on real
> parsing, because the time when it could be done with regular
> expressions and similar techniques has come and gone.  We cannot
> enable significant new IDE-like features if we don't acquire these
> technologies.
>
> Please someone start working on this ASAP.  We sorely need that, just
> look at the recent discussions on Reddit that underline these
> deficiencies in Emacs.

I thought João wrote eglot which is in ELPA for this? (FWIW I don’t use it
personally because I found it didn’t work with the servers I use, but when I
used it shortly it was pretty great, a pretty smooth process. I was  
impressed.)

And it’s definitely much better than before, Emacs now works with a lot of
‘modern’ languages. Unfortunately, LSP doesn’t provide support for syntax
highlighting, but I thought tree-sitter is being worked on for that?

Re: PL support (was: Drop the Copyright Assignment requirement for Emacs)

[João Távora]

t's is On Sat, May 9, 2020 at 4:55 PM 조성빈 <pcr910303@icloud.com> wrote:
> Eli Zaretskii <eliz@gnu.org> 작성:

> I thought João wrote eglot which is in ELPA for this?

Yes, you're correct.  This is the goal from the start.

> (FWIW I don’t use it personally because I found it didn’t work with
> the servers I use, but when I used it shortly it was pretty great, a
> pretty smooth process. I was impressed.)

Maybe it works now.  Its goal is to work with any server that speaks
LSP protocol.

> And it’s definitely much better than before, Emacs now works with a lot of
> ‘modern’ languages. Unfortunately, LSP doesn’t provide support for syntax
> highlighting, but I thought tree-sitter is being worked on for that?

Are you sure about this and LSP?  I mean tree-sitter is fantastic, but
I'm pretty sure LSP has some of this at least outlined:

https://github.com/microsoft/language-server-protocol/issues/18

It's bound to be pretty VS Code centric though, but that's another
discussion.   Having "full" LSP in Emacs would certain give us better
arguments to lobby for a less VSCode-centric specification.

João Távora

Re: PL support

[Dmitry Gutov]

On 09.05.2020 19:02, João Távora wrote:
> Are you sure about this and LSP?  I mean tree-sitter is fantastic, but
> I'm pretty sure LSP has some of this at least outlined:
> 
> https://github.com/microsoft/language-server-protocol/issues/18

Perhaps we should suspend this discussion until it's in the spec, and 
there are at least some LSP servers that implement it.

> Having "full" LSP in Emacs would certain give us better
> arguments to lobby for a less VSCode-centric specification.

With the minority marketshare, and Microsoft being Microsoft, I really 
doubt that. They don't even have a conforming LSP server for TypeScript, 
for crying out loud.

Re: PL support

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

  > > Having "full" LSP in Emacs would certain give us better
  > > arguments to lobby for a less VSCode-centric specification.

Is there someone who would like to explain this issue to me, off the
list?  (Perhaps by phone to save time.)  There _might_ be moral or
strategic considerations here, but I don't know the facts of this
situation so I can't tell.

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

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 09.05.2020 18:25, João Távora wrote:
> It's not for discoverability.  It's, among other reasons, so that major modes
> can adding to Eglot's hooks, for example.

I'm not sure for what purposes, but hooks are flexible enough for this 
to be possible today already (without Eglot in the core).

More generally, I oppose collecting more and more code inside Emacs. 
Lots of features can live just as well as packages.

> Or that someday font-locking and
> or indentation can be done via the LSP server.

That's the goal of TreeSitter, isn't it? Or are there some new additions 
to the LSP protocol I haven't heard about?

> I think Eli has indicated
> that LSP support in the core is desirable at some point, and this would
> be a step in that direction, I think.

We should support LSP, and have an easy way for the users to take 
advantage of the support. That's clear.

But even the usual argument to have stuff in the core ("what if I don't 
have Internet?") doesn't work for Eglot, considering it needs to 
download external programs anyway (or have the user download them).

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sat, May 9, 2020 at 4:41 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 09.05.2020 18:25, João Távora wrote:
> > It's not for discoverability.  It's, among other reasons, so that major modes
> > can adding to Eglot's hooks, for example.
>
> I'm not sure for what purposes, but hooks are flexible enough for this
> to be possible today already (without Eglot in the core).

Yes, that works.  But Eglot doesn't have only these kinds of interfaces.  It
also has generic functions.  I guess we could have just a "lsp-interface.el"
in the core that defines the generic functions and no implementations.

But in general, that's a fair stance, to have little interdependence and
suitable indirections betweenmodules.

> More generally, I oppose collecting more and more code inside Emacs.
> Lots of features can live just as well as packages.

That's true.  Some things are desirable in the core though.  In my view
a proper completion tooltip that lives in the core and uses capf
exclusively is a nice thing to have.  I don't want to M-x package-install
completion-thingy.

> > Or that someday font-locking and
> > or indentation can be done via the LSP server.
> That's the goal of TreeSitter, isn't it? Or are there some new additions
> to the LSP protocol I haven't heard about?

I think so yes.

> But even the usual argument to have stuff in the core ("what if I don't
> have Internet?") doesn't work for Eglot, considering it needs to
> download external programs anyway (or have the user download them).

True, to a point.  But the user could have those programs already,
or use Eglot to connect through the network. But that argument sucks,
I agree.  I do think once something is in the core it's more
discoverable/taken more seriously.  At least until we start bundling
packages.

In other words, we could be farther from that ideal of modularity, but
we're just not there yet.

João

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 09.05.2020 18:52, João Távora wrote:

>> I'm not sure for what purposes, but hooks are flexible enough for this
>> to be possible today already (without Eglot in the core).
> 
> Yes, that works.  But Eglot doesn't have only these kinds of interfaces.  It
> also has generic functions.  I guess we could have just a "lsp-interface.el"
> in the core that defines the generic functions and no implementations.

I suppose so. Though I'd like to look at its contents. So far I don't 
have any solid idea what this file would contain.

>> More generally, I oppose collecting more and more code inside Emacs.
>> Lots of features can live just as well as packages.
> 
> That's true.  Some things are desirable in the core though.  In my view
> a proper completion tooltip that lives in the core and uses capf
> exclusively is a nice thing to have.  I don't want to M-x package-install
> completion-thingy.

One project that aimed to solve this was bundling a set of ELPA packages 
together in the Emacs distribution, while they generally continue to 
reside in ELPA. I agree that having a completion tooltip in there could 
be a good improvement.

A bit less sure about Eglot TBH (or any LSP client), because Emacs has a 
long history of alternative solutions in this field, and it would be 
best not to step on their toes either. So this will be a question of how 
to do this most unobtrusively but still help.

>> But even the usual argument to have stuff in the core ("what if I don't
>> have Internet?") doesn't work for Eglot, considering it needs to
>> download external programs anyway (or have the user download them).
> 
> True, to a point.  But the user could have those programs already,
> or use Eglot to connect through the network. But that argument sucks,
> I agree.  I do think once something is in the core it's more
> discoverable/taken more seriously.  At least until we start bundling
> packages.

I guess my opinion is that merging Eglot in won't help much, and there 
are other, smaller things we should start doing first. When we're do 
with them, maybe bundling is already on the table.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Sun, May 10, 2020 at 2:12 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 09.05.2020 18:52, João Távora wrote:
>
> >> I'm not sure for what purposes, but hooks are flexible enough for this
> >> to be possible today already (without Eglot in the core).
> > Yes, that works.  But Eglot doesn't have only these kinds of interfaces.  It
> > also has generic functions.  I guess we could have just a "lsp-interface.el"
> > in the core that defines the generic functions and no implementations.
> I suppose so. Though I'd like to look at its contents. So far I don't
> have any solid idea what this file would contain.

I think it's important to clarify something.  I'm not "selling" you
lsp-interface.el
in exchange for "Eglot in the core".  I'm just stating that if you're worried
about protecting the hypothetical, however unlikely, entrance of another
LSP client into Emacs, such a file can be developed from parts of Eglot.

In fact, I think it's a good idea to do so regardless of the possibility that
other LSP clients make it into the core.  And for sure you'll be able to
participate in its design.  But that goal isn't in any way mutually exclusive
with Eglot being in the core. Quite the contrary: it is facilitated by it.

In fact that's exactly what I did with jsonrpc.el (which lsp-mode.el never
took up) It was hard enough doing the two-repository dance then, and
I don't want to do that again.  So unless you state a negative,
irrefutable, irreparable consequence of having eglot.el developed in
emacs.git instead of some other place, I'll bring the issue to a discussion
with the Eglot developers, a group which you aren't (yet) a member of,
but whom I think are the main ones to consult regarding this this, since
Eli and Stefan haven't stated any objections with such a move.

João

Re: Drop the Copyright Assignment requirement for Emacs

[Stefan Monnier]

> A bit less sure about Eglot TBH (or any LSP client), because Emacs has
> a long history of alternative solutions in this field, and it would be 
> best not to step on their toes either.

I strongly disagree here: the existence of various implementations of
a feature shouldn't mean that we can't have such a feature in vanilla
Emacs (which would also mean we can't have such a feature enabled by
default).


        Stefan


PS: "vanilla Emacs" here refers to what you get in Emacs's tarball.

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 10.05.2020 19:39, Stefan Monnier wrote:
>> A bit less sure about Eglot TBH (or any LSP client), because Emacs has
>> a long history of alternative solutions in this field, and it would be
>> best not to step on their toes either.
> I strongly disagree here: the existence of various implementations of
> a feature shouldn't mean that we can't have such a feature in vanilla
> Emacs (which would also mean we can't have such a feature enabled by
> default).

I agree in principle, but enabling it by default is not enough for the 
feature to work (a language server needs to be installed, a build 
configuration file created...).

And really, do you expect to be able to enable Eglot by default anytime 
soon?

Re: Drop the Copyright Assignment requirement for Emacs

[Stefan Monnier]

> And really, do you expect to be able to enable Eglot by default
> anytime soon?

No, I'm just pointing out that existence of alternatives should be
prevent integration.  I would also say that having Eglot in core
shouldn't necessarily prevent inclusion of LSP-mode in core either.

I always strongly favor merging alternatives (at least by sharing as
much code as possible), but there are several examples where we
have such alternatives in core.
E.g. expand.el -vs- skeleton.el -vs- tempo.el,
perl-mode -vs- cperl-mode,
pascal-mode -vs- opascal-mode,
...


        Stefan

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 10.05.2020 20:58, Stefan Monnier wrote:
>> And really, do you expect to be able to enable Eglot by default
>> anytime soon?
> No, I'm just pointing out that existence of alternatives should be
> prevent integration.  I would also say that having Eglot in core
> shouldn't necessarily prevent inclusion of LSP-mode in core either.

By alternative solutions, I actually meant non-LSP projects (some of 
them old) like etags/irony/cider/repl-based completion providers, and so 
on. Every one of them has some existing userbase not in a hurry to 
install language servers.

 > I always strongly favor merging alternatives (at least by sharing as
much code as possible), but there are several examples where we
have such alternatives in core.
E.g. expand.el -vs- skeleton.el -vs- tempo.el,
perl-mode -vs- cperl-mode,
pascal-mode -vs- opascal-mode,

I guess it's a personal opinion, but while having major modes for #10 
most popular languages in vanilla Emacs is a good idea, I'd rather have 
everything else in ELPA. Unless including a package in vanilla provides 
some specific benefits aside from not having to 'M-x package-install'.

Regarding discoverability, I would argue that having a package show up 
in 'M-x list-packages' might do more for it than having it somewhere 
inside Emacs distribution, but disabled by default.

Re: Drop the Copyright Assignment requirement for Emacs

[Daniel Colascione]

On 5/10/20 9:39 AM, Stefan Monnier wrote:
>> A bit less sure about Eglot TBH (or any LSP client), because Emacs has
>> a long history of alternative solutions in this field, and it would be
>> best not to step on their toes either.
> 
> I strongly disagree here: the existence of various implementations of
> a feature shouldn't mean that we can't have such a feature in vanilla
> Emacs (which would also mean we can't have such a feature enabled by
> default).
> 

Right. And these externally developed modules function as a kind of 
laboratory that explores what should be in core when core support 
happens. Emacs should be usable, attractive, and compelling out of the box.

Re: Drop the Copyright Assignment requirement for Emacs

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

  > That was my impression initially too.  But in practice it evolved to
  > a place for the "not quite ready for prime-time" cases: i.e. we
  > let most everything in, provided they have copyright and adhere
  > to some minimal conventions.

That is a good point.

				  So we don't uphold the same
  > standard there, never did, I think.

Not 100% of the technical conventions, I think -- but the exceptions,
the ones we don't insist on before putting the package in ELPA,
should be things that we can reasonably hope to fix.

					 Nowadays, I see ELPA as a
  > staging place for packages to come in, eventually make it into core
  > _and_ back into ELPA as :core packages.

I didn't know we were using it that way, but it seems like a good
approach.

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

Re: Drop the Copyright Assignment requirement for Emacs

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

  > That was my impression initially too.  But in practice it evolved to
  > a place for the "not quite ready for prime-time" cases: i.e. we
  > let most everything in, provided they have copyright and adhere
  > to some minimal conventions.

That is a good point.

				  So we don't uphold the same
  > standard there, never did, I think.

Not 100% of the technical conventions, I think -- but the exceptions,
the ones we don't insist on before putting the package in ELPA,
should be things that we know we can fix when someone has time to do it,
because all it takes is some work.

					 Nowadays, I see ELPA as a
  > staging place for packages to come in, eventually make it into core
  > _and_ back into ELPA as :core packages.

It's ok to use it that way.

  > FWIW, I don't fully agree with Stefan: we should not require
  > copyright assignment for inclusion in GNU ELPA if that introduces
  > needless friction, but we should require of authors, maintainers or
  > proponents that they make an effort to track down the contributors
  > and solve this, otherwise it makes no sense for it to be there.

It would be unwise to put that sort of work off, because we can't do
it on our own.  Our doing work is not guaranteed to suffice.

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

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 08.05.2020 21:54, Eli Zaretskii wrote:
> After thinking about that for a while, I came to the sad conclusion
> that I no longer understand what is the relation between GNU ELPA and
> the Emacs project.

I've always considered GNU ELPA to be the "blessed" package repository 
of Emacs. One where we have read the code of all packages and can 
confirm that they don't do anything malicious and don't use proprietary 
software. And aren't useless, I guess.

In any case, since we can't confirm the same of MELPA packages (at any 
time the author of a given package could push out a new version with 
some malicious payload inside; that's never happened, but still), we 
can't recommend them to the same extent.

That's why we have ELPA as the only package repository in new Emacs 
installations. And these are also the reasons why it's good to add new 
packages to it.

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 9 May 2020 18:46:07 +0300
> 
> On 08.05.2020 21:54, Eli Zaretskii wrote:
> > After thinking about that for a while, I came to the sad conclusion
> > that I no longer understand what is the relation between GNU ELPA and
> > the Emacs project.
> 
> I've always considered GNU ELPA to be the "blessed" package repository 
> of Emacs. One where we have read the code of all packages and can 
> confirm that they don't do anything malicious and don't use proprietary 
> software. And aren't useless, I guess.

Why do we need to bless any package?  I can understand why the package
developers would want to be blessed, but why do _we_ want to do so?  I
could understand that effort being invested if we gain more packages
that could be pout in core or bundled with Emacs or even just being
optional dependencies in our code.  But waiving our basic requirements
makes sure these packages will _never_ be eligible, which makes this
effort not worth it.

> In any case, since we can't confirm the same of MELPA packages (at any 
> time the author of a given package could push out a new version with 
> some malicious payload inside; that's never happened, but still), we 
> can't recommend them to the same extent.

We don't _have_ to recommend anything.  People will use them or won't
use them regardless.

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 11.05.2020 19:33, Eli Zaretskii wrote:
> Why do we need to bless any package?  I can understand why the package
> developers would want to be blessed, but why do_we_  want to do so?

Because we can tell the users on our home page to:

1. Install Emacs,

2. If you [do IDE stuff with it], install packages b and c.

3. Be productive.

or

4. [do some creative stuff with it]

5. Install packages d and e.

6. Be happy and create.

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 19:56:59 +0300
> 
> On 11.05.2020 19:33, Eli Zaretskii wrote:
> > Why do we need to bless any package?  I can understand why the package
> > developers would want to be blessed, but why do_we_  want to do so?
> 
> Because we can tell the users on our home page to:
> 
> 1. Install Emacs,
> 
> 2. If you [do IDE stuff with it], install packages b and c.
> 
> 3. Be productive.
> 
> or
> 
> 4. [do some creative stuff with it]
> 
> 5. Install packages d and e.
> 
> 6. Be happy and create.

We can say the same without having the packages in ELPA, we just need
to tell them in addition to set up package.el for MELPA.

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 11.05.2020 20:13, Eli Zaretskii wrote:
> We can say the same without having the packages in ELPA, we just need
> to tell them in addition to set up package.el for MELPA.

Then, if MELPA suffers a security breach, we will likely be taking a 
significant part of the blame.

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 20:28:27 +0300
> 
> On 11.05.2020 20:13, Eli Zaretskii wrote:
> > We can say the same without having the packages in ELPA, we just need
> > to tell them in addition to set up package.el for MELPA.
> 
> Then, if MELPA suffers a security breach, we will likely be taking a 
> significant part of the blame.

No, we won't.  The responsibility is on the end-user and on MELPA
admins.

Re: Drop the Copyright Assignment requirement for Emacs

[David Engster]

>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Mon, 11 May 2020 19:56:59 +0300
>
>> 
>> On 11.05.2020 19:33, Eli Zaretskii wrote:
>> > Why do we need to bless any package?  I can understand why the package
>> > developers would want to be blessed, but why do_we_  want to do so?
>> 
>> Because we can tell the users on our home page to:
>> 
>> 1. Install Emacs,
>> 
>> 2. If you [do IDE stuff with it], install packages b and c.
>> 
>> 3. Be productive.
>> 
>> or
>> 
>> 4. [do some creative stuff with it]
>> 
>> 5. Install packages d and e.
>> 
>> 6. Be happy and create.
>
> We can say the same without having the packages in ELPA, we just need
> to tell them in addition to set up package.el for MELPA.

No, we cannot do that. MELPA contains packages promoting non-free
software and services, so at least Richard would surely veto that.

-David

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org
> Date: Mon, 11 May 2020 19:33:26 +0200
> 
> > We can say the same without having the packages in ELPA, we just need
> > to tell them in addition to set up package.el for MELPA.
> 
> No, we cannot do that. MELPA contains packages promoting non-free
> software and services, so at least Richard would surely veto that.

If your problem is mentioning "MELPA" the name, we don't have to do
that.  How to add any site to the package.el setup is already
documented in the Emacs user manual.

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 11.05.2020 21:20, Eli Zaretskii wrote:
>>> We can say the same without having the packages in ELPA, we just need
>>> to tell them in addition to set up package.el for MELPA.
>> No, we cannot do that. MELPA contains packages promoting non-free
>> software and services, so at least Richard would surely veto that.
> If your problem is mentioning "MELPA" the name, we don't have to do
> that.  How to add any site to the package.el setup is already
> documented in the Emacs user manual.

If we don't do any of that, we can't create a publish a user-friendly 
guide "How to IDE" on our website.

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 21:58:45 +0300
> 
> On 11.05.2020 21:20, Eli Zaretskii wrote:
> >>> We can say the same without having the packages in ELPA, we just need
> >>> to tell them in addition to set up package.el for MELPA.
> >> No, we cannot do that. MELPA contains packages promoting non-free
> >> software and services, so at least Richard would surely veto that.
> > If your problem is mentioning "MELPA" the name, we don't have to do
> > that.  How to add any site to the package.el setup is already
> > documented in the Emacs user manual.
> 
> If we don't do any of that, we can't create a publish a user-friendly 
> guide "How to IDE" on our website.

I don't think we should give up our standards to gain a couple of
marketing points.  It is completely backwards, IMO, to put that cart
ahead of the horse.  We are supposed to develop high-quality software
first and advertising ourselves second, not the other way around.

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 11.05.2020 22:54, Eli Zaretskii wrote:
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Mon, 11 May 2020 21:58:45 +0300
>>
>> On 11.05.2020 21:20, Eli Zaretskii wrote:
>>>>> We can say the same without having the packages in ELPA, we just need
>>>>> to tell them in addition to set up package.el for MELPA.
>>>> No, we cannot do that. MELPA contains packages promoting non-free
>>>> software and services, so at least Richard would surely veto that.
>>> If your problem is mentioning "MELPA" the name, we don't have to do
>>> that.  How to add any site to the package.el setup is already
>>> documented in the Emacs user manual.
>>
>> If we don't do any of that, we can't create a publish a user-friendly
>> guide "How to IDE" on our website.
> 
> I don't think we should give up our standards to gain a couple of
> marketing points.

It's usability, not just marketing.

> It is completely backwards, IMO, to put that cart
> ahead of the horse.  We are supposed to develop high-quality software
> first and advertising ourselves second, not the other way around.

We're supposed to make our users' life better.

Re: Drop the Copyright Assignment requirement for Emacs

[Alfred M. Szmidt]

   > I don't think we should give up our standards to gain a couple of
   > marketing points.

   It's usability, not just marketing.

Emacs seems quite usable to me.

   > It is completely backwards, IMO, to put that cart
   > ahead of the horse.  We are supposed to develop high-quality software
   > first and advertising ourselves second, not the other way around.

   We're supposed to make our users' life better.

That is achievable without giving up developing high-quality free
software.

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> Cc: deng@randomsample.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 11 May 2020 23:03:56 +0300
> 
> >> If we don't do any of that, we can't create a publish a user-friendly
> >> guide "How to IDE" on our website.
> > 
> > I don't think we should give up our standards to gain a couple of
> > marketing points.
> 
> It's usability, not just marketing.
> 
> > It is completely backwards, IMO, to put that cart
> > ahead of the horse.  We are supposed to develop high-quality software
> > first and advertising ourselves second, not the other way around.
> 
> We're supposed to make our users' life better.

Again, not at any cost, and not by giving up our principles.

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 12.05.2020 05:28, Eli Zaretskii wrote:
>> Cc:deng@randomsample.de,monnier@iro.umontreal.ca,emacs-devel@gnu.org
>> From: Dmitry Gutov<dgutov@yandex.ru>
>> Date: Mon, 11 May 2020 23:03:56 +0300
>>
>>>> If we don't do any of that, we can't create a publish a user-friendly
>>>> guide "How to IDE" on our website.
>>> I don't think we should give up our standards to gain a couple of
>>> marketing points.
>> It's usability, not just marketing.
>>
>>> It is completely backwards, IMO, to put that cart
>>> ahead of the horse.  We are supposed to develop high-quality software
>>> first and advertising ourselves second, not the other way around.
>> We're supposed to make our users' life better.
> Again, not at any cost, and not by giving up our principles.

I don't understand what you're saying.

Publishing a better "getting started" guide would go against our 
"principles"?

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> Cc: deng@randomsample.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 12 May 2020 16:58:20 +0300
> 
> On 12.05.2020 05:28, Eli Zaretskii wrote:
> >> Cc:deng@randomsample.de,monnier@iro.umontreal.ca,emacs-devel@gnu.org
> >> From: Dmitry Gutov<dgutov@yandex.ru>
> >> Date: Mon, 11 May 2020 23:03:56 +0300
> >>
> >>>> If we don't do any of that, we can't create a publish a user-friendly
> >>>> guide "How to IDE" on our website.
> >>> I don't think we should give up our standards to gain a couple of
> >>> marketing points.
> >> It's usability, not just marketing.
> >>
> >>> It is completely backwards, IMO, to put that cart
> >>> ahead of the horse.  We are supposed to develop high-quality software
> >>> first and advertising ourselves second, not the other way around.
> >> We're supposed to make our users' life better.
> > Again, not at any cost, and not by giving up our principles.
> 
> I don't understand what you're saying.
> 
> Publishing a better "getting started" guide would go against our 
> "principles"?

No, but installing packages that don't adhere to our standards is.

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 12.05.2020 20:08, Eli Zaretskii wrote:
>>>>>> If we don't do any of that, we can't create a publish a user-friendly
>>>>>> guide "How to IDE" on our website.
>>>>> I don't think we should give up our standards to gain a couple of
>>>>> marketing points.
>>>> It's usability, not just marketing.
>>>>
>>>>> It is completely backwards, IMO, to put that cart
>>>>> ahead of the horse.  We are supposed to develop high-quality software
>>>>> first and advertising ourselves second, not the other way around.
>>>> We're supposed to make our users' life better.
>>> Again, not at any cost, and not by giving up our principles.
>> I don't understand what you're saying.
>>
>> Publishing a better "getting started" guide would go against our
>> "principles"?
> No, but installing packages that don't adhere to our standards is.

Let me try this again. Is installing an otherwise Free Software package, 
one that doesn't belong to FSF though, against our *principles*?

It's certainly not against mine.

Re: Drop the Copyright Assignment requirement for Emacs

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

  > Publishing a better "getting started" guide would go against our 
  > "principles"?

That depends on what would be "better" about the proposed "better" guide.

If it teaches the same things and is better inthe manner of teaching
them, I think we would embrace it.

But if the "improvement" consists of recommending things that go
against our principles, then yes that guide would go against our
principles.

I think Eli has a feeling it would be the latter case.  But you
"restated" his position to leave that possibility out of it.
The effect is to criticize something that isn't what he said.

This does not contribute to a useful discussion.

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

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 14.05.2020 08:14, Richard Stallman wrote:
>    > Publishing a better "getting started" guide would go against our
>    > "principles"?
> 
> That depends on what would be "better" about the proposed "better" guide.
> 
> If it teaches the same things and is better inthe manner of teaching
> them, I think we would embrace it.

The goal is pretty much this, except one obstacle is missing a number of 
(otherwise libre software) packages in GNU ELPA, because of the 
copyright assignment difficulties.

> But if the "improvement" consists of recommending things that go
> against our principles, then yes that guide would go against our
> principles.
> 
> I think Eli has a feeling it would be the latter case.

I don't see why. Or what part of the previous discussion would lead him 
(or you) to that conclusion.

Re: Drop the Copyright Assignment requirement for Emacs

[Stefan Monnier]

> I don't think we should give up our standards to gain a couple of
> marketing points.  It is completely backwards, IMO, to put that cart
> ahead of the horse.  We are supposed to develop high-quality software
> first and advertising ourselves second, not the other way around.

Given the context, the above could be understood to mean that you
consider that developers of MELPA packages are not part of "us" and
don't develop high-quality software.

I don't think that was your intention, but at the same time I'm not
completely sure what you wanted to say because I don't see the direct
connection with copyright assignments for GNU ELPA (which do nothing for
the quality of software) nor with adding a hypothetical archive like
MELPA-Libre (or GNU-ELPA-contrib) to our `package-archives`.


        Stefan

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  deng@randomsample.de,
>   emacs-devel@gnu.org
> Date: Mon, 11 May 2020 17:12:54 -0400
> 
> Given the context, the above could be understood to mean that you
> consider that developers of MELPA packages are not part of "us" and
> don't develop high-quality software.
> 
> I don't think that was your intention, but at the same time I'm not
> completely sure what you wanted to say because I don't see the direct
> connection with copyright assignments for GNU ELPA (which do nothing for
> the quality of software) nor with adding a hypothetical archive like
> MELPA-Libre (or GNU-ELPA-contrib) to our `package-archives`.

MELPA packages are not part of the Emacs project, yes.  As for their
quality, all I'm saying is that we should consider the quality when we
make the decision whether we want a certain package in ELPA.  If the
package being considered is not up to our standards, we should ask the
developer to make the necessary changes.  Like we do with any other
contribution to Emacs.

Copyright assignments are not related to quality, they are related to
our ability to move packages into and out of core without a lot of
fuss.

Re: Drop the Copyright Assignment requirement for Emacs

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

  > Given the context, the above could be understood to mean that you
  > consider that developers of MELPA packages are not part of "us" and
  > don't develop high-quality software.

I have no comment to make about the quality of their software.
I suppose some packages are high quality and some are not.

Whether they are part of "us" is another question.  Or rather,
several other questions.

We could mean the developers of GNU Emacs.  We would welcome their
help, if they want to contribute.  To do that, they should talk with
us and try to make their contributions fit in.

We could mean the GNU Project.  We campaign for certain overriding
goals and principles: our work is not simply to develop "high-quality
software".  To help us, they should support our campaign -- starting
with not recommending nonfree software.

They choose what they do, and through that choice, they also choose to
be part of "us" or not.

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

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

I just had to sign something online and I wonder if Emacs copyright
assignments could not use the same mechanism.

It was done with Adobe Sign, basically it displayed a PDF to me in my
browser and I could sign by writing on my keyboard (displayed using a
"hand-written" font), draw with my mouse, or import an image of my
signature (or even use my mobile device).

I don't think we need that much options (just type on keyboard), but
surely something similar is doable using only GNU tools no? If you can
reduce the "print - sign - scan - email" cycle to "browse online and
click" I suspect a lot more people would agree to bother with the
copyright assignments.

Kind regards,
Philippe

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 18.05.2020 08:56, Philippe Vaucher wrote:
> I just had to sign something online and I wonder if Emacs copyright
> assignments could not use the same mechanism.
> 
> It was done with Adobe Sign, basically it displayed a PDF to me in my
> browser and I could sign by writing on my keyboard (displayed using a
> "hand-written" font), draw with my mouse, or import an image of my
> signature (or even use my mobile device).
> 
> I don't think we need that much options (just type on keyboard), but
> surely something similar is doable using only GNU tools no? If you can
> reduce the "print - sign - scan - email" cycle to "browse online and
> click" I suspect a lot more people would agree to bother with the
> copyright assignments.

IIRC US and German citizens can sign the copyright assignment 
electronically (no snail mail involved). Citizens of other countries 
can't do that yet.

Re: Drop the Copyright Assignment requirement for Emacs

[Clément Pit-Claudel]

On 18/05/2020 07.33, Dmitry Gutov wrote:
> IIRC US and German citizens can sign the copyright assignment electronically (no snail mail involved). Citizens of other countries can't do that yet.

Thankfully, things have improved since then: https://www.fsf.org/blogs/licensing/fsf-now-offering-paperless-option-for-all-copyright-assignments

Re: Drop the Copyright Assignment requirement for Emacs

[Dmitry Gutov]

On 18.05.2020 16:16, Clément Pit-Claudel wrote:
> On 18/05/2020 07.33, Dmitry Gutov wrote:
>> IIRC US and German citizens can sign the copyright assignment electronically (no snail mail involved). Citizens of other countries can't do that yet.
> Thankfully, things have improved since then:https://www.fsf.org/blogs/licensing/fsf-now-offering-paperless-option-for-all-copyright-assignments
> 

Ooh, that's a good news, then. My info was seriously out of date.

Re: Drop the Copyright Assignment requirement for Emacs

[Robert Pluim]

>>>>> On Mon, 18 May 2020 16:25:45 +0300, Dmitry Gutov <dgutov@yandex.ru> said:

    Dmitry> On 18.05.2020 16:16, Clément Pit-Claudel wrote:
    >> On 18/05/2020 07.33, Dmitry Gutov wrote:
    >>> IIRC US and German citizens can sign the copyright assignment
    >>> electronically (no snail mail involved). Citizens of other
    >>> countries can't do that yet.
    >> Thankfully, things have improved since
    >> then:https://www.fsf.org/blogs/licensing/fsf-now-offering-paperless-option-for-all-copyright-assignments
    >> 

    Dmitry> Ooh, that's a good news, then. My info was seriously out of date.

This is not what Iʼd call 'electronic signing'. You print the form,
sign it with a pen, scan it, and email it. Someone mentioned using PGP
to do the signing, now that would be electronic signing.

Robert

Re: Drop the Copyright Assignment requirement for Emacs

[Clément Pit-Claudel]

On 18/05/2020 12.36, Robert Pluim wrote:
>>>>>> On Mon, 18 May 2020 16:25:45 +0300, Dmitry Gutov <dgutov@yandex.ru> said:
> 
>     Dmitry> On 18.05.2020 16:16, Clément Pit-Claudel wrote:
>     >> On 18/05/2020 07.33, Dmitry Gutov wrote:
>     >>> IIRC US and German citizens can sign the copyright assignment
>     >>> electronically (no snail mail involved). Citizens of other
>     >>> countries can't do that yet.
>     >> Thankfully, things have improved since
>     >> then:https://www.fsf.org/blogs/licensing/fsf-now-offering-paperless-option-for-all-copyright-assignments
>     >> 
> 
>     Dmitry> Ooh, that's a good news, then. My info was seriously out of date.
> 
> This is not what Iʼd call 'electronic signing'. You print the form,
> sign it with a pen, scan it, and email it. Someone mentioned using PGP
> to do the signing, now that would be electronic signing.

Do you know that this is currently not possible? I know PGP is possible for people in the US, at least, and has been for a long time.

Re: Drop the Copyright Assignment requirement for Emacs

[Robert Pluim]

>>>>> On Mon, 18 May 2020 15:04:30 -0400, Clément Pit-Claudel <cpitclaudel@gmail.com> said:

    Clément> On 18/05/2020 12.36, Robert Pluim wrote:
    >>>>>>> On Mon, 18 May 2020 16:25:45 +0300, Dmitry Gutov <dgutov@yandex.ru> said:
    >> 
    Dmitry> On 18.05.2020 16:16, Clément Pit-Claudel wrote:
    >> >> On 18/05/2020 07.33, Dmitry Gutov wrote:
    >> >>> IIRC US and German citizens can sign the copyright assignment
    >> >>> electronically (no snail mail involved). Citizens of other
    >> >>> countries can't do that yet.
    >> >> Thankfully, things have improved since
    >> >> then:https://www.fsf.org/blogs/licensing/fsf-now-offering-paperless-option-for-all-copyright-assignments
    >> >> 
    >> 
    Dmitry> Ooh, that's a good news, then. My info was seriously out of date.
    >> 
    >> This is not what Iʼd call 'electronic signing'. You print the form,
    >> sign it with a pen, scan it, and email it. Someone mentioned using PGP
    >> to do the signing, now that would be electronic signing.

    Clément> Do you know that this is currently not possible? I know PGP is
    Clément> possible for people in the US, at least, and has been for a long time.

I donʼt know one way or the other. We could ask the FSF, I suppose.

Robert

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> > I don't think we need that much options (just type on keyboard), but
> > surely something similar is doable using only GNU tools no? If you can
> > reduce the "print - sign - scan - email" cycle to "browse online and
> > click" I suspect a lot more people would agree to bother with the
> > copyright assignments.
>
> IIRC US and German citizens can sign the copyright assignment
> electronically (no snail mail involved). Citizens of other countries
> can't do that yet.

Yes, as I said I also could print-sign-scan-email, but that's still a
lot of work compared to just "browse to some webpage and click next"
like I did.

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> > IIRC US and German citizens can sign the copyright assignment
> > electronically (no snail mail involved). Citizens of other countries
> > can't do that yet.
>
> Yes, as I said I also could print-sign-scan-email, but that's still a
> lot of work compared to just "browse to some webpage and click next"
> like I did.

... like I did on that other site that used Adobe Sign.

Philippe

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

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

On Mon, May 18, 2020 at 2:28 PM Philippe Vaucher <philippe.vaucher@gmail.com>
wrote:

> > IIRC US and German citizens can sign the copyright assignment
> > electronically (no snail mail involved). Citizens of other countries
> > can't do that yet.
> Yes, as I said I also could print-sign-scan-email, but that's still a
> lot of work compared to just "browse to some webpage and click next"
> like I did.


Isn't it enough to overlay a bitmap of your signature into the PDF file,
or does the FSF really require that you print a dead-tree version and
then rescan it back onto digital?  I "signed" lots of documents using
the overlay technique recently for my university. It was very easy and
IMO entirely equivalent to the print-and-scan method, security-wise.
You can do it easily from the Gimp, and likely most image-editing
programs.

João

[-- Attachment #2: Type: text/html, Size: 1270 bytes --]

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

>> Yes, as I said I also could print-sign-scan-email, but that's still a
>> lot of work compared to just "browse to some webpage and click next"
>> like I did.
>
> Isn't it enough to overlay a bitmap of your signature into the PDF file,
> or does the FSF really require that you print a dead-tree version and
> then rescan it back onto digital?  I "signed" lots of documents using
> the overlay technique recently for my university. It was very easy and
> IMO entirely equivalent to the print-and-scan method, security-wise.
> You can do it easily from the Gimp, and likely most image-editing
> programs.

Yes, that'd work...

But it's still more work than simply clicking a few times in a browser.

The first thing is that all you have is a PDF. The instructions are to
print it, sign it and a scan it. So you first MUST have the idea of
editing it in gimp. Then you have to find your signature. Then realise
you cannot find it anymore. Thus sign a piece of paper & scan it. Then
do the gimp editing. Then export the image. Then go back to email
writing and attach the file.

Do you understand my point now?

Maybe we have different limits as to what is perceived "annoying
paperwork" but to me (and I suspect a lot of others) it's basically:
anything where I cannot complete the annoying process in one smooth
go.

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> The first thing is that all you have is a PDF. The instructions are to
> print it, sign it and a scan it. So you first MUST have the idea of
> editing it in gimp. Then you have to find your signature. Then realise
> you cannot find it anymore. Thus sign a piece of paper & scan it. Then
> do the gimp editing. Then export the image. Then go back to email
> writing and attach the file.

Just to make it extra clear, compare that with:

"Follow this link to begin the assignment process [LINK]". You click
it, it says "you are about to do this and that". You click next. You
have a form to fill with very little information that are very easy
available to you. In that form there is a way to add your signature by
simply typing your name or attaching an image. When you finish it says
"are you sure?" and you click yes and it says "Thanks! Everything is
done you are free to go".

One smooth registration process without any manual kludges in the
middle. That's what most people want.

Philippe

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Mon, May 18, 2020 at 5:46 PM Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:

> "Follow this link to begin the assignment process [LINK]". You click
> it, it says "you are about to do this and that". You click next. You
> have a form to fill with very little information that are very easy
> available to you. In that form there is a way to add your signature by
> simply typing your name or attaching an image. When you finish it says
> "are you sure?" and you click yes and it says "Thanks! Everything is
> done you are free to go".
>
> One smooth registration process without any manual kludges in the
> middle. That's what most people want.

Sure, if you want to write that using Free software and respecting
privacy, I'm all for it, go ahead.  But don't try to convince me that's
what's going to get people to start contributing to Emacs.

(and I do note you'd still have to go through the horrors of finding a
pen and paper in your office and manually using your arms to hold
it up to the webcam)

João

Re: Drop the Copyright Assignment requirement for Emacs

[Stefan Monnier]

> (and I do note you'd still have to go through the horrors of finding a
> pen and paper in your office and manually using your arms to hold
> it up to the webcam)

[ FWIW, for me until about a year or two ago, the problem was not so much
  finding a pen, but finding a scanner or a camera.  ]

Many parts of the assignment process could be streamlined in some way.
The actual signing is one part where improvements can be possible but
AFAIK they're mostly imposed by legal issues (where the FSF wants to
make sure that the signature would be legally valid in a court of law),
so it's likely the hardest part to streamline, and I suspect that the
current situation is "good enough" that it's "out of the critical
path" nowadays.

The "critical path" is rather on the ideological side, on the "so many
steps, so much time" side (send an email to emacs-devel, then get an
email in return, the send an email to the FSF, then ... the actual
signing is a just a small part of it compared to all the waiting), and
last but not least on getting the employer to sign its part.


        Stefan

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Mon, May 18, 2020 at 6:15 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The "critical path" is rather on the ideological side, on the "so many
> steps, so much time" side

Those are quite two different sides.  And yes I agree the
"ideological side" is very relevant here, I've said it before.

> (send an email to emacs-devel, then get an
> email in return, the send an email to the FSF, then

Yes, the hard life of sending email back and forth. As
evidenced by zillion-mail-long threads about the subject.

> signing is a just a small part of it compared to all the waiting), and
> last but not least on getting the employer to sign its part.

My employer didn't sign anything back in 2012 oir 2011
or something like that. I just answered a questionnaire, I think,
stating that the employer had no claim over the software.

And if there's no impediments, I think patch reviews can
proceed while all that waiting is going on . In my case I did
it for yasnippet and I didn't stop contributing to it while I
was waiting for the paperwork to come in.

I disagree with you, Stefan, I think the "critical path" lies
in the engineering bits. As you said: integration is hard.

João

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> (and I do note you'd still have to go through the horrors of finding a
> pen and paper in your office and manually using your arms to hold
> it up to the webcam)

Please, I said 3 times already that YOU JUST TYPE YOUR NAME ON YOUR
KEYBOARD, or attach an image. Yes, that's how I did in in Adobe Sign
(just typed "Philippe Vaucher" on my keyboard). The only thing it did
is the name was displayed using a hand-written font. Surely this
cannot be complicated to duplicate. I already said all this.

Sorry for yelling but maybe with caps it's more clear.

Philippe

Re: Drop the Copyright Assignment requirement for Emacs

[Yuri Khan]

On Tue, 19 May 2020 at 12:27, Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:

> Please, I said 3 times already that YOU JUST TYPE YOUR NAME ON YOUR
> KEYBOARD, or attach an image. Yes, that's how I did in in Adobe Sign
> (just typed "Philippe Vaucher" on my keyboard). The only thing it did
> is the name was displayed using a hand-written font. Surely this
> cannot be complicated to duplicate. I already said all this.

OK, that is very convenient for the signer, but how can the recipient
of such a signed document verify this signature? If it is taken at
face value, I can’t see anything that prevents an adversary from
typing your name and signing away some of your possessions.

With hand-written signatures, the assumption is that your signature is
sufficiently complex that another person cannot duplicate it in a way
that a graphologist wouldn’t detect. With GPG, the assumption is that
you control your private key and that it cannot be brute-forced in a
realistic time frame.

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> > Please, I said 3 times already that YOU JUST TYPE YOUR NAME ON YOUR
> > KEYBOARD, or attach an image. Yes, that's how I did in in Adobe Sign
> > (just typed "Philippe Vaucher" on my keyboard). The only thing it did
> > is the name was displayed using a hand-written font. Surely this
> > cannot be complicated to duplicate. I already said all this.
>
> OK, that is very convenient for the signer, but how can the recipient
> of such a signed document verify this signature? If it is taken at
> face value, I can’t see anything that prevents an adversary from
> typing your name and signing away some of your possessions.
>
> With hand-written signatures, the assumption is that your signature is
> sufficiently complex that another person cannot duplicate it in a way
> that a graphologist wouldn’t detect. With GPG, the assumption is that
> you control your private key and that it cannot be brute-forced in a
> realistic time frame.

As with hand-written signature, you are supposed to check the identify
of the signer prior to that.

Electronically, that means receive a private link through your
verified email that only you can access.

Philippe

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> > OK, that is very convenient for the signer, but how can the recipient
> > of such a signed document verify this signature? If it is taken at
> > face value, I can’t see anything that prevents an adversary from
> > typing your name and signing away some of your possessions.

Just to enhance a little bit on that, from what I read on digital
signatures what counts more is "the intent to sign" rather that the
form. I am pretty sure that if Adobe Sign decide it's a valid way of
signing they it probably is.

> With hand-written signatures, the assumption is that your signature is
> sufficiently complex that another person cannot duplicate it in a way
> that a graphologist wouldn’t detect.

I think that was the original intent but it's not really valid
anymore. For example if there is a camera showing me signing a
document but signing "John Smith" instead of my real name, I guess the
signature would still be valid despite not being "verifiable" using
the graphologist method. What counts more is being able to capture the
"intent to sign". When doing this online, there are several ways to
capture that intent (2-step identifications, confirmations, etc).

> With GPG, the assumption is that
> you control your private key and that it cannot be brute-forced in a
> realistic time frame.

Just to be clear I'm not against adding a little GPG dance, especially
since it can help identify commits authors later on. Maybe that can
even replace the "complicated" PDF display and make the
print-scan-email cycle more simple, that'd already be an improvement.

Philippe

Re: Drop the Copyright Assignment requirement for Emacs

[Clément Pit-Claudel]

On 19/05/2020 01.49, Yuri Khan wrote:
> With GPG, the assumption is that
> you control your private key and that it cannot be brute-forced in a
> realistic time frame.

The FSF doesn't verify that your PGP signature matches you.  Nor is it necessary, really, since the adversarial case isn't very interesting (worst case, you just remove the corresponding code from your codebase; a pain, but not the end of the world).

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> > (and I do note you'd still have to go through the horrors of finding a
> > pen and paper in your office and manually using your arms to hold
> > it up to the webcam)
>
> Please, I said 3 times already that YOU JUST TYPE YOUR NAME ON YOUR
> KEYBOARD, or attach an image. Yes, that's how I did in in Adobe Sign
> (just typed "Philippe Vaucher" on my keyboard). The only thing it did
> is the name was displayed using a hand-written font. Surely this
> cannot be complicated to duplicate. I already said all this.

Ok, I looked what it means in terms of technology, it's all pretty
simple on the UI side (even drawing your signature with the mouse is
easy: https://codepen.io/dus7/pen/qGQbVP)

But it's more complicated on the digital signature side:

It looks like for the form you cannot simply use an HTML page over
HTTPs, you have to display a PDF. In the open source world I found
https://www.signserver.org and http://isafepdf.eurekaa.org, there are
probably others too, it looks like a lot of companies are into this
business. Anyhow I don't think it'd be particularly complicated to
find out how to achieve online digital signatures, but sure it's an
investment of time & effort.

Philippe

Re: Drop the Copyright Assignment requirement for Emacs

[tomas]

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

On Tue, May 19, 2020 at 07:26:10AM +0200, Philippe Vaucher wrote:
> > (and I do note you'd still have to go through the horrors of finding a
> > pen and paper in your office and manually using your arms to hold
> > it up to the webcam)
> 
> Please, I said 3 times already that YOU JUST TYPE YOUR NAME ON YOUR
> KEYBOARD, or attach an image. Yes, that's how I did in in Adobe Sign
> (just typed "Philippe Vaucher" on my keyboard). The only thing it did
> is the name was displayed using a hand-written font. Surely this
> cannot be complicated to duplicate. I already said all this.

But anyone can type your name on her keyboard. I can type it. Am
I now signing something for you? Is it valid before court?

That's the "interesting" problem. Yelling doesn't solve it :)

Now you'd say that I could forge your signature on paper and send
it in, but traditional trust into something like that is a tad
higher, and I see two reasons for that: (a) it is more difficult
to get hold of a physical signature of yours to do the forging,
and (b) there is significantly more expertise in place to detect
forged signatures.

Now PGP/GPG might be a technically perfect solution to the problem,
but effective deployment has been hindered, not last by entities
hoping to make quick cash of that and seeing a free solution
threatening their pie-in-the-sky business plans.

The situation is what it is, alas.

> Sorry for yelling but maybe with caps it's more clear.

Nevermind, but I think you're still missing the point: at the
moment the FSF ends before court over some copyright spat (and
there have been high-profile ones, they can be hellishly
expensive, see [1] if you think you've got some time to kill),
at this moment the FSF will have to prove that it has done its
due diligence... and no, Someone (TM) at the other end of an
HTTPS connection saying "yeah, sure, it's me" probably won't
cut it.

Solutions [2] welcome. Especially if they aren't spiked all over
with Surveillance Capitalism :-)

Cheers

[1] https://en.wikipedia.org/wiki/SCO_Group%2C_Inc._v._International_Business_Machines_Corp.
[2] Sometimes I dream of decentralized FSF "delegates", one
   in each small village, who can sign someone's public GPG
   key. Then I wake up and realize that I'm re-inventing the
   web of trust, and I hear "PGP? But that's really hard",
   and keep wondering where that sick meme comes from. Sigh.

-- tomás

-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> On Tue, May 19, 2020 at 07:26:10AM +0200, Philippe Vaucher wrote:
> > > (and I do note you'd still have to go through the horrors of finding a
> > > pen and paper in your office and manually using your arms to hold
> > > it up to the webcam)
> >
> > Please, I said 3 times already that YOU JUST TYPE YOUR NAME ON YOUR
> > KEYBOARD, or attach an image. Yes, that's how I did in in Adobe Sign
> > (just typed "Philippe Vaucher" on my keyboard). The only thing it did
> > is the name was displayed using a hand-written font. Surely this
> > cannot be complicated to duplicate. I already said all this.
>
> But anyone can type your name on her keyboard. I can type it. Am
> I now signing something for you? Is it valid before court?

No, only me can open that link in my email.

It's apparently valid in court because other companies use that, the
company I had to sign a paper online with is
https://www.milestonesys.com so I trust their judgement but IANAL.
This looks to be the accepted standard in Adobe Sign and I suspect
others too.

To be honest: typing your name, attaching an image, writing your
signature with your mouse: this is all easy to fake if you have access
to the person's email.

Even the current printing-signing-scanning-emailing is very easy to
fake. Even in the real world, it's pretty easy to go in a shop and
order something for someone else.

For serious things, they usually ask for an ID and verify it's you,
which digitally can be done in numerous ways I already enumerated in
other emails.

> That's the "interesting" problem. Yelling doesn't solve it :)

Well I this interesting problem came after my yelling :-) I yelled for
another reason (people misrepresenting the experience I had).

> Now you'd say that I could forge your signature on paper and send
> it in, but traditional trust into something like that is a tad
> higher, and I see two reasons for that: (a) it is more difficult
> to get hold of a physical signature of yours to do the forging,
> and (b) there is significantly more expertise in place to detect
> forged signatures.

I'd argue it's harder to forge a digital signature than a physical
signature, but I don't want to waste braincells about that so let's
just move on :-)

> > Sorry for yelling but maybe with caps it's more clear.
>
> Nevermind, but I think you're still missing the point: at the
> moment the FSF ends before court over some copyright spat (and
> there have been high-profile ones, they can be hellishly
> expensive, see [1] if you think you've got some time to kill),
> at this moment the FSF will have to prove that it has done its
> due diligence... and no, Someone (TM) at the other end of an
> HTTPS connection saying "yeah, sure, it's me" probably won't
> cut it.

Okay, I understand FSF wants the safe option. Once there is
jurisprudence that the digital signatures are valid in court, the FSF
will probably adapt.

So, basically until then it's useless to even pursue these smooth options.

Thanks for making it clear this is a dealbreaker.

Philippe

Re: Drop the Copyright Assignment requirement for Emacs

[tomas]

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

On Tue, May 19, 2020 at 12:11:58PM +0200, Philippe Vaucher wrote:

[...]

> Okay, I understand FSF wants the safe option. Once there is
> jurisprudence that the digital signatures are valid in court, the FSF
> will probably adapt.
> 
> So, basically until then it's useless to even pursue these smooth options.
> 
> Thanks for making it clear this is a dealbreaker.

Well -- I didn't reach that conclusion yet. As you noted,
the environment moves, and it is a Good Thing to get some
discussion moving. Ideally the outcome is some set of
requirements the FSF has on the signature process, and
then a set of technical measures can be adapted to that.

I can understand your position (this pushing of physical
paper around does feel antiquated), so raising the point
is valid. But to change it, it's necessary to understand
why it's there.

Or something.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Drop the Copyright Assignment requirement for Emacs

[Arthur Miller]

<tomas@tuxteam.de> writes:

> On Tue, May 19, 2020 at 07:26:10AM +0200, Philippe Vaucher wrote:
>> > (and I do note you'd still have to go through the horrors of finding a
>> > pen and paper in your office and manually using your arms to hold
>> > it up to the webcam)
>> 
>> Please, I said 3 times already that YOU JUST TYPE YOUR NAME ON YOUR
>> KEYBOARD, or attach an image. Yes, that's how I did in in Adobe Sign
>> (just typed "Philippe Vaucher" on my keyboard). The only thing it did
>> is the name was displayed using a hand-written font. Surely this
>> cannot be complicated to duplicate. I already said all this.
>
> But anyone can type your name on her keyboard. I can type it. Am
> I now signing something for you? Is it valid before court?
>
> That's the "interesting" problem. Yelling doesn't solve it :)
>
> Now you'd say that I could forge your signature on paper and send
> it in, but traditional trust into something like that is a tad
> higher, and I see two reasons for that: (a) it is more difficult
> to get hold of a physical signature of yours to do the forging,
> and (b) there is significantly more expertise in place to detect
> forged signatures.
>
> Now PGP/GPG might be a technically perfect solution to the problem,
> but effective deployment has been hindered, not last by entities
> hoping to make quick cash of that and seeing a free solution
> threatening their pie-in-the-sky business plans.
>
> The situation is what it is, alas.
>
>> Sorry for yelling but maybe with caps it's more clear.
>
> Nevermind, but I think you're still missing the point: at the
> moment the FSF ends before court over some copyright spat (and
> there have been high-profile ones, they can be hellishly
> expensive, see [1] if you think you've got some time to kill),
> at this moment the FSF will have to prove that it has done its
> due diligence... and no, Someone (TM) at the other end of an
> HTTPS connection saying "yeah, sure, it's me" probably won't
> cut it.
>
> Solutions [2] welcome. Especially if they aren't spiked all over
> with Surveillance Capitalism :-)
>
> Cheers
>
> [1] https://en.wikipedia.org/wiki/SCO_Group%2C_Inc._v._International_Business_Machines_Corp.
> [2] Sometimes I dream of decentralized FSF "delegates", one
>    in each small village, who can sign someone's public GPG
>    key. Then I wake up and realize that I'm re-inventing the
>    web of trust, and I hear "PGP? But that's really hard",
>    and keep wondering where that sick meme comes from. Sigh.
>
> -- tomás
>
> -- tomás

Could the problem be attacked from some other angle? It is about
defending in court room? What do you defend in court room? Copyright
(stolen code), patent (stolen idea) and licence (stolen right to use the
code)? Or do I missunderstand?

If someone steel code from some other place, and some company sues for
copyright infrigement, that can equally well happen with current signed
process? Can't it? Some random Joe can send in their paperwork, get
through the process and still send in some code that infringes on
someones copyright. I don't see how is current paperwork a guarantee
against code theft. Patent and licence infrigement are probably
analogus, so I don't think you have a guarantee that this will not
happen even with current process in-place. Yes, FSF has done what it can
to ask you to assure you aren't doing shady stuff, but that can be asked
even without paperwork in some simpler way. No other FOSS projects have
this kind of collaboration demand, are they wrong or bad, I don't know,
but many of them has existed for a blink of time compared to Emacs and
have yet surpassed Emacs in term of users, collaboration etc. I believe
that more users means more developers which means more development and
(maybe) better software.

What about stealth the other way around; if somebody does not take it
and not give back the source code? Does FSF really need to have the
copyright assigned to itself in order to defend someones GPL code? Or
could that assignment happen on case-by-case basis when the situation arises?

Re: Drop the Copyright Assignment requirement for Emacs

[Clément Pit-Claudel]

On 19/05/2020 10.34, Arthur Miller wrote:
> Could the problem be attacked from some other angle? It is about
> defending in court room? What do you defend in court room? Copyright
> (stolen code), patent (stolen idea) and licence (stolen right to use the
> code)? Or do I missunderstand?

I suggest reading these:

  https://www.gnu.org/licenses/why-assign.html
  https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/conditions.text
  https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf
  https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html

Re: Drop the Copyright Assignment requirement for Emacs

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Tue, 19 May 2020 16:34:03 +0200
> Cc: emacs-devel@gnu.org
> 
> Could the problem be attacked from some other angle? It is about
> defending in court room? What do you defend in court room?

Basically, it's defense against someone taking Emacs, making changes
in its code, and then distributing that derivative as their
proprietary product without making the modified source code available.

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> (and I do note you'd still have to go through the horrors of finding a
>> pen and paper in your office and manually using your arms to hold
>> it up to the webcam)
>
> Please, I said 3 times already that YOU JUST TYPE YOUR NAME ON YOUR
> KEYBOARD, or attach an image. Yes, that's how I did in in Adobe Sign
> (just typed "Philippe Vaucher" on my keyboard).

So Adobe Sign allows me to "just type Philippe Vaucher on my keyboard""
and bam, I am Philippe Vaucher!  Gee thanks Adobe.

> Surely this cannot be complicated to duplicate.

Indeed, duplication of the Philippes seems seems to be pretty
straightforward.

> Sorry for yelling but maybe with caps it's more clear.

Hope you used Caps Lock and saved your pinky all the physical!

João

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> So Adobe Sign allows me to "just type Philippe Vaucher on my keyboard""
> and bam, I am Philippe Vaucher!  Gee thanks Adobe.

Yes, just like in a real world shop I can sign X and I am now X
instead of Philippe Vaucher :-)

My point is that signature is not identification, signature is
confirmation. A contract is "identification + confirmation"
(identification of who is about to sign followed by confirmation of
acceptance of the terms).

In the real world it's more complex: identification is done using the
person's ID and the name they filled the form with, then at sign time
the signature is used as a confirmation for closing the deal. Then
later on if there is an issue, the signature is then used as
identification again by comparing it to other signatures and using
graphology.

Online it's more simple: identification is done before accessing the
form (double authentication, email validation, whatever), then once
you access the form there's only the confirmation-step remaining.

Can this be abused? Sure. More that in the real world? I doubt it.

Philippe

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> Online it's more simple: identification is done before accessing the
> form (double authentication, email validation, whatever), then once
> you access the form there's only the confirmation-step remaining.

I'll let you use your imagination as to how add even more
identification along this process, maybe by adding identification after
you confirmed the contract, invalidating it if you cannot reconfirm it's you.




Philippe

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> Online it's more simple: identification is done before accessing the
>> form (double authentication, email validation, whatever), then once
>> you access the form there's only the confirmation-step remaining.
> I'll let you use your imagination as to how add even more
> identification along this process, maybe by adding identification after
> you confirmed the contract, invalidating it if you cannot reconfirm it's you.

You've lost me in the signing technology minutiae at this point.  But I
encourage you to develop a free software solution that does what you
think is important to Emacs and the world in general.

In fact, we can compile a list of things that could ameliorate some of
the problems you are facing and have brought up.  Things you could start
working on, if you so wanted:

- An automated way to generate API lists from certain sections in the
  manual;

- A completion style that scores completion items mentioned in the
  manual higher.  I think I put a prototype of this somewhere in the
  discussion.  On a tangent, today I saw a completion style for emojis
  that showed be :cry: when I typed :sad:.  Interesting;

- A easy-to-use digital/electronic signing solution based on free
  software;

João

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> - An automated way to generate API lists from certain sections in the
>   manual;

I did not notice you because I don't like to do that with unfinished
work, but it's already work in progress.


> - A completion style that scores completion items mentioned in the
>   manual higher.  I think I put a prototype of this somewhere in the
>   discussion.  On a tangent, today I saw a completion style for emojis
>   that showed be :cry: when I typed :sad:.  Interesting;

That I'm not interested in. I want an exact list not fuzzy heuristics.
I'd be easy to implement using what I'm writing above tho.


> - A easy-to-use digital/electronic signing solution based on free
>   software;

As Richard pointed out I'll ask the fsf directly.

Re: Drop the Copyright Assignment requirement for Emacs

[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 Adobe Sign is a proprietary program, please do not talk here
about using it.  The goal of the GNU Project is that nonfree programs
should cease to exist; in the mean time, people should refuse to use them.

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

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> If Adobe Sign is a proprietary program, please do not talk here
> about using it.  The goal of the GNU Project is that nonfree programs
> should cease to exist; in the mean time, people should refuse to use them.

That does not make sense, if you want them to disappear we need to
talk about them on how to replace them with open source tools, which
is my goal in this discussion.

Re: Drop the Copyright Assignment requirement for Emacs

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

  > That does not make sense, if you want them to disappear we need to
  > talk about them on how to replace them with open source tools, which
  > is my goal in this discussion.

Discussing how to replace a nonfree program with a free program (not
"open source") is a useful thing to do.  This would not be the right
place to discuss it, unless the program is closely related to Emacs.

However, talking about _using_ the nonfree program is a different thing.

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

Re: Drop the Copyright Assignment requirement for Emacs

[Arthur Miller]

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. ]]]
>
>   > That does not make sense, if you want them to disappear we need to
>   > talk about them on how to replace them with open source tools, which
>   > is my goal in this discussion.
>
> Discussing how to replace a nonfree program with a free program (not
> "open source") is a useful thing to do.  This would not be the right
> place to discuss it, unless the program is closely related to Emacs.
>
> However, talking about _using_ the nonfree program is a different thing.
There are a lot of non-free programs which can't be replaced easily, at
least currently and it does not really makes sense to ignore them
either. For example I haven't heard or seen of free programs (in GNU
sense) that control life-supporting hardware for medical use, industrial
machines and robots, vechicle controlling systems and such. Sure one
could write such software but companies that produce the hardware does
not, and that will probably not change in very near future.

If people working for those companies or in activities involving such
hardware/software, say in some hospital, and would like to use Emacs (or
other GNU software) to develop possibly but non-necessary free or "open
source" applications to work with/alongside non-free what should they
do? Isn't it unnecessary hard on them to not be able to talk about
non-free software? Isn't it also a limitation on GNU software itself if
it can't be used in such cases as well as further inclination for
development of non-free software?

Re: Drop the Copyright Assignment requirement for Emacs

[Alfred M. Szmidt]

   If people working for those companies or in activities involving such
   hardware/software, say in some hospital, and would like to use Emacs (or
   other GNU software) to develop possibly but non-necessary free or "open
   source" applications to work with/alongside non-free what should they
   do? 

One way that can help the free software movement is to get more people
using free software, trying to get managment, or otherwise to use more
free software, and release existing code under a free software
license.

E.g, having a free software mode for a propietery program, is just
slightly better than depending on the propietery program to edit its
source code.  But this wouldn't be something that would be suitable
for the GNU project, where the goal is to have software to tries to
make non-free software irrelevant.

   Isn't it unnecessary hard on them to not be able to talk about
   non-free software? 

Nobody is prohibiting anyone from talking about non-free software.  It
is just off-topic and unsuitable to discuss non-free software on GNU
projects mailing lists.  Much like it talking about ornithology on
emacs-devel.

   Isn't it also a limitation on GNU software itself if it can't be
   used in such cases as well as further inclination for development
   of non-free software?

That isn't the case though, GNU software can be used for such things.
The license explicitly allows it, and it is one of the fundamental
four software freedoms -- to run the software for any purpose.  But
the GNU project specifically doesn't try to cater to those needs since
they would work against its goals.

Re: Drop the Copyright Assignment requirement for Emacs

[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 people working for those companies or in activities involving such
  > hardware/software, say in some hospital, and would like to use Emacs (or
  > other GNU software) to develop possibly but non-necessary free or "open
  > source" applications to work with/alongside non-free what should they
  > do?

What they should do is, not use GNU discussion lists to promote the use
of those nonfree programs.

Regarding the putative free programs they might perhaps be developing,
there may be some GNU discussion list where it is pertinent to discuss
them.  Especially if they are GNU packages.

But not here -- this list is for developing GNU Emacs.  Those other
free programs may be entirely admirable, but discussing them here is
off topic, aside from special cases.

BTW, the words "free or 'open source'" could reinforce a widespread
confusion.  It appears that most people in computing think that "free"
and "open source" are disjoint.  On the contrary, nearly all free
programs are open source, and most open source programs are free.  See
https://gnu.org/philosophy/open-source-misses-the-point.html and
https://gnu.org/licenses/license-list.html.

        Isn't it unnecessary hard on them to not be able to talk about
  > non-free software?

For mailing lists to have specified topics is normal and necessary.
I am sure they can learn to live with that.

                       Isn't it also a limitation on GNU software itself if
  > it can't be used in such cases as well as further inclination for
  > development of non-free software?

Golly, what a misunderstanding.  These rules are about GNU mailing
lists, not about using your MUA (whichever one that may be).

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

Re: Drop the Copyright Assignment requirement for Emacs

[Stefan Monnier]

> If people working for those companies or in activities involving such
> hardware/software, say in some hospital, and would like to use Emacs (or
> other GNU software) to develop possibly but non-necessary free or "open
> source" applications to work with/alongside non-free what should they
> do?

I don't see any particular difficulty: just don't promote the
proprietary software with which you need to work.

Very often, you can mention its name without it being a promotion.
Very often for the situations you talk a bout the software is
sufficiently special-purposed that the name is both harmless and useless
(harmless because mentioning it won't cause other people to try it out
because they don't have the necessary equipment anyway, and useless
because the probability that someone knows that software and reads your
post is fairly low).

And in case of doubt, you can skip the name (replace it with "that
damned proprietary software" ;-)

> Isn't it unnecessary hard on them to not be able to talk about
> non-free software?

Presumably they don't want to talk about that non-Free software but
about the Free software that they are writing (and about the format of
the data it has to manipulate: whether that data comes from or goes to
a program that's proprietary or not is rather irrelevant).

> Isn't it also a limitation on GNU software itself if it can't be used
> in such cases as well as further inclination for development of
> non-free software?

I don't think there is such a limitation.


        Stefan

Re: Drop the Copyright Assignment requirement for Emacs

[João Távora]

On Mon, May 18, 2020 at 5:41 PM Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:

> But it's still more work than simply clicking a few times in a browser.
>
> The first thing is that all you have is a PDF. The instructions are to
> print it, sign it and a scan it. So you first MUST have the idea of
> editing it in gimp. Then you have to find your signature. Then realise
> you cannot find it anymore. Thus sign a piece of paper & scan it. Then
> do the gimp editing. Then export the image. Then go back to email
> writing and attach the file.

> Do you understand my point now?

No, I really don't.

> Maybe we have different limits as to what is perceived "annoying
> paperwork"

Indeed. We're really talking sloth-level lazy programmers who won't
go through this one-time 10 minute-long ordeal involving email and
a mobile phone.

I'd do that a million times over clicking "I agree" in some shady
Adobe EULA.

João

Re: Drop the Copyright Assignment requirement for Emacs

[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 was done with Adobe Sign,

I am not familiar with that, but if it comes from Adobe, I expect
it is a nonfree program.  Is that correct?

Overall, I agree with Joao that the mechanics of signing is a
secondary part of the issue.  But we have to apply our general
moral principles there.

We consider nonfree programs an injustice.
We cannot suggest using one of them -- it would conflict
with our principles.

Maybe there is free software to do this job.
Would you like to check and see?

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

Re: Drop the Copyright Assignment requirement for Emacs

[Clément Pit-Claudel]

On 18/05/2020 23.53, Richard Stallman wrote:
> Maybe there is free software to do this job.
> Would you like to check and see?

Yes, there is free software to do this (https://www.signserver.org, for example)
The real question is not whether people will write the code — the question is whether the FSF will take it :)

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

>   > It was done with Adobe Sign,
>
> I am not familiar with that, but if it comes from Adobe, I expect
> it is a nonfree program.  Is that correct?
>
> Overall, I agree with Joao that the mechanics of signing is a
> secondary part of the issue.  But we have to apply our general
> moral principles there.
>
> We consider nonfree programs an injustice.
> We cannot suggest using one of them -- it would conflict
> with our principles.
>
> Maybe there is free software to do this job.
> Would you like to check and see?


Please, I'm not suggesting to use Adobe Sign. It looks like you missed
my original message:

>It was done with Adobe Sign, basically it displayed a PDF to me in my
>browser and I could sign by writing on my keyboard (displayed using a
>"hand-written" font), draw with my mouse, or import an image of my
>signature (or even use my mobile device).

>I don't think we need that much options (just type on keyboard), but
>surely something similar is doable using only GNU tools no? If you can
>reduce the "print - sign - scan - email" cycle to "browse online and
>click" I suspect a lot more people would agree to bother with the
>copyright assignments.

Hope it clears up the confusion.

Philippe

Re: Drop the Copyright Assignment requirement for Emacs

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

  > Please, I'm not suggesting to use Adobe Sign. It looks like you missed
  > my original message:

  > >It was done with Adobe Sign, basically it displayed a PDF to me in my
  > >browser and I could sign by writing on my keyboard (displayed using a
  > >"hand-written" font), draw with my mouse, or import an image of my
  > >signature (or even use my mobile device).

Yes I saw that message.  That is what I replied to.

Your message talked about use of Adobe Sign, but did not try to
present a clear descrition of what that program DOES.  Without that,
we could not think seriously about replacing it with free software,
or even finding out whether there is already free software to do this
job.

But the message did give the name Adobe Sign as something that was
useful for a job.

I know you meant well, but the effort went astray because of
the choice of what details to include.

To raise the point in a helpful way, please include the firstset of
info and leave out the second.


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

Re: Drop the Copyright Assignment requirement for Emacs

[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 don't think we should give up our standards to gain a couple of
  > marketing points.  It is completely backwards, IMO, to put that cart
  > ahead of the horse.  We are supposed to develop high-quality software

high quality _and_ freedom-defending!

  > first and advertising ourselves second, not the other way around.

Yes, exactly.

We do not accept the set of values that most programmers take for
granted.  On the contrary, rejecting some of those values is our most
important mission.  We _must_ show people that we are serious about
condemning nonfree software -- and that means we don't compromise
on that question.

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

Re: Drop the Copyright Assignment requirement for Emacs

[T.V Raman]

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

with this clarification, could we perhaps put all our energy behind
melpa --- and carefully include (very carefully) packages from melpa
into core Emacs in the rare case where bundling is appropriate?


> Just a side note: my comment about the copyright assignment being
> harmful to our project was about GNU ELPA, not about Emacs.
>
>
>         Stefan
>
>

-- 

Re: Drop the Copyright Assignment requirement for Emacs

[Philippe Vaucher]

> Now, this is very interesting.  And it points to a solution:
>
>     1. Allow contributions without assignments.
>
>     2. Actively encourage every contributor to sign the assignment.
>
> This is a very conservative compromise that ensures that we can both
> enforce the GPL effectively, _and_ ensure that Emacs prospers.

FWIW I completely agree.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Phillip Lord]

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. ]]]
>
> The difficulty about taking precautions,
> is that people see the inconvenience of taking them
> and may not weigh that against the harm the precautions prevent.


Perhaps, but at least be aware of the inconvenience and do all that you
can to lessen the inconvenience.

Provide a way that maintainers can see who has papers, provide a list of
the different emails people use, provide an API so that people can test
for it in their continuous integration, provide a way to track the
progress of the process.

Phil

Re: Why are so many great packages not trying to get included in GNU Emacs?

[João Távora]

On Fri, May 8, 2020 at 7:02 PM Phillip Lord <phillip.lord@russet.org.uk> wrote:
>
> Provide a way that maintainers can see who has papers, provide a list of
> the different emails people use, provide an API so that people can test
> for it in their continuous integration, provide a way to track the
> progress of the process.

I agree that his would be pretty sweet, though I'd be happy just to
have a script to grep the copyright file.  It is my understanding
that as an Emacs committer I have access to a Savannah machine.
Where are the instructions for doing so and accessing the copyright
file?  I think I once had a mail with them, but misplaced it.

João

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 8 May 2020 19:47:03 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> It is my understanding that as an Emacs committer I have access to a
> Savannah machine.  Where are the instructions for doing so and
> accessing the copyright file?  I think I once had a mail with them,
> but misplaced it.

The copyright list is not on Savannah.  You need an account on the GNU
shell server to be able to access it.

Re: Why are so many great packages not trying to get included in GNU Emacs?

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

We need to follow the same policies for including code in GNU ELPA
and the Emacs distribution, because we want the choice of which one
a certain package should go in
to be a purely technical decision.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

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

  > Perhaps, but at least be aware of the inconvenience and do all that you
  > can to lessen the inconvenience.

I agree with this goal.  In fact, we have made it considerably less
work, since contributors can now send in the forms digitally.
That takes a lot less time.

I'm in favor in principle of automating the checking, at least
partially.  But we need to carefully study the details.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> I'm in favor in principle of automating the checking, at least
> partially.  But we need to carefully study the details.

That's been the status quo for at least ten years.
So, apparently, no, there's no hope for improvement here.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[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'm in favor in principle of automating the checking, at least
  > > partially.  But we need to carefully study the details.

  > That's been the status quo for at least ten years.
  > So, apparently, no, there's no hope for improvement here.

That seems like a leap of unfaith.

What needs to be checked here is practical -- that it will work
in practice as reliably as our current practice.  This doesn't
require any special knowledge, just careful attention to possible
ways things can go awry, from people who won't overlook problems
in their eagerness to make the change.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Andreas Röhler]

Am 07.05.20 um 05:33 schrieb Stefan Monnier:
>> It is not terrible lot of work for people to deal with those issues,
>> but I wouldn't assume a simple program can.
> 
> The better option is to stop requiring copyright paperwork.
> It is harmful to the Emacs project.
> 
> 
>          Stefan
> 
> 

Thanks Stefan. Considering that request also vain. Will really someone 
walk to court claiming that all code shipped at a certain moment is 
validly copyright signed? Such a claim would by a major risk.

Andreas

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 06/05/2020 22.43, Richard Stallman wrote:
> It is not terrible lot of work for people to deal with those issues, 
> but I wouldn't assume a simple program can.

These days assignments are signed with PGP keys.  Commits can also be signed using PGP keys.  Wouldn't that provide an reliable way to pair up contributors who have assigned copyright with their contributions?

Concretely, the suggestion is that going forward, assign@gnu.org would sign the keys used to sign copyright forms that it receives.  Then contributors would use the same keys to sign patches, and maintainers would just have to query the keyserver to check if the patch author has copyright papers on file.

(The suggestion is not that all Emacs commits should be signed; only that people who don't have commit access but have signed copyright papers could indicate that by signing their commits with the key they used to sign their copyright papers)

Would that not work?

Clément.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Mon, 11 May 2020 14:51:26 -0400
> Cc: eric@ericabrahamsen.net, casouri@gmail.com, emacs-devel@gnu.org,
>  monnier@iro.umontreal.ca, ndame@protonmail.com
> 
> On 06/05/2020 22.43, Richard Stallman wrote:
> > It is not terrible lot of work for people to deal with those issues, 
> > but I wouldn't assume a simple program can.
> 
> These days assignments are signed with PGP keys.  Commits can also be signed using PGP keys.  Wouldn't that provide an reliable way to pair up contributors who have assigned copyright with their contributions?

I think you are missing the main point.  The problem is not security,
it is correct attribution.  The author of the committed changeset (not
the person who does the commit, the author) must be the person who
actually wrote the code, not someone else.  If that someone else is a
real benevolent person, it is still a problem, because we will make a
false presentation that a different person made the change.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 11/05/2020 14.57, Eli Zaretskii wrote:>> From: Clément Pit-Claudel <cpitclaudel@gmail.com> Date: Mon, 11 May
>> 2020 14:51:26 -0400 Cc: eric@ericabrahamsen.net, casouri@gmail.com,
>> emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>> ndame@protonmail.com
>> 
>> On 06/05/2020 22.43, Richard Stallman wrote:
>>> It is not terrible lot of work for people to deal with those
>>> issues, but I wouldn't assume a simple program can.
>> 
>> These days assignments are signed with PGP keys.  Commits can also
>> be signed using PGP keys.  Wouldn't that provide an reliable way to
>> pair up contributors who have assigned copyright with their
>> contributions?
> 
> I think you are missing the main point.  The problem is not
> security, it is correct attribution.

Sorry, it seems my email was unclear.  The proposal doesn't have to do with security.  I'm trying to find a robust way to figure out if someone has copyright papers.  Right now Stefan & you can check the list, and the rest of us can't, which is a problem for package maintainers.  Apparently the list can't be made public, so I'm suggesting to make public a list of public keys public instead.  I was not thinking about security.

> The author of the committed changeset (not the person who does the
> commit, the author) must be the person who actually wrote the code,
> not someone else. If that someone else is a real benevolent person, it is still a
> problem, because we will make a false presentation that a different
> person made the change.

That problem exists regardless of how we check whether someone has copyright papers, right?
What I'm trying to find is a way to check whether I can accept a patch into an ELPA package without having to email an Emacs maintainer every time.

Clément.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

The following message is a courtesy copy of an article
that has been posted to gmane.emacs.devel as well.

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 11/05/2020 14.57, Eli Zaretskii wrote:>> From: Clément Pit-Claudel
> <cpitclaudel@gmail.com> Date: Mon, 11 May
>>> 2020 14:51:26 -0400 Cc: eric@ericabrahamsen.net, casouri@gmail.com,
>>> emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>> ndame@protonmail.com
>>> 
>>> On 06/05/2020 22.43, Richard Stallman wrote:
>>>> It is not terrible lot of work for people to deal with those
>>>> issues, but I wouldn't assume a simple program can.
>>> 
>>> These days assignments are signed with PGP keys.  Commits can also
>>> be signed using PGP keys.  Wouldn't that provide an reliable way to
>>> pair up contributors who have assigned copyright with their
>>> contributions?
>> 
>> I think you are missing the main point.  The problem is not
>> security, it is correct attribution.
>
> Sorry, it seems my email was unclear. The proposal doesn't have to do
> with security. I'm trying to find a robust way to figure out if
> someone has copyright papers. Right now Stefan & you can check the
> list, and the rest of us can't, which is a problem for package
> maintainers. Apparently the list can't be made public, so I'm
> suggesting to make public a list of public keys public instead. I was
> not thinking about security.
>
>> The author of the committed changeset (not the person who does the
>> commit, the author) must be the person who actually wrote the code,
>> not someone else. If that someone else is a real benevolent person, it is still a
>> problem, because we will make a false presentation that a different
>> person made the change.
>
> That problem exists regardless of how we check whether someone has
> copyright papers, right?
> What I'm trying to find is a way to check whether I can accept a patch
> into an ELPA package without having to email an Emacs maintainer every
> time.

This is above my paygrade but I'm still on the cc, so... If the
information needs to stay private because it contains PII that
contributors haven't consented to release, would it be possible to set
up something automatic where package maintainers enter an email address,
and the system gives us a plain thumbs up or thumbs down? A webform, an
API endpoint, an automated email address, even something built into
debbugs...?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Mon, 11 May 2020 15:13:23 -0400
> 
> > I think you are missing the main point.  The problem is not
> > security, it is correct attribution.
> 
> Sorry, it seems my email was unclear.  The proposal doesn't have to do with security.  I'm trying to find a robust way to figure out if someone has copyright papers.

But that isn't the main problem.  The main problem is how to identify
the name of the person for whom you need to check the status of
copyright assignment.  We are talking about the situation where all
you have is a commit made by someone in a Git repository other than
that of Emacs.  It has some name and some email.  That's all you have.

> That problem exists regardless of how we check whether someone has copyright papers, right?

Yes, but if a human does the checking, that human can do stuff that
programs cannot.

> What I'm trying to find is a way to check whether I can accept a patch into an ELPA package without having to email an Emacs maintainer every time.

Yes, I understand.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 11/05/2020 15.27, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>  ndame@protonmail.com
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Mon, 11 May 2020 15:13:23 -0400
>>
>>> I think you are missing the main point.  The problem is not
>>> security, it is correct attribution.
>>
>> Sorry, it seems my email was unclear.  The proposal doesn't have to do with security.  I'm trying to find a robust way to figure out if someone has copyright papers.
> 
> But that isn't the main problem.  The main problem is how to identify
> the name of the person for whom you need to check the status of
> copyright assignment.  We are talking about the situation where all
> you have is a commit made by someone in a Git repository other than
> that of Emacs.  It has some name and some email. 

No, my situation is that I have someone sending me a pull request or a patch by email.  I can ask this person if they have an assignment, but I can't check whether they in fact do.
I'm proposing a way to fix the problem for future assignments and commits: if the convention is that patches should be signed by their author, it's easy to check if a patch has a corresponding assignment, using the signature.

> We are talking about the situation where all
> you have is a commit made by someone in a Git repository other than
> that of Emacs.

I don't understand this part.  If there is no signature on that commit, how does it relate to the scheme I was proposing?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Mon, 11 May 2020 15:36:31 -0400
> 
> No, my situation is that I have someone sending me a pull request or a patch by email.  I can ask this person if they have an assignment, but I can't check whether they in fact do.

Then you describing a situation different from the one that started
this.  This thread is about copyright assignments for GNU ELPA, where
we discuss packages that already exist on some site that we consider
for adding to ELPA.

> > We are talking about the situation where all
> > you have is a commit made by someone in a Git repository other than
> > that of Emacs.
> 
> I don't understand this part.  If there is no signature on that commit, how does it relate to the scheme I was proposing?

It relates to the subject of this thread, whereas you are talking
about something very different.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 11/05/2020 22.23, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>  ndame@protonmail.com
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Mon, 11 May 2020 15:36:31 -0400
>>
>> No, my situation is that I have someone sending me a pull request or a patch by email.  I can ask this person if they have an assignment, but I can't check whether they in fact do.
> 
> Then you describing a situation different from the one that started
> this.  This thread is about copyright assignments for GNU ELPA, where
> we discuss packages that already exist on some site that we consider
> for adding to ELPA.
Sorry, I did think it was related.  If I start signing all my future commits to Emacs packages outside of Emacs & ELPA with a key that FSF knows about, then won't that mean there won't be a problem with these commits when/if the corresponding packages consider moving into ELPA?

>>> We are talking about the situation where all
>>> you have is a commit made by someone in a Git repository other than
>>> that of Emacs.
>>
>> I don't understand this part.  If there is no signature on that commit, how does it relate to the scheme I was proposing?
> 
> It relates to the subject of this thread, whereas you are talking
> about something very different.

Part of the answer to "Why are so many packages not trying to get included in GNU Emacs?" is that, at least for me, I have no idea how to track whether people have assignments on file, so I don't put my packages in ELPA.  If there was an easy way to check, I would.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Mon, 11 May 2020 22:46:23 -0400
> 
> > Then you describing a situation different from the one that started
> > this.  This thread is about copyright assignments for GNU ELPA, where
> > we discuss packages that already exist on some site that we consider
> > for adding to ELPA.
> Sorry, I did think it was related.  If I start signing all my future commits to Emacs packages outside of Emacs & ELPA with a key that FSF knows about, then won't that mean there won't be a problem with these commits when/if the corresponding packages consider moving into ELPA?

For a single package with a single committer who is also the author,
perhaps that would work (assuming the FSF staff arranges for the
copyright list to be accessible via some URL in a secure and
privacy-respecting way).  But the question which started this was much
more general: it asked why do we need to request assignments at all,
if we can determine mechanically, at some future point in time, that
the author of every commit has signed the papers.  That is a much more
general and potentially complicated situation than what you describe.

Besides, if you make that test and discover one or more commits by
people without an assignment, what do you do then?  Those commits
could be years in the past, and the persons who made them could be
hard to find and ask to sign the papers.

> Part of the answer to "Why are so many packages not trying to get included in GNU Emacs?" is that, at least for me, I have no idea how to track whether people have assignments on file, so I don't put my packages in ELPA.  If there was an easy way to check, I would.

I think there was an agreement that providing a public API for
checking this would be good.  But "Someone" needs to do that, and even
after that not every situation could be resolved mechanically,
certainly not at "git commit" time.  A human should be in the loop.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 12/05/2020 10.53, Eli Zaretskii wrote:
> I think there was an agreement that providing a public API for
> checking this would be good.  But "Someone" needs to do that, and even
> after that not every situation could be resolved mechanically,
> certainly not at "git commit" time.  A human should be in the loop.

My proposal is that this API should be the FSF signing public keys

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 12 May 2020 12:44:40 -0400
> 
> On 12/05/2020 10.53, Eli Zaretskii wrote:
> > I think there was an agreement that providing a public API for
> > checking this would be good.  But "Someone" needs to do that, and even
> > after that not every situation could be resolved mechanically,
> > certainly not at "git commit" time.  A human should be in the loop.
> 
> My proposal is that this API should be the FSF signing public keys

I don't think I follow.  FSF is not a piece of software and not an
API.  It is an organization.  How can an organization be an API?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 12/05/2020 13.15, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>  ndame@protonmail.com
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Tue, 12 May 2020 12:44:40 -0400
>>
>> On 12/05/2020 10.53, Eli Zaretskii wrote:
>>> I think there was an agreement that providing a public API for
>>> checking this would be good.  But "Someone" needs to do that, and even
>>> after that not every situation could be resolved mechanically,
>>> certainly not at "git commit" time.  A human should be in the loop.
>>
>> My proposal is that this API should be the FSF signing public keys
> 
> I don't think I follow.  FSF is not a piece of software and not an
> API.  It is an organization.  How can an organization be an API?

With the scheme I propose, you don't need an API any more, I think (for properly signed commits).
You still have the same problem for old commits, of course.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 12 May 2020 13:26:37 -0400
> 
> >> My proposal is that this API should be the FSF signing public keys
> > 
> > I don't think I follow.  FSF is not a piece of software and not an
> > API.  It is an organization.  How can an organization be an API?
> 
> With the scheme I propose, you don't need an API any more, I think (for properly signed commits).

Now I'm completely confused: what scheme are you proposing?  Can you
describe it in more detail?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 12/05/2020 13.39, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, phillip.lord@russet.org.uk,
>> eric@ericabrahamsen.net, casouri@gmail.com, emacs-devel@gnu.org,
>> monnier@iro.umontreal.ca, ndame@protonmail.com From: Clément
>> Pit-Claudel <cpitclaudel@gmail.com> Date: Tue, 12 May 2020 13:26:37
>> -0400
>> 
>>>> My proposal is that this API should be the FSF signing public
>>>> keys
>>> 
>>> I don't think I follow.  FSF is not a piece of software and not
>>> an API.  It is an organization.  How can an organization be an
>>> API?
>> 
>> With the scheme I propose, you don't need an API any more, I think
>> (for properly signed commits).
> 
> Now I'm completely confused: what scheme are you proposing?  Can you 
> describe it in more detail?

Yes, of course.

One problem with have when integrating external packages is that we have many commits whose copyright status is unclear: who wrote them? Does the FSF have a copyright assignment for that person?

Currently, the way you answer such a question is that you look at the commit, try to determine the author, and check a list of people who have assigned copyright to see if the author is in it.

This process is cumbersome, because few have access to the list.  One way to make it smoother is to add an API that gives access to that list.  

Another strategy, which doesn't solve the problem for past commits but could help for future commits, is to embed that information into commits.  Something like adding a line in the commit saying "I-have-assigned-copyright: Yes".

Of course, just adding that line doesn't prove anything: we want to make sure that we do have an assignment for that commit.
So, instead of adding a line, the author could sign the commit with their PGP key, saying "all these changes are mine or from sources owned by FSF" (a bit like a developer certificate of origin).

Now the problem is reduced to "does the author with this PGP key have an assignment on file"?  But this question can be answered in a decentralized way (no need for an API): the FSF can just sign keys instead.

Indeed, currently, when you assign copyright to the FSF, you sign a document with a GPG key.  The FSF could sign that key to indicate "we have received copyright papers for this author".

Then, to verify "do we have papers for the author of this commit", anyone could check "is this commit signed with a key signed by the FSF"?

As a package maintainer, I wouldn't have to ever check fencepost to verify assignments when I receive patches.  Instead, the way I check that someone has an assignment on file is by asking them to sign their commit with an FSF-signed key.

Does it make sense?
Clément.  

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Alan Third]

On Tue, May 12, 2020 at 03:48:01PM -0400, Clément Pit-Claudel wrote:
> Now the problem is reduced to "does the author with this PGP key
> have an assignment on file"? But this question can be answered in a
> decentralized way (no need for an API): the FSF can just sign keys
> instead.

As if there aren’t enough people complaining about copyright
assignment, now you want to force everyone to use the horror that is
PGP/GPG?

Good luck.
-- 
Alan Third

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

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

On 12/05/2020 16.17, Alan Third wrote:
> On Tue, May 12, 2020 at 03:48:01PM -0400, Clément Pit-Claudel wrote:
>> Now the problem is reduced to "does the author with this PGP key
>> have an assignment on file"? But this question can be answered in a
>> decentralized way (no need for an API): the FSF can just sign keys
>> instead.
> 
> As if there aren’t enough people complaining about copyright
> assignment, now you want to force everyone to use the horror that is
> PGP/GPG?

No no, not at all!  Definitely not force and definitely not everyone.  I'm trying to find a way to allow package maintainers to check copyright assignments when they accept patches, that's all.  There are easy cases: for Emacs committers like you, the list is already public, so that's no trouble (and thus signatures wouldn't be needed).  For others, the signature would be one reliable option to determine whether they have papers on file.

But the complexity of PGP is a valid concern.  I operated under the assumption that most new contributors sign copyright papers with PGP, and so that PGP was a reasonable baseline.

Concretely, how do you handle these cases?  What am I supposed to do, when I get a patch, to check if the patch author has an assignment on file?  Surely I can't bother Eli every time.  Is it enough to take the author's word for it that they have an assignment?  Alan, do you have advice on handling these situations?

As an alternative, the attached python script implements a REST API to do the checking.  I don't have access to fencepost, so I don't know what format the file tracking assignments is — I made a guess about that part.  

(Of course, having an API makes it possible to determine whether a given email address has copyright papers on file, but it gives no guarantees against impersonation.)

Cheers,
Clément.

[-- Attachment #2: fencepost_api.py --]
[-- Type: text/x-python, Size: 628 bytes --]

#!/usr/bin/env python3
from flask import Flask

# Usage: pip3 install flask
#        echo "user@domain some more data" > /tmp/assignments
#        FLASK_APP=fencepost_api.py flask run
#        firefox http://127.0.0.1:5000/has_assignment/name@domain57.org

app = Flask(__name__)

ASSIGNMENTS_FILE = "/tmp/assignments"

def get_copyright_list():
    with open(ASSIGNMENTS_FILE) as assignments:
        for line in assignments:
            yield line.split()[0].lower()

@app.route('/has_assignment/<email_address>')
def check_assignment(email_address):
    return "yes" if email_address.lower() in get_copyright_list() else "no"

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 12 May 2020 23:03:06 -0400
> 
> Surely I can't bother Eli every time.

Yes, you can.  It isn't a bother.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Alan Third]

On Tue, May 12, 2020 at 11:03:06PM -0400, Clément Pit-Claudel wrote:
> 
> But the complexity of PGP is a valid concern. I operated under the
> assumption that most new contributors sign copyright papers with
> PGP, and so that PGP was a reasonable baseline.

I didn’t sign mine with PGP, as far as I can remember, so my
assumption was that most people don’t. Is it a new requirement?

If people are happy to sign commits with PGP then I don’t have a
problem with that, I just really don’t want to be left having to try
to talk someone through the process of setting it up.

> Concretely, how do you handle these cases? What am I supposed to do,
> when I get a patch, to check if the patch author has an assignment
> on file? Surely I can't bother Eli every time. Is it enough to take
> the author's word for it that they have an assignment? Alan, do you
> have advice on handling these situations?

I’m afraid not. Usually I check the Emacs repo to see if they’re
already in it, if not then I ask if they’ve signed the papers, and
usually Eli pops up with the answer before they reply.

> As an alternative, the attached python script implements a REST API
> to do the checking. I don't have access to fencepost, so I don't
> know what format the file tracking assignments is — I made a guess
> about that part.

I think an API makes a lot of sense.
-- 
Alan Third

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 13/05/2020 12.58, Alan Third wrote:
> On Tue, May 12, 2020 at 11:03:06PM -0400, Clément Pit-Claudel wrote:
>>
>> But the complexity of PGP is a valid concern. I operated under the
>> assumption that most new contributors sign copyright papers with
>> PGP, and so that PGP was a reasonable baseline.
> 
> I didn’t sign mine with PGP, as far as I can remember, so my
> assumption was that most people don’t. Is it a new requirement?

It's not a new requirement, just a new option, I think :) (well, not so new: I did mine in 2014 with PGP).

>> Alan, do you
>> have advice on handling these situations?
> 
> I’m afraid not. Usually I check the Emacs repo to see if they’re
> already in it, if not then I ask if they’ve signed the papers, and
> usually Eli pops up with the answer before they reply.

OK, thanks a lot.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Robert Pluim]

>>>>> On Wed, 13 May 2020 13:36:08 -0400, Clément Pit-Claudel <cpitclaudel@gmail.com> said:

    Clément> On 13/05/2020 12.58, Alan Third wrote:
    >> On Tue, May 12, 2020 at 11:03:06PM -0400, Clément Pit-Claudel wrote:
    >>> 
    >>> But the complexity of PGP is a valid concern. I operated under the
    >>> assumption that most new contributors sign copyright papers with
    >>> PGP, and so that PGP was a reasonable baseline.
    >> 
    >> I didn’t sign mine with PGP, as far as I can remember, so my
    >> assumption was that most people don’t. Is it a new requirement?

    Clément> It's not a new requirement, just a new option, I think :)
    Clément> (well, not so new: I did mine in 2014 with PGP).

I did mine in 2017 via print/sign/scan, I guess it depends on where
you reside. There are other options these days, but weʼd have to find
an acceptable ESIGN/eIDAS provider to use.

Robert

Re: Why are so many great packages not trying to get included in GNU Emacs?

[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 didn’t sign mine with PGP, as far as I can remember, so my
  > assumption was that most people don’t. Is it a new requirement?

I think it is a new option.  Some years ago we needed a signature on paper,
but then we became able to accept digital signatures.  I think we use
GPG to implement them.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[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’m afraid not. Usually I check the Emacs repo to see if they’re
  > already in it,

In concrete terms, what does "already in it" mean?
We can install small changes without papers, so the fact that a person's
name is on a change is not proof that we got an assignment from per.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 14 May 2020 01:08:33 -0400
> Cc: casouri@gmail.com, eric@ericabrahamsen.net, alan@idiocy.org,
>  emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca,
>  eliz@gnu.org, phillip.lord@russet.org.uk, ndame@protonmail.com
> 
> We can install small changes without papers, so the fact that a person's
> name is on a change is not proof that we got an assignment from per.

Normally such commits should have a telltale header in the log message
saying this was accepted without papers.  Of course, sometimes people
(including myself) forget, and Git doesn't allow amending commit log
messages post-factum, so the error stays there forever.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Alan Third]

On Thu, May 14, 2020 at 05:09:26PM +0300, Eli Zaretskii wrote:
> > From: Richard Stallman <rms@gnu.org>
> > Date: Thu, 14 May 2020 01:08:33 -0400
> > Cc: casouri@gmail.com, eric@ericabrahamsen.net, alan@idiocy.org,
> >  emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca,
> >  eliz@gnu.org, phillip.lord@russet.org.uk, ndame@protonmail.com
> > 
> > We can install small changes without papers, so the fact that a person's
> > name is on a change is not proof that we got an assignment from per.
> 
> Normally such commits should have a telltale header in the log message
> saying this was accepted without papers.  Of course, sometimes people
> (including myself) forget, and Git doesn't allow amending commit log
> messages post-factum, so the error stays there forever.

Yes, I wouldn’t commit a change on the strength of a small number of
short commits, but if they had a few large commits I’d have to assume
they’re good.

-- 
Alan Third

Re: Why are so many great packages not trying to get included in GNU Emacs?

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

Emacs has a convenient interface to GPG.  I think it is epg.
Please try it.

Our policy is that it is good to recommend people use another GNU
package.


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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Dmitry Gutov]

On 12.05.2020 22:48, Clément Pit-Claudel wrote:
> So, instead of adding a line, the author could sign the commit with their PGP key, saying "all these changes are mine or from sources owned by FSF" (a bit like a developer certificate of origin).

Considering that signed commits are not ubiquitous, it seems to be not a 
trivial thing to do. Also, we'd need some recourse in case when some 
commits have slipped by that are not signed anyway. Or are signed by a 
key that Savannah doesn't know about (or whatever other database we'd be 
using).

I was suggesting to sign tagged commits (for example), which seems more 
feasible, but keeps the responsibility of checking the copyright status 
on the author. The the reasons to do that would be different (basically, 
security).

Re: Why are so many great packages not trying to get included in GNU Emacs?

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

  > Currently, the way you answer such a question is that you look at
  > the commit, try to determine the author, and check a list of
  > people who have assigned copyright to see if the author is in it.

  > This process is cumbersome, because few have access to the list.
  > One way to make it smoother is to add an API that gives access to
  > that list.

I would like to make that easier.  That may be complex.  We don't
publish the list, for privacy reasons.  We don't want to offer
the public a way to probe the list.  We can offer certain people
access to probe the list in limited ways.  We need to discuss that
with the FSF.

  > Indeed, currently, when you assign copyright to the FSF, you sign
  > a document with a GPG key.  The FSF could sign that key to
  > indicate "we have received copyright papers for this author".

  > Then, to verify "do we have papers for the author of this commit",
  > anyone could check "is this commit signed with a key signed by the
  > FSF"?

At first glance, this looks good to me.  It would be necessary
for people to study it to make sure it doens't have problems.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 13/05/2020 00.07, Richard Stallman wrote:
>   > Currently, the way you answer such a question is that you look at
>   > the commit, try to determine the author, and check a list of
>   > people who have assigned copyright to see if the author is in it.
> 
>   > This process is cumbersome, because few have access to the list.
>   > One way to make it smoother is to add an API that gives access to
>   > that list.
> 
> I would like to make that easier.  

Thanks a lot.  It would be great.

> That may be complex.  We don't
> publish the list, for privacy reasons.  We don't want to offer
> the public a way to probe the list.  

Maybe we can publicize a part of the list which would not violate privacy?  When I signed my copyright papers, I answered yes to a question that said "Would it be acceptable for us to publicize your contribution by microblogging that you are contributing, and listing your name in our monthly newsletter?".  I think it is safe to assume that those who answered yes to this question do not object to appearing on a public list; correct?

>   > Indeed, currently, when you assign copyright to the FSF, you sign
>   > a document with a GPG key.  The FSF could sign that key to
>   > indicate "we have received copyright papers for this author".
> 
>   > Then, to verify "do we have papers for the author of this commit",
>   > anyone could check "is this commit signed with a key signed by the
>   > FSF"?
> 
> At first glance, this looks good to me.  It would be necessary
> for people to study it to make sure it doens't have problems.

Note that with this scheme, it would be possible to reconstruct parts of the list, by looking for keys signed by the FSF.  So, if knowing a list of address emails that have signed FSF copyright papers is an issue, then this scheme won't solve it.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: eliz@gnu.org, casouri@gmail.com, eric@ericabrahamsen.net,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, ndame@protonmail.com,
>  phillip.lord@russet.org.uk
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 13 May 2020 00:22:56 -0400
> 
> Maybe we can publicize a part of the list which would not violate privacy?  When I signed my copyright papers, I answered yes to a question that said "Would it be acceptable for us to publicize your contribution by microblogging that you are contributing, and listing your name in our monthly newsletter?".  I think it is safe to assume that those who answered yes to this question do not object to appearing on a public list; correct?

If you suggest making public a part of the entries in the list, then
this would be worse than not publishing it at all, I think.

If you suggest publishing part of the _data_ in each entry, then this
should work in principle, but (a) "Someone" needs to do the work of
setting this up, and (b) even in this case there might be issues which
need to be resolved.  For example, some people need to submit
disclaimers from their employers, in addition to their personal
assignment, but publishing that part discloses their employment, which
may be invading their privacy.  Others have other private arrangements
mentioned, or are minors who need their parents' permissions, etc.
Deciding which of this is necessary to make sure a person's assignment
is in order, while at the same time avoiding disclosure of private
information is the hard part of the job.  At least AFAIU, that is.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 13/05/2020 11.00, Eli Zaretskii wrote:
>> Cc: eliz@gnu.org, casouri@gmail.com, eric@ericabrahamsen.net,
>>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, ndame@protonmail.com,
>>  phillip.lord@russet.org.uk
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 13 May 2020 00:22:56 -0400
>>
>> Maybe we can publicize a part of the list which would not violate privacy?  When I signed my copyright papers, I answered yes to a question that said "Would it be acceptable for us to publicize your contribution by microblogging that you are contributing, and listing your name in our monthly newsletter?".  I think it is safe to assume that those who answered yes to this question do not object to appearing on a public list; correct?
> 
> If you suggest making public a part of the entries in the list, then
> this would be worse than not publishing it at all, I think.
> 
> If you suggest publishing part of the _data_ in each entry, then this
> should work in principle, but (a) "Someone" needs to do the work of
> setting this up

I've sent an implementation ^^ I'm happy to write the code if code is needed, it's the specs that I don't know :)

> and (b) even in this case there might be issues which
> need to be resolved.  For example, some people need to submit
> disclaimers from their employers, in addition to their personal
> assignment, but publishing that part discloses their employment, which
> may be invading their privacy.

I think an API could say "yes", "no", or "check with maintainer".
We can put all tricky cases in the "check with maintainer" category.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, casouri@gmail.com, eric@ericabrahamsen.net,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, ndame@protonmail.com,
>  phillip.lord@russet.org.uk
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 13 May 2020 11:16:50 -0400
> 
> > If you suggest publishing part of the _data_ in each entry, then this
> > should work in principle, but (a) "Someone" needs to do the work of
> > setting this up
> 
> I've sent an implementation ^^ I'm happy to write the code if code is needed, it's the specs that I don't know :)

I meant to set this up on gnu.org machines.  The hard part is to
extract the data that can be published, I think (and maybe even to
decide which part is that).

> > and (b) even in this case there might be issues which
> > need to be resolved.  For example, some people need to submit
> > disclaimers from their employers, in addition to their personal
> > assignment, but publishing that part discloses their employment, which
> > may be invading their privacy.
> 
> I think an API could say "yes", "no", or "check with maintainer".
> We can put all tricky cases in the "check with maintainer" category.

Anything's possible, but a volunteer who'd do all that is still
needed.  As always with Emacs (and GNU in general).

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 13/05/2020 12.01, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, casouri@gmail.com, eric@ericabrahamsen.net,
>>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, ndame@protonmail.com,
>>  phillip.lord@russet.org.uk
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 13 May 2020 11:16:50 -0400
>>
>>> If you suggest publishing part of the _data_ in each entry, then this
>>> should work in principle, but (a) "Someone" needs to do the work of
>>> setting this up
>>
>> I've sent an implementation ^^ I'm happy to write the code if code is needed, it's the specs that I don't know :)
> 
> I meant to set this up on gnu.org machines.  The hard part is to
> extract the data that can be published, I think (and maybe even to
> decide which part is that).
>
> Anything's possible, but a volunteer who'd do all that is still
> needed.  As always with Emacs (and GNU in general).

Yes, of course: again, I'm happy to write the code and set thip up on gnu.org machines, if someone can clarify which data can be exposed.
But in another thread Noam was suggesting that it's enough to just ask the contributor whether they have an assignment, so maybe this is all moot for future commits?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Alfred M. Szmidt]

Please do not forget that the FSF is the responsible party for the
copyright list.

Re: Why are so many great packages not trying to get included in GNU Emacs?

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

  > Maybe we can publicize a part of the list which would not violate
  > privacy?  When I signed my copyright papers, I answered yes to a
  > question that said "Would it be acceptable for us to publicize
  > your contribution by microblogging that you are contributing, and
  > listing your name in our monthly newsletter?".  I think it is safe
  > to assume that those who answered yes to this question do not
  > object to appearing on a public list; correct?

I think so.  However, we probably didn't ask that question N years ago.

Hmm.  If the name of the contributor will appear publicly in the repo,
I guess privacy about the name is not necessary.  Maybe it is only the
_other_ data in that file which we need to keep private.  If so, this
could be easy to solve.

Eli, would you like to talk about this with people at the FSF?


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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: casouri@gmail.com, eric@ericabrahamsen.net, emacs-devel@gnu.org,
> 	monnier@iro.umontreal.ca, eliz@gnu.org,
> 	phillip.lord@russet.org.uk, ndame@protonmail.com
> Date: Thu, 14 May 2020 01:09:05 -0400
> 
> Hmm.  If the name of the contributor will appear publicly in the repo,
> I guess privacy about the name is not necessary.  Maybe it is only the
> _other_ data in that file which we need to keep private.  If so, this
> could be easy to solve.
> 
> Eli, would you like to talk about this with people at the FSF?

I could, but I don't think I know anything about this any other GNU
maintainers don't.

Whom should we talk to, and what should we say?  Setting up such a
service would need savannah-hackers or sysadmin@gnu.org to do
something, I guess, and the FSF people are not them?

Re: Why are so many great packages not trying to get included in GNU Emacs?

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

  > Whom should we talk to, and what should we say?  Setting up such a
  > service would need savannah-hackers or sysadmin@gnu.org to do
  > something, I guess, and the FSF people are not them?

Sysadmin would have to implement it, but the copyright team would
first decide what is ok to do.

I will ask them now.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 12 May 2020 15:48:01 -0400
> 
> Another strategy, which doesn't solve the problem for past commits but could help for future commits, is to embed that information into commits.  Something like adding a line in the commit saying "I-have-assigned-copyright: Yes".
> 
> Of course, just adding that line doesn't prove anything: we want to make sure that we do have an assignment for that commit.
> So, instead of adding a line, the author could sign the commit with their PGP key, saying "all these changes are mine or from sources owned by FSF" (a bit like a developer certificate of origin).
> 
> Now the problem is reduced to "does the author with this PGP key have an assignment on file"?  But this question can be answered in a decentralized way (no need for an API): the FSF can just sign keys instead.

This will only work for some cases: when the committer is also the
author, and when the committer has a PGP key.  So some cases will
still need to be handled in some other way, and I suspect that those
cases are the majority.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 13/05/2020 10.14, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>  ndame@protonmail.com
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Tue, 12 May 2020 15:48:01 -0400
>>
>> Another strategy, which doesn't solve the problem for past commits but could help for future commits, is to embed that information into commits.  Something like adding a line in the commit saying "I-have-assigned-copyright: Yes".
>>
>> Of course, just adding that line doesn't prove anything: we want to make sure that we do have an assignment for that commit.
>> So, instead of adding a line, the author could sign the commit with their PGP key, saying "all these changes are mine or from sources owned by FSF" (a bit like a developer certificate of origin).
>>
>> Now the problem is reduced to "does the author with this PGP key have an assignment on file"?  But this question can be answered in a decentralized way (no need for an API): the FSF can just sign keys instead.
> 
> This will only work for some cases: when the committer is also the
> author, and when the committer has a PGP key.  So some cases will
> still need to be handled in some other way, and I suspect that those
> cases are the majority.

I have the opposite intuition, but not very much evidence.  I think it depends a lot on how you end up using git, too (in particular, whether patches are typically rebased or marged).
Alan raised the issue of PGP's complexity and availability, and I don't have much to say on that.  But on the committer versus author debate, as long as the original patch sent by the contributor is signed, it might not matter whether the final commit is (as long as the committer also does have papers and record that they checked that commit).

Copyright assignment checking by PGP-signed commits (WAS: Why are so many great packages not trying to get included in GNU Emacs?)

[Noam Postavsky]

> As a package maintainer, I wouldn't have to ever check fencepost to verify assignments when I receive patches.  Instead, the way I check that someone has an assignment on file is by asking them to sign their commit with an FSF-signed key.

I'm not sure this gives a sufficient advantage over just asking the
author whether they've done assignment. The main difference is that it
would be harder for someone to lie about it, but I'm not seeing that
as much of a risk (in the rare case where someone does lie, the commit
can still be reverted later).

Re: Copyright assignment checking by PGP-signed commits (WAS: Why are so many great packages not trying to get included in GNU Emacs?)

[Clément Pit-Claudel]

On 13/05/2020 11.01, Noam Postavsky wrote:
>> As a package maintainer, I wouldn't have to ever check fencepost to verify assignments when I receive patches.  Instead, the way I check that someone has an assignment on file is by asking them to sign their commit with an FSF-signed key.
> 
> I'm not sure this gives a sufficient advantage over just asking the
> author whether they've done assignment. The main difference is that it
> would be harder for someone to lie about it, but I'm not seeing that
> as much of a risk (in the rare case where someone does lie, the commit
> can still be reverted later).

My understanding was that asking wasn't sufficient — otherwise, the whole process is trivial, indeed.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[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 think you are missing the main point.  The problem is not security,
  > it is correct attribution.  The author of the committed changeset (not
  > the person who does the commit, the author) must be the person who
  > actually wrote the code, not someone else.  If that someone else is a
  > real benevolent person, it is still a problem, because we will make a
  > false presentation that a different person made the change.

We do our best to avoid errors of this sort, but our current systems
don'tmake errors absolutely impossible.  Can we make Clement's proposal
as reliable as our current non-automated system?  I don't see, off-hand,
why that would be impossible.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[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 think it could be even simpler than that: ELPA is built every 24 hours
  > right now. If we just registered external repos with ELPA, part of the
  > build process could be pulling from those repos automatically

That is rather breathless, so I can't concretely understand the
proposal.  I can't start to think about what specific consequences it
might have.  I am not sure which situations you propose to use this
solution for.

If this is meant as a way to implement pull requests, there is no need
for it.  We will not implement pull requests by copying proposed
patches into our repo before they are installed.

There are various ways to implement pull requests.  The way I hope we
will do it is that maintainers can ask to see the contents of the
request, and commit it to our repo if/when that is proper.  Until that
time, the patch won't be in our repo at all.

Or maybe you're proposing a way to make a given package in GNU ELPA
virtually included from some other GNU-managed repository; the method
consisting of copying each commit automatically from that other repo
to the GNU ELPA repo.

It is ok to do that, assuming the other repo is managed appropriately,
and your method could do it.  Other methods could give equivalent
results.  We could use whichever method is most convenient.

The crucial thing is that the repo where the package is really maintained
be managed carefully in regard to who can commit changes.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

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. ]]]
>
>   > I think it could be even simpler than that: ELPA is built every 24 hours
>   > right now. If we just registered external repos with ELPA, part of the
>   > build process could be pulling from those repos automatically
>
> That is rather breathless, so I can't concretely understand the
> proposal.  I can't start to think about what specific consequences it
> might have.  I am not sure which situations you propose to use this
> solution for.
>
> If this is meant as a way to implement pull requests, there is no need
> for it.  We will not implement pull requests by copying proposed
> patches into our repo before they are installed.
>
> There are various ways to implement pull requests.  The way I hope we
> will do it is that maintainers can ask to see the contents of the
> request, and commit it to our repo if/when that is proper.  Until that
> time, the patch won't be in our repo at all.
>
> Or maybe you're proposing a way to make a given package in GNU ELPA
> virtually included from some other GNU-managed repository; the method
> consisting of copying each commit automatically from that other repo
> to the GNU ELPA repo.

Yes, it's this latter I was referring to -- I don't have much feeling
about pull requests either way.

> It is ok to do that, assuming the other repo is managed appropriately,
> and your method could do it.  Other methods could give equivalent
> results.  We could use whichever method is most convenient.
>
> The crucial thing is that the repo where the package is really maintained
> be managed carefully in regard to who can commit changes.

And this was ultimately Stefan's concern, and the reason why my
suggestion is probably no-go. But no matter!

Re: Why are so many great packages not trying to get included in GNU Emacs?

[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 is ok to do that, assuming the other repo is managed appropriately,
  > > and your method could do it.  Other methods could give equivalent
  > > results.  We could use whichever method is most convenient.
  > >
  > > The crucial thing is that the repo where the package is really maintained
  > > be managed carefully in regard to who can commit changes.

  > And this was ultimately Stefan's concern, and the reason why my
  > suggestion is probably no-go. But no matter!

I think your suggestion has potential.  We could set up the
package's own repo ourselves and manage it in the right way.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross]

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

On Sat, 25 Apr 2020 at 13:32, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>
> If this is meant as a way to implement pull requests, there is no need
> for it.  We will not implement pull requests by copying proposed
> patches into our repo before they are installed.
>
>
There seems to be some confusion regarding 'pull requests'. When you look
at it, all a pull request is is a request to merge a branch from another
repo into your repo. Nothing is added to your repo until you perform the
merge. The pull request adds nothing to your repo. Some of this confusion
is likely due to github and to some extent, gitlab, putting some UI 'sugar'
on top of the process to make it easier. However, you can do/manage pull
requests completely from the git command line (although it is a bit
fiddly).  Basically, you add the PR repository to your LOCAL repo and check
it out as a branch. Do whatever you need (review, fix, etc), commit it to
your local repository. Perhaps do some diffs against your master repository
and if all is good, merge it with your local master branch. At this point,
there is still no change to the 'main' master repository. If the merge all
goes fine, you can then push the changes to your master branch in your main
repository. It is only at this point that the changes have been introduced
to the main repository.

So, in short, making a PR has NO impact on the master repository until
someone with write permission ie.g. the owner, merges the PR into the
master repository. In this respect, it is no different from when the owner
recieves a patch via email. Others cannot see the PR in the master
repository (they would be able to see it and clone it from the pull
requestor's repository, just like I can pull fro any public repository in
github or gitlab), It is only after the owner (or someone with write
permission to the 'master' repository (i.e. the one on savannah) merges
that PR into the master repo that it will be seen by anyone who has cloned
the master repo.

It should also be noted that the 'git pull-request' command is NOT a
standard git command. This is an extension that github has added. It would
be possible to create an FSF GNU git module which does something similar or
more specific to suit FSF requirements. For example, you could have a
module which looks at the size of the changes in the commit, checks a list
of people who have submitted copyright paperwork and only allow the pull
request to complete if either the change is 'tiny' or the submitter has
provided copyright assignment.

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 3257 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Sat, 25 Apr 2020 17:56:48 +1000
> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, Yuan Fu <casouri@gmail.com>,
>  ndame <ndame@protonmail.com>, Stefan Monnier <monnier@iro.umontreal.ca>,
>  Emacs developers <emacs-devel@gnu.org>
> 
>  If this is meant as a way to implement pull requests, there is no need
>  for it.  We will not implement pull requests by copying proposed
>  patches into our repo before they are installed.
> 
> There seems to be some confusion regarding 'pull requests'.

There definitely is, but let's not exacerbate the situation by using
confusing inconsistent terminology.

> When you look at it, all a pull request is is a request to merge a
> branch from another repo into your repo.  Nothing is added to your
> repo until you perform the merge.

It should be clear that Richard is talking about 2 things:

  . the location (i.e. the hosting server) where that "other"
    repository lives
  . the process of merging the PR

> Basically, you add
> the PR repository to your LOCAL repo

How can you "add a repository to a repo"?  (And why use two different
words, "repository" and "repo", to indicate the same thing?)  Don't
you mean to say "you fork a repository", i.e. clone the repository to
produce a separate one, in another directory on the local system?

> and check it out as a branch. Do whatever you need (review, fix, etc),
> commit it to your local repository. Perhaps do some diffs against your master repository and if all is good,
> merge it with your local master branch. At this point, there is still no change to the 'main' master repository.
> If the merge all goes fine, you can then push the changes to your master branch in your main repository. It is
> only at this point that the changes have been introduced to the main repository. 
> 
> So, in short, making a PR has NO impact on the master repository until someone with write permission ie.g.
> the owner, merges the PR into the master repository.

And here you use "master repository" without defining what that is,
and then use "main master repository" as if it were a different thing
(is it?).  Should we be surprised that people get confused?

I think there are 3 repositories involved in this story:

  . the upstream repository, which lives on Savannah
  . the local clone of the upstream repository on the user's machine
  . the "forked repository", which is a clone of the clone mentioned
    in the previous item; this forked repository is also local, and it
    is where the user makes the changes which will be the subject of
    the PR

So far so good?

Then we have another person in the picture, someone with write access
to the upstream repository.  That person is supposed to pull from the
"forked repository", into his or her local clone of the upstream,
which merges the PR changes, and then eventually push the results of
the merge to upstream.  At which point the PR is considered "accepted"
(or "merged"), and is visible to everyone who tracks the upstream.

Does this describe what you had in mind?

If so, as previous discussions have established, the issue that is of
concern is what server should host the "forked repository".  It
cannot be someone's private machine, because private machines don't
usually have Git servers, and thus cannot be pulled from.  Richard
also didn't want this to be Savannah, because then the forked
repository and its changes could be perceived as "endorsed" by GNU.
The practical solution is to host this on some nongnu.org server.

And now I think you can understand what Richard means when he says
"our repo".

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross]

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

On Sat, 25 Apr 2020 at 18:33, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Tim Cross <theophilusx@gmail.com>
> > Date: Sat, 25 Apr 2020 17:56:48 +1000
> > Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, Yuan Fu <
> casouri@gmail.com>,
> >  ndame <ndame@protonmail.com>, Stefan Monnier <monnier@iro.umontreal.ca
> >,
> >  Emacs developers <emacs-devel@gnu.org>
> >
> >  If this is meant as a way to implement pull requests, there is no need
> >  for it.  We will not implement pull requests by copying proposed
> >  patches into our repo before they are installed.
> >
> > There seems to be some confusion regarding 'pull requests'.
>
> There definitely is, but let's not exacerbate the situation by using
> confusing inconsistent terminology.
>
> > When you look at it, all a pull request is is a request to merge a
> > branch from another repo into your repo.  Nothing is added to your
> > repo until you perform the merge.
>
> It should be clear that Richard is talking about 2 things:
>
>   . the location (i.e. the hosting server) where that "other"
>     repository lives
>   . the process of merging the PR
>
>
No, it is not clear. What I got from a number of Richard's posts was the
concern that a PR would appear to be part of the GNU Emacs distribution or
in some way mistaken as being 'official' or agreed to. What I was trying to
make clear is that the PR has NO impact on the repository in itself. It is
only after someone takes that pull request and merges it into the
repository that it becomes part of the repository. A PR in itself is just a
request to merge changes. It is effectively no different from sending an
email with a patch in it except it is more public (or at least can be). As
the PR is hosted in a completely separate repository, there is no chance it
can be confused or seen as being part of the official repository.


> > Basically, you add
> > the PR repository to your LOCAL repo
>
> How can you "add a repository to a repo"?  (And why use two different
> words, "repository" and "repo", to indicate the same thing?)


repo is shorthand for repository. It is a term in common usage and I think
pretty obvious.


> Don't
> you mean to say "you fork a repository", i.e. clone the repository to
> produce a separate one, in another directory on the local system?
>
>
Definitely not! You do not need to clone the PR repository. You can add the
PR repository to your local clone as another upstream source. This is part
of what makes PRs so easy to work with. Once you have aded the PR
repository to your clone, you can checkout a branch from that repo in your
clone. From this point, merging is just normal merging of branches in your
clone. Nothing is seen in the upstream repo until you do a push.


> and check it out as a branch. Do whatever you need (review, fix, etc),
> > commit it to your local repository. Perhaps do some diffs against your
> master repository and if all is good,
> > merge it with your local master branch. At this point, there is still no
> change to the 'main' master repository.
> > If the merge all goes fine, you can then push the changes to your master
> branch in your main repository. It is
> > only at this point that the changes have been introduced to the main
> repository.
> >
> > So, in short, making a PR has NO impact on the master repository until
> someone with write permission ie.g.
> > the owner, merges the PR into the master repository.
>
> And here you use "master repository" without defining what that is,
> and then use "main master repository" as if it were a different thing
> (is it?).  Should we be surprised that people get confused?
>
>
Fair enough. I will try to clarify and define the terms to make it clearer.


> I think there are 3 repositories involved in this story:
>
>   . the upstream repository, which lives on Savannah
>   . the local clone of the upstream repository on the user's machine
>   . the "forked repository", which is a clone of the clone mentioned
>     in the previous item; this forked repository is also local, and it
>     is where the user makes the changes which will be the subject of
>     the PR
>
> So far so good?
>

No, not quite. We do have 3 repositories, but not quite as you have defined
them.

1. The upstream repository which lives on Savannah. Let's call this the
master repository.
2. Local clone of master repository used by a maintainer. Call this one the
maintenance repository
3. A developers fork of the master repository. This can be anywhere, but
needs a public interface, like https (i.e. github, gitlab, bitbucket etc).
Call this the developers repository.

There is not much difference between a fork and a clone. A fork typically
refers to a clone of a repository which itself is made available for
further cloning/forking on a server somewhere. Changes can be made on the
forked clone, but typically the changes cannot be pushed upstream to the
master repository the forked repository was cloned from. The 3rd repository
above needs to be a fork because it needs to be public and available to
perform a merge following a pull request.

A maintainer is someone who has write access to the master repository
A developer is someone who would like to contribute code. They have read
access (can clone) from the master repository, but do not have write access.

The PR consists of two workflows, the developers workflow and the
maintainers workflow.

The developers workflow is roughly

1. Fork the master repository to some location, creating the developer
repository.
2. Clone the developer repository so that the developer now has a local
repository to work on
3. Make changes and when complete, push to the developers repository.
Often, the changes will be in a feature branch. It would also be normal
practice for the developer to make sure their forked copy is up-to-date and
their changes in their feature branch have been merged with the current
state of the upstream code i.e. pull from upstream, merge master with
feature branch.
4. Make the PR. How this is done would depend on what interfaces are
available, but could be as simple as an email to the maintainer which
requests that the maintainer pull their changes from their developer
repository and merge them into the master repository. The email would need
to include the URL for the developer repository and include any branch
information if required i.e. the changes might be in a feature branch
within the developer repoository.

 The maintainer workflow could be something like

1. Maintainer receives the PR from the developer (how depends on what
interfaces are available, but might just be an email).
2. Maintainer adds the developers repository as another upstream source to
their LOCAL maintenance repository.
3. Maintainer checks out the developers PR branch as a local branch in
their working directory
4. Maintainer does whatever reviews, cleanup, adjustments etc they think
are necessary and commits the branch. This only commits to their local
maintenance repository.
5. Maintainer does any other check, such as verifying copyright or whatever
6. Maintainer now checks out master branch of maintenance repository
(possibly after doing a pull from upstream master repository to ensure
latest code base).
7. Maintainer then merges local PR branch into master branch
8 Maintainer runs tests and verifies merge is good and if happy commits the
master to local maintenance repository with appropriate commit message.

At this point, the PR is only in the local maintenance repository. There
has not yet been any changes made to the master repository, so nobody can
see these changes.

9. Maintainer pushes the local master branch to the upstream master
repository

The maintainer may then choose to do some cleanup work, like removing the
PR branch and PR upsream source from their local maintenance repository (or
they can leave them, they don't use much space and you may get further PRs
from that developer etc).


If so, as previous discussions have established, the issue that is of
> concern is what server should host the "forked repository".  It
> cannot be someone's private machine, because private machines don't
> usually have Git servers, and thus cannot be pulled from.  Richard
> also didn't want this to be Savannah, because then the forked
> repository and its changes could be perceived as "endorsed" by GNU.
> The practical solution is to host this on some nongnu.org server.
>
>
I don't think we need to care. Provided the person making the PR is able to
provide a public interface to their repository, it doesn't matter where it
is hosted. Once the PR is complete, the code is part of the master
repository and the forked developer repository is irrelevant.


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 11470 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs?

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

  >   Basically, you add the PR repository to your LOCAL repo and check
  > it out as a branch. Do whatever you need (review, fix, etc), commit it to
  > your local repository. Perhaps do some diffs against your master repository
  > and if all is good, merge it with your local master branch. At this point,
  > there is still no change to the 'main' master repository. If the merge all
  > goes fine, you can then push the changes to your master branch in your main
  > repository. It is only at this point that the changes have been introduced
  > to the main repository.

This is a good way of handling pull requests.  I'm in favor of
supporting them this way.

I've been told that some repo sites do it another way, where they
pull the patch into a branch in the site.  That way has problems.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> I've been told that some repo sites do it another way, where they
> pull the patch into a branch in the site.  That way has problems.

I don't know of any system that uses "plain branches" for that.

I believe you've been misled by the fact that many systems represent PRs
*technically* as "branches", but those branches do not appear as regular
branches, so you can't bump into it thinking it's actually
a legitimate branch: you will only find it if you're looking for
a pull request, with no possibility of confusion.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[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 believe you've been misled by the fact that many systems represent PRs
  > *technically* as "branches", but those branches do not appear as regular
  > branches, so you can't bump into it thinking it's actually
  > a legitimate branch: you will only find it if you're looking for
  > a pull request, with no possibility of confusion.

I'm goin by what I was told by someone who explained the area to me.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Andrea Corallo]

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

> That's right.  There is a practical problem, OTOH, which is that
> write/push access to a GNU ELPA package currently means write access to
> all GNU ELPA packages as well as to Emacs's repository.
>
> For this reason, while some GNU ELPA package maintainers can "just push"
> as they see fit, as it should be, others haven't yet been granted this
> right.  This is a problem which we should solve, indeed, for the benefit
> of those less-lucky package maintainers, as well as for the benefit of
> those Emacs maintainers who have to play the middle men, and more
> generally for the benefit of the GNU ELPA archive and hence Emacs users
> since the current situation tends to discourage submissions.
>
> Note that giving write access widely, as we do now, has advantages as
> well, in that it encourages package maintainers to participate in
> development of Emacs more generally.

To me the fact that a number of package maintainers is without write
access sounds quite odd.

If they are trusted to maintain a package they are supposed to have also
the skills to push correctly a git commit.

Looking at other Free Software projects I'm involved I can testify that
trust pays off and I think they should get write access.  My 2 cents.

  Andrea

-- 
akrl@sdf.org

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross]

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

I don't think it is quite that simple.

Your not just trusting that person will do the right thing. You are also
trusting that they also have good operational security. It is precisely
this sort of trust model which resulted n a number of GNU/Linux
distributions being compromised in the past. The same thing has occurred
with NPM and other 'public' repositories. It wasn't that people who had
access did the wrong thing, but rather people who had access who failed to
secure their systems adequately.

You only need to do a search of places like github to see how often people
accidentally commit sensitive data or look at the analysis of repositories
that have been compromised to see how often this occured because passwords
were poor, keys were not secured or sensitive data was accidentally posted
to public forums.

The only real solution is one where each package maintainer is isolated
from write access to code/packages they are not authorised to maintain. The
challenge is, such setups usually also result in higher levels of
maintenance overheads and that can often be a challenge for an organisation
which needs to walk a tight line wrt funding.

To make matters worse, typically, it is almost impossible to have good
security retro fitted to a solution this is something which needs to be
designed into the architecture from the start. This means that to fix this
problem would require a considerable amount of work and change. The change
part is extremely difficult as most people simply don't like change (as is
evident in many of the discussions about updating how we handle patches,
pull requests, defaults, etc).

On Fri, 24 Apr 2020 at 07:51, Andrea Corallo <akrl@sdf.org> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > That's right.  There is a practical problem, OTOH, which is that
> > write/push access to a GNU ELPA package currently means write access to
> > all GNU ELPA packages as well as to Emacs's repository.
> >
> > For this reason, while some GNU ELPA package maintainers can "just push"
> > as they see fit, as it should be, others haven't yet been granted this
> > right.  This is a problem which we should solve, indeed, for the benefit
> > of those less-lucky package maintainers, as well as for the benefit of
> > those Emacs maintainers who have to play the middle men, and more
> > generally for the benefit of the GNU ELPA archive and hence Emacs users
> > since the current situation tends to discourage submissions.
> >
> > Note that giving write access widely, as we do now, has advantages as
> > well, in that it encourages package maintainers to participate in
> > development of Emacs more generally.
>
> To me the fact that a number of package maintainers is without write
> access sounds quite odd.
>
> If they are trusted to maintain a package they are supposed to have also
> the skills to push correctly a git commit.
>
> Looking at other Free Software projects I'm involved I can testify that
> trust pays off and I think they should get write access.  My 2 cents.
>
>   Andrea
>
> --
> akrl@sdf.org
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 3986 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Andrea Corallo]

Tim Cross <theophilusx@gmail.com> writes:

> I don't think it is quite that simple.
>
> Your not just trusting that person will do the right thing. You are
> also trusting that they also have good operational security. It is
> precisely this sort of trust model which resulted n a number of GNU/
> Linux distributions being compromised in the past.

IMO the comparison does not stand.  We are not talking about a big
volume of binaries hard to verify that are continuously pushed by
developers.  With the current volume of commits we have on ELPA the eyes
of other developers on elpa-diffs are sufficient.

I believe giving a little more responsibilities to developers is also a
fundamental stimulus to involve them more.

This need for security is most likely not to be beneficial and BTW I'm
not sure is backuped by specific examples of the past happen in the ELPA repo.

Lastly wanted to mention that yeah... as a last resource 'git revert'
exists :)

Regards

  Andrea

-- 
akrl@sdf.org

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Kangas]

Andrea Corallo <akrl@sdf.org> writes:

> I believe giving a little more responsibilities to developers is also a
> fundamental stimulus to involve them more.

FWIW, I think Andrea is right on the money here and in her previous message.

Of course, giving out commit access more freely will cause occasional
problems and inconveniences.  I think this drawback is heavily
outweighed by the potential benefits.

Best regards,
Stefan Kangas

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Date: Fri, 24 Apr 2020 08:56:20 +0000
> Cc: Yuan Fu <casouri@gmail.com>, ndame <ndame@protonmail.com>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> I believe giving a little more responsibilities to developers is also a
> fundamental stimulus to involve them more.

Let's please keep this in perspective.  As shown on the project's
Savannah page

  https://savannah.gnu.org/projects/emacs

we currently have 209 people who can commit to ELPA and Emacs
repositories.  Does that sound like we don't give enough people
responsibilities and the trust to go with that?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Dmitry Gutov]

On 24.04.2020 11:56, Andrea Corallo wrote:
> IMO the comparison does not stand.  We are not talking about a big
> volume of binaries hard to verify that are continuously pushed by
> developers.  With the current volume of commits we have on ELPA the eyes
> of other developers on elpa-diffs are sufficient.

FWIW, as one of the "other developers", I'm not fond of the volume of 
the commits already. Especially when they come from packages which I 
don't personally care about.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross]

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

On Fri, 24 Apr 2020 at 18:56, Andrea Corallo <akrl@sdf.org> wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>
> > I don't think it is quite that simple.
> >
> > Your not just trusting that person will do the right thing. You are
> > also trusting that they also have good operational security. It is
> > precisely this sort of trust model which resulted n a number of GNU/
> > Linux distributions being compromised in the past.
>
> IMO the comparison does not stand.  We are not talking about a big
> volume of binaries hard to verify that are continuously pushed by
> developers.  With the current volume of commits we have on ELPA the eyes
> of other developers on elpa-diffs are sufficient.
>
>
That model sounds good, but simply fails in reality. This has long been a
claim of the open source movement - because the code is available, it is
thoroughly reviewed and therefore a lot more secure. Sounds good, but as
has been shown in other projects (consider openSSL for example), this is
not the case. While having access to the code is extremely important,
relying on ad hoc review is a very weak control. Reviewing of software is
complex and time consuming. Those wanting to inuect malicious content are
clever and do so in ways that are extremely difficult to detect. There has
already been 1 reply which indicates the volume of commits is quite large,
which makes the claim that all commits are scrutinized somewhat
questionable.

> I believe giving a little more responsibilities to developers is also a
> fundamental stimulus to involve them more.
>
> This need for security is most likely not to be beneficial and BTW I'm
> not sure is backuped by specific examples of the past happen in the ELPA
> repo.
>
>
The fact it may ot have occurred does not mean it won't. If plans to
increase popularity and number of packages are successful, it is likely the
associated risks will also increase. Past experience is a very poor
indicator when it comes to security - I was never burgled, until I was.


> Lastly wanted to mention that yeah... as a last resource 'git revert'
> exists :)
>

The problem with this approach is the damage has already been done. How bad
that damage is depends on your own op sec, but it could be substantial.

I don't disagree with empowering developers and giving them more
responsibility. Having good security and enabling developers to have more
responsibility are not mutually exclusive. You can have both and despite
popular opinion, it does not have to come with high levels of inconvenience
or maintenance overhead.

A good security model needs to fulfill 3 requirements

1. People only have access to what they need. The current model fails with
this requirement as developers have access to modifying code they are not
responsible for.
2. Simple, reliable and robust. The system needs to be easy to use and
understand. If it is too complicated, it cannot be easily verified or
modified to fit evolving requirements. If it is too hard to use or
unreliable, people will find a means to work around it and often in ways
which severely compromise security. The current model is very convenient,
but due to 1), is not very secure.
3. It needs to be auditable. Things will go wrong and when they do, you
need to be able to identify what has happened and when. Git logs are pretty
useful in this area. However, I don't know what the process is for adding
access, verifying accounts or reviewing access etc.

Having been involved in helping companies recover from security breaches, I
cannot stress enough how much time, resources and effort it takes. Too
often, such breaches are caused by poor security practices of individuals
rather than a lack of security at the server, firewall etc. Individuals are
frequently unaware they have been compromised. Developers often make
mistakes, like accidentally committing test code which contains sensitive
data, committing a private key or config file containing access tokens etc.
A simple revert will not remove such sensitive data. and requires you
realise the error has occurred.

The key point is there is no reason you can't have convenience and
security. There are several models you could adopt which would restrict
developers to only have access to the code they are responsible for which
do not impose high levels of inconvenience or maintenance overhead. The
important thing is to make this a core requirement and not an after thought
as trying to do this retrospectively is always harder and less successful.
If there is to be a real effort to increase the number of packages
considered to be part of GNU Emacs and included in ELPA, then now is the
time to ensure such issues are addressed.

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 5844 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs?

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

  > A good security model needs to fulfill 3 requirements

  > 1. People only have access to what they need. The current model fails with
  > this requirement as developers have access to modifying code they are not
  > responsible for.

Maintaining a specific GNU ELPA package in itsown individual repos
(and automatically copying commits patches from there into GNU ELPA)
would address this.  Only the maintainers of that package, plus a few
Emacs maintainers, would have access to write the per-package repo.

  > 2. Simple, reliable and robust. The system needs to be easy to use and
  > understand. If it is too complicated, it cannot be easily verified or
  > modified to fit evolving requirements.

I think this change would not harm convenience.  I presume the
per-package repo would be as easy to use as the GNU ELPA repo is now.





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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Dmitry Gutov]

On 23.04.2020 21:50, Yuan Fu wrote:
> but if it’s in ELPA, you need to take care of commit message formats, submit a patch and wait for someone to review & commit the patch

This part is not really true.

You don't really need to worry about commit message format in ELPA, nor 
wait for code review (if you're the author of the package).

Re: Why are so many great packages not trying to get included in GNU Emacs?

[João Távora]

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

On Thu, Apr 23, 2020 at 8:03 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 23.04.2020 21:50, Yuan Fu wrote:
> > but if it’s in ELPA, you need to take care of commit message formats,
> submit a patch and wait for someone to review & commit the patch
>
> This part is not really true.
>
> You don't really need to worry about commit message format in ELPA, nor
> wait for code review (if you're the author of the package).
>

However, in projects like Eglot, I do review stuff and do ask people
to follow the GNU Commit message format.  Not always, I will
do it for "newbie" committers often, not to burden them with the
red tape, then add a "Co-authored-by:" cookie to the commit
message.  (In fact I just did that for another GNU Elpa package
also hosted on Github, darkroom.el) If someone is serious about
contributing, I ask them to learn the format and I don't see
any resistance.

Anyway, just as a data point, I don't think Eglot has shortage of
committers because of the copyright issue (everyone I've asked
has eventually assigned to Emacs), the commit message
format, or the review process. I've turned down a few contributions
before, because I didn't like them technically, but they eventually
mutate into valid alternatives that do make it in.

João

[-- Attachment #2: Type: text/html, Size: 1792 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 07/05/2020 13.42, João Távora wrote:
> Not always, I will do it for "newbie" committers often, not to burden
> them with the red tape, then add a "Co-authored-by:" cookie to the
> commit message.

I got confused by this part: why do you need the cookie?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[João Távora]

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

On Thu, May 7, 2020 at 8:54 PM Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:

> On 07/05/2020 13.42, João Távora wrote:
> > Not always, I will do it for "newbie" committers often, not to burden
> > them with the red tape, then add a "Co-authored-by:" cookie to the
> > commit message.
>
> I got confused by this part: why do you need the cookie?
>

Because I changed the commit message: here's the commit I was
talking about earlier (from git.sv.gnu.org:/srv/git/emacs/elpa.git)

commit 4953ee6f7de4ead0fced02e0da823eafaf5797e0
Author: Ilya Ostapyshyn <ilya.ostapyshyn@gmail.com>
Date:   Thu May 7 20:34:14 2020 +0300

    Fix #13: correctly calculate search bound for narrowed buffers

    The search-forward function does not take narrowing into account, so we
must
    do that  ourselves.

    Co-authored-by: João Távora <joaotavora@gmail.com>
    Copyright-paperwork-exempt: yes

    * darkroom.el (darkroom-guess-margins): Add (point-min) to the 20000

I added all the commit message, but Ilya did the actual patch.

Though reading Luke's email, it seems I could have use
"Signed-off-by:" or something like that.

João

[-- Attachment #2: Type: text/html, Size: 1815 bytes --]

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 7 May 2020 21:28:23 +0100
> Cc: ndame <ndame@protonmail.com>, Yuan Fu <casouri@gmail.com>,
>  Emacs developers <emacs-devel@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
>  I got confused by this part: why do you need the cookie?
> 
> Because I changed the commit message: here's the commit I was 
> talking about earlier (from git.sv.gnu.org:/srv/git/emacs/elpa.git)
> 
> commit 4953ee6f7de4ead0fced02e0da823eafaf5797e0
> Author: Ilya Ostapyshyn <ilya.ostapyshyn@gmail.com>
> Date:   Thu May 7 20:34:14 2020 +0300
> 
>     Fix #13: correctly calculate search bound for narrowed buffers
>     
>     The search-forward function does not take narrowing into account, so we must
>     do that  ourselves.
>     
>     Co-authored-by: João Távora <joaotavora@gmail.com>
>     Copyright-paperwork-exempt: yes
>     
>     * darkroom.el (darkroom-guess-margins): Add (point-min) to the 20000
> 
> I added all the commit message, but Ilya did the actual patch.
> 
> Though reading Luke's email, it seems I could have use
> "Signed-off-by:" or something like that.

See CONTRIBUTE: we are asking not to use Signed-off-by.

As for Co-authored-by, this is IMO a borderline case: a change in the
commit log message does not necessarily mean you become a co-author.
But it doesn't do any harm, so it's your call whether to use it in
such cases.  I don't, FWIW.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[João Távora]

On Fri, May 8, 2020 at 7:26 AM Eli Zaretskii <eliz@gnu.org> wrote:

> As for Co-authored-by, this is IMO a borderline case: a change in the
> commit log message does not necessarily mean you become a co-author.

I don't think a newbie author would like to see a strange
commit message under his name without warning (tho
I'm guessing: noone has complained).

> But it doesn't do any harm, so it's your call whether to use it in
> such cases.  I don't, FWIW.

Got it.  No Signed-off-by. But just so I understand, you're "borderline"
on Co-authored-by if that is motivated by the commit message
text. You're _not_ opposed to it if I add a comment to code, or
change some detail, right? Because I'll do that sometimes,
too.  Though only for larger changes, and from those authors
I request copyright assignments.

Thanks,
João

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 8 May 2020 17:28:52 +0100
> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	ilya.ostapyshyn@gmail.com, ndame <ndame@protonmail.com>, 
> 	Yuan Fu <casouri@gmail.com>, emacs-devel <emacs-devel@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > But it doesn't do any harm, so it's your call whether to use it in
> > such cases.  I don't, FWIW.
> 
> Got it.  No Signed-off-by. But just so I understand, you're "borderline"
> on Co-authored-by if that is motivated by the commit message
> text. You're _not_ opposed to it if I add a comment to code, or
> change some detail, right?

I'm not opposed to it at all.  If you feel you need to add that, I'm
fine with that.  (My own interpretation of co-authorship is that some
serious code change would have to have place, but I see no reason not
to leave this to the discretion of each one of us.)

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Date: Thu, 23 Apr 2020 17:47:00 +0000
> From: ndame <ndame@protonmail.com>
> 
> Is there an actual effort too seek out prospective packages and ask the
> code owners to include it in emacs?

Yes, in some cases.

> What about current popular packages outside Emacs? Were those developers
> all asked?

Not all of them, but some were asked, yes.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

>
> > What about current popular packages outside Emacs? Were those developers
> > all asked?
>
> Not all of them, but some were asked, yes.

And in those cases what were the typical reasons given for refusals?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Date: Thu, 23 Apr 2020 19:35:07 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > > What about current popular packages outside Emacs? Were those developers
> > > all asked?
> >
> > Not all of them, but some were asked, yes.
> 
> And in those cases what were the typical reasons given for refusals?

They varied.  I suggest to look them up in the archives.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> Is there an actual effort too seek out prospective packages and ask the
> code owners to include it in emacs?

Yes.  I'd say at least half of the packages we currently have in GNU
ELPA are there because we went out and tried to get the authors to
contribute their package to GNU ELPA.
I welcome help in doing that work, BTW.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

>
> Yes. I'd say at least half of the packages we currently have in GNU
> ELPA are there because we went out and tried to get the authors to
> contribute their package to GNU ELPA.

An alternative could be adding MELPA too by default to package-archives,
but with a filtered package list.

In order to get into the default MELPA filter a package is required
to have a free license and it has to be a quality package with an
active maintainer.

This way out of the box emacs would be in control what can be installed
from MELPA, so there is less need to move the package into ELPA.
The filter list itself could be in ELPA, so it can be
updated independently of Emacs' release cycle.

And, of course, the user could also modify the filter list in his own
config allowing installation of any package he likes.

Re: Why are so many great packages not trying to get included in GNU Emacs?

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

  > An alternative could be adding MELPA too by default to package-archives,
  > but with a filtered package list.

  > This way out of the box emacs would be in control what can be installed
  > from MELPA, so there is less need to move the package into ELPA.

Yes indeed -- and that is the drawback of that proposal.

We want the developers of the MELPA packages that users like
to sign copyright assignments so we can put those packages into GNU ELPA.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Kangas]

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

> > Is there an actual effort too seek out prospective packages and ask the
> > code owners to include it in emacs?
>
> Yes.  I'd say at least half of the packages we currently have in GNU
> ELPA are there because we went out and tried to get the authors to
> contribute their package to GNU ELPA.

Interesting; I wasn't aware that it was that many.  Important progress
has clearly been made.

But ideally we would see it happen the other way around: package
maintainers reaching out to us for inclusion.

> I welcome help in doing that work, BTW.

Is there a list of packages we would like to see included and their
current status?  That would definitely make it easier to get involved.
Such a list could also include the packages where we have tried but
hit a dead end.

We could add this to the Emacs TODO and/or a separate file in the ELPA
repository.

Best regards,
Stefan Kangas

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

>> I welcome help in doing that work, BTW.
> Is there a list of packages we would like to see included and their
> current status?

No, sorry.  But yes, it would be good for someone to manage such a list.
Since we welcome pretty much any reasonable package into GNU ELPA, the
starting list can start as "all the packages you use from MELPA".
And packages used by other packages would likely have higher priority
(which is why we worked fairly hard to get `dash` into GNU ELPA, for
example).

> Such a list could also include the packages where we have tried but
> hit a dead end.

Or not dead ends but where we're "in the process".

Other work to do is to make sure the GNU ELPA packages don't
become stale.  E.g. `dash` is out of date, IIRC.

> We could add this to the Emacs TODO and/or a separate file in the ELPA
> repository.

I think it makes more sense to keep it in elpa.git than emacs.git, but
either way works.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[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.  I'd say at least half of the packages we currently have in GNU
  > ELPA are there because we went out and tried to get the authors to
  > contribute their package to GNU ELPA.

Thanks to you and the others who helped do this.

  > I welcome help in doing that work, BTW.

I encourage others to join in this.


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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Jean-Christophe Helary]

> On Apr 24, 2020, at 5:52, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> Is there an actual effort too seek out prospective packages and ask the
>> code owners to include it in emacs?
> 
> Yes.  I'd say at least half of the packages we currently have in GNU
> ELPA are there because we went out and tried to get the authors to
> contribute their package to GNU ELPA.

I seem to remember that in the summer of 2017 and after, Mats Lidell and I, led by Jonas Bernoulli did something very similar for packages hosted on emacsmirror, after a discussion here about copyright assignments and licenses.

> I welcome help in doing that work, BTW.

If you have clear instructions, I could help.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Po Lu]

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


> Yes.  I'd say at least half of the packages we currently have in GNU
> ELPA are there because we went out and tried to get the authors to
> contribute their package to GNU ELPA.
> I welcome help in doing that work, BTW.

BTW, has there been any real progress in including Magit in ELPA?
I remember a discussion pertaning to that and it seemed promising at the
time, but now I can't find anything related to it.