Adding advisory notification for non-ELPA package.el downloads

Adding advisory notification for non-ELPA package.el downloads

[John Wiegley]

Richard recently suggested the idea of adding a notification message -- to
remain completely unobtrusive -- that would indicate to users installing
packages from MELPA something along the lines of:

    "We urge the developers of Emacs packages that are in MELPA, or
    that they hope to put in MELPA, to write to emacs-devel@gnu.org
    about signing the legal papers to enable us to include them in
    Emacs or in the Emacs package library."

This message could remain on the screen for a few seconds, or until the user
types something else. The aim is to make people aware of the importance of
this in a gentle way that won't interfere with what they are doing.

First what do people think of such an idea, and second, does it sound like
something anyone would be interesting in adding to package.el, so more people
can learn about how to contribute to ELPA? I have a feeling that a lot of
package authors choose MELPA because the barrier to entry is so low, and they
may not realize how easy it is to get it into Emacs as well.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Adding advisory notification for non-ELPA package.el downloads

[Dmitry Gutov]

Hi John,

On 7/8/17 4:59 AM, John Wiegley wrote:

> First what do people think of such an idea, and second, does it sound like
> something anyone would be interesting in adding to package.el, so more people
> can learn about how to contribute to ELPA?

Doesn't sound great: the message would be shown to the users, and there 
are much more of them than the package developers. It will be a nuisance.

> I have a feeling that a lot of
> package authors choose MELPA because the barrier to entry is so low, and they
> may not realize how easy it is to get it into Emacs as well.

Try asking the MELPA developers about including that paragraph (or a 
modified version) somewhere near the instructions for publishing 
packages to MELPA.

Re: Adding advisory notification for non-ELPA package.el downloads

[Kaushal Modi]

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

On Sat, Jul 8, 2017, 6:29 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

>
> Doesn't sound great: the message would be shown to the users, and there
> are much more of them than the package developers. It will be a nuisance.
>

+1

> I have a feeling that a lot of
> > package authors choose MELPA because the barrier to entry is so low, and
> they
> > may not realize how easy it is to get it into Emacs as well.
>
> Try asking the MELPA developers about including that paragraph (or a
> modified version) somewhere near the instructions for publishing
> packages to MELPA.
>

+1

To add, instead of emailing emacs-devel, we can ask them to email
assign@gnu.org directly.

The instructions can look something like this:

=====
In order to contribute to Emacs (or GNU Elpa, Org-mode, etc), it is
required to assign your copyright to FSF.

You need to send an email to assign@gnu.org asking that you'd like to
assign your copyrights to FSF.

Here's a sample of an email that one can send:

> Hello,

> I visited this site:
https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html#Copyright-Papers

> I would like to contribute to GNU Emacs.

> What are the copyright papers that I would need to sign?
=====

-- 

Kaushal Modi

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Clément Pit-Claudel]

On 2017-07-07 21:59, John Wiegley wrote:
> I have a feeling that a lot of package authors choose MELPA because 
> the barrier to entry is so low,  and they may not realize how easy it
> is to get it into Emacs as well.

It's not that they doesn't realize how easy it is: it's that it's not easy.

Getting into MELPA requires a writing a one-line Lisp form and submitting it for inclusion.  Getting into ELPA requires subtle git invocations that end up mashing up the history of your project with that of tens of others, while fearing to break the entire ELPA repo because of a missing copyright line in a test file.

And ELPA makes maintaining the package more painful, too: picking out the commits made by others and copying them on your personal repo requires further arcane git invocations — same for importing new commits from your personal repo. And of course you lose other MELPA goodies, like getting download statistics.

For now, the main motivation to publish on ELPA is ideological — not practical. My feeling is that package authors chose not to publish on ELPA because they get all they need from MELPA, for a fraction of the invested time.

Clément.

Re: Adding advisory notification for non-ELPA package.el downloads

[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 goal here is to avoid having packages end up in the situation
Magit is in now.

They get into that situation because developers accept contributions
without thinking of legal papers.  They get contributions from one
person, then another, then another 50 people, then another 50.

The way to avoid this is by showing people what the situation is like
and how they can avoid it.  We need to educate the whole Emacs Lisp
development community.

  > > I have a feeling that a lot of
  > > package authors choose MELPA because the barrier to entry is so low, and they
  > > may not realize how easy it is to get it into Emacs as well.

  > Try asking the MELPA developers about including that paragraph (or a 
  > modified version) somewhere near the instructions for publishing 
  > packages to MELPA.

That notice approach won't be effective, because people would only see
the notice when they have a package ready to use.  That is too late.
We want people to think of this when they START developing the
package.

To inform Emacs users when they load a package from outside ELPA would
be more effective, because they would see it earlier -- well before
they think about putting it in a repository.

That approach would do the job, but it is not perfect.  It is not
perfectly targeted.

Here's an idea that might be better targeted.

The idea is to display a notice when the user edits a file in Emacs
Lisp mode (other than .emacs).  The code could avoid displaying the
notice more than once per week -- using a timestamp for the last time
it was displayed.

To avoid these problems is important.  By comparison, this occasional
small annoyance is a small matter.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Jean-Christophe Helary]

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


> On Jul 9, 2017, at 2:03, Richard Stallman <rms@gnu.org> wrote:
> 
> The goal here is to avoid having packages end up in the situation
> Magit is in now.

If ELPA inclusion is as cumbersome as Clement describes it, adding elisp *user* notifications will only upset users and will change little else.

The first thing to do seems to be seriously refine the technical process to have packages included in ELPA. Then we can improve the paper signing system, and then we can embark on a vast campagne to inform MELPA contributors that they can move to ELPA with little extra overhead.

If ELPA is concerned with free software, MELPA seems more inclined to think in terms of "open source software". We can't have people move to free software if oss proves to be less of a hassle (the minority of people who can easily be convinced that free software is better are probably already on ELPA).

Jean-Christophe

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Tim Cross]

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

Totally agree. If we want people to 'do the right thing', we have to make
it as easy as possible. If things are as bad as Clement indicates, nagging
users will have little impact and what impact it does have will likely be
negative.

WRT Richard's suggestion about a weekly notice when editing elisp files -
not sure if it should be all elisp files or whether it should be restricted
to files like *-pkg.el that are part of package.el packages? I do a fair
amount of elisp which does not use package.el, so notices about ELPA are
just annoying. Maybe we could modify package.el to make it mandatory for
packages to include a file/statement which maintainers must include which
requires them to acknowledge the benefits of free software and the
disadvantages of non-ELPA repositories.

Regardless of the approach used, the fundamental requirement will be to
remove all unnecessary barriers to using ELPA and maintaining ELPA
packages.

On 9 July 2017 at 08:12, Jean-Christophe Helary <
jean.christophe.helary@gmail.com> wrote:

>
> On Jul 9, 2017, at 2:03, Richard Stallman <rms@gnu.org> wrote:
>
> The goal here is to avoid having packages end up in the situation
> Magit is in now.
>
>
> If ELPA inclusion is as cumbersome as Clement describes it, adding elisp
> *user* notifications will only upset users and will change little else.
>
> The first thing to do seems to be seriously refine the technical process
> to have packages included in ELPA. Then we can improve the paper signing
> system, and then we can embark on a vast campagne to inform MELPA
> contributors that they can move to ELPA with little extra overhead.
>
> If ELPA is concerned with free software, MELPA seems more inclined to
> think in terms of "open source software". We can't have people move to free
> software if oss proves to be less of a hassle (the minority of people who
> can easily be convinced that free software is better are probably already
> on ELPA).
>
> Jean-Christophe
>



-- 
regards,

Tim

--
Tim Cross

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Dmitry Gutov]

On 7/8/17 8:03 PM, Richard Stallman wrote:

> They get into that situation because developers accept contributions
> without thinking of legal papers.  They get contributions from one
> person, then another, then another 50 people, then another 50.

It's not that serious. Most packages are created and maintained by a 
single developer, with only minor contributions from users.

There are big ones where that's not true, but they older, and they have 
surely considered going the ELPA route already.

> The way to avoid this is by showing people what the situation is like
> and how they can avoid it.  We need to educate the whole Emacs Lisp
> development community.

The nagging approach can just as likely alienate users. We already have 
a lot of those that scoff at the conditions of contributing to Emacs. 
Saying that the hassle is negligible (and saying that often, in users' 
faces) is unlikely to improve the situation.

It's better to work on streamlining the copyright assignment process and 
have a separate campaign (outside of our precious Emacs) to encourage 
developers to do it.

> That notice approach won't be effective, because people would only see
> the notice when they have a package ready to use.  That is too late.
> We want people to think of this when they START developing the
> package.

This distinction doesn't matter much. When someone starts developing a 
package, and until they publish it, they work alone in 99.9% cases.

> To inform Emacs users when they load a package from outside ELPA would
> be more effective, because they would see it earlier -- well before
> they think about putting it in a repository.
> 
> That approach would do the job, but it is not perfect.  It is not
> perfectly targeted.

I think it would be targeted perfectly: "Want to publish a package? 
Here's what you need to do to publish it where *every* Emacs user will 
be able to install it from!"

> Here's an idea that might be better targeted.
> 
> The idea is to display a notice when the user edits a file in Emacs
> Lisp mode (other than .emacs).  The code could avoid displaying the
> notice more than once per week -- using a timestamp for the last time
> it was displayed.

You might want to consider the idea that public relations is not your 
best skill.

Re: Adding advisory notification for non-ELPA package.el downloads

[Yann Hodique]

>>>>> "Clément" == Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 2017-07-07 21:59, John Wiegley wrote:
>> I have a feeling that a lot of package authors choose MELPA because
>> the barrier to entry is so low, and they may not realize how easy it
>> is to get it into Emacs as well.

> It's not that they doesn't realize how easy it is: it's that it's
> not easy.

> Getting into MELPA requires a writing a one-line Lisp form and
> submitting it for inclusion.  Getting into ELPA requires subtle git
> invocations that end up mashing up the history of your project with
> that of tens of others, while fearing to break the entire ELPA repo
> because of a missing copyright line in a test file.

> And ELPA makes maintaining the package more painful, too: picking out
> the commits made by others and copying them on your personal repo
> requires further arcane git invocations — same for importing new
> commits from your personal repo. And of course you lose other MELPA
> goodies, like getting download statistics.

> For now, the main motivation to publish on ELPA is ideological — not
> practical. My feeling is that package authors chose not to publish on
> ELPA because they get all they need from MELPA, for a fraction of the
> invested time.

+1

I'd also like to add a few things:

- some package authors *do not* choose MELPA, MELPA chooses them. Most
  of my packages are in MELPA without me ever asking for it, it's just
  that somebody else cared enough.

- let's not trivialize the act of assigning copyright. It's *not*
  a neutral action (if it was, it wouldn't be required...), and it's
  definitely *not* only about signing some paper. For many people it
  involves researching whether it's actually meaningful or legal to do
  so, depending on their country of citizenship and/or residence. In
  some cases it means selling the idea to their employer (who frequenly
  is the default copyright owner of all their work) which can easily be
  met with scepticism and resistance from legal departments: personally
  it took me more than 2 months to complete that particular
  conversation, just because it's a highly unusual request and people
  didn't understand what was the need.

Bottom-line there are legal implications beyond licensing to doing so
(which is again the whole point), and that can never be as simple as
handling licensing alone. I would consider it quite misleading if those
aspects were glossed over: I fear that would only encourage people to
sign without understanding what it's about.

Proactively contacting elisp developers to ask them if they would
consider a copyright assignment (mentioning the benefit of potential
bundling with Emacs, along with the rest of the implications) seems much
more OK to me.

my 2¢

Yann.

-- 
It is your fate, forgetfulness.  All of the old lessons of life, you lose and 
gain and lose and gain again.

  -- Leto II, the Voice of Dar-es-Balat

Re: Adding advisory notification for non-ELPA package.el downloads

[Chad Brown]

> On 8Jul, 2017, at 17:39, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> I think it would be targeted perfectly: "Want to publish a package? Here's what you need to do to publish it where *every* Emacs user will be able to install it from!"

I think Dmitry has a very good idea here: build a mechanism for
publishing elisp packages, incorporate it directly into emacs.
Include in it at least basic support for popular non-ELPA elisp
repositories, even if only as links to external web pages. This is
a good place to include notes about the ELPA process, and it also
provides an interface for starting people on the copyright assignment
process.  (As an aside, the copyright assignment part can probably
also be used for a subsequent “submit a patch to Emacs” elisp
interface.)

~Chad

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > There are big ones where that's not true, but they older, and they have 
  > surely considered going the ELPA route already.

I'm talking about packages that will get into this state in the future,
which at present have just one developer, but will have more.

Maybe that wasn't stated clearly at first.

  > The nagging approach can just as likely alienate users.

A message at most once a week, that is on the screen for a short time,
is hardly "nagging".

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[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 ELPA inclusion is as cumbersome as Clement describes it, adding
  > elisp *user* notifications will only upset users and will change
  > little else.

We are miscommunicating.  The point of this notice is to teach the
whole community about the need to think about legal papers
from an early stage.

If they have done this, it would eliminate one obstacle to
putting the package in ELPA.  But really it is not about ELPA.

The point is to prevent packages from getting into the problem
situation that Magit is now in.


It sounds like ELPA is very inconvenient to use.  I agree we should
make it easier.  But that's a separate issue.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > WRT Richard's suggestion about a weekly notice when editing elisp files -
  > not sure if it should be all elisp files or whether it should be restricted
  > to files like *-pkg.el that are part of package.el packages?

This is not really about the activity of preparing a package.  The
point is to educate the community to think about legal papers when
they start to accept contributions to their packages from other
developers.

If people generally incorporate contributions from lots of other
people first, and only then prepare a package, then attaching this
notice to editing *-pkg.el would show it to them too late.

However, if people generally prepare a package first, and get offered
contributions afterward, then maybe attaching this notice to editing
*-pkg.el is a very good idea.

Which way do those things generally happen nowadays?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > Proactively contacting elisp developers to ask them if they would
  > consider a copyright assignment (mentioning the benefit of potential
  > bundling with Emacs, along with the rest of the implications) seems much
  > more OK to me.

That would entail searching for people who are just starting packages
and sending each one mail.  I agree it would give better results -- if
we could do it.  But it would be a lot of work.  Who would do the
work?  And how would we find people that are just starting
to get contributions to their packages?

It isn't better if it isn't feasible.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Dmitry Gutov]

On 7/10/17 12:27 PM, Richard Stallman wrote:

> I'm talking about packages that will get into this state in the future,
> which at present have just one developer, but will have more.

These can be well served by having the discussed call to action 
somewhere near (before or after) MELPA package publishing instructions.

> Maybe that wasn't stated clearly at first.

It was. And I believe I've addressed it already.

>    > The nagging approach can just as likely alienate users.
> 
> A message at most once a week, that is on the screen for a short time,
> is hardly "nagging".

It's an ill-defined task, at best. Which files, when, where to store the 
last message date? Will it distract the user from writing code (will it 
make the buffer contents jump)? How will it deal with personal 
configurations (which people have no intention of publishing), and will 
it continue to show those messages even after the package is published?

Re: Adding advisory notification for non-ELPA package.el downloads

[Ken Manheimer]

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

On Mon, Jul 10, 2017 at 5:27 AM, Richard Stallman <rms@gnu.org> wrote:

> [...]
>   > The nagging approach can just as likely alienate users.
>
> A message at most once a week, that is on the screen for a short time,
> is hardly "nagging".


That's a misleading way to think about it. If every major facility on a
machine was nonchalant about some random once-per-week notification, you
could potentially have several to hundreds per day. (I sometimes feel like
it's towards the more extreme end on the rare occasions that I fire up
Windows machines.) Righteous as the specific purpose might or might not be,
it will be another interruption in the escalating battle for users stray
attention, in which users are the losers.

A properly targeted notification is delivered when someone is initiating
actions specifically for the purpose that the notification addresses. I'm
not sure where that would be in this case, but hearing "once per week"
suggests to me that it's randomly targeted, as part of an activity that
sometimes and sometimes doesn't include the specific activity.

Ken

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Ken Manheimer]

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

On Mon, Jul 10, 2017 at 5:29 AM, 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. ]]]
>
>   > Proactively contacting elisp developers to ask them if they would
>   > consider a copyright assignment (mentioning the benefit of potential
>   > bundling with Emacs, along with the rest of the implications) seems
> much
>   > more OK to me.
>
> That would entail searching for people who are just starting packages
> and sending each one mail.  I agree it would give better results -- if
> we could do it.  But it would be a lot of work.  Who would do the
> work?  And how would we find people that are just starting
> to get contributions to their packages?
>

This is starting to zero in on a specific activity where informing the user
about the ELPA process would be appropriate.

How about enlisting the support of the various package repositories (MELPA
and etc.), so they provide notices to people establishing packages that the
additional steps to include their package in ELPA, including doing their
own copyright assignment and prompting their (prospective) contributors for
copyright assignment early on in the process, is good for Emacs and for
their packages...


> It isn't better if it isn't feasible.
>

The approach you proposed is only one option, there are others.

Ken


>
> --
> Dr Richard Stallman
> President, Free Software Foundation (gnu.org, fsf.org)
> Internet Hall-of-Famer (internethalloffame.org)
> Skype: No way! See stallman.org/skype.html.
>
>
>

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Yann Hodique]

>>>>> "Richard" == 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. ]]]

>> Proactively contacting elisp developers to ask them if they would
>> consider a copyright assignment (mentioning the benefit of potential
>> bundling with Emacs, along with the rest of the implications) seems much
>> more OK to me.

> That would entail searching for people who are just starting packages
> and sending each one mail.  I agree it would give better results -- if
> we could do it.  But it would be a lot of work.  Who would do the
> work?  And how would we find people that are just starting
> to get contributions to their packages?

> It isn't better if it isn't feasible.

Well, one possibility would be to:

1. figure out where most of the code that ends up in MELPA lives (since
   it seems to be the target so far):

   ~/src/github.com/melpa/melpa/recipes master
   ❯ grep :fetcher * | sed 's/.*:fetcher \([a-z]*\).*/\1/' | sort | uniq -c | sort -rg
   3393 github
    156 wiki
     44 git
     38 bitbucket
     26 gitlab
      9 svn
      4 cvs
      2 darcs
      2 bzr
      1 hg

   given that the wiki data is reachable from github (via
   https://github.com/emacsmirror/emacswiki.org) that means that at
   least 96.6% of the target is present on github one way or the
   other. I'm too lazy to extract real trends, but this share is
   slowly growing
   
   | 07/2012 | 07/2013 | 07/2014 | 07/2015 | 07/2016 | 07/2017 |
   |---------+---------+---------+---------+---------+---------|
   |    89.8 |    92.4 |      94 |    95.8 |    96.5 |    96.6 |

2. use the fact that github data is published weekly as a BigQuery
   dataset (https://cloud.google.com/bigquery/public-data/github) to
   perform fancy queries on it: like what are the emacs repositories
   that went from 1 contributor last week to 2 contributors this week,
   crosscheck with paperwork data and identify who to go after next.
   An example of what has already been achieved using those tools:
   https://kozikow.com/2016/06/29/top-emacs-packages-used-in-github-repos/

That's kind of handwavy and vaguely creepy (then again, any kind of
automatic detection of what I might be doing to "help me being a better
member of the community" is gonna creep me out no matter what), but most
of the data is definitely readily available.

Yann.

-- 
The worst sort of protection is confidence.  The best defense is suspicion.

  -- HASIMIR FENRING

Re: Adding advisory notification for non-ELPA package.el downloads

[Joost Kremers]

On Sat, Jul 08 2017, Clément Pit-Claudel wrote:
> On 2017-07-07 21:59, John Wiegley wrote:
>> I have a feeling that a lot of package authors choose MELPA 
>> because 
>> the barrier to entry is so low,  and they may not realize how 
>> easy it
>> is to get it into Emacs as well.
>
> It's not that they doesn't realize how easy it is: it's that 
> it's not easy.
>
> Getting into MELPA requires a writing a one-line Lisp form and 
> submitting it for inclusion.  Getting into ELPA requires subtle 
> git invocations that end up mashing up the history of your 
> project with that of tens of others, while fearing to break the 
> entire ELPA repo because of a missing copyright line in a test 
> file.
>
> And ELPA makes maintaining the package more painful, too: 
> picking out the commits made by others and copying them on your 
> personal repo requires further arcane git invocations — same for 
> importing new commits from your personal repo. And of course you 
> lose other MELPA goodies, like getting download statistics.
>
> For now, the main motivation to publish on ELPA is ideological — 
> not practical. My feeling is that package authors chose not to 
> publish on ELPA because they get all they need from MELPA, for a 
> fraction of the invested time.

Let me just say 'hear, hear' to that, as one of those typical 
package maintainers. I thought about using ELPA instead of MELPA a 
few times, but reading such comments as "arcane git commands", 
"mashing up your history" and "breaking the entire ELPA repo", my 
immediate reaction is "oh well, some other time, perhaps". 

I should probably point out that my git skill level is low, and 
while I'd be willing to learn more, the time investment if often 
prohibitive. (I'm not a professional programmer, just a guy with a 
hobby.) With MELPA, that's sufficient, though, and Github has a 
lot of help pages that provide clear and concise instructions for 
things I don't do every day, such as dealing with PRs or keeping a 
fork up-to-date with its upstream repo.

I've just been skimming the GNU ELPA README on 
http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README and 
although it *looks* like once thing's are set up, I shouldn't have 
to do much more than a git push to update my package, the process 
of getting there seems quite involved.

More importantly perhaps, the entire workflow seems to be 
different. With MELPA, I put my code in a publicly accessible repo 
that I create myself, on a service of my own choosing (in my case 
Github), and then tell MELPA where to look for it. With GNU ELPA, 
it seems I need to put my code somewhere specific, and it's not in 
a repo that I create or own.

In itself, it's not a big problem that GNU ELPA uses a different 
workflow from MELPA, but, speaking for myself, it would be good if 
the ELPA README (or some other document) would contain a few 
paragraphs explaining the differences and would cover the steps 
involved in such a way that they make sense for someone with a 
less-than-stellar understanding of git.

Anyway, just my two €0.02.


-- 
Joost Kremers
Life has its moments

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > This is starting to zero in on a specific activity where informing the user
  > about the ELPA process would be appropriate.

"The ELPA process" gives the wrong idea.  This is the process for making
a package that CAN easily be integrated into Emacs, or ELPA.
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[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's a misleading way to think about it. If every major facility on a
  > machine was nonchalant about some random once-per-week notification, you
  > could potentially have several to hundreds per day.

There is no reason to worry about an implausible extrapolation of what
we are planning.

It's not just unlikely, it's mathematically implausible because
it assumes the person uses thousands of major facilities.
I doubt I use even a hundred.

Anyway, it will be easy to turn off these notices if you want to.
So the problem is imaginary.

In fact, people don't mind notices so much anyway.

Some programs offer hints each time they start, and you have to click
to make them go away.  For instance, Audacity does this.  It offers
a way to turn them off, but I never bothered to do that.

I don't think this issue amounts to a real problem.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[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's an ill-defined task, at best.

That's not a problem.  We're talking about communicating an idea to
people.

				       Which files, when, where to store the 
  > last message date? Will it distract the user from writing code (will it 
  > make the buffer contents jump)?

These are technical details that I am sure we will handle.  Since
you don't need to do the work, don't make a fuss about it.

There will be a setting to turn off the messages.  Once you know the
point we want to show people, shut off the message if you like.

				    How will it deal with personal 
  > configurations (which people have no intention of publishing), and will 
  > it continue to show those messages even after the package is published?

I see a misunderstanding.  This is not a question of "dealing with"
individual packages one by one.  The goal is to make sure people are
aware of the importance of getting legal papers as they accept
contributions.

The idea of doing this in specific situations (maybe editing Elisp
files, maybe editing package files) is to identify the people it is
useful to inform: people who are developing Emacs packages.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Yuri Khan]

On Tue, Jul 11, 2017 at 6:45 PM, Richard Stallman <rms@gnu.org> wrote:

> I see a misunderstanding.  This is not a question of "dealing with"
> individual packages one by one.  The goal is to make sure people are
> aware of the importance of getting legal papers as they accept
> contributions.

I’d like to voice several ideas related to attracting users and
developers and raising awareness of the Emacs contribution policy.

1. Emacs has a web site at <https://www.gnu.org/software/emacs/>. At
the same time, the emacs.org domain name, although under control of
FSF, stands unused.

**Suggestion:** Make https://emacs.org/ the official site of Emacs. Or
at least set up redirection from ^https://emacs\.org/\(.*\)$ to
https://www.gnu.org/software/emacs/\1.


2. The Emacs web site has a two-line menu, but no “Contributing” item
in that menu. One has to go through “Documentation & Support”, then
the Reporting Bugs subheading, then actually read the first paragraph
of that section, which sends them to the CONTRIBUTE file, which is a
literal plain text copy of that file from the source tree. That file
goes on to tell a lot of technical things about the development
process, but does not mention copyright assignment paperwork except in
passing in the section about commit messages.

**Suggestions:**

* Add an actual “Contributing” page to the Emacs web site, and a link
to that page to the site menu.

* That page should be an attractively formatted web page, not a plain
text file with Org markup.

* It should be reasonably short, have clear structure, and might link
to sub-pages for detailed explanations.

* Copyright assignment should be discussed early in that page. It
should explain the benefit of copyright assignment concisely,
convincingly, and *in terms of the contributor*. (As in, “If you
assign copyright to us, we will defend it on your behalf against evil
corporations that are out there to parasitize on your work”.)
Alternatives should also be explored, with explanations how choosing a
different path is bad for *the contributor* as well as the community.


3. The ELPA site, <http://elpa.gnu.org/>, says this near the bottom of
the home page: “To contribute new packages refer to the README”, where
README is a link to another Org-like plain text file that discusses
technicalities without mentioning copyright paperwork.

**Suggestions:**

* Make that README an attractively formatted, well-structured web page
or a collection of pages.

* Explain copyright assignment and alternatives there, too.


4. The MELPA site is not your competitor. It is there to fill a need,
both for users and package authors.

**Suggestion:** Place a short notice there, to the effect of “Wouldn’t
it be great if your package were accepted into ELPA? Consider this…”
with a short explanation of the prerequisites and a link to the ELPA
site.

Re: Adding advisory notification for non-ELPA package.el downloads

[John Wiegley]

>>>>> "YK" == Yuri Khan <yuri.v.khan@gmail.com> writes:

KY> 1. Emacs has a web site at <https://www.gnu.org/software/emacs/>. At the
KY> same time, the emacs.org domain name, although under control of FSF,
KY> stands unused.

That's excellent; I didn't realize Toby had given up the domain to the FSF! We
should definitely put it to use.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Adding advisory notification for non-ELPA package.el downloads

[Yuri Khan]

On Wed, Jul 12, 2017 at 1:01 AM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> "YK" == Yuri Khan <yuri.v.khan@gmail.com> writes:
>
> KY> 1. Emacs has a web site at <https://www.gnu.org/software/emacs/>. At the
> KY> same time, the emacs.org domain name, although under control of FSF,
> KY> stands unused.
>
> That's excellent; I didn't realize Toby had given up the domain to the FSF! We
> should definitely put it to use.

Okay, I was unaware that the transfer happened less than a month ago.
Google cache says emacs.org was under control of John Toby Knudsen on
2017-05-13.

In that case, I understand why emacs.org is not the official site of
Emacs, but the suggestion still stands.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > **Suggestion:** Make https://emacs.org/ the official site of Emacs.

To do that, we would have to set up so the GNU Project and Emacs developers
can edit it.  THat would take our sysadmins more time than we want to
lose from other work.

									Or
  > at least set up redirection from ^https://emacs\.org/\(.*\)$ to
  > https://www.gnu.org/software/emacs/\1.

That would be easy.  Does anyone see a problem with this?  If not,
I will ask the sysadmins to do it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > 2. The Emacs web site

You mean /software/emacs, right?  I would call that a directory,
not a web site.

			  has a two-line menu, but no “Contributing” item
  > in that menu. One has to go through “Documentation & Support”, ...

These suggestions make sense to me.

Nicolas Petton maintains those pages, I believe.
If he likes these ideas, would people like to help him implement them?

  > 3. The ELPA site, <http://elpa.gnu.org/>, says this near the bottom of
  > the home page: “To contribute new packages refer to the README”, where
  > README is a link to another Org-like plain text file that discusses
  > technicalities without mentioning copyright paperwork.

  > **Suggestions:**

  > * Make that README an attractively formatted, well-structured web page
  > or a collection of pages.

  > * Explain copyright assignment and alternatives there, too.

These are good ideas.  Don't the Emacs maintainers maintain that site?

  > 4. The MELPA site is not your competitor. It is there to fill a need,
  > both for users and package authors.

I will be talking with them when I'm sure of what to say.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > In itself, it's not a big problem that GNU ELPA uses a different 
  > workflow from MELPA, but, speaking for myself, it would be good if 
  > the ELPA README (or some other document) would contain a few 
  > paragraphs explaining the differences and would cover the steps 
  > involved in such a way that they make sense for someone with a 
  > less-than-stellar understanding of git.

I agree.  I encourage the people who manage ELPA to do this.

  > With MELPA, I put my code in a publicly accessible repo 
  > that I create myself, on a service of my own choosing,
  > and then tell MELPA where to look for it.

Is there any reason we should not do this on ELPA?

If the repo that ELPA copies from is fully under the control
of the developer of that package, I don't see that it
matters greatly whether the developer installs
changes into that package via ELPA directly, or into some
other repo which then gets copied wholesale to ELPA.

ELPA managers, does the act of installing directly into ELPA give us
an opportunity to make sure something is being handled right?

  > (in my case Github)

If only the developer uses that repo system, we don't
have to be concerned with what system it is.

But if other contributors are going to be directed
to that other repo system, we would want it not to be Github.
(See https://gnu.org/software/repo-criteria.html.)


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Stefan Monnier]

> ELPA managers, does the act of installing directly into ELPA give us
> an opportunity to make sure something is being handled right?

I think the difference is pretty significant, yes.
If we pull from other repositories:
- maintainers of the package will not be reminded that the package is
  also in GNU ELPA (and should hence adhere to a copyright assignment
  policy).

- While the repository may be under the sole control of the package
  maintainer when the package is added to GNU ELPA, that can and will
  evolve over time, completely outside of our control.

- There is no easy way for us (Emacs maintainers) to install fixes to
  adapt to changes in Emacs.  More specifically, it needs to be done by
  hand package-by-package, by submitting a patch and hoping the upstream
  maintainer is still listening.

- Handling old unmaintained packages is more trouble.

- We won't get elpa-diffs email, where we have the opportunity to give
  advice on coding style and have a minimum amount of review of the code
  we end up distributing.

Basically it would turn GNU ELPA into a pure distribution site, with
very little control over what we distribute, including the copyright
status of what we distribute.

The only real difference with MELPA would be that we could check that
each file comes with the proper GPLv3+ blurb.  Not sure if it would be
worth the trouble.


        Stefan

Re: Adding advisory notification for non-ELPA package.el downloads

[Yuri Khan]

On Wed, Jul 12, 2017 at 5:57 AM, 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. ]]]
>
>   > **Suggestion:** Make https://emacs.org/ the official site of Emacs.
>
> To do that, we would have to set up so the GNU Project and Emacs developers
> can edit it.  THat would take our sysadmins more time than we want to
> lose from other work.

That doesn’t have to be hard. Likely, both sites can be served by the
same machine from the same directory.

Assuming the whole //gnu.org/software/emacs subtree is served as
static files and contains no relative links outside that subtree:

* Add a DNS entry for emacs.org pointing to the same IP address as gnu.org.

* On that machine, add a virtual host named "emacs.org" to the web
server configuration, rooted at the software/emacs subdirectory of the
main site root.

Functionally, that is all; for search engine optimization purposes, it
may be desirable to also configure both locations to add an HTTP
header of the form

Link: <https://emacs.org/{subpath}>; rel="canonical"

so that search engines know the two locations are equivalent and don’t
show both in search results.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > Assuming the whole //gnu.org/software/emacs subtree is served as
  > static files and contains no relative links outside that subtree:

  > * Add a DNS entry for emacs.org pointing to the same IP address as gnu.org.

  > * On that machine, add a virtual host named "emacs.org" to the web
  > server configuration, rooted at the software/emacs subdirectory of the
  > main site root.

I will suggest doing that.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > - maintainers of the package will not be reminded that the package is
  >   also in GNU ELPA (and should hence adhere to a copyright assignment
  >   policy).

  > - While the repository may be under the sole control of the package
  >   maintainer when the package is added to GNU ELPA, that can and will
  >   evolve over time, completely outside of our control.

  > - There is no easy way for us (Emacs maintainers) to install fixes to
  >   adapt to changes in Emacs.  More specifically, it needs to be done by
  >   hand package-by-package, by submitting a patch and hoping the upstream
  >   maintainer is still listening.

  > - Handling old unmaintained packages is more trouble.

One way to prevent these problems is by insisting they give the Emacs
maintainers administrative access to the real package repository.
Then we could install notices about legal papers, take action if
non-signers have write access, install fixes, and handling old
unmaintained packages with little more trouble than they are now.


  > - We won't get elpa-diffs email, where we have the opportunity to give
  >   advice on coding style and have a minimum amount of review of the code
  >   we end up distributing.

That would be a loss, but can we install another system to send diff
mail?  It could operate on a clone of the real package repository.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Nicolas Petton]

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

Richard Stallman <rms@gnu.org> writes:

> These suggestions make sense to me.
>
> Nicolas Petton maintains those pages, I believe.
> If he likes these ideas, would people like to help him implement them?

They also make sense to me, I could implement them if people think they
make sense.

>   > 3. The ELPA site, <http://elpa.gnu.org/>, says this near the bottom of
>   > the home page: “To contribute new packages refer to the README”, where
>   > README is a link to another Org-like plain text file that discusses
>   > technicalities without mentioning copyright paperwork.
>
>   > **Suggestions:**
>
>   > * Make that README an attractively formatted, well-structured web page
>   > or a collection of pages.
>
>   > * Explain copyright assignment and alternatives there, too.
>
> These are good ideas.  Don't the Emacs maintainers maintain that site?

I revamped this website some months ago, and I also think it's a good
idea.

Cheers,
Nico

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

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > >   > **Suggestions:**
  > >
  > >   > * Make that README an attractively formatted, well-structured web page
  > >   > or a collection of pages.
  > >
  > >   > * Explain copyright assignment and alternatives there, too.

Who would like to implement these suggested communications in ELPA
itself?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Jean Louis]

On Sun, Jul 09, 2017 at 08:50:53AM +1000, Tim Cross wrote:
> Totally agree. If we want people to 'do the
> right thing', we have to make it as easy as
> possible. If things are as bad as Clement
> indicates, nagging users will have little impact
> and what impact it does have will likely be
> negative.
> 
> WRT Richard's suggestion about a weekly notice
> when editing elisp files - not sure if it should
> be all elisp files or whether it should be
> restricted to files like *-pkg.el that are part
> of package.el packages? I do a fair amount of
> elisp which does not use package.el, so notices
> about ELPA are just annoying. Maybe we could
> modify package.el to make it mandatory for
> packages to include a file/statement which
> maintainers must include which requires them to
> acknowledge the benefits of free software and
> the disadvantages of non-ELPA repositories.

What developers of GNU Emacs could do is to have
yet another HELP menu item, "How to contribute",
where the full instructions and updated file may
be displayed in the manner of Emacs News or "How
to display bugs".

The menu "How to contribute" should be there all
the time.

I do not think that users editing *.el files shall
be bothered.

But they can be bothered on the Splash screen
which could link to "How to contribute" file and
on other screns, there could be link to "How to
contribute".

Same links could explain the problem with
copyrights and proper assignments.

And the same section could be included in Emacs
Lisp and Emacs manuals.

That way larger number of people would understand
that they can directly contribute and they would
have not just a short notice, but full
explanation.

Jean Louis

Re: Adding advisory notification for non-ELPA package.el downloads

[Nicolas Petton]

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

Richard Stallman <rms@gnu.org> writes:

> Who would like to implement these suggested communications in ELPA
> itself?

What do you mean by "in ELPA itself"?

Nico

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

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > > Who would like to implement these suggested communications in ELPA
  > > itself?

  > What do you mean by "in ELPA itself"?

Someone proposed making these changes in ELPA, in its web pages, and
repo.  They would be changes in ELPA itself.

Would someone like to implement them (in ELPA)?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Nicolas Petton]

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

Richard Stallman <rms@gnu.org> writes:

>   > > Who would like to implement these suggested communications in ELPA
>   > > itself?
>
>   > What do you mean by "in ELPA itself"?
>
> Someone proposed making these changes in ELPA, in its web pages, and
> repo.  They would be changes in ELPA itself.
>
> Would someone like to implement them (in ELPA)?

I can add a web page, but I'd need help with the content.

Cheers,
Nico

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Paul Rankin]

> The goal here is to avoid having packages end up in the situation
> Magit is in now.

I think there has already been plenty of discussion of your
characterisation of Magit as a bad situation as being off-base.

> They get into that situation because developers accept contributions
> without thinking of legal papers.  They get contributions from one
> person, then another, then another 50 people, then another 50.
>
> The way to avoid this is by showing people what the situation is like
> and how they can avoid it.  We need to educate the whole Emacs Lisp
> development community.

All of this is based on the assumption that people *want* to assign
their copyright to FSF. This is not the case. I develop a couple of
packages and I would never assign my copyright. Copyright isn't just
some legal nuisance, to many people it's something pretty sacred. It's a
stamp that says "I made this, I contributed this to the world." The
notion that I should be "reminded" or "educated" that in developing
Emacs packages that my goal should be to assign my copyright to FSF is
beyond insulting.

From my perspective, the only situation that needs attention is the
FSF's position that any code with any real value should be assigned to
the FSF, and that everyone who doesn't do this is making problems.

> Here's an idea that might be better targeted.
>
> The idea is to display a notice when the user edits a file in Emacs
> Lisp mode (other than .emacs).  The code could avoid displaying the
> notice more than once per week -- using a timestamp for the last time
> it was displayed.
>
> To avoid these problems is important.  By comparison, this occasional
> small annoyance is a small matter.

These are only problems from the FSF's perspective. Most other people
don't care, so your plan would just annoy people.

Re: Adding advisory notification for non-ELPA package.el downloads

[Clément Pit-Claudel]

On 2017-07-20 14:29, Paul Rankin wrote:
> Copyright isn't just some legal nuisance, to many people it's
> something pretty sacred. It's a stamp that says "I made this, I
> contributed this to the world."

Isn't that what the "Author" header is for in ELisp files?
Authorship is pretty independent from copyright: transferring copyright does not change the authorship situation.
 
Clément.

Re: Adding advisory notification for non-ELPA package.el downloads

[Eli Zaretskii]

> From: Paul Rankin <hello@paulwrankin.com>
> Date: Thu, 20 Jul 2017 22:29:28 +1000
> Cc: emacs-devel@gnu.org
> 
> All of this is based on the assumption that people *want* to assign
> their copyright to FSF. This is not the case. I develop a couple of
> packages and I would never assign my copyright. Copyright isn't just
> some legal nuisance, to many people it's something pretty sacred. It's a
> stamp that says "I made this, I contributed this to the world." The
> notion that I should be "reminded" or "educated" that in developing
> Emacs packages that my goal should be to assign my copyright to FSF is
> beyond insulting.

I think you might misunderstand the nature and the essence of the
copyright assignment: it doesn't in any way diminish the author's
rights on his/her code.  Here's a direct citation from

 https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf

  Sometimes contributors are concerned about giving up rights to their
  work. As the assignment is a gift to the free software community,
  they don't want it to come at the expense of having flexibility in
  the use of their own code. Thus, we grant back to contributors a
  license to use their work as they see fit. This means they are free
  to modify, share, and sublicense their own work under terms of their
  choice. This enables contributors to redistribute their work under
  another free software license. While this technically also permits
  distributing their work under a proprietary license, we hope they
  won't.

I can confirm that every one of my assignments I got back signed by
the FSF includes a specific clause about the above rights granted back
to me.

I suggest a reading of that page, it has additional useful
information.

Re: Adding advisory notification for non-ELPA package.el downloads

[Jean-Christophe Helary]

> On Jul 20, 2017, at 22:42, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Paul Rankin <hello@paulwrankin.com>
>> Date: Thu, 20 Jul 2017 22:29:28 +1000
>> Cc: emacs-devel@gnu.org
>> 
>> All of this is based on the assumption that people *want* to assign
>> their copyright to FSF. This is not the case. I develop a couple of
>> packages and I would never assign my copyright. Copyright isn't just
>> some legal nuisance, to many people it's something pretty sacred. It's a
>> stamp that says "I made this, I contributed this to the world." The
>> notion that I should be "reminded" or "educated" that in developing
>> Emacs packages that my goal should be to assign my copyright to FSF is
>> beyond insulting.
> 
> I think you might misunderstand the nature and the essence of the
> copyright assignment: it doesn't in any way diminish the author's
> rights on his/her code.  Here's a direct citation from
> 
> https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf

Maybe such explanations should be made more visible on the FSF page.

Jean-Christophe 

Re: Adding advisory notification for non-ELPA package.el downloads

[Paul Rankin]

On Thu, 20 Jul 2017, at 11:42 PM, Eli Zaretskii wrote:
> I think you might misunderstand the nature and the essence of the
> copyright assignment: it doesn't in any way diminish the author's
> rights on his/her code.  Here's a direct citation from
> 
>  https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf
> 
>   Sometimes contributors are concerned about giving up rights to their
>   work. As the assignment is a gift to the free software community,
>   they don't want it to come at the expense of having flexibility in
>   the use of their own code. Thus, we grant back to contributors a
>   license to use their work as they see fit. This means they are free
>   to modify, share, and sublicense their own work under terms of their
>   choice. This enables contributors to redistribute their work under
>   another free software license. While this technically also permits
>   distributing their work under a proprietary license, we hope they
>   won't.
> 
> I can confirm that every one of my assignments I got back signed by
> the FSF includes a specific clause about the above rights granted back
> to me.

Eli you've missed the point completely.

Re: Adding advisory notification for non-ELPA package.el downloads

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@gmail.com>
> Date: Thu, 20 Jul 2017 22:49:21 +0900
> Cc: Paul Rankin <hello@paulwrankin.com>, rms@gnu.org, emacs-devel@gnu.org
> 
> > I think you might misunderstand the nature and the essence of the
> > copyright assignment: it doesn't in any way diminish the author's
> > rights on his/her code.  Here's a direct citation from
> > 
> > https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf
> 
> Maybe such explanations should be made more visible on the FSF page.

I think they should be added to this page:

  https://www.gnu.org/licenses/why-assign.en.html

Re: Adding advisory notification for non-ELPA package.el downloads

[Eli Zaretskii]

> From: Paul Rankin <hello@paulwrankin.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Fri, 21 Jul 2017 00:01:48 +1000
> 
> On Thu, 20 Jul 2017, at 11:42 PM, Eli Zaretskii wrote:
> > I think you might misunderstand the nature and the essence of the
> > copyright assignment: it doesn't in any way diminish the author's
> > rights on his/her code.  Here's a direct citation from
> > 
> >  https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf
> > 
> >   Sometimes contributors are concerned about giving up rights to their
> >   work. As the assignment is a gift to the free software community,
> >   they don't want it to come at the expense of having flexibility in
> >   the use of their own code. Thus, we grant back to contributors a
> >   license to use their work as they see fit. This means they are free
> >   to modify, share, and sublicense their own work under terms of their
> >   choice. This enables contributors to redistribute their work under
> >   another free software license. While this technically also permits
> >   distributing their work under a proprietary license, we hope they
> >   won't.
> > 
> > I can confirm that every one of my assignments I got back signed by
> > the FSF includes a specific clause about the above rights granted back
> > to me.
> 
> Eli you've missed the point completely.

Maybe so, but then how about explaining what I missed?

From my POV, you expressed a concern about giving up the rights for
your code, and I pointed out that by assigning you don't give up any
rights.  Given that Clément pointed out the "Author" and/or "Written
by" records in the sources, what other concerns remain?

Re: Adding advisory notification for non-ELPA package.el downloads

[John Wiegley]

>>>>> "PR" == Paul Rankin <hello@paulwrankin.com> writes:

PR> Eli you've missed the point completely.

Paul, comments like these are neither helpful, nor conducive to fruitful
conversation. Please specify -- for the other readers -- what was missed, or
refrain from simply stating that another person is wrong on the Internet.

Thanks,
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Adding advisory notification for non-ELPA package.el downloads

[Paul Rankin]

On Fri, 21 Jul 2017, at 12:20 AM, Eli Zaretskii wrote:
> > From: Paul Rankin <hello@paulwrankin.com>
> > Cc: rms@gnu.org, emacs-devel@gnu.org
> > Date: Fri, 21 Jul 2017 00:01:48 +1000
> > 
> > On Thu, 20 Jul 2017, at 11:42 PM, Eli Zaretskii wrote:
> > > I think you might misunderstand the nature and the essence of the
> > > copyright assignment: it doesn't in any way diminish the author's
> > > rights on his/her code.  Here's a direct citation from
> > > 
> > >  https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf
> > > 
> > >   Sometimes contributors are concerned about giving up rights to their
> > >   work. As the assignment is a gift to the free software community,
> > >   they don't want it to come at the expense of having flexibility in
> > >   the use of their own code. Thus, we grant back to contributors a
> > >   license to use their work as they see fit. This means they are free
> > >   to modify, share, and sublicense their own work under terms of their
> > >   choice. This enables contributors to redistribute their work under
> > >   another free software license. While this technically also permits
> > >   distributing their work under a proprietary license, we hope they
> > >   won't.
> > > 
> > > I can confirm that every one of my assignments I got back signed by
> > > the FSF includes a specific clause about the above rights granted back
> > > to me.
> > 
> > Eli you've missed the point completely.
> 
> Maybe so, but then how about explaining what I missed?
> 
> From my POV, you expressed a concern about giving up the rights for
> your code, and I pointed out that by assigning you don't give up any
> rights.  Given that Clément pointed out the "Author" and/or "Written
> by" records in the sources, what other concerns remain?

Copyright is not merely functional, and you're reducing it to even
lesser functional purposes by arguing that given assigning copyright to
the FSF retains the subset of functional purposes of copyright that are
important to you, then they are effectively the same and should be
treated the same for everyone. Copyright is not its function, rather its
functions arise as the manifestations of the importance we see in
authorship as ownership. That's a symbolic importance, and while that
may not mean much to you, it's where all the functional purposes above
come from. Owning a thing, and having rights to that thing as if you
owned it, are not the same thing.

Re: Adding advisory notification for non-ELPA package.el downloads

[Jean-Christophe Helary]

> On Jul 20, 2017, at 23:36, Paul Rankin <hello@paulwrankin.com> wrote:
> 
> Owning a thing, and having rights to that thing as if you
> owned it, are not the same thing.

My understanding is that assigning copyright to the FSF means that you own your thing and allow the FSF to own a copy. It is not at all what you describe.

For all practical purposes, what you describe above is two legally/symbolically/philosophically equivalent things.

But I may be wrong...

Jean-Christophe 

Re: Adding advisory notification for non-ELPA package.el downloads

[Jean-Christophe Helary]

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


> On Jul 20, 2017, at 23:17, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>>> I think you might misunderstand the nature and the essence of the
>>> copyright assignment: it doesn't in any way diminish the author's
>>> rights on his/her code.  Here's a direct citation from
>>> 
>>> https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf <https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf>
>> 
>> Maybe such explanations should be made more visible on the FSF page.
> 
> I think they should be added to this page:
> 
>  https://www.gnu.org/licenses/why-assign.en.html <https://www.gnu.org/licenses/why-assign.en.html>
Is there a bug tracker on the FSF site where such issues can be registered ?

Jean-Christophe 

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@gmail.com>
> Date: Thu, 20 Jul 2017 23:48:02 +0900
> Cc: hello@paulwrankin.com,
>  rms@gnu.org,
>  emacs-devel@gnu.org
> 
>  https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf
> 
>  Maybe such explanations should be made more visible on the FSF page.
> 
>  I think they should be added to this page:
> 
>  https://www.gnu.org/licenses/why-assign.en.html
> 
> Is there a bug tracker on the FSF site where such issues can be registered ?

Since Richard is reading this, I think you have all the audience you
need ;-)

Re: Adding advisory notification for non-ELPA package.el downloads

[Eli Zaretskii]

> From: Paul Rankin <hello@paulwrankin.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Fri, 21 Jul 2017 00:36:40 +1000
> 
> Copyright is not merely functional, and you're reducing it to even
> lesser functional purposes by arguing that given assigning copyright to
> the FSF retains the subset of functional purposes of copyright that are
> important to you, then they are effectively the same and should be
> treated the same for everyone. Copyright is not its function, rather its
> functions arise as the manifestations of the importance we see in
> authorship as ownership. That's a symbolic importance, and while that
> may not mean much to you, it's where all the functional purposes above
> come from. Owning a thing, and having rights to that thing as if you
> owned it, are not the same thing.

AFAIK, the original author still owns the code he/she wrote, even
after the assignment, and the authorship information is not lost by
assigning the copyright.  If that is true, then your concerns are
based on misunderstandings.

I would like to stress that it's IMO okay not to agree to assign
copyright, for whatever reasons.  We just need to make sure that
people don't make these decisions based on misconceptions about what
the assignment means, legally and practically, for the original author
of the code.  Once the decision is an informed one, it's eventually
the call of each one of us whether to assign or not.

Re: Adding advisory notification for non-ELPA package.el downloads

[Paul Rankin]

On Fri, 21 Jul 2017, at 12:47 AM, Jean-Christophe Helary wrote:
> 
> > On Jul 20, 2017, at 23:36, Paul Rankin <hello@paulwrankin.com> wrote:
> > 
> > Owning a thing, and having rights to that thing as if you
> > owned it, are not the same thing.
> 
> My understanding is that assigning copyright to the FSF means that you own your thing and allow the FSF to own a copy. It is not at all what you describe.

As it stands in the various international copyright treaties, assigning
copyright to another person or entity means assigning ownership. Owning
a copy is provided through a licence, e.g. owning Iron Man on DVD.

> For all practical purposes, what you describe above is two
> legally/symbolically/philosophically equivalent things.

To me this is feels internally contradictory.... I don't think practical
purposes can be taken to provide symbolic equivalency.... but, the whole
issue I'm trying to get across is with reducing copyright to its
practical purpose (or a subset thereof). If we are reducing all things
to their practical purposes, then yes, of course owning a thing and
having all the same rights to that thing can be called equivalent. But
to reframe my earlier point, the practical purposes of a thing do not
entail the thing.

Re: Adding advisory notification for non-ELPA package.el downloads

[Stephen Berman]

On Thu, 20 Jul 2017 22:29:28 +1000 Paul Rankin <hello@paulwrankin.com> wrote:

> From my perspective, the only situation that needs attention is the
> FSF's position that any code with any real value should be assigned to
> the FSF, and that everyone who doesn't do this is making problems.

I don't recall ever hearing or reading such a position from anyone
associated with the FSF.  What is your source for this statement?

Steve Berman

Re: Adding advisory notification for non-ELPA package.el downloads

[Paul Rankin]

On Fri, 21 Jul 2017, at 01:08 AM, Eli Zaretskii wrote:
> > From: Paul Rankin <hello@paulwrankin.com>
> > Cc: rms@gnu.org, emacs-devel@gnu.org
> > Date: Fri, 21 Jul 2017 00:36:40 +1000
> > 
> > Copyright is not merely functional, and you're reducing it to even
> > lesser functional purposes by arguing that given assigning copyright to
> > the FSF retains the subset of functional purposes of copyright that are
> > important to you, then they are effectively the same and should be
> > treated the same for everyone. Copyright is not its function, rather its
> > functions arise as the manifestations of the importance we see in
> > authorship as ownership. That's a symbolic importance, and while that
> > may not mean much to you, it's where all the functional purposes above
> > come from. Owning a thing, and having rights to that thing as if you
> > owned it, are not the same thing.
> 
> AFAIK, the original author still owns the code he/she wrote, even
> after the assignment, and the authorship information is not lost by
> assigning the copyright.  If that is true, then your concerns are
> based on misunderstandings.

I'm sorry to disagree with you, but no, if you assign copyright to
someone else, you no longer own the work. Hence why FSF licences the
work back to you.

It may be the case that the FSF is entering into joint ownership
agreements with authors, but going off the passage you quoted before, I
don't think that's the case. Such agreements would also make the FSF's
legal standing very difficult if they ever needed to defend against
infringement.

The authorship information (or "moral rights") is not really what I'm
talking about, but specifically copyright ownership.

> I would like to stress that it's IMO okay not to agree to assign
> copyright, for whatever reasons.  We just need to make sure that
> people don't make these decisions based on misconceptions about what
> the assignment means, legally and practically, for the original author
> of the code.  Once the decision is an informed one, it's eventually
> the call of each one of us whether to assign or not.

I agree. But let's make sure it really is informed and people know
that assigning copyright means assigning ownership. We can argue about
what it really means to "own" something, but I doubt anyone wants to
hear that.

I didn't really want to get into a debate about *why* I did not want to
assign copyright, rather just that there are people out there who don't,
for good reasons, and so decisions about Emacs development maybe should
not be made based on the perspective that everyone would assign
copyright if they only were adequately informed.

Re: Adding advisory notification for non-ELPA package.el downloads

[Radon Rosborough]

> All of this is based on the assumption that people *want* to assign
> their copyright to FSF.

I think this is possibly the most important point here. Not everyone
agrees about these sorts of issues.

Some people don't want to assign copyright to the FSF. Some people
don't want to put their packages on GNU ELPA. Some people don't want
to license their code under the GPL. And we have to respect these
feelings. If we try to *force* people, then that will just make them
angry and liable to spread exaggerated criticism.

In my opinion, the only reasonable way to make more people assign
copyright to the FSF is to make this process as easy as possible. The
appropriate response to people preferring MELPA over GNU ELPA is to
make GNU ELPA just as feature-rich and easy to use as MELPA.
Displaying a notice message in Emacs about these things will annoy
people. Not me, personally; I'll just turn it off. But I'm not
important: the people who are important are the people who don't care
about this stuff, and will just see the message as a nuisance that
turns them off Emacs. In other words, the other 95% of developers who
do not use Emacs but whom we want to convince to use Emacs.

I might have my own opinions about these issues, but I care much, much
more about Emacs and other free software becoming more widely used.
Pragmatically, the only way that this will happen is if they become
better alternatives to non-free software. Putting the GPL on them is
not sufficient. If someone advocating non-free software is
inconvenienced by the GPL, then that will just push them even farther
away. Likewise, if someone receives a message telling them how they
should manage the copyright for their project, that will also push
them farther away, if they happen to disagree with the FSF's stance on
copyright assignment.

That's why these issues about making contributions easy and using
modern development tooling are really important. Regardless of
anyone's personal feelings on the matter, it's a fact that software
projects which have kept a closer eye on these things have seen more
success and adoption. I'd love to see Emacs overtake Atom but that
won't happen unless we stop being so insular and distrusting of the
"outside world". RMS, I've seen you say things like "we need to make
it clear that the 'Emacs ecosystem' is not part of Emacs" and "there
is a big ethical problem with melpa.org" (I'm quoting from memory,
please correct me if I'm wrong). You may perfectly well be right, but
that doesn't mean it's the right message to send: "We are right; you
are wrong; please do it our way instead or you shouldn't be a part of
our community."

To reiterate, the most important thing to do is to bring the FSF way
into feature and easy-of-use parity with third-party offerings. That
is what will bring success, in the long run.

Best regards,
Radon Rosborough

Re: Adding advisory notification for non-ELPA package.el downloads

[Eli Zaretskii]

> From: Paul Rankin <hello@paulwrankin.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Fri, 21 Jul 2017 01:58:29 +1000
> 
> > AFAIK, the original author still owns the code he/she wrote, even
> > after the assignment, and the authorship information is not lost by
> > assigning the copyright.  If that is true, then your concerns are
> > based on misunderstandings.
> 
> I'm sorry to disagree with you, but no, if you assign copyright to
> someone else, you no longer own the work. Hence why FSF licences the
> work back to you.

Yes, and after that, I still have my rights.  The "grant back" part is
right there in the assignment agreement, it is not something separate.

> > I would like to stress that it's IMO okay not to agree to assign
> > copyright, for whatever reasons.  We just need to make sure that
> > people don't make these decisions based on misconceptions about what
> > the assignment means, legally and practically, for the original author
> > of the code.  Once the decision is an informed one, it's eventually
> > the call of each one of us whether to assign or not.
> 
> I agree. But let's make sure it really is informed and people know
> that assigning copyright means assigning ownership. We can argue about
> what it really means to "own" something, but I doubt anyone wants to
> hear that.

If you can still work on your code after the assignment, and can
redistribute it at will under any conditions you like, then how is
that different from ownership?  If it looks like duck, walks like
duck, and quacks like duck, then how can it be anything other than a
duck?

> I didn't really want to get into a debate about *why* I did not want to
> assign copyright, rather just that there are people out there who don't,
> for good reasons, and so decisions about Emacs development maybe should
> not be made based on the perspective that everyone would assign
> copyright if they only were adequately informed.

You make it sound like people who sign the papers do that only because
they are uninformed, which is certainly not true.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > These are only problems from the FSF's perspective.

Emacs is part of the GNU project, so it is based on the FSF's values
and views.  If you start a project, you can run it as you wish.

  > All of this is based on the assumption that people *want* to assign
  > their copyright to FSF. This is not the case. I develop a couple of
  > packages and I would never assign my copyright.

This list is for discussion about Emacs development.  Correct me if
I'm mistaken, but it sounds like you're saying you are unwilling to
contribute code to Emacs.

You are under no obligation to contribute, but if you aren't going to,
the value of what you say here is somewhat reduced.
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Nikolaus Rath]

On Jul 20 2017, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Paul Rankin <hello@paulwrankin.com>
>> Cc: rms@gnu.org, emacs-devel@gnu.org
>> Date: Fri, 21 Jul 2017 01:58:29 +1000
>> 
>> > AFAIK, the original author still owns the code he/she wrote, even
>> > after the assignment, and the authorship information is not lost by
>> > assigning the copyright.  If that is true, then your concerns are
>> > based on misunderstandings.
>> 
>> I'm sorry to disagree with you, but no, if you assign copyright to
>> someone else, you no longer own the work. Hence why FSF licences the
>> work back to you.
>
> Yes, and after that, I still have my rights.

But not ownership. Owership entails you to certain rights, but having
these rights doesn't give you ownership. 

> If you can still work on your code after the assignment, and can
> redistribute it at will under any conditions you like, then how is
> that different from ownership?

There's more to ownership that that. Incidentally, this is the reason
why the FSF would like to have it.

> If it looks like duck, walks like duck, and quacks like duck, then how
> can it be anything other than a duck?

By that argument, the FSF should have no need for copyright assignments
in the first place. The license should be enough.


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: Adding advisory notification for non-ELPA package.el downloads

[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 they should be added to this page:

  >   https://www.gnu.org/licenses/why-assign.en.html

I will do that.  Thanks.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[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 might have my own opinions about these issues, but I care much, much
  > more about Emacs and other free software becoming more widely used.

In the GNU Project, our goal is to give freedom to users to the
maximum possible extent.  Delivering freedom to more people takes
priority over having more users.



-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[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 can add a web page, but I'd need help with the content.

Would anyone like to help Nicolas implement the ELPA documentation
and guidance suggestions?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Radon Rosborough]

> Delivering freedom to more people takes priority over having more users.

Have you considered that by -- in the short run -- being less
insistent on having everything be 100% free of the "taint" of non-free
software, we might actually be able to mount a better defense against
non-free software advocates (by providing better software), and
thereby deliver freedom to more people in the long run?

But we can agree to disagree on that point. What's more important,
IMO, is avoiding alienating the rest of the community (e.g. MELPA,
people who develop packages outside of the FSF system), since they are
much larger and more powerful than the comparatively small number of
people working on GNU ELPA and Emacs core.

I think that many people have gotten the impression that "in the GNU
Project, delivering freedom to more people takes priority over having
a healthy community". I really don't think that's the case, but you
don't have to look very far to see people drawing such conclusions, as
a result of (for example) some rather heated exchanges on this mailing
list.

So I'll just reiterate that I think the only effective approach is
going to be improving the process of and community around contributing
to GNU ELPA and Emacs, and that if we don't do this first, attempts to
advertise them will only backfire.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > Have you considered that by -- in the short run -- being less
  > insistent

People have urged this on me dozens of times, so I have had plenty
of opportunity to think about the question.

As you have noticed, most of the user community hardly thinks about
freedom.  It's our job to teach people that freedom is very important.
The way to do that is by visibly giving it great importance ourselves.

If we stop, no one else will do this work for us.  In the long run,
it would be a great setback for freedom.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.