unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: rms@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: Help testing emacs-28.3-rc1.tar.gz on MS-Windows
Date: Tue, 22 Aug 2023 14:40:20 +0300	[thread overview]
Message-ID: <83bkeztie3.fsf@gnu.org> (raw)
In-Reply-To: <E1qYFqa-0002BT-SD@fencepost.gnu.org> (message from Richard Stallman on Mon, 21 Aug 2023 21:06:16 -0400)

> From: Richard Stallman <rms@gnu.org>
> Cc: casouri@gmail.com, stefankangas@gmail.com, njackson@posteo.net,
> 	emacs-devel@gnu.org
> Date: Mon, 21 Aug 2023 21:06:16 -0400
> 
>   > > I would be remiss to take whichwever advice is most convenient for us
>   > > just because it is convienient.
>   > > 
>   > > But I will ask a lawyer who advises the FSF about this question.
> 
>   > Any news about this?
> 
> No -- I was busy and let it drop.
> 
> But we don't need to recheck the advice we got before.
> We wrote down what it was and we can keep following it.

I don't think I understand: are you saying you have already asked the
lawyers about this and received their answers?  Or that the current
practice is fine and we could keep using it?

If the latter, then while the current situation is definitely not a
catastrophe, if we can avoid updating the copyright years every year,
it would reduce the maintenance burden, the code churn, and the need
to recompile everything once a year (per each branch), altogether
contributing to energy savings and keeping down the emissions, which
is good for the world at large.  So I think it's worth our while to
see if this nuisance can be avoided.

TIA



  reply	other threads:[~2023-08-22 11:40 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-19 10:51 Help testing emacs-28.3-rc1.tar.gz on MS-Windows Stefan Kangas
2023-02-19 12:05 ` lux
2023-02-19 12:34   ` Stefan Kangas
2023-02-19 16:04     ` lux
2023-02-19 12:20 ` Eli Zaretskii
2023-02-19 12:34   ` Stefan Kangas
2023-02-19 12:39 ` lux
2023-02-19 13:05   ` Stefan Kangas
2023-02-19 13:49 ` N. Jackson
2023-02-19 14:06   ` Stefan Kangas
2023-02-19 15:00     ` Eli Zaretskii
2023-02-19 17:11       ` Stefan Kangas
2023-03-03  6:00         ` Yuan Fu
2023-03-03  7:57           ` Eli Zaretskii
2023-03-05  4:05           ` Richard Stallman
2023-08-19 18:14             ` Eli Zaretskii
2023-08-22  1:06               ` Richard Stallman
2023-08-22 11:40                 ` Eli Zaretskii [this message]
2023-08-23  2:14                   ` Richard Stallman
2023-02-19 15:31     ` Ulrich Mueller
2023-02-19 15:34       ` Eli Zaretskii
2023-02-19 15:05 ` Ulrich Mueller
2023-02-19 16:29   ` Stefan Kangas
2023-03-02 18:52     ` Troy Hinckley
2023-02-19 15:59 ` Óscar Fuentes
2023-02-19 19:05   ` Óscar Fuentes
2023-03-06 19:40     ` H. Dieter Wilhelm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=83bkeztie3.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).