[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[elpa] elpa-admin d19a5b8 341/357: * README.org: New file
From: |
Stefan Monnier |
Subject: |
[elpa] elpa-admin d19a5b8 341/357: * README.org: New file |
Date: |
Thu, 10 Dec 2020 18:07:11 -0500 (EST) |
branch: elpa-admin
commit d19a5b801ea45d7e5f900044dca573f5ab6519c6
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Commit: Stefan Monnier <monnier@iro.umontreal.ca>
* README.org: New file
---
README.org | 113 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 113 insertions(+)
diff --git a/README.org b/README.org
new file mode 100644
index 0000000..02d2f72
--- /dev/null
+++ b/README.org
@@ -0,0 +1,113 @@
+* 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 prackages. 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 repositor. 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.
+
- [elpa] elpa-admin 19a11bc 278/357: Add explicit instructions for new external packages, (continued)
- [elpa] elpa-admin 19a11bc 278/357: Add explicit instructions for new external packages, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 280353e 287/357: Merge commit 'cb905bdc728fb3b5f9fdff8836d71b62bd717eab' from mmm-mode, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 63888f3 292/357: Warn about transfer.fsckObjects, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin a5d74b0 291/357: * packages/yasnippet: Merge version 0.13.0 from upstream., Stefan Monnier, 2020/12/10
- [elpa] elpa-admin eb92dfc 293/357: Fix repo links for :core packages, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin a71a25a 306/357: Update packages/darkroom from upstream, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin f79d3e5 327/357: Merge commit 'b49ba259cc7e490e8acdecd28e66063f5ad1325e', Stefan Monnier, 2020/12/10
- [elpa] elpa-admin f9ce2f8 328/357: Merge commit 'b2c449c0d5aad67eeee9857e7fd7710f985084ec', Stefan Monnier, 2020/12/10
- [elpa] elpa-admin e48de90 332/357: * README: Fix typos., Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 223f7eb 331/357: * README: Clarify deployment process., Stefan Monnier, 2020/12/10
- [elpa] elpa-admin d19a5b8 341/357: * README.org: New file,
Stefan Monnier <=
- [elpa] elpa-admin b3e663b 353/357: Rename ELisp files, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 4ade74d 346/357: * README.org: Add license and an introduction., Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 4a3a7c2 193/357: * README: Improve subtree instructions, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 54886a6 199/357: Better generated HTML pages, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 5e9fdd4 197/357: * README: Revert change about package.el headers, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 3a394c3 188/357: Merge commit 'd76bcd7c0dcecb33e6955e25963028600c371588', Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 7558d12 206/357: Make externals directory removal safer, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin a8b876c 207/357: * admin/archive-contents.el: Make :core handling optional, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 3a129d5 190/357: Add support to build packages from Emacs repo, Stefan Monnier, 2020/12/10
- [elpa] elpa-admin 581dd5b 231/357: Fix a typo in the readme, Stefan Monnier, 2020/12/10