From: Jean Louis <bugs@gnu.support>
To: help-gnu-emacs@gnu.org
Subject: Re: NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)
Date: Sat, 15 Jan 2022 10:39:29 +0300 [thread overview]
Message-ID: <YeJ6MTFEHvAdql2/@protected.localdomain> (raw)
In-Reply-To: <87sftpx5ja.fsf_-_@zoho.eu>
* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-15 02:32]:
> Tassilo Horn wrote:
>
> > But it would still be fine for NonGNU ELPA if it had
> > a proper license statement (which is the actual missing
> > part).
>
> What's this NonGNU ELPA I keep hearing about lately?
Maybe winter sleep took you too long.
NonGNU Emacs Lisp Package Archive is the answer to issues otherwise
not handled on MELPA, for example, this repository will include any
kind of packages but not steer users to vague licensed packages or
proprietary software.
More information: https://git.savannah.gnu.org/cgit/emacs/nongnu.git/plain/README.org
* Guidance for accepting packages
** We don't ask for copyright assignments to include packages in NonGNU ELPA.
** The Emacs maintainers will decide what packages to put in NonGNU ELPA.
** If an ELisp package follows the rules below,
we can add it to NonGNU ELPA if we want to. If the code doesn't
follow them, we can change the code to follow them. We may also
change the code in NonGNU ELPA for other reasons, technical or not.
After all, it is free software.
** For practical reasons, we usually refrain from making local changes
to NonGNU ELPA packages, in order to simplify integration of future
changes from the upstream version.
** The package's developers don't have an obligation to maintain the
NonGNU ELPA version, but we would like to invite them to do that, or
to cooperate and coordinate with us in doing that. If you are the
developer of a NonGNU ELPA package, or a package that might be added
to NonGNU ELPA, and you're interested in maintaining it there, let's
discuss it.
** Rules for a package to be acceptable in NonGNU ELPA
*** A NonGNU ELPA package must display its copyright notices and license
notices clearly on each nontrivial file. The notices do not have to
follow the FSF conventions about their presentation.
Software files need to carry a free license that is compatible with the
GNU GPL version 3-or-later. Which licenses qualify is stated in
https://gnu.org/licenses/license-list.html.
Manuals need to be under a free license that is compatible
with the GNU FDL version 1.4-or-later. Which licenses qualify is
stated in https://gnu.org/licenses/license-list.html.
All other documentation files, for users (manuals, help files, man
pages, and so on), and for developers (program logic, change logs,
and so on), can be under a license acceptable for manuals or a
license acceptable for software files (see above). We can agree
with the package developers to include documentation published under
other free licenses.
Trivial files of just a few lines don't need to state a copyright or
a license.
Normally we don't include material other than software or
documentation, but we can agree with the developers to include
specific material. If the material in question is an educational
resource, then it can have a license compatible with GNU FDL version
1.4 or one of the free Creative Commons licenses (CC-BY-SA, CC-BY or
CC-0), or another free license at our discretion. If the material is
not an educational resource, it can instead be licensed under
CC-BY-ND.
*** The package need not follow the GNU Coding Standards or the GNU
Maintainers Guide, except for a few specific points as stated below.
*** The package must follow the rules in
https://www.gnu.org/prep/standards/, node References. This means it
may not refer users to any nonfree software or nonfree
documentation, except as stated there. Leading users to run a
program, and suggesting they run it, or depending on it to be
installed, are forms of referring users to it.
*** Aside from packages obtained from GNU ELPA and NonGNU ELPA,
a package may not run code that it has fetched over the internet.
In particular, the package may install other packages in GNU ELPA and
NonGNU ELPA, but not any other software.
We will consider exceptions to that rule, but we will need to
consider them carefully, to make sure that the practices are
safe for Emacs users, not just in one package but when used in
many packages. Each time we approve such an exception, we will
say so in comments in the package, with an explanation of our reasoning.
*** The package must deliver its full functionality and convenience on a
completely free platform based on the GNU operating system (in
practice, GNU/Linux), working exclusively with other free software.
Otherwise, it would act as an inducement to install nonfree systems
or other nonfree software, and that would work against our cause.
However, as an exception it is ok for a package to provide, on some
non-GNU operating systems, features that the rest of Emacs (plus GNU
ELPA and NonGNU ELPA) already supports on GNU.
This is a moral issue. See https://www.gnu.org/prep/standards/,
node System Portability. The reason for this rule is that at no
time, in no way, should a NonGNU ELPA package put users who defend
their freedom at a disadvantage compared with those who surrender
their freedom.
*** The package may communicate with a class of remote services, either
using a standard interface or using an ad-hoc interface for each
service, or a combination, *provided* that these services' jobs
consist of either communication or lookup of published data.
The package may not use remote services to do the user's own
computational processing. "Your own computational processing" means
anything you could _in principle_ do in your own computers by
installing and running suitable software, without communicating with
any other computers.
*** A general Savannah rule about advertisements
In general, you may not advertise anything commercial with material
in the NonGNU ELPA package or this repository. However, as
exceptions, you can point people to commercial support offerings for
the package, and you can mention fan items that you sell directly to
the users.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
next prev parent reply other threads:[~2022-01-15 7:39 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-08 5:20 How do I go about debugging my Elisp code? Davin Pearson
2022-01-10 10:11 ` Michael Heerdegen
2022-01-10 10:37 ` Po Lu
2022-01-13 1:22 ` Fwd: " Davin Pearson
2022-01-13 1:34 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-13 12:58 ` Michael Heerdegen
2022-01-14 6:55 ` Marcin Borkowski
2022-01-14 8:24 ` Jean Louis
2022-01-14 23:22 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-14 13:46 ` Jean Louis
2022-01-14 14:56 ` Tassilo Horn
2022-01-14 15:20 ` Jean Louis
2022-01-14 16:23 ` Tassilo Horn
2022-01-14 16:53 ` Jean Louis
2022-01-14 17:24 ` Tassilo Horn
2022-01-14 17:57 ` Jean Louis
2022-01-14 18:58 ` Tassilo Horn
2022-01-15 7:34 ` Jean Louis
2022-01-14 18:56 ` Marcin Borkowski
2022-01-14 19:02 ` Jean Louis
2022-01-14 19:51 ` Tassilo Horn
2022-01-15 7:35 ` Jean Louis
2022-01-15 10:15 ` Tassilo Horn
2022-01-15 11:33 ` Jean Louis
2022-01-18 0:03 ` Davin Pearson
2022-01-14 23:28 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-14 23:26 ` NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?) Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-15 7:39 ` Jean Louis [this message]
2022-01-17 3:47 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-17 18:15 ` Jean Louis
2022-01-18 0:01 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-18 5:02 ` Jean Louis
2022-01-18 6:06 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-18 3:02 ` NonGNU ELPA Stefan Monnier via Users list for the GNU Emacs text editor
2022-01-18 3:20 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-18 3:49 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-01-21 21:32 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-22 4:00 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-01-22 4:53 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-22 5:23 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-22 5:24 ` Po Lu
2022-01-22 5:38 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-22 6:32 ` Po Lu
2022-01-22 6:42 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-22 7:10 ` Po Lu
2022-01-22 12:24 ` Jean Louis
2022-01-22 12:38 ` Po Lu
2022-01-22 11:13 ` Jean Louis
2022-01-22 13:43 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-23 9:24 ` Jean Louis
2022-01-23 16:26 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-01-23 16:39 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-22 4:58 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-22 5:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-18 3:23 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-14 17:40 ` Fwd: How do I go about debugging my Elisp code? Yuri Khan
2022-01-14 17:51 ` Jean Louis
2022-01-14 23:31 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-14 23:24 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-15 2:13 ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-01-15 8:24 ` Jean Louis
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YeJ6MTFEHvAdql2/@protected.localdomain \
--to=bugs@gnu.support \
--cc=help-gnu-emacs@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.