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.

Improving GNU ELPA (was: Adding advisory notification for non-ELPA package.el downloads)

[Stefan Monnier]

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

While most of the above only applies to the case where you put your
package as a "subtree" rather than an "external", I can't say that the
criticism is unfair.

And I indeed think that if we want to expand the use of ELPA, the
proverbial someone should first work on the elpa.gnu.org infrastructure.
It's all a simple matter of writing scripts, really, so help is very
welcome.

I know of the following:
- when someone commits to elpa.git we get an elpa-diffs email which
  I used to then forward to the corresponding package maintainer.
  This forwarding is currently broken because of changes to my
  email server.  This should really be done in elpa.gnu.org instead of
  iro.umontreal.ca anyway, so I don't intend to fix the old setup.

- elpa.gnu.org should be notified (e.g. via the elpa-diffs thingy)
  whenever a commit is made to an elpa package, and should then build
  the corresponding package (if the version was changed).  Currently, we
  just rebuild the world blindly twice a day, which is both more costly
  and adds a ~6h delay.  More importantly, this will make the handling
  of "externals" just as efficient as "subtrees", so it will scale
  a lot better.

- once that's in place, we could also consider supporting "one
  repository per package" rather than "one branch per package".

- we have the web-server log, so we could provide download stats.

Publishing on GNU ELPA is inevitably more work than on MELPA:
- you need to sign paperwork.
- we don't want to fetch from non-GNU servers, so we need the maintainer
  to push to elpa.git explicitly.
- we want the elpa.git code to be writable by "Emacs maintainers", so
  the package's maintainer will sometimes have to deal with commits made
  outside of his control.

But we could tilt the balance the other way.  The way I see GNU ELPA,
it doesn't just provide package distribution but also package hosting,
so we could maybe move towards a gitea/gogs/gitlab/younameit system
for it.  We could add some wiki or some way for users to vote up/down
and add comments to each package, ...

IOW, elpa.gnu.org needs some tender love from someone who understands
the web.  So far I've been doing most of the maintenance and I don't
understand the web, really.


        Stefan

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: Improving GNU ELPA

[Clément Pit-Claudel]

On 2017-07-11 12:04, Stefan Monnier wrote:
> - we don't want to fetch from non-GNU servers, so we need the maintainer
>   to push to elpa.git explicitly.

Not really (I think you hint at this a bit later): if the FSF hosts a gitlab instance, or any sort of (multi-repo) git hosting, then developers could just mirror their repos to that instance.

And in fact we already have this.  ELPA could work just like MELPA, but restricting the package source to Savannah.  Then publishing to ELPA would be just like MELPA, except for having to mirror to Savannah from time to time.

Clément.

Re: Improving GNU ELPA

[Stefan Monnier]

>> - we don't want to fetch from non-GNU servers, so we need the maintainer
>> to push to elpa.git explicitly.
>
> Not really (I think you hint at this a bit later): if the FSF hosts a gitlab
> instance, or any sort of (multi-repo) git hosting, then developers could
> just mirror their repos to that instance.

Indeed, by "elpa.git" I really meant "some repository under our
control".  Currently it's elpa.git, but that could be expanded.

> And in fact we already have this.  ELPA could work just like MELPA, but
> restricting the package source to Savannah.  Then publishing to ELPA would
> be just like MELPA, except for having to mirror to Savannah from time
> to time.

Note that allowing any package on Savannah would already be quite
different, since people without copyright papers have write access to it
(and we'd lose the write access for Emacs maintainers, as well as the
elpa-diffs reviews, ...).

I guess it would be marginally better than allowing any package from
"anywhere" (e.g. when a package goes unmaintained, there's a process
that could allow us to get write access), but it would add the hurdle of
being accepted into Savannah, so I don't think it would eliminate enough
friction to make a significant difference.


        Stefan


PS: BTW, to clarify my position: if it were up to me, I'd get rid of the
    copyright assignment policy for GNU ELPA (and for Emacs as well,
    while we're at it), but I'd keep the "locally hosted in a repository
    to which we have write access, with commit-diffs".

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.

emacs.org website [was Re: Adding advisory notification for non-ELPA package.el downloads]

[Glenn Morris]

Yuri Khan wrote:

> Assuming the whole //gnu.org/software/emacs subtree is served as
> static files 

Yes, AFAIK.

> and contains no relative links outside that subtree:

No; it does contain links to other pages on gnu.org. (Many of these are
set up through the .htaccess files.)

emacs.org website [was Re: Adding advisory notification for non-ELPA package.el downloads]

[Glenn Morris]

Richard Stallman wrote:

> I will suggest doing that.

Before you ask people to do work, I'd encourage you to explore what
the options are, what the consequences would be, and what the people
who maintain Emacs and its website think (if that's a factor; this
topic is currently buried in a long unrelated thread). There seem to
be various options:

1) Make emacs.org the canonical Emacs homepage address. This would be a
fair bit of work to update all the links that exist in Emacs and
elsewhere (obviously there would be a redirect from the old site, but
you'd still want links updated). IMO such a move would de-emphasize the
relation to GNU.

2) Make emacs.org a duplicate of gnu.org/s/emacs. Requires some work
on the current site contents, which assume a gnu.org address.
Frankly I don't see the benefit of this approach.

3) Redirect emacs.org to gnu.org/s/emacs. Easy. May as well.

Obviously I'm not the target of this proposal, since I don't care what
URL I use to access a site, unless it's very long, and gnu.org/s/emacs
is short enough for me.

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: Improving GNU ELPA

[Nicolas Petton]

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

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

Salut Stefan,

> PS: BTW, to clarify my position: if it were up to me, I'd get rid of the
>     copyright assignment policy for GNU ELPA (and for Emacs as well,
>     while we're at it)

Je voudrais comprendre pourquoi tu penses ça.  Tu peux m'expliquer ? (ou
répondre sur la mailing-list si tu préfères).

Nico

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

Re: Improving GNU ELPA

[Stefan Monnier]

>> PS: BTW, to clarify my position: if it were up to me, I'd get rid of the
>> copyright assignment policy for GNU ELPA (and for Emacs as well,
>> while we're at it)
> Je voudrais comprendre pourquoi tu penses ça.
> Tu peux m'expliquer ?

Je ne pense pas que ça en vaut la peine: le gain est négligeable
comparé au coût.

> (ou répondre sur la mailing-list si tu préfères).

Je ne pense pas que ce soit utile d'en discuter, parce que la position
de Richard est ferme là dessus à ma connaissance (et c'est bien trop mineur
pour mériter un fork).


        Stefan

Re: Improving GNU ELPA

[Stefan Monnier]

Duh!  And here I am posting to the list that which I didn't want!
Please don't respond!


        Stefan

Re: emacs.org website [was 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. ]]]

  > 3) Redirect emacs.org to gnu.org/s/emacs. Easy. May as well.

I too think that is best.  I don't know how such redirects work, so am
not sure if that is really different from the previous suggestion.

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

  > >   > **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: Improving GNU ELPA

[Etienne Prud’homme]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> PS: BTW, to clarify my position: if it were up to me, I'd get rid of the
>     copyright assignment policy for GNU ELPA (and for Emacs as well,
>     while we're at it), but I'd keep the "locally hosted in a repository
>     to which we have write access, with commit-diffs".

For one thing we can all agree that the bureaucracy isn’t what we would
expect for free (libre) software.  Free software should be easy to
modify and contribute.

Given that the process has been criticized as been both hard to
understand and burdensome for new contributors, we need to find a
solution for newcomers to understand the reason and process of doing
such things.

I think people are right in saying that a text file and a legal paper
describing the need for copyright assignment is not sufficient.  We
really need a way to describe the process in a simple and clear
interface.  That’s what I see is most needed in either Emacs or ELPA.

So here’s my proposal:

Making a web application for describing the need and the process of the
paperwork.  I mean by that a simple 3-4 clicks process.

1. show major reasons why we ask that.

2. a menu list to choose the country the person lives in.  Depending on
   the country requirements, we would show how to make a valid copyright
   assignment.

  2a. if the country allow to filling an online form, show a form to
      assign copyright to the FSF.

  2b. if the country allow copyright assignment with a signature, allow
      the user to sign electronically (either using mouse or signature
      picture).  I’ve signed a Non Disclosure Agreement using my mouse
      in the past for a US company.

  2c. if the country doesn’t allow electronic signature, allow printing
      the document and explaining how to scan it (some people have no
      idea a phone can do the job).
 
  2d. if the country does require paper with ink, automatically generate
      the document to be printed and signed.  Also display information
      on how to post it to the copyright holder.

3. validate the information to send and that the employer would allow
   such thing.  In case the work might be done on the company’s time,
   ask a confirmation from the company (similar to step 2).

4. confirm the copyright assignment.

  4a. if no signature is needed, confirm to the user the copyright
      assignment.

  4b. if a signature is needed, we might need to verify it.  I know some
      countries don’t require it.

  4c. make an assignment ticket in case we need material paper.  Once we
      receive, we will notify the user.

All of those things could be done from the web browser (and also from
Emacs).  We could make a web application for that that could be used by
other projects.  A copyright assignment could be done in 5min.

That was my two cons cells.

--
Etienne

Re: Improving GNU ELPA

[Phillip Lord]

Etienne Prud’homme <e.e.f.prudhomme@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> PS: BTW, to clarify my position: if it were up to me, I'd get rid of the
>>     copyright assignment policy for GNU ELPA (and for Emacs as well,
>>     while we're at it), but I'd keep the "locally hosted in a repository
>>     to which we have write access, with commit-diffs".
>
> Making a web application for describing the need and the process of the
> paperwork.  I mean by that a simple 3-4 clicks process.

A web interface with an current status and easy navigation would be a
great addition, I think.


> 3. validate the information to send and that the employer would allow
>    such thing.  In case the work might be done on the company’s time,
>    ask a confirmation from the company (similar to step 2).

It's irrelevant when the work is done unfortunately. If you are employed
as a programmer, then a priori your employer has a strong claim on the
copyright of any code you right.

So, you have to get a disclaimer. This is one of those things that can
take quite a while, especially if you work for a big company.


> All of those things could be done from the web browser (and also from
> Emacs).  We could make a web application for that that could be used by
> other projects.  A copyright assignment could be done in 5min.

It's worth a try for sure!

Phil

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: emacs.org website [was Re: Adding advisory notification for non-ELPA package.el downloads]

[John Wiegley]

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

RS> I too think that is best. I don't know how such redirects work, so am not
RS> sure if that is really different from the previous suggestion.

We just need a webserver, on the machine pointed to by emacs.org, to accept
incoming requests on port 80 for that IP address, and transparently redirect
them to the target URL.

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

Re: Improving GNU ELPA (was: Adding advisory notification for non-ELPA package.el downloads)

[Jonas Bernoulli]

I think we should keep requiring authors to push to and pull from Elpa,
that is not really the issue.  The issue as I see it is that doing so is
not as easy as:

  git pull elpa
  git push elpa

Instead one has to do something like (provided one does actually care
about the history in both the "personal" and the Elpa repository staying
clean).

* Integrating Elpa changes.

  git fetch elpa
  git filter-branch
  git branch -f elpa &&
  git filter-branch -f --subdirectory-filter "packages/$package" --commit-filter '
  # One could use "--prune-empty" instead, but this script is better.
  test $# = 1 && test -z "$(git ls-tree $1)" && skip_commit "$1" && exit
  args="$@"
  tree="$1"
  shift
  while test -n "$1"
  do
	shift
	test "$tree" = $(git rev-parse "$1^{tree}") && map "$1" && exit
	shift
  done
  git commit-tree $args' elpa

So I think the focus should be on enabling "one repository per package"
instead of making Elpa pull.  If pushing to Elpa was as easy as for normal
Git repositories, then people would not mind.

  Jonas

Re: Improving GNU ELPA

[Stefan Monnier]

>   git fetch elpa
>   git filter-branch

That's only for the "subtree" packages.  You can use an "external"
package, in which case the package has its own branch.

> So I think the focus should be on enabling "one repository per package"

One repository per package would be a bit more convenient in some cases,
admittedly, but one branch per package is not that bad.


        Stefan

Re: Improving GNU ELPA

[Jonas Bernoulli]

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

>>   git fetch elpa
>>   git filter-branch
>
> That's only for the "subtree" packages.  You can use an "external"
> package, in which case the package has its own branch.
>
>> So I think the focus should be on enabling "one repository per package"
>
> One repository per package would be a bit more convenient in some cases,
> admittedly, but one branch per package is not that bad.

That works for me, and I suspect for many others too.

I was somehow under the impression that "subtree" packages were
preferred, and "external" packages only recommended for big packages
and maintainers who refused to use the subtree approach.

Since "one branch per package" works mostly (*) like "one repository
per package", I don't think teaching Elpa to pull is a good idea.
The downsides of doing that have already been discussed and as long
as one goes with the "subtree" option, I don't see the need.

*: git remote add -t externals/<package> --no-tags elpa git://...
     vs.
   git remote add elpa git://...

  Cheers,
  Jonas

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: Improving GNU ELPA

[Phillip Lord]

Jonas Bernoulli <jonas@bernoul.li> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>   git fetch elpa
>>>   git filter-branch
>>
>> That's only for the "subtree" packages.  You can use an "external"
>> package, in which case the package has its own branch.
>>
>>> So I think the focus should be on enabling "one repository per package"
>>
>> One repository per package would be a bit more convenient in some cases,
>> admittedly, but one branch per package is not that bad.
>
> That works for me, and I suspect for many others too.

I have used a branch for my packages so that it (mostly) remains as
simple as git pull/git push.

It does bring some added complexity, as the git pull is a potential
merge. In the case of magit, this is not going to be a problem as you
know how to use git well: you can avoid the merge if you want or deal
with it if you want. For others, it might be a little harder. It is why
I think ELPA should be modified by PRs where an upstream exists. Having
a branch makes this easier also.

Phil

Re: Improving GNU ELPA

[Stefan Monnier]

> I was somehow under the impression that "subtree" packages were
> preferred, and "external" packages only recommended for big packages
> and maintainers who refused to use the subtree approach.

It's up to the package's maintainer to decide.


        Stefan

Re: Improving GNU ELPA

[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 was somehow under the impression that "subtree" packages were
  > > preferred, and "external" packages only recommended for big packages
  > > and maintainers who refused to use the subtree approach.

  > It's up to the package's maintainer to decide.

People have presented complicated workflows, saying those are required
to install any patch in ELPA, and that this makes using ELPA a pain.
Those did seem so complicated that it would be a pain in the neck to
do this.

Are those complicated workflows for "subtree" packages only?
Does using an "external" package avoid the 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: Improving GNU ELPA

[Stefan Monnier]

> Are those complicated workflows for "subtree" packages only?

Yes (and only if you use a separate upstream).

> Does using an "external" package avoid the problem?

Yes,


        Stefan

Re: Improving GNU ELPA

[Phillip Lord]

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

>> Are those complicated workflows for "subtree" packages only?
>
> Yes (and only if you use a separate upstream).
>
>> Does using an "external" package avoid the problem?
>
> Yes,


Mostly.

With dash, I can push to elpa, but not to upstream. So, changes occuring
to dash on ELPA, have to be pulled onto a branch, turned into a PR for
dash.

If I could push to upstream, it would be simpler, but still require
merges.

Phil

Re: Improving GNU ELPA

[Stefan Monnier]

> If I could push to upstream, it would be simpler, but still require
> merges.

AFAIU, what you mean by "merges" is simply the result of changes being
made both to the github repository and to the elpa.git repository.
It's unrelated to how the copy of dash kept on the gnu.org side is
stored (a subtree, or a separate branchm or a separate repository) as
long as it can be modified on the gnu.org side.

Right?


        Stefan

Re: Improving GNU ELPA

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

  > > Are those complicated workflows for "subtree" packages only?

  > Yes (and only if you use a separate upstream).

Using a separate upstream can be ok, if we ensure proper rules are
followed, to avoid difficulties.

What are the current rules for using a separate upstream
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: Improving GNU ELPA

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

  > With dash, I can push to elpa, but not to upstream. So, changes occuring
  > to dash on ELPA, have to be pulled onto a branch, turned into a PR for
  > dash.

The reason I say we should have admin access to the real repository
is to avoid problem situations like this one.



-- 
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: Improving GNU ELPA

[Stefan Monnier]

> What are the current rules for using a separate upstream
> in ELPA?

There are no real rules, here, other than the fact that elpa.git may be
modified by us directly, so if the maintainer decides to keep the
"upstream" elsewhere it's his responsibility to deal with the fallout

[ We try to help with that by automatically sending her an email with
  the diffs that have been installed, tho this automatic forwarding is
  currently broken, as mentioned earlier in this thread:

  > - when someone commits to elpa.git we get an elpa-diffs email which
  >   I used to then forward to the corresponding package maintainer.
  >   This forwarding is currently broken because of changes to my
  >   email server.  This should really be done in elpa.gnu.org instead of
  >   iro.umontreal.ca anyway, so I don't intend to fix the old setup.

  Help would be very warmly welcome here.  ]

More generally: it's not ideas that are missing, it's people helping
improve the setup.


        Stefan

Re: Improving GNU ELPA

[Phillip Lord]

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

>> If I could push to upstream, it would be simpler, but still require
>> merges.
>
> AFAIU, what you mean by "merges" is simply the result of changes being
> made both to the github repository and to the elpa.git repository.
> It's unrelated to how the copy of dash kept on the gnu.org side is
> stored (a subtree, or a separate branchm or a separate repository) as
> long as it can be modified on the gnu.org side.
>
> Right?

I think so, yes. I've never used subtrees. Orphan branches in a repo are
essentially the same as a separate repo except that they share a
namespace for branches and tags. So, I guess, with a separate repo you
could do things like make a feature branch and then PR for this
upstream.

But in terms of use, not modifying the gnu.org side (except in
exceptional circumstances) would make the use of ELPA with an upstream
repo easier. ELPA would, effectively, operate like Jonas' emacsmirror;
there in case the upstream disappeared.

Phil

Re: Improving GNU ELPA

[Phillip Lord]

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

>> What are the current rules for using a separate upstream
>> in ELPA?
>
> There are no real rules, here, other than the fact that elpa.git may be
> modified by us directly, so if the maintainer decides to keep the
> "upstream" elsewhere it's his responsibility to deal with the fallout

This bit I don't like!

> [ We try to help with that by automatically sending her an email with
>   the diffs that have been installed, tho this automatic forwarding is
>   currently broken, as mentioned earlier in this thread:
>
>   > - when someone commits to elpa.git we get an elpa-diffs email which
>   >   I used to then forward to the corresponding package maintainer.
>   >   This forwarding is currently broken because of changes to my
>   >   email server.  This should really be done in elpa.gnu.org instead of
>   >   iro.umontreal.ca anyway, so I don't intend to fix the old setup.
>
>   Help would be very warmly welcome here.  ]
>
> More generally: it's not ideas that are missing, it's people helping
> improve the setup.


What sort of commits do you do locally? Would scripting something to
branch, and do git-request-pull to the upstream be a substitute?

Phil

Re: Improving GNU ELPA

[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. ]]]
>
>   > With dash, I can push to elpa, but not to upstream. So, changes occuring
>   > to dash on ELPA, have to be pulled onto a branch, turned into a PR for
>   > dash.
>
> The reason I say we should have admin access to the real repository
> is to avoid problem situations like this one.

As I said, it doesn't avoid the problem, it just changes the nature of
that problem. As Stefan has said, at the moment, dealing with these
issues is, anyway, consider the problem of the upstream person. The
presence of push rights changes nothing if you do not use them.

Phil

Re: Improving GNU ELPA

[Stefan Monnier]

>> There are no real rules, here, other than the fact that elpa.git may be
>> modified by us directly, so if the maintainer decides to keep the
>> "upstream" elsewhere it's his responsibility to deal with the fallout
> This bit I don't like!

You're not alone, so in general we should try to avoid it.

> What sort of commits do you do locally?

Not sure what you mean by "locally".  Do you mean, what kinds of commits
do we want to install directly into elpa.git (for those cases where the
upstream is elsewhere)?

Typically things like incorrect copyright notices or compilation breakage.

> Would scripting something to branch, and do git-request-pull to the
> upstream be a substitute?

Nowadays, most of time I send a patch via email to the maintainer rather
than committing directly.  It's more tedious but since I now do much less
janitorial work on elpa.git code it's OK.


        Stefan

Re: Improving GNU ELPA

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

  > As I said, it doesn't avoid the problem, it just changes the nature of
  > that problem.

I have a hunch that "the problem" you are talking about is not the
same problem.  I can't verify this, because you tallk about "the
problem" tersely in the abstract, without stating concretely what
problem you mean.  But I am pretty sure it's not the one I am trying
to avoid.

		  As Stefan has said, at the moment, dealing with these
  > issues is, anyway, consider the problem of the upstream person.

I would describe that as the "easy way out".  You consider it a good
option and recommend it as a solution, but I see it as opening a can
of worms.  Thus, for me it is "the problem" and I am looking for how
we can _avoid_ it.

  > The
  > presence of push rights changes nothing if you do not use them.

Alas, I don't follow -- that is rather terse, so I don't understand
the point.  I am not sure whether I would agree or disagree, if I
understood.

-- 
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: Improving GNU ELPA

[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. ]]]
>
>   > As I said, it doesn't avoid the problem, it just changes the nature of
>   > that problem.
>
> I have a hunch that "the problem" you are talking about is not the
> same problem.  I can't verify this, because you tallk about "the
> problem" tersely in the abstract, without stating concretely what
> problem you mean.  But I am pretty sure it's not the one I am trying
> to avoid.

Specifically, that I cannot push to dash on github which is the main
repository. This is not a big deal, I just haven't asked for it.

>
> 		  As Stefan has said, at the moment, dealing with these
>   > issues is, anyway, consider the problem of the upstream person.
>
> I would describe that as the "easy way out".  You consider it a good
> option and recommend it as a solution, but I see it as opening a can
> of worms.  Thus, for me it is "the problem" and I am looking for how
> we can _avoid_ it.
>
>   > The
>   > presence of push rights changes nothing if you do not use them.
>
> Alas, I don't follow -- that is rather terse, so I don't understand
> the point.  I am not sure whether I would agree or disagree, if I
> understood.


So, the issue is this:

Assume we have a package (like dash) which is maintained and developed
in some external git repo.

I think, ELPA would be easier to use if it just pulled directly and
automatically from this external git repo. If the Emacs maintainers want
to update that package, they should use PRs to the upstream. Commit or
push rights on upstream are not necessary. This is enough, for most
cases, and is also easy for the upstream developer. This is also how
MELPA runs, so clearly it can work in practice.

There are emergencies that we might concieve of where a change needs to
be made to ELPA immediately, today, without any delay. In these
circumstances, a copy of the project history would be available in the
ELPA repository. Changes could be made there, with the knowledge that
the upstream package would need to do something to reincorporate these
emergency changes. MELPA has a similar policy for switching upstream.

This requires almost no software (just something to run the pull), no
changes to ELPA, just a change in policy. In response, ELPA becomes a
little more frictionless, a little more convienient for contributors.

Going round in circles here, so I stop.

Phil

Re: Improving GNU ELPA

[Phillip Lord]

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

>>> There are no real rules, here, other than the fact that elpa.git may be
>>> modified by us directly, so if the maintainer decides to keep the
>>> "upstream" elsewhere it's his responsibility to deal with the fallout
>> This bit I don't like!
>
> You're not alone, so in general we should try to avoid it.
>
>> What sort of commits do you do locally?
>
> Not sure what you mean by "locally".  Do you mean, what kinds of commits
> do we want to install directly into elpa.git (for those cases where the
> upstream is elsewhere)?

Yes, precisely so.

> Typically things like incorrect copyright notices or compilation breakage.

Does ELPA not check for the copyright? I.e. if it's incorrect, it will
be wrong in the git repo only and not in the distributed ELPA package.


>> Would scripting something to branch, and do git-request-pull to the
>> upstream be a substitute?
>
> Nowadays, most of time I send a patch via email to the maintainer rather
> than committing directly.  It's more tedious but since I now do much less
> janitorial work on elpa.git code it's OK.

janitorial work is always tedious!

Phil

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: Improving GNU ELPA

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

  > > Typically things like incorrect copyright notices or compilation breakage.

  > Does ELPA not check for the copyright? I.e. if it's incorrect, it will
  > be wrong in the git repo only and not in the distributed ELPA package.

We could make ELPA check that files have the correct copyright notices.
We could also make it check that they have the correct license notices.
It would be useful to implement sending us warnings for that.

Would anyone like to implement this?

However, the crucial thing is not what the file SAYS about copyright,
but what the actual facts are about the copyright.  We take care of
that by getting copyright assignments.  Once that is done, if a notice
in a file is inaccurate, all we need to do is correct 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

[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: Improving GNU ELPA

[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. ]]]
>
>   > > Typically things like incorrect copyright notices or compilation breakage.
>
>   > Does ELPA not check for the copyright? I.e. if it's incorrect, it will
>   > be wrong in the git repo only and not in the distributed ELPA package.
>
> We could make ELPA check that files have the correct copyright notices.
> We could also make it check that they have the correct license notices.
> It would be useful to implement sending us warnings for that.
>
> Would anyone like to implement this?

It already does this.

Incorrect copyright notices are nothing urgent, since they need not go
live to elpa.gnu.org -- they will be present only in git. So not an
urgent need for changes.

Phil

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.