non-gnu elpa issue tracking

non-gnu elpa issue tracking

[Boruch Baum]

I've read sumaries of Richard Stallman's presentation about the
proposed, and in comparing it with Stefan Monnier's in-progress web
interface, have several suggestions:

1) License disclosure: The summaries indicate that RMS is open to having
   the repository host packages bearing *any* free license, but there
   may be users who are pickier, so a package's license should be
   disclosed prominently on the listing page and the package detail
   page;

2) The acceptance or candidacy process for each package should be
   documented in some discrete method. Melpa does this using github's
   pull request feature, which documents the entire conversation related
   to the process of accepting a package.

3) After a package is initially accepted to the repository, the
   summaries of Richard Stallman's presentation indicate that subsequent
   commits or releases may be rejected or modified. That record should
   also be documented. Debian does this using its own package tracking
   software.

   Here's an example of it in action (for the package 'bash'):
     https://tracker.debian.org/pkg/bash

   It's source code is available on its 'salsa' repository (gitlab?):
     https://salsa.debian.org/qa/distro-tracker

   Debian's experience and the automation of its infrastructure might be
   useful to adopt in-toto even if its not an absolutely perfect match
   because it's a turnkey solution and is actively maintained (eg. they
   may accept feature requests).

4) There's no link on the repository page[1] to the software being used
   to generate it, and the forge at which it is being developed. Having
   that would make the infrastructure friendlier for pull-requests, bug
   reports, and other feedback.

[1] https://elpa.gnu.org/nongnu/

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: non-gnu elpa issue tracking

[Stefan Kangas]

Boruch Baum <boruch_baum@gmx.com> writes:

> I've read sumaries of Richard Stallman's presentation about the
> proposed, and in comparing it with Stefan Monnier's in-progress web
> interface, have several suggestions:
>
> 1) License disclosure: The summaries indicate that RMS is open to having
>    the repository host packages bearing *any* free license, but there
>    may be users who are pickier, so a package's license should be
>    disclosed prominently on the listing page and the package detail
>    page;

Are there any packages out there that don't use the GPL?  Could you
point us to some examples?

> 2) The acceptance or candidacy process for each package should be
>    documented in some discrete method. Melpa does this using github's
>    pull request feature, which documents the entire conversation related
>    to the process of accepting a package.

Could you be more specific?  Do you mean that we should document it
somewhere, or do you mean something else?

> 3) After a package is initially accepted to the repository, the
>    summaries of Richard Stallman's presentation indicate that subsequent
>    commits or releases may be rejected or modified. That record should
>    also be documented. Debian does this using its own package tracking
>    software.
>
>    Here's an example of it in action (for the package 'bash'):
>      https://tracker.debian.org/pkg/bash
>
>    It's source code is available on its 'salsa' repository (gitlab?):
>      https://salsa.debian.org/qa/distro-tracker
>
>    Debian's experience and the automation of its infrastructure might be
>    useful to adopt in-toto even if its not an absolutely perfect match
>    because it's a turnkey solution and is actively maintained (eg. they
>    may accept feature requests).

"Debian's infrastructure" is massive and has many moving parts.
Do you suggest that we should adopt all of that wholesale?

> 4) There's no link on the repository page[1] to the software being used
>    to generate it, and the forge at which it is being developed. Having
>    that would make the infrastructure friendlier for pull-requests, bug
>    reports, and other feedback.

I assume that there will be a landing page similar to the one on
elpa.gnu.org.

Re: non-gnu elpa issue tracking

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2020-12-09 19:59]:
> Boruch Baum <boruch_baum@gmx.com> writes:
> 
> > I've read sumaries of Richard Stallman's presentation about the
> > proposed, and in comparing it with Stefan Monnier's in-progress web
> > interface, have several suggestions:
> >
> > 1) License disclosure: The summaries indicate that RMS is open to having
> >    the repository host packages bearing *any* free license, but there
> >    may be users who are pickier, so a package's license should be
> >    disclosed prominently on the listing page and the package detail
> >    page;
> 
> Are there any packages out there that don't use the GPL?  Could you
> point us to some examples?

Just to name a few, among more of them:

grep --color -nH --null -e "Apache License" *.el
auth-source-xoauth2-20200911.1554.el\05:;; Licensed under the Apache License, Version 2.0 (the "License");
emidje-20190209.1726.el\016:;; Licensed under the Apache License, Version 2.0 (the "License"); you may not use
furl-20150509.316.el\025:;; Licensed under the Apache License, Version 2.0 (the "License");
go-noisegate-20200503.1358.el\013:;; Licensed under the Apache License, Version 2.0 (the "License");
govc-20201020.1619.el\015:;; Licensed under the Apache License, Version 2.0 (the "License");
ietf-docs-20190420.851.el\017:;; Licensed under the Apache License, Version 2.0 (the "License");
mmm-jinja2-20170313.1420.el\030:;;   Licensed under the Apache License, Version 2.0 (the "License"); you may not
pack-20191017.456.el\013:;;   Licensed under the Apache License, Version 2.0 (the "License");
redpen-paragraph-20200506.1558.el\014:;; Licensed under the Apache License, Version 2.0 (the "License");
rust-mode-20200709.723.el\012:;; Apache License (version 2.0).
salt-mode-20200210.1227.el\032:;;   Licensed under the Apache License, Version 2.0 (the "License"); you may not
sayid-20200902.708.el\012:;; Licensed under the Apache License, Version 2.0 (the "License");
thrift-20201021.956.el\012:;; to you under the Apache License, Version 2.0 (the
vale-mode-20190725.125.el\016:;; Licensed under the Apache License, Version 2.0 (the "License");
wedge-ws-20140714.2149.el\014:;; Licensed under the Apache License, Version 2.0 (the "License");

Then those packages where words "Free Software Foundation" do not
exist:

0x0-20201014.1445.el
 - public domain CC0 1.0 questionable if free in other countries but
   US

aggressive-fill-paragraph-20181106.1354.el
  - no license
  
alan-mode-20200723.1405.el
   - MIT
   
anaphora-20180618.2200.el
  - public domain, in other countries can be proprietary by default
  
anki-mode-20200703.739.el
  - no license, proprietary by default

now these below I did not check, but the pattern says that there will
be many like that. In these there is no "Free Software" inside. But I
did not grep well enough.

Pattern above should speak for itself.

annotate-20200829.1336.el
annotation-20201020.717.el
aria2-20190906.2226.el
ascii-table-20201019.700.el
asilea-20150105.1525.el
aurora-config-mode-20180216.2302.el
auth-source-xoauth2-20200911.1554.el
auto-sudoedit-20200427.635.el
autotest-20200609.1811.el
autotetris-mode-20180609.111.el
back-button-20150804.2004.el
baff-20200824.2111.el
bang-20200930.1300.el
banner-comment-20190606.1809.el
bap-mode-20200128.1354.el
basic-c-compile-20170918.1649.el
benchstat-20171014.907.el
bento-20191025.2350.el
biblio-bibsonomy-20190201.52.el
bifocal-20200428.314.el
bind-chord-20200805.1727.el
bind-key-20200805.1727.el
bitlbee-20151203.11.el
blackboard-bold-mode-20160813.206.el
blackout-20200503.1426.el
bool-flip-20161215.1548.el
browse-url-dwim-20140804.1922.el
bufshow-20170110.323.el
button-lock-20200309.1323.el
cd-compile-20141108.1957.el
cheatsheet-20170126.2150.el
chicken-scheme-20141116.1939.el
chronometrist-goal-20200906.1522.el
ciel-20180914.815.el
clojars-20180825.1955.el
codcut-20190929.2126.el
comint-hyperlink-20191104.2224.el
commify-20200921.2002.el
conda-20200818.1614.el
config-general-mode-20171024.1840.el
counsel-codesearch-20180925.803.el
counsel-dash-20200103.1411.el
counsel-jq-20200907.1458.el
coverage-20191113.1958.el
cpputils-cmake-20181006.328.el
css-autoprefixer-20180311.1600.el
css-comb-20160416.559.el
cssh-20150810.1709.el
ctrlf-20201020.1353.el
cubicaltt-20181016.1157.el
cucumber-goto-step-20131210.519.el
currency-convert-20201017.1817.el
dark-souls-20140314.2226.el
dash-at-point-20180710.1356.el
deft-20200515.1513.el
deno-fmt-20200602.1550.el
dfmt-20170728.1023.el
diary-manager-20200922.1329.el
didyoumean-20200905.1843.el
digit-groups-20200506.37.el
dired-fdclone-20180403.608.el
dired-launch-20200430.1625.el
dired-toggle-sudo-20200401.1353.el
direnv-20200529.1305.el
dirtree-prosjekt-20151127.1416.el
dispass-20140202.1531.el
distel-completion-lib-20180827.1344.el
dmacro-20200803.635.el
dpaste_de-20131015.1232.el
dtk-20201006.1835.el
dynamic-fonts-20140804.1922.el
edit-at-point-20191013.1218.el
edit-indirect-20200805.1840.el
edn-20201009.1244.el
egg-timer-20200314.1727.el
eldoc-cmake-20190419.2244.el
eldoc-overlay-20200715.1214.el
elpa-clone-20191006.1953.el
el-patch-20200922.1329.el
emacsql-mysql-20200714.28.el
emidje-20190209.1726.el
emms-bilibili-20180103.418.el
empos-20151011.1916.el
eno-20191013.1239.el
epic-20170210.23.el
erc-crypt-20200520.451.el
erc-view-log-20140227.2039.el
eredis-20191004.1545.el
eri-20201020.717.el
eshell-autojump-20150927.724.el
eslint-fix-20180514.700.el
ethan-wspace-20190522.1448.el
execline-20190711.2010.el
express-20140804.1922.el
exwm-surf-20171204.1140.el
face-shift-20190825.1131.el
fakespace-20120818.6.el
fancy-dabbrev-20200129.1933.el
fasd-20200925.1549.el
fetch-20131201.730.el
fillcode-20200524.2226.el
fixmee-20200512.1530.el
fix-muscle-memory-20160920.451.el
flames-of-freedom-20191202.1637.el
flappymacs-20171026.6.el
fliptext-20171124.2056.el
fm-bookmarks-20170104.1716.el
font-utils-20150806.1751.el
forecast-20200919.1348.el
format-sql-20150422.1333.el
friendly-remote-shell-20200828.1218.el
friendly-shell-20200828.1218.el
friendly-shell-command-20200828.1218.el
friendly-tramp-path-20200502.1032.el
fringe-current-line-20140111.411.el
fuo-20190812.927.el
furl-20150509.316.el
git-time-metric-20181116.2011.el
gntp-20141025.250.el
go-capf-20200814.1046.el
godoctor-20180710.2152.el
go-errcheck-20160723.43.el
go-gopath-20160705.1034.el
go-guru-20200822.1936.el
goldendict-20200731.1119.el
golden-ratio-20191028.1732.el
golint-20200302.2058.el
go-noisegate-20200503.1358.el
google-c-style-20200925.1727.el
go-playground-cli-20160503.914.el
go-rename-20200822.1936.el
go-translate-20200912.212.el
govc-20201020.1619.el
greek-polytonic-20190303.1358.el
habitica-20190721.1620.el
hardhat-20160414.1413.el
heaven-and-hell-20190713.1830.el
helm-bitbucket-20191022.2055.el
helm-catkin-20190506.1451.el
helm-charinfo-20170810.1231.el
helm-fuzzy-find-20171106.400.el
helm-gitignore-20170211.8.el
helm-itunes-20151013.648.el
helm-lean-20200930.604.el
helm-ls-svn-20190316.2203.el
helm-nixos-options-20191126.759.el
helm-prosjekt-20151127.1416.el
helm-spotify-20160905.2147.el
helm-sql-connect-20170319.1251.el
helm-youtube-20190101.1733.el
hercules-20200420.747.el
hexo-20200416.1410.el
hide-mode-line-20190922.115.el
hidepw-20200326.112.el
highlight-blocks-20190318.1557.el
highlight-defined-20181106.1718.el
highlight-indent-guides-20200820.2328.el
highlight-numbers-20181013.1744.el
highlight-quoted-20160123.1140.el
hippie-namespace-20140804.1922.el
historian-20200203.1927.el
hlint-refactor-20190115.900.el
hsluv-20181130.1607.el
httprepl-20141101.1734.el
http-twiddle-20160801.1915.el
hyperkitty-20200927.106.el
ido-exit-target-20170717.1851.el
ido-load-library-20140804.1922.el
ietf-docs-20190420.851.el
iflipb-20200731.1655.el
ignoramus-20160414.1409.el
imgbb-20180609.1649.el
import-js-20180709.1833.el
inherit-local-20170409.1649.el
inline-docs-20170523.450.el
insert-shebang-20200320.1537.el
ipcalc-20200809.1457.el
ipretty-20180606.522.el
isolate-20190808.731.el
ivy-clipmenu-20200302.1419.el
ivy-historian-20200203.1927.el
ivy-pass-20170812.1955.el
ivy-prescient-20201017.1519.el
ivy-todo-20200323.2005.el
ivy-xcdoc-20160917.1203.el
ivy-youtube-20181126.1039.el
jade-mode-20160525.1441.el
javap-mode-20120223.2208.el
jemdoc-mode-20170704.2027.el
jg-quicknav-20170809.130.el
jmt-mode-20201019.2342.el
journalctl-mode-20200607.910.el
jq-format-20190428.1434.el
json-reformat-20161027.1407.el
json-rpc-20200417.1629.el
kaleidoscope-20180723.1945.el
kapacitor-20190414.1908.el
keydef-20090428.1931.el
keyswap-20160813.957.el
kfg-20140909.611.el
kolon-mode-20140122.1134.el
kpm-list-20170924.1352.el
ksp-cfg-mode-20190414.2348.el
kubel-20201020.2043.el
kubernetes-helm-20190603.1533.el
kurecolor-20200113.2027.el
language-id-20200929.1339.el
learn-ocaml-20200526.1603.el
line-up-words-20200616.906.el
linkode-20200819.1409.el
lisp-local-20200409.1330.el
lispyscript-mode-20170720.1917.el
list-utils-20200502.1309.el
live-preview-20201010.1948.el
logpad-20190927.2043.el
lusty-explorer-20200602.424.el
malyon-20161208.2125.el
mandoku-tls-20171118.240.el
maxframe-20200617.218.el
mbsync-20200128.1053.el
memento-mori-20190719.1051.el
memoize-20200103.2036.el
meta-presenter-20190414.1720.el
milkode-20140927.529.el
minimal-session-saver-20140804.1922.el
mix-20200920.1500.el
mocha-20200729.1130.el
modern-fringes-20200321.1817.el
move-dup-20200819.940.el
mozc-20201018.345.el
mpages-20150710.1404.el
multi-20131013.1544.el
namespaces-20130326.2250.el
name-this-color-20151014.2030.el
nav-flash-20191204.1427.el
nemerle-20200622.1027.el
netrunner-20160910.2332.el
nixos-options-20191126.759.el
nix-sandbox-20191126.759.el
nlinum-hl-20190301.2117.el
noaa-20200420.1949.el
no-emoji-20180515.1837.el
ob-axiom-20200411.1031.el
ob-cfengine3-20191011.1721.el
ob-deno-20201019.101.el
ob-diagrams-20160407.1240.el
ob-elvish-20180427.1900.el
ob-html-chrome-20181219.1042.el
ob-mongo-20170720.1919.el
ob-translate-20170720.1919.el
ocamlformat-20201017.801.el
ocp-indent-20191023.1304.el
one-time-pad-encrypt-20160329.1513.el
operate-on-number-20150707.623.el
org-brain-20200930.2103.el
org-clock-split-20200331.526.el
org-easy-img-insert-20160915.2014.el
org-fragtog-20200703.229.el
org-journal-20201019.1813.el
  - this example is file without any license, thus proprietary.
  - author Bastian Bechthold, probably not intended, but in the file
    here is no license information
org-journal-list-20190221.2052.el
  - no license information known, proprietary thus by default
org-kanban-20200729.2120.el
  - no license informaiton, proprietary by default
org-mobile-sync-20180606.524.el
org-redmine-20170710.438.el
org-rtm-20160214.1236.el
org-seek-20161217.502.el
org-shoplist-20201003.1236.el
org-snooze-20181229.1424.el
org-static-blog-20200720.715.el
orgstrap-20201019.605.el
org-tanglesync-20200130.2301.el
org-themis-20160122.404.el
origami-predef-20200823.1054.el
otama-20160404.1049.el
outline-toc-20200401.1208.el
outorg-20190720.2002.el
pack-20191017.456.el
package+-20191112.4.el
package-filter-20170728.446.el
package-safe-delete-20150116.1607.el
panda-20200917.520.el
parsebib-20200513.2352.el
parse-csv-20160512.1723.el
passmm-20181130.1612.el
password-generator-20181229.1601.el
password-vault-20160126.1820.el
pc-bufsw-20201011.1918.el
pepita-20200917.519.el
persistent-scratch-20200921.2309.el
persistent-soft-20150223.1853.el
perspective-20200827.1945.el
phabricator-20160510.1425.el
phi-search-mc-20160324.1503.el
pinboard-popular-20180511.1726.el
plaster-20190622.818.el
point-stack-20200427.107.el
poly-ruby-20180905.929.el
poporg-20170403.751.el
prescient-20201017.1519.el
prettier-js-20190311.1604.el
prettify-greek-20160603.908.el
projector-20190703.1418.el
projekt-20150324.848.el
prompt-text-20190408.311.el
quilt-20190828.506.el
racer-20191001.2344.el
rainbow-identifiers-20141102.1526.el
random-splash-image-20170316.350.el
rcirc-groups-20170731.2101.el
rc-mode-20160913.1918.el
rdp-20120929.154.el
read-aloud-20170730.1127.el
redpen-paragraph-20200506.1558.el
region-occurrences-highlighter-20200815.1608.el
register-channel-20180926.2349.el
replace-symbol-20160518.12.el
replace-with-inflections-20180831.635.el
restclient-20200901.1442.el
restclient-helm-20200901.1442.el
rfc-mode-20201005.809.el
rivet-mode-20201013.1949.el
rjsx-mode-20200224.2149.el
ron-mode-20200830.1554.el
rubik-20180222.2014.el
rubocopfmt-20200713.1146.el
ruby-electric-20200328.1528.el
rufo-20191112.1609.el
rum-mode-20191004.1119.el
runtests-20150807.831.el
rust-mode-20200709.723.el
ryo-modal-20200907.647.el
sailfish-scratchbox-20200228.817.el
sass-mode-20190502.53.el
sayid-20200902.708.el
scheme-complete-20181029.1255.el
scratch-20190314.614.el
scratch-ext-20140104.516.el
selected-20200528.606.el
selectrum-prescient-20201017.1519.el
sfz-mode-20200716.1023.el
shadchen-20141102.1839.el
shadowenv-20200617.1556.el
sharper-20201014.335.el
shell-split-string-20151224.1008.el
shelltest-mode-20180501.141.el
shx-20200905.1918.el
simpleclip-20200211.1459.el
simple-httpd-20191103.1446.el
simple-rtm-20160222.1535.el
slirm-20160201.1425.el
slow-keys-20180831.459.el
smblog-20200424.938.el
smex-20151212.2209.el
smiles-mode-20160717.1120.el
smmry-20161024.2019.el
soar-mode-20190513.1436.el
solaire-mode-20201006.22.el
soundcloud-20150502.326.el
sourcetrail-20170411.57.el
space-theming-20200502.1032.el
spark-20160503.528.el
sparkline-20150101.1319.el
sprintly-mode-20121006.534.el
sproto-mode-20151208.403.el
sql-clickhouse-20191209.1443.el
sql-impala-20181218.410.el
sql-presto-20190113.1742.el
sql-sqlline-20191102.2120.el
steam-20190916.633.el
string-utils-20140804.1922.el
stripes-20200330.2022.el
stylus-mode-20160525.1441.el
svelte-mode-20201009.831.el
swap-regions-20180915.1346.el
sws-mode-20160525.1441.el
sxiv-20200803.1431.el
symbolword-mode-20201013.1049.el
synonymous-20180325.1817.el
syntactic-sugar-20140804.1922.el
sysctl-20200615.1824.el
ta-20160619.1645.el
teletext-20201019.700.el
teletext-yle-20201019.756.el
tern-20200708.143.el
tern-auto-complete-20200708.143.el
tern-context-coloring-20170102.2253.el
textmate-20110816.2146.el
tfsmacs-20200917.518.el
thrift-20201021.956.el
tinysegmenter-20141124.1013.el
tldr-20200330.1025.el
todoist-20200517.1825.el
todotxt-mode-20200228.952.el
toggle-20200609.1811.el
toml-20200901.1340.el
tql-mode-20170724.254.el
traad-20180730.48.el
tramp-hdfs-20201001.2022.el
trident-mode-20190410.2036.el
truthy-20140804.1922.el
try-20181204.236.el
tt-mode-20130804.1110.el
turkish-20170910.1511.el
twtxt-20200902.19.el
undercover-20200830.1638.el
unicode-enbox-20140804.1922.el
unicode-escape-20160620.1135.el
unicode-fonts-20200803.1335.el
unicode-troll-stopper-20190209.411.el
unicode-whitespace-20140804.1922.el
unipoint-20140113.2224.el
urscript-mode-20190219.1604.el
use-package-chords-20200805.1727.el
use-package-ensure-system-package-20200805.1727.el
utop-20200601.410.el
uuid-20120910.851.el
vale-mode-20190725.125.el
validate-html-20200913.2002.el
vcsh-20200226.1339.el
vector-utils-20140804.1922.el
viking-mode-20160705.2027.el
vmd-mode-20200727.701.el
walkman-20200418.1554.el
wdl-mode-20180831.1946.el
weak-ref-20200217.2200.el
web-mode-20201009.1633.el
wedge-ws-20140714.2149.el
whois-20200715.1715.el
wiki-nav-20200309.1323.el
wiki-summary-20181010.1824.el
wilt-20180220.854.el
wispjs-mode-20170720.1919.el
with-shell-interpreter-20200828.1217.el
wn-mode-20151110.552.el
wonderland-20130913.119.el
wordgen-20170803.1820.el
wttrin-20170614.1206.el
x86-lookup-20180528.1635.el
xah-css-mode-20200905.2218.el
xah-elisp-mode-20201014.1717.el
xah-find-20190314.2039.el
xah-fly-keys-20201012.759.el
xah-get-thing-20170821.1053.el
xahk-mode-20170821.1107.el
xah-lookup-20200420.1528.el
xah-math-input-20200217.740.el
xah-reformat-code-20200913.1702.el
xah-replace-pairs-20180508.249.el
xml-format-20191011.1159.el
xml-rpc-20200907.104.el
yaml-tomato-20151123.2111.el
yankpad-20200409.1747.el
ytel-20200725.1056.el
zeal-at-point-20180131.2354.el
znc-20160627.2032.el
zoom-20200708.1105.el
zpl-mode-20180906.1059.el
~/Programming/others/my-elpa/packages
$ 

Re: non-gnu elpa issue tracking

[Stefan Kangas]

Jean Louis <bugs@gnu.support> writes:

>> Are there any packages out there that don't use the GPL?  Could you
>> point us to some examples?
>
> Just to name a few, among more of them:

Thanks for the list.

> anki-mode-20200703.739.el
>   - no license, proprietary by default

It seems to be under the GPL:

    https://github.com/davidshepherd7/anki-mode/blob/master/LICENCE

MELPA requires a "GPL compatible license", according to

    https://github.com/melpa/melpa/blob/master/CONTRIBUTING.org

so I guess the "proprietary by default" packages you are speaking of are
simply missing the license information in the library itself?  Sounds
like that should be reported as a bug against those packages.

PS. I've opened a pull request against anki-mode to add the license
    header.

Re: non-gnu elpa issue tracking

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2020-12-10 00:48]:
> Jean Louis <bugs@gnu.support> writes:
> 
> >> Are there any packages out there that don't use the GPL?  Could you
> >> point us to some examples?
> >
> > Just to name a few, among more of them:
> 
> Thanks for the list.
> 
> > anki-mode-20200703.739.el
> >   - no license, proprietary by default
> 
> It seems to be under the GPL:
> 
>     https://github.com/davidshepherd7/anki-mode/blob/master/LICENCE

Not that I am personally asking. Please think of conveying software
and end user receiving software without license. If it is received
without license software is proprietary for the end user.

Software can be double licensed and be "same" inside. If there is no
license distributed with the software together a receiver cannot just
stumble upon some license on Internet and assume to put it
together. Then the repository is not verified to be author's
repository, it could be fork and licenses could be added there. For
GNU ELPA is good to verify apparently dubious packages if they are
licensed or not, and that they are sourced from their authors. There
are many problems related to licensing specifically on Github:
https://github.com/github/dmca/search?q=GPL&type=

> MELPA requires a "GPL compatible license", according to
> 
>     https://github.com/melpa/melpa/blob/master/CONTRIBUTING.org
> 
> so I guess the "proprietary by default" packages you are speaking of are
> simply missing the license information in the library itself?  Sounds
> like that should be reported as a bug against those packages.

Who am I to decide? If fetch a package from MELPA git repository and
there is no license in the file, it is proprietary for me. As simple
as that. Ask attorneys in the FSF if my statements do not make sense
but you still think there could be something.

Your software you may give to person Joe without license rendering it
proprietary for Joe. And you may give it to Jane under free software
license. Joe cannot ask Jane to give him a license to make it
free. Legal world does not work that way as he did not receive the
license from the author or other person licensed to convey software
and license to new receiver. 

> PS. I've opened a pull request against anki-mode to add the license
>     header.

Good if that package is destined for the non GNU ELPA, but if not
destined, then doing reports for licenses should be made by priorities
for those packages that developers want to have in non GNU ELPA.

Jean

Re: non-gnu elpa issue tracking

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2020-12-10 00:48]:
> MELPA requires a "GPL compatible license", according to
> 
>     https://github.com/melpa/melpa/blob/master/CONTRIBUTING.org

That does not matter really. It is not specific and software is
distributed from various authors without license or notice about where
is license located. Author could still hypothetically say, no, I did
not give you the software and it is clear there was no license. But
there was Copyright sign that it was reserved. Very clear. And that
packages are distributed without license from MELPA also shows that
there is no clear policy.

Reference:
https://www.gnu.org/licenses/license-list.html#NoLicense

It is mind bending. Even if they require from authors GPL compatible
license, nothing prevents MELPA to distribute proprietary software. I
know it is improbable intention, but that can happen. Case that
software have been conveyed from MELPA to users without license is
already legally serious issue. Practically less. But we have to look
at legal view points.

I know it is confusing and that practically all of those authors do
make free software. But without explicitly given license it is not
free.

Additinally, the claim that MELPA requires GPL compatible license is
fine but not proven to factually be so for all packages. In other
words one cannot rely on MELPA to do the proper legal verification.

We have Linux kernel that was meant to be free and requires GPL code
but it is not free really due to inclusion of those proprietary
blobs. Then we have for similar reason fully free GNU/Linux operating
systems endorsed by FSF on www.gnu.org Among them, several have their
tracking systems where developers inspect what is free, what is not
free, and may exclude software for reasons of freedom or
non-conclusive licenses. Example is pip Python package manager that
includes many UNKNOWN licenses. That is non-free and such package
cannot drive people to non-free software and is excluded from some of
those OS-es.

So if you find some package on MELPA and there is no license, then
maybe there is license in the original package and headers and package
need to be improved, so it is better looking into their original
repositories. It can be that MELPA changed some packages or did not
take the license properly.

Re: non-gnu elpa issue tracking

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

When we put a package into NonGNU ELPA we will look at its licensing
and verify that meets our criteria.  We won't decide based
on what MELPA says about it.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

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

  > > anki-mode-20200703.739.el
  > >   - no license, proprietary by default

  > It seems to be under the GPL:

  >     https://github.com/davidshepherd7/anki-mode/blob/master/LICENCE

That says AGPL version 3 _only_.  We should ask them to change to
AGPL version 3-or-later.

  > PS. I've opened a pull request against anki-mode to add the license
  >     header.

Would you like to raise this issue too?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

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

  > Then those packages where words "Free Software Foundation" do not
  > exist:

There is no need for a package in NonGNU ELPA to have those words in it,
as far as I can see.  Does anyone see why that should be required?

  > 0x0-20201014.1445.el
  >  - public domain CC0 1.0 questionable if free in other countries but
  >    US

CC0 is ok.

  > aggressive-fill-paragraph-20181106.1354.el
  >   - no license

That is nonfree software -- not ok.

  > alan-mode-20200723.1405.el
  >    - MIT

That is vague; it should specify the license.

  > anaphora-20180618.2200.el
  >   - public domain, in other countries can be proprietary by default

That is a problem.

  > anki-mode-20200703.739.el
  >   - no license, proprietary by default

Right, that is no good.

I can't draw much in the way of conclusions from your report
since you have not said how you got this list of packages that
you are searching through.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-12-10 07:33]:
> [[[ 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. ]]]
> 
>   > Then those packages where words "Free Software Foundation" do not
>   > exist:
> 
> There is no need for a package in NonGNU ELPA to have those words in it,
> as far as I can see.  Does anyone see why that should be required?

The comment was in the context of packages having other licenses, one way to find it to grep for those without those words.
It did work.

>   > 0x0-20201014.1445.el
>   >  - public domain CC0 1.0 questionable if free in other countries but
>   >    US
> 
> CC0 is ok.

Yes. After review I see that it is alright as it is not just simple "I give this to public domain" and it covers jurisdictions where it cannot apply same as in US.

>   > aggressive-fill-paragraph-20181106.1354.el
>   >   - no license
> 
> That is nonfree software -- not ok.
> 
>   > alan-mode-20200723.1405.el
>   >    - MIT
> 
> That is vague; it should specify the license.

I did not copy all words just few, maybe it does specify it. It was in the context of packages having other licenses than GPL.

> I can't draw much in the way of conclusions from your report
> since you have not said how you got this list of packages that
> you are searching through.

It is easy to git clone MELPA distribution, then produce all packages and grep through it. But I did not grep it all as many were deleted, short review is there only to show the pattern.

I have deleted hundreds of packages, but this grep below shows which packages have "public domain" but do not have "CC0"
But I think that my grep expression may not be correct.

$ zgrep -P 'public domain(?!CC0)' *.tar *.el
@-20181225.1438.tar:Binary file (standard input) matches
aio-20200610.1904.tar:Binary file (standard input) matches
autocrypt-20201002.1924.tar:Binary file (standard input) matches
chronometrist-20200905.1618.tar:Binary file (standard input) matches
elfeed-20200913.29.tar:Binary file (standard input) matches
elfeed-web-20200913.29.tar:Binary file (standard input) matches
elhome-20161025.2042.tar:Binary file (standard input) matches
emacsql-20200714.28.tar:Binary file (standard input) matches
emacsql-psql-20200714.28.tar:Binary file (standard input) matches
emacsql-sqlite-20200714.28.tar:Binary file (standard input) matches
finalize-20171218.1438.tar:Binary file (standard input) matches
github-elpa-20200129.422.tar:Binary file (standard input) matches
impatient-mode-20200723.2117.tar:Binary file (standard input) matches
insert-kaomoji-20200509.1112.tar:Binary file (standard input) matches
javadoc-lookup-20160214.31.tar:Binary file (standard input) matches
libgit-20200515.1759.tar:Binary file (standard input) matches
lice-20200607.103.tar:Binary file (standard input) matches
oauth-20130128.151.tar:Binary file (standard input) matches
oer-reveal-20201018.1759.tar:Binary file (standard input) matches
org-iv-20171001.1022.tar:Binary file (standard input) matches
osa-20200522.2103.tar:Binary file (standard input) matches
osa-chrome-20200627.1344.tar:Binary file (standard input) matches
redtick-20180424.2140.tar:Binary file (standard input) matches
shroud-20200124.1833.tar:Binary file (standard input) matches
skewer-mode-20200304.1142.tar:Binary file (standard input) matches
skewer-reload-stylesheets-20171119.359.tar:Binary file (standard input) matches
slime-20200810.224.tar:Binary file (standard input) matches
suomalainen-kalenteri-20201012.1937.tar:Binary file (standard input) matches
symex-20200928.1424.tar:Binary file (standard input) matches
0x0-20201014.1445.el:;; This file is in the public domain, to the extent possible under law,
anaphora-20180618.2200.el:;; This code is in the public domain.
anaphora-20180618.2200.el:;; public domain.  It is the author's belief that the portions adapted
anaphora-20180618.2200.el:;; from examples in "On Lisp" are in the public domain.
autotetris-mode-20180609.111.el:;; This is free and unencumbered software released into the public domain.
bang-20200930.1300.el:;; This file is in the public domain, to the extent possible under law,
chronometrist-goal-20200906.1522.el:;; This is free and unencumbered software released into the public domain.
dark-souls-20140314.2226.el:;; This file is in the public domain. Do whatever you want with it!
elx-20200728.819.el:    ("public-domain" . "^;+ This program belongs to the public domain")
elx-20200728.819.el:    ("public-domain" . "^;; This file is public domain")
elx-20200728.819.el:    ("public-domain" . "^;; No license, this code is under public domain, do whatever you want") ; company-go
emacsql-mysql-20200714.28.el:;; This is free and unencumbered software released into the public domain.
face-shift-20190825.1131.el:;; This file is in the public domain, to the extent possible under law,
fakespace-20120818.6.el:;; This is free and unencumbered software released into the public domain.
fillcode-20200524.2226.el:;; This code is in the public domain.
fliptext-20171124.2056.el:;; This file is in the public domain.
go-capf-20200814.1046.el:;; This file is in the public domain, to the extent possible under law,
hsluv-20181130.1607.el:;; The math is available under the public domain.
http-twiddle-20160801.1915.el:;; This program belongs to the public domain.
json-rpc-20200417.1629.el:;; This is free and unencumbered software released into the public domain.
keydef-20090428.1931.el:;; This program was placed in the public domain on 2001/01/18 by the
list-utils-20200502.1309.el:;;; tconc - this section of code is in the public domain
memoize-20200103.2036.el:;; This is free and unencumbered software released into the public domain.
pc-bufsw-20201011.1918.el:;; This is free and unencumbered software released into the public domain.
pc-bufsw-20201011.1918.el:;; software to the public domain. We make this dedication for the benefit
prompt-text-20190408.311.el:;; This is free and unencumbered software released into the public domain.
prompt-text-20190408.311.el:;; software to the public domain. We make this dedication for the benefit
rdp-20120929.154.el:;; This is free and unencumbered software released into the public domain.
replace-symbol-20160518.12.el:;; DOT net) and is placed in the public domain.
restclient-20200901.1442.el:;; This file is public domain software. Do what you want.
restclient-helm-20200901.1442.el:;; This file is public domain software. Do what you want.
shell-split-string-20151224.1008.el:;; This is free and unencumbered software released into the public domain.
shell-split-string-20151224.1008.el:;; software to the public domain. We make this dedication for the benefit
simple-httpd-20191103.1446.el:;; This is free and unencumbered software released into the public domain.
stripes-20200330.2022.el:;; License: public domain
sxiv-20200803.1431.el:;; This is free and unencumbered software released into the public domain.
trident-mode-20190410.2036.el:;; This is free and unencumbered software released into the public domain.
twittering-mode-20181121.1402.el:;;; Copyright: This code is in the public domain.
vcsh-20200226.1339.el:;; License: public domain
weak-ref-20200217.2200.el:;; This is free and unencumbered software released into the public domain.
wn-mode-20151110.552.el:;; public domain.
x86-lookup-20180528.1635.el:;; This is free and unencumbered software released into the public domain.

Re: non-gnu elpa issue tracking

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2020-12-09 19:59]:
> > 2) The acceptance or candidacy process for each package should be
> >    documented in some discrete method. Melpa does this using github's
> >    pull request feature, which documents the entire conversation related
> >    to the process of accepting a package.
> 
> Could you be more specific?  Do you mean that we should document it
> somewhere, or do you mean something else?


My opinion is that things should be transparent. But not to bother
developers it is best to keep it in the mailing list which is
transparent enough and durable over decades. 

> > 4) There's no link on the repository page[1] to the software being used
> >    to generate it, and the forge at which it is being developed. Having
> >    that would make the infrastructure friendlier for pull-requests, bug
> >    reports, and other feedback.
> 
> I assume that there will be a landing page similar to the one on
> elpa.gnu.org.

My opinion is that non-GNU ELPA and GNU ELPA both should never point
to any website that has any proprietary Javascript or promotes
proprietary software, specifically hyperlinks to Github better be
removed completely.

The other issue with licenses should be used to help those people who
left unlicensed packages to license them properly.

Re: non-gnu elpa issue tracking

[Thibaut Verron]

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

>
> My opinion is that non-GNU ELPA and GNU ELPA both should never point
> to any website that has any proprietary Javascript or promotes
> proprietary software, specifically hyperlinks to Github better be
> removed completely.
>

Without backlinks to the original repositories, how will people know where
to report bugs with packages installed from non-GNU ELPA?

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

Re: non-gnu elpa issue tracking

[Jean Louis]

* Thibaut Verron <thibaut.verron@gmail.com> [2020-12-10 02:23]:
> >
> > My opinion is that non-GNU ELPA and GNU ELPA both should never point
> > to any website that has any proprietary Javascript or promotes
> > proprietary software, specifically hyperlinks to Github better be
> > removed completely.
> >
> 
> Without backlinks to the original repositories, how will people know where
> to report bugs with packages installed from non-GNU ELPA?

My opinion is that nothing offered within Emacs, be it ELPA packages
or now non-GNU ELPA packages should guide users to any non-free
software, especially not websites with non-free Javascript like
Github.

Author name should be there, email address and there can be URL as
per: (info "(elisp) Simple Packages")

I would change that URL to point to non-GNU ELPA repository as it
becomes not only plain distributor but slight fork of the
package. There is nothing wrong with it. People can still use author's
name and email to report directly.

Remember that this does not prevent other users of any other website
such as MELPA to use their hyperlinks how they like. T

This opinion is for specifically for Emacs that should never point to
non-free websites and relates to ELPA as well.

So I do not see any real problem there. Those using MELPA will do what
they wish. And those using non-GNU ELPA would report there where
developers decide, but not on Github, provided this type of proposal
is accepted.

Re: non-gnu elpa issue tracking

[Thibaut Verron]

Le jeu. 10 déc. 2020 à 09:32, Jean Louis <bugs@gnu.support> a écrit :
>
> * Thibaut Verron <thibaut.verron@gmail.com> [2020-12-10 02:23]:
> > >
> > > My opinion is that non-GNU ELPA and GNU ELPA both should never point
> > > to any website that has any proprietary Javascript or promotes
> > > proprietary software, specifically hyperlinks to Github better be
> > > removed completely.
> > >
> >
> > Without backlinks to the original repositories, how will people know where
> > to report bugs with packages installed from non-GNU ELPA?
>
> My opinion is that nothing offered within Emacs, be it ELPA packages
> or now non-GNU ELPA packages should guide users to any non-free
> software, especially not websites with non-free Javascript like
> Github.

Would gitlab be acceptable, at the very least?

>
> Author name should be there, email address and there can be URL as
> per: (info "(elisp) Simple Packages")
>
> I would change that URL to point to non-GNU ELPA repository as it
> becomes not only plain distributor but slight fork of the
> package. There is nothing wrong with it. People can still use author's
> name and email to report directly.

I personally would be annoyed if users started reporting bugs directly
to my e-mail. I cannot imagine how it would be for high-traffic
packages.

And what about packages with extensive guidelines for reporting bugs?
Should they now include those guidelines in the package description?
And would you amend those guidelines to remove references to github,
too?

I thought that the point of non-GNU ELPA was to bridge the gap between
the emacs developers and the "community developers". But this kind of
minor ideological changes, in my opinion, is more likely to antagonize
developers.

Am I correct to understand that if some developers decide that they do
not want their package included in non-GNU ELPA, the only way that
they can enforce this decision is to use a less permissive license for
future releases?

I don't think that we want to encourage such a choice.

> Remember that this does not prevent other users of any other website
> such as MELPA to use their hyperlinks how they like. T
>
> This opinion is for specifically for Emacs that should never point to
> non-free websites and relates to ELPA as well.
>
> So I do not see any real problem there. Those using MELPA will do what
> they wish.

I thought the goal of non-GNU ELPA was to make MELPA necessary only
for non-free packages, and thus useless of the vast majority of users.

If "non-free" now includes all those packages whose developers don't
want to deal with issues outside of github, it can become a lot more
extensive.

> And those using non-GNU ELPA would report there where
> developers decide, but not on Github, provided this type of proposal
> is accepted.

What is "there" in this context? And who are "developers"?

Re: non-gnu elpa issue tracking

[Stefan Kangas]

Thibaut Verron <thibaut.verron@gmail.com> writes:

> Would gitlab be acceptable, at the very least?

There are no requirements that the git repository should not be hosted
on Gitlab, Microsoft Github or any other place.  This is already the
case on GNU ELPA, and NonGNU ELPA will not change that.

> I thought that the point of non-GNU ELPA was to bridge the gap between
> the emacs developers and the "community developers". But this kind of
> minor ideological changes, in my opinion, is more likely to antagonize
> developers.

To be clear, no such changes are planned.

> Am I correct to understand that if some developers decide that they do
> not want their package included in non-GNU ELPA, the only way that
> they can enforce this decision is to use a less permissive license for
> future releases?

Correct, that is in general how free software works.

But they could also, you know, tell us that they don't want it included.
There is no reason to suspect that it would not be taken into
consideration.

I don't think it is prudent to tie our hands in advance by saying that
we will never, under any circumstances, distribute a package unless its
maintainer wants to work with us.

> I thought the goal of non-GNU ELPA was to make MELPA necessary only
> for non-free packages, and thus useless of the vast majority of users.

AFAIK, the goal is to provide a curated and free package archive that
can be enabled by default in Emacs.

The aim is not to make MELPA "useless", in fact it would be better if it
could become more useful, for example by not including packages that
encourages the use of non-free software.

> If "non-free" now includes all those packages whose developers don't
> want to deal with issues outside of github, it can become a lot more
> extensive.

NonGNU ELPA has no rules detailing how a maintainer should deal with
bugs.

Re: non-gnu elpa issue tracking

[Thibaut Verron]

Le jeu. 10 déc. 2020 à 12:23, Stefan Kangas <stefankangas@gmail.com> a écrit :
>
> Thibaut Verron <thibaut.verron@gmail.com> writes:
>
> > Would gitlab be acceptable, at the very least?
>
> There are no requirements that the git repository should not be hosted
> on Gitlab, Microsoft Github or any other place.  This is already the
> case on GNU ELPA, and NonGNU ELPA will not change that.

Thank you, that's a very useful clarification.

> > Am I correct to understand that if some developers decide that they do
> > not want their package included in non-GNU ELPA, the only way that
> > they can enforce this decision is to use a less permissive license for
> > future releases?
>
> Correct, that is in general how free software works.
>
> But they could also, you know, tell us that they don't want it included.
> There is no reason to suspect that it would not be taken into
> consideration.
>
> I don't think it is prudent to tie our hands in advance by saying that
> we will never, under any circumstances, distribute a package unless its
> maintainer wants to work with us.

I understand and agree with the intention behind both paragraphs, but
they could very easily come into conflict. :)

>
> > I thought the goal of non-GNU ELPA was to make MELPA necessary only
> > for non-free packages, and thus useless of the vast majority of users.
>
> AFAIK, the goal is to provide a curated and free package archive that
> can be enabled by default in Emacs.
>
> The aim is not to make MELPA "useless", in fact it would be better if it
> could become more useful, for example by not including packages that
> encourages the use of non-free software.

I didn't mean "useless" but "unnecessary". As of now, the easiest way
to install Magit or Projectile is by activating Melpa, which exposes
users to packages promoting non-free software. With NonGNU ELPA, a
large portion of users will never need to activate Melpa.

But for those who will need it, I suspect that those packages
promoting non-free software will be the reason.

If Melpa stopped including those packages, then they would find a home
in some other software repository and the situation would be the same
mutatis mutandis. But in any case, with NonGNU ELPA providing the
useful and purely free packages, users won't be accidentally exposed
to the ones promoting non-free software.

Anyway, that's only how I see it, and the issue is orthogonal to the
question at hand.

>
> > If "non-free" now includes all those packages whose developers don't
> > want to deal with issues outside of github, it can become a lot more
> > extensive.
>
> NonGNU ELPA has no rules detailing how a maintainer should deal with
> bugs.

That was in the context of the discussion: if there were to be a rule
that a package description on a gnu.org page cannot link to github, it
would force the maintainers to collect bugs and issues in another way
in addition to github.

So, again, thanks for the clarification.

> > As I said, hypothethical talk is not useful. Bring a package and ask
> > if such can be included. Let us see, that we do not create problems
> > out of nothing.

> Indeed.

For instance: https://github.com/Fuco1/smartparens
The readme and all files have multiple links to non-free websites.

Re: non-gnu elpa issue tracking

[Jean Louis]

* Thibaut Verron <thibaut.verron@gmail.com> [2020-12-10 17:26]:
> For instance: https://github.com/Fuco1/smartparens
> The readme and all files have multiple links to non-free websites.

I hope that package will conform to requirements that it can be
included.

That is how I understand it. It looks popular and useful.

Can this package be included?

Jean

Re: non-gnu elpa issue tracking

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

  > * Thibaut Verron <thibaut.verron@gmail.com> [2020-12-10 17:26]:
  > > For instance: https://github.com/Fuco1/smartparens
  > > The readme and all files have multiple links to non-free websites.

The distinction between free and non-free is defined for _works_,
which can be copied.  To call a web site "non-free" is not defined.  See
https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html.

I don't know what Thibaut had in mind when he categorized some web
sites as "non-free", so I have no idea whether there is a real issue
in that package at all.  Maybe it is fully ok.

Please remember that we have a written standard for referring to web
sites.  It is the node References in the GNU Coding Standards.  If you
want to discuss questions like this, please read it carefully so that
you don't get trapped in spurious arguments criticizing policies that
are _not our actual policies_.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Jean Louis]

* Thibaut Verron <thibaut.verron@gmail.com> [2020-12-10 12:15]:
> Le jeu. 10 déc. 2020 à 09:32, Jean Louis <bugs@gnu.support> a écrit :
> >
> > * Thibaut Verron <thibaut.verron@gmail.com> [2020-12-10 02:23]:
> > > >
> > > > My opinion is that non-GNU ELPA and GNU ELPA both should never point
> > > > to any website that has any proprietary Javascript or promotes
> > > > proprietary software, specifically hyperlinks to Github better be
> > > > removed completely.
> > > >
> > >
> > > Without backlinks to the original repositories, how will people know where
> > > to report bugs with packages installed from non-GNU ELPA?
> >
> > My opinion is that nothing offered within Emacs, be it ELPA packages
> > or now non-GNU ELPA packages should guide users to any non-free
> > software, especially not websites with non-free Javascript like
> > Github.
> 
> Would gitlab be acceptable, at the very least?

Not my decision. Developers decide on that.

Maybe people wish to see this reference:
https://www.gnu.org/software/repo-criteria-evaluation.html

There are many similar.

Codeberg.org (Germany)
https://codeberg.org

Sourcehut.org
https://sourcehut.org

Trisquel GNU/Linux-libre Git Repositories
https://devel.trisquel.info/groups/trisquel

Pagure
https://pagure.io/pagure

Fosshost
https://fosshost.org/

GitGud - Fast and Free Git Hosting
https://gitgud.io/users/sign_in

> > Author name should be there, email address and there can be URL as
> > per: (info "(elisp) Simple Packages")
> >
> > I would change that URL to point to non-GNU ELPA repository as it
> > becomes not only plain distributor but slight fork of the
> > package. There is nothing wrong with it. People can still use author's
> > name and email to report directly.
> 
> I personally would be annoyed if users started reporting bugs directly
> to my e-mail. I cannot imagine how it would be for high-traffic
> packages.

Packages live their URL and author's name. I do not think that
licenses forbid changing the URL. Normally one has to tell who are
authors and provide license. From that viewpoint whatever authors
write in the package commentary or README file will be used by users.

non-GNU ELPA is more similar to a fork. As the control will be
maintained which packages are distributed to users and what is changed
there or modified. In that sense it can be that for some features we
start reporting to non-GNU ELPA, and not to upstream. We discussed
here that it is desirable to make relations with upstream authors. But
what if they do not wish? Then packages, as they are free software,
may be distributed and modified in non-GNU ELPA without notification
to author.

> And what about packages with extensive guidelines for reporting bugs?
> Should they now include those guidelines in the package description?
> And would you amend those guidelines to remove references to github,
> too?

I don't think so and I am not authorized to make statements on that. I
think that general questions do not lead to useful solution. There is
no need to make hypothetical conclusions as there is no specific
package to talk about.

> I thought that the point of non-GNU ELPA was to bridge the gap between
> the emacs developers and the "community developers". But this kind of
> minor ideological changes, in my opinion, is more likely to antagonize
> developers.

I see it quite contrary. People will get interested and will apply to
non-GNU ELPA with their proposals. There are limits mostly related to
free software principles, there are packaging guidelines, there is
certai limit how many packages can be handled by developers in what
period of times. By opening non-GNU ELPA GNU project is doing exactly
what you said, providing a bridge that any Emacs Lisp developers,
may get their packages easier discovered by default.

We shall not forget that option to include the package to GNU ELPA
always existed and exists today. Everybody is welcome. Naturally those
who have proprietary packages would need to adopt their license for
that to take place.

Sorry, I cannot see minor ideological changes, in fact I see no
ideological change at all since decades.

If we wish to compare it to MELPA, we today discovered that MELPA
practically distributes proprietary software. Then a person discovered
that the license does exist somewhere else on Github. If I would have
package there and license in the same repository that would make me
feel unjust that somebody like MELPA is fetching my package and not
distributing license with it. In that sense MELPA is changin the
author's package without author's knowledge. That is all by mistake
and some neglect, not by bad intention.

While changing author's package MELPA is not antagonizing anybody, so
will non-GNU ELPA not antagonize anybody. Quite contrary, people wish
to integrate with each other and help each other.

As I said, hypothethical talk is not useful. Bring a package and ask
if such can be included. Let us see, that we do not create problems
out of nothing. I am sure that Emacs developers already have lists of
packages in their mind and will come to it soon.

> Am I correct to understand that if some developers decide that they do
> not want their package included in non-GNU ELPA, the only way that
> they can enforce this decision is to use a less permissive license for
> future releases?
> 
> I don't think that we want to encourage such a choice.

Maybe you review again what is free software. As I already pointed, if
you have account on Github, within seconds you can already fork other
people's software, and you do not need to ask people about that. They
have already given explicit permission that you may copy software,
modify it, distribute it.

I do not see practical reason why would a developer object that free
softwar package is distributed, copied, modified from some other place
than original repository? If they do object, they can tell their
opinion, but nevertheless the rights obtained by free software license
cannot be just taken back as author wish and want.

Thus the hypothetical case you explained above I cannot see happening.

Quite contrary I feel that when Emacs packages are distributed that
authors have certain pleasure when other people use the package how
they wish and want.

> > Remember that this does not prevent other users of any other website
> > such as MELPA to use their hyperlinks how they like. T
> >
> > This opinion is for specifically for Emacs that should never point to
> > non-free websites and relates to ELPA as well.
> >
> > So I do not see any real problem there. Those using MELPA will do what
> > they wish.
> 
> I thought the goal of non-GNU ELPA was to make MELPA necessary only
> for non-free packages, and thus useless of the vast majority of
> users.

That would be negative goal that goes into wrong direction. If MELPA
is useful or not useful it does not matter.

It is different project with a different set of ethical
principles. GNU is different project with different sent of ethical
principles. Goal for GNU is to provide free operating system and for
Emacs packages to be useful free software accessible by default
without user having to stumble upon or being guided into non-free or
proprietary software.

Goal is not to make other repository useless. Various groups and
communities do what they want. GNU project is always proposing to use
free software, to distribute licenses correctly, it teaches users
about free software. If some separate project like MELPA provided
non-free software then such will get less and less recommended by GNU
project or never at all. As simple as that.

It is analogous to Archlinux that has open policy to accept any
software including proprietary as long as authors agree that it can be
distributed from Archlinux. GNU project cannot possibly recommend
Archlinux to users. That does not mean that GNU project is working
against Archlinux to make it useless. Nothing changed fundamentally in
GNU project, what changed is in those other communities.

> If "non-free" now includes all those packages whose developers don't
> want to deal with issues outside of github, it can become a lot more
> extensive.

That is not definition of non-free. Remember that my opinion is
personal, not authorized for GNU project to speak of final decisions.

If I understand it well you mean that some issues to maintain packages
will be sent by Emacs users and such issues may not arrive to
developers of upstream package? People discussed it already here that
non-GNU ELPA should establish relations with authors so that authores
can contribute directly to non-GNU ELPA.

Compare that to Github fork:

1. User clicks to fork the package. Author is not asked
   anything. Package is just forked. They may not even speak to author
   ever.

2. Or telling author kindly that non-GNU ELPA is now interested to
   distribute the package and if author wish to maintain it directly.

Those questions rather apply to Github, not to GNU.

Please remember that license gives rights to copy, modify, distribute
packages as users wish and want.

When doing so, I could change all original URLs and point back to my
URL as long as license is respected. I could now say: I do not wish to
take any reports or bugs, issues, as they are not welcome. That is
what many people do when they finish with the package. They will say
take it and do what you wish with it, it is free software, but I have
not time for it.

> > And those using non-GNU ELPA would report there where
> > developers decide, but not on Github, provided this type of proposal
> > is accepted.
> 
> What is "there" in this context? And who are "developers"?

Remember, me not authorized for Emacs developers.

I am expressing personal opinion. Emacs developers will decide how
they will publish software they package in non-GNU ELPA. They have yet
to say how to report bugs on such packages.

I would not like if GNU project would start pointing to people: go
back to Github and report bugs there for reason that users are driven
or guided to non-free software and unethical software repositories.

When making those comparisons and analyzes I suggest that you first
compare it to what is already at hand and present in the world.

Example is Melpa, you are free to pull sources for Melpa and open up
your own server providing your own ELPA. It is trivial to do so as
they have given website, and scripts available for everybody. Maybe
main problem is that people do not know how to setup their own
servers. When doing so, pulling software, everybody is free to modify
what is free software and offer to others. Melpa is doing that on each
software package by modifying their version numbers and other meta
data. Isn't modification of a version number against author's
decision? I think it is. But it is free software and Melpa is free to
do what they wish. They can say that version number is 2 when it is
1. Free software.

GNU/Linux distributions such as Debian modify the software with
patches. They desire but do not need to ask original authors. What is
more important is maintainer of a package who does the job and
prepares package to be compatible with other packages. Imagine if
Debian would be waiting for authors to start acting upon something
they maybe long forgotten or do not maintain.

Companies like Redhat have been modifying Linux kernel. Many companies
modified Linux kernel without necessarily informing developers. Free
software. But as long as kernel is distributed developers could get
those modifications back. 

Compare those thoughts of today to that what is already present in the
world to see that there is nothing different in non-GNU ELPA in the
context of software modification and distribution.

Jean

Re: non-gnu elpa issue tracking

[Stefan Kangas]

Jean Louis <bugs@gnu.support> writes:

> non-GNU ELPA is more similar to a fork.

I believe this is a misconception that risks damaging the reputation and
success of NonGNU ELPA.  According to Wikipedia, "a project fork happens
when developers take a copy of source code from one software package and
start independent development on it, creating a distinct and separate
piece of software".  This is not what NonGNU ELPA is about.

Yes, NonGNU ELPA will have support for maintaining forks (as does GNU
ELPA, MELPA, Marmalade, etc.).  Richard has pointed out that it is
important that we have such support in case it is necessary.  But in my
view this is still largely hypothetical and would in any case be applied
only in exceptional cases.

For NonGNU ELPA, we will seek to cooperate with existing package
maintainers, that will ideally for the most part maintain their packages
as they have done up until their inclusion in the archive.  My hope
would be that we could also contribute back some of our knowledge and
help improve the package from a technical (and sometimes ethical)
standpoint.

> As I said, hypothethical talk is not useful. Bring a package and ask
> if such can be included. Let us see, that we do not create problems
> out of nothing.

Indeed.

Re: non-gnu elpa issue tracking

[Stefan Monnier]

> Am I correct to understand that if some developers decide that they do
> not want their package included in non-GNU ELPA, the only way that
> they can enforce this decision is to use a less permissive license for
> future releases?

Yes and no: the legality of distributing an ELisp package with a license
that is not compatible with GPLv3+ is dubious (because that code
likely can't run without linking to Emacs which is GPLv3+).

So it's not clear whether they could legally use a less
permissive license.


        Stefan

Re: non-gnu elpa issue tracking

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-12-10 18:49]:
> > Am I correct to understand that if some developers decide that they do
> > not want their package included in non-GNU ELPA, the only way that
> > they can enforce this decision is to use a less permissive license for
> > future releases?
> 
> Yes and no: the legality of distributing an ELisp package with a license
> that is not compatible with GPLv3+ is dubious (because that code
> likely can't run without linking to Emacs which is GPLv3+).
> 
> So it's not clear whether they could legally use a less
> permissive license.

I guess that quoted paragraph is meant to say that when package is in
non-GNU ELPA under GNU GPL let us say, and author objects to be
included in non-GNU ELPA, which is unlikely, that such author could
change license of package.

For your quote paragraph, Stefan, I am not sure on that. I know
exactly what you mean. And I still do not know the final answer.

Emacs Lisp is programming language. Software can be written in Perl,
Lua, Forth, CLISP, GCL, Guile and can be proprietary software, people
do that. Would then Emacs package be considered extension of Emacs or
program in itself, that is what I do not know. Maybe if program uses
Emacs interface cannot be proprietary. But if it does not use the
interface then maybe it could. Not that I want, but those are doubts.

Re: non-gnu elpa issue tracking

[Stefan Monnier]

> For your quote paragraph, Stefan, I am not sure on that. I know
> exactly what you mean. And I still do not know the final answer.

What I'm saying is that if they want a package removed, they should ask
for it.  Trying to get this result indirectly by using a license that's
not compatible with the GPLv3+ not only is a round-about way to go about
it, but it's not even clear if it would be legal because it's not clear
whether it's legal to distribute ELisp packages with a license
incompatible with the GPLv3+.

> But if it does not use the interface then maybe it could.

Indeed, but those ELisp packages which don't make use of an
Emacs-specific interface are pretty rare.


        Stefan

Re: non-gnu elpa issue tracking

[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 personally would be annoyed if users started reporting bugs directly
  > to my e-mail.

That's a minor in a side issue in a discussion.  It's not a policy
decision or even a proposal.  Please don't worry about it so much.

Obviously, if developers specify an address for reporting bugs -- as
we do for Emacs -- we will direct users there.

What about if there is no email address for reporting bugs?

I personally am always annoyed when I can't report a bug in a program
by email.  To me it says, "To report a bug, climb these hurdles first."
Usually I won't even try.

But if a package lets people report bugs via a web page, and they can
do this without running nonfree software, we will direct users to that
page.  Of course.

No one here is interested in being gratuitously uncooperative.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

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

  > > My opinion is that non-GNU ELPA and GNU ELPA both should never point
  > > to any website that has any proprietary Javascript or promotes
  > > proprietary software, specifically hyperlinks to Github better be
  > > removed completely.

That is more strict than our actual criteria for references to
other material.  Please see the GNU Coding Standards, node References.

We can refer people to GitHub for the purposes of doing things which
GitHub lets you do without your running nonfree software (including JS
code).

Please do not simplify this rule, because simplifying it leads to
something either too strict or too lax.  Too lax means we encourage
people to give up their freedom.  Too strict means we ask users to
make annoying gratuitous sacrifices.

  > Without backlinks to the original repositories, how will people know where
  > to report bugs with packages installed from non-GNU ELPA?

We should always tell users a way to report bugs in the package _provided_
users can do it without running nonfree software (including JS).

If there is no way to do that, we probably should not include the
package in NonGNU ELPA, and talk with the package developers about
providing a way to report bugs in their package from the Free World.

Does GitHub let users report bugs in a package without running nonfree
software (including JS code)?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Thibaut Verron]

> We should always tell users a way to report bugs in the package _provided_
> users can do it without running nonfree software (including JS).
>
> If there is no way to do that, we probably should not include the
> package in NonGNU ELPA, and talk with the package developers about
> providing a way to report bugs in their package from the Free World.
>
> Does GitHub let users report bugs in a package without running nonfree
> software (including JS code)?

As far as I remember from a previous discussion, it is possible to use
github with javascript disabled, but creating an account requires
running non-free javascript for the captcha. And it is not possible to
open or comment on issues without an account.

Re: non-gnu elpa issue tracking

[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 far as I remember from a previous discussion, it is possible to use
  > github with javascript disabled, but creating an account requires
  > running non-free javascript for the captcha. And it is not possible to
  > open or comment on issues without an account.

Assuming someone who knows for certain confirms that information, I
have to conclude that reporting bugs via GitHub comments is not an
ethical way to accept bug reports.  We cannot direct users to report
bugs in the package that way.  We should edit the README file to
remove that.

But there are other kinds of arrangements we can ask to make with the
package developers, such as

* The developers check bug-gnu-emacs for reports about their package.

* Establish an email address which will forward to them,
and give that as the way to report bugs in that package.

* A volunteer relayer who already has a GitHib account checks
bug-gnu-emacs for reports about that package, and enters them in
GitHib as comments.  The developers will have to reach the OP by email
-- the relayer would not want to keep relaying every conversation
for its whole length.

If the developers propose something else, and it meets the moral
requirements and isn't too much work, and we can do it, we should be
flexible.  I expect most packages won't get a bug report every month.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Tim Cross]

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

Bottom line is that if packages in non-GNU ELPA are hosted on Github, like
it or not, you are encouraging the use of Github. Yes, there are many
Github features you can access from the command line and via other means,
like commenting on issues via email, but these other mechanisms typically
take more effort and are not as convenient (and have limitations - you
cannot use markup when commenting on issues via email for example).

The non-GNU ELPA is supposed to be a repository for packages which are GPL
compliant and it is a reasonable expectation that those who make their
packages GPL compliant do so because they support the philosophical goals
of the FSF. Therefore, I don't think it is too much to ask that they also
have those packages hosted on a platform which also supports these same
philosophical goals. As I understand it, non-GNU ELPA is not supposed to be
a repository for all other packages where the author doe snot want to
assign copyright to the FSF. It is supposed to be for all other GPL
compliant packages where the author does not want to assign copyright to
the FSF.

I think a mandatory requirement should simply be that any packages which go
into non-GNU ELPA are hosted on an approved platform. We could point to a
list of such hosting providers e.g.
https://www.gnu.org/software/repo-criteria-evaluation.html and say Grade C
or better only. .

This will also have the added incentive of encouraging better hosting
options. It might even encourage GitLab for example, to enhance their
environment to meet Class B.

Many people have selected Github for hosting simply because it was the best
known solution. With a little encouragement, they would probably be willing
to move to at least GitLab, which offers many of the similar convenience
features of Github.  Being able to host your package in non-GNU ELPA might
be that encouragement.

BTW I also think the questions regarding openess, arguments, not hurting
feelings etc can be largely avoided by simply having clear well publicised
policy which outlines the requirements for inclusion in non-GNU ELPA. The
README is a good start, but it will likely take a few rounds of editing to
get it right and make it clear (a challenging task, but not impossible) and
a documented process for requesting a review for a rejected package or a
package which has been included which someone thinks is not compliant.

On Sat, 12 Dec 2020 at 16:36, 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. ]]]
>
>   > As far as I remember from a previous discussion, it is possible to use
>   > github with javascript disabled, but creating an account requires
>   > running non-free javascript for the captcha. And it is not possible to
>   > open or comment on issues without an account.
>
> Assuming someone who knows for certain confirms that information, I
> have to conclude that reporting bugs via GitHub comments is not an
> ethical way to accept bug reports.  We cannot direct users to report
> bugs in the package that way.  We should edit the README file to
> remove that.
>
> But there are other kinds of arrangements we can ask to make with the
> package developers, such as
>
> * The developers check bug-gnu-emacs for reports about their package.
>
> * Establish an email address which will forward to them,
> and give that as the way to report bugs in that package.
>
> * A volunteer relayer who already has a GitHib account checks
> bug-gnu-emacs for reports about that package, and enters them in
> GitHib as comments.  The developers will have to reach the OP by email
> -- the relayer would not want to keep relaying every conversation
> for its whole length.
>
> If the developers propose something else, and it meets the moral
> requirements and isn't too much work, and we can do it, we should be
> flexible.  I expect most packages won't get a bug report every month.
>
> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
>

-- 
regards,

Tim

--
Tim Cross

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

Re: non-gnu elpa issue tracking

[Thibaut Verron]

Le sam. 12 déc. 2020 à 07:37, Tim Cross <theophilusx@gmail.com> a écrit :
>
> Bottom line is that if packages in non-GNU ELPA are hosted on Github, like it or not, you are encouraging the use of Github. Yes, there are many Github features you can access from the command line and via other means, like commenting on issues via email, but these other mechanisms typically take more effort and are not as convenient (and have limitations - you cannot use markup when commenting on issues via email for example).
>
> The non-GNU ELPA is supposed to be a repository for packages which are GPL compliant and it is a reasonable expectation that those who make their packages GPL compliant do so because they support the philosophical goals of the FSF.

GPL licensing is what's the default elisp auto-insert inserts. And
apparently it's not even clear if it is legal to license packages
under any incompatible license.

I wouldn't read a statement of support in the mere fact that a package
if GPL compliant.

I also recall a discussion where some developers were worried that
assigning a copyright to the FSF was an official statement of
philosophical support, and that it was a statement they were not
willing to make. The official answer was that there is no such
statement in the copyright.

> Therefore, I don't think it is too much to ask that they also have those packages hosted on a platform which also supports these same philosophical goals. As I understand it, non-GNU ELPA is not supposed to be a repository for all other packages where the author doe snot want to assign copyright to the FSF. It is supposed to be for all other GPL compliant packages where the author does not want to assign copyright to the FSF.

Or can't. In a lot of cases it turns out that contacting all
contributors to obtain copyright assignment is a difficult task, or
that some contributors are not legally allowed to transfer their
copyright.

> I think a mandatory requirement should simply be that any packages which go into non-GNU ELPA are hosted on an approved platform. We could point to a list of such hosting providers e.g. https://www.gnu.org/software/repo-criteria-evaluation.html and say Grade C or better only. .

There is no such requirement for GNU ELPA at the moment.

> This will also have the added incentive of encouraging better hosting options. It might even encourage GitLab for example, to enhance their environment to meet Class B.

Couldn't it just as well be an occasion to encourage Github to improve?

> Many people have selected Github for hosting simply because it was the best known solution. With a little encouragement, they would probably be willing to move to at least GitLab, which offers many of the similar convenience features of Github.  Being able to host your package in non-GNU ELPA might be that encouragement.

There is a lot of inertia involved in relocating a package with
hundreds of contributors.

I agree that some of the difficulties posed by copyright assignment do
not apply for relocation (e.g. that one contributor 7 years ago whom
nobody can contact), but there is an effort involved in both.

Re: non-gnu elpa issue tracking

[Tim Cross]

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

On Sat, 12 Dec 2020 at 21:08, Thibaut Verron <thibaut.verron@gmail.com>
wrote:

> Le sam. 12 déc. 2020 à 07:37, Tim Cross <theophilusx@gmail.com> a écrit :
> >
>
>
> I also recall a discussion where some developers were worried that
> assigning a copyright to the FSF was an official statement of
> philosophical support, and that it was a statement they were not
> willing to make. The official answer was that there is no such
> statement in the copyright.
>

As non-GNU ELPA is primarily about having a repository of packages which
fit with the FSF philosophy and which do not require copyright assignment,
concerns relating to copyright assignment are not relevant.

>
> > Therefore, I don't think it is too much to ask that they also have those
> packages hosted on a platform which also supports these same philosophical
> goals. As I understand it, non-GNU ELPA is not supposed to be a repository
> for all other packages where the author doe snot want to assign copyright
> to the FSF. It is supposed to be for all other GPL compliant packages where
> the author does not want to assign copyright to the FSF.
>
> Or can't. In a lot of cases it turns out that contacting all
> contributors to obtain copyright assignment is a difficult task, or
> that some contributors are not legally allowed to transfer their
> copyright.
>

Copyright assignment is irrelevant with respect to non-GNU ELPA. It is sort
of the point.

>
> > I think a mandatory requirement should simply be that any packages which
> go into non-GNU ELPA are hosted on an approved platform. We could point to
> a list of such hosting providers e.g.
> https://www.gnu.org/software/repo-criteria-evaluation.html and say Grade
> C or better only. .
>
> There is no such requirement for GNU ELPA at the moment.
>

Perhaps there should be. However, GNU ELPA consists of code which has had
copyright assigned to the FSF, so I guess that is their call.

>
> > This will also have the added incentive of encouraging better hosting
> options. It might even encourage GitLab for example, to enhance their
> environment to meet Class B.
>
> Couldn't it just as well be an occasion to encourage Github to improve?
>
>
I strongly doubt it. Github has become a significant platform for Microsoft
and I see little interest from them in supporting the philosophy and goals
of the FSF.



> > Many people have selected Github for hosting simply because it was the
> best known solution. With a little encouragement, they would probably be
> willing to move to at least GitLab, which offers many of the similar
> convenience features of Github.  Being able to host your package in non-GNU
> ELPA might be that encouragement.
>
> There is a lot of inertia involved in relocating a package with
> hundreds of contributors.
>

Hence adding a requirement to be hosted on a platform which furthers FSF
goals to help combat that inertia. People will have the choice - if they
want their package to go into non-GNU ELPA, move it to a more compliant
hosting environment or leave it where it is and don't worry about getting
your package into non-GNU ELPA.

>
> I agree that some of the difficulties posed by copyright assignment do
> not apply for relocation (e.g. that one contributor 7 years ago whom
> nobody can contact), but there is an effort involved in both.
>

Copyright issues are not relevant for non-GNU ELPA.
-- 
regards,

Tim

--
Tim Cross

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

Re: non-gnu elpa issue tracking

[Thibaut Verron]

Le sam. 12 déc. 2020 à 16:23, Tim Cross <theophilusx@gmail.com> a écrit :
>
>
>
> On Sat, 12 Dec 2020 at 21:08, Thibaut Verron <thibaut.verron@gmail.com> wrote:
>>
>> Le sam. 12 déc. 2020 à 07:37, Tim Cross <theophilusx@gmail.com> a écrit :
>> >
>>
>>
>> I also recall a discussion where some developers were worried that
>> assigning a copyright to the FSF was an official statement of
>> philosophical support, and that it was a statement they were not
>> willing to make. The official answer was that there is no such
>> statement in the copyright.
>
>
> As non-GNU ELPA is primarily about having a repository of packages which fit with the FSF philosophy and which do not require copyright assignment, concerns relating to copyright assignment are not relevant.

My point was that if assigning the copyright is not a statement of
philosophical support for the FSF, clearly, choosing the default
license (and possibly the only legal one) for an elisp file is also
not.

>>
>> > I think a mandatory requirement should simply be that any packages which go into non-GNU ELPA are hosted on an approved platform. We could point to a list of such hosting providers e.g. https://www.gnu.org/software/repo-criteria-evaluation.html and say Grade C or better only. .
>>
>> There is no such requirement for GNU ELPA at the moment.
>
> Perhaps there should be. However, GNU ELPA consists of code which has had copyright assigned to the FSF, so I guess that is their call.

I might be mistaken, but as I understand it, the copyright assignment
does not give the FSF authority to move the repositories (including
issues, pull requests, etc), only to create a new one mirroring the
code.

It is always possible to remove those packages which are hosted on
Github, of course, but I don't know how many maintainers would be
willing to jump through hoops *again* to get their package readmitted.

>> > This will also have the added incentive of encouraging better hosting options. It might even encourage GitLab for example, to enhance their environment to meet Class B.
>>
>> Couldn't it just as well be an occasion to encourage Github to improve?
>>
> I strongly doubt it. Github has become a significant platform for Microsoft and I see little interest from them in supporting the philosophy and goals of the FSF.

Right, because they are evil and it's in their nature. But seriously,
I see interest in retaining their audience.

Gitlab is already gaining traction in several communities (e.g., from
first-hand experience, public research), and Microsoft knows that
Github is only popular for companies for as long as it is popular for
developers.

Asking Microsoft to completely give up control on Github is not
realistic of course. But small changes such as moving to a free
Captcha system, or giving repositories the option to allow anonymous
comments, why not?

>> > Many people have selected Github for hosting simply because it was the best known solution. With a little encouragement, they would probably be willing to move to at least GitLab, which offers many of the similar convenience features of Github.  Being able to host your package in non-GNU ELPA might be that encouragement.
>>
>> There is a lot of inertia involved in relocating a package with
>> hundreds of contributors.
>
>
> Hence adding a requirement to be hosted on a platform which furthers FSF goals to help combat that inertia. People will have the choice - if they want their package to go into non-GNU ELPA, move it to a more compliant hosting environment or leave it where it is and don't worry about getting your package into non-GNU ELPA.

In my opinion, they won't worry, just like they didn't worry about
getting their package into GNU ELPA before. Melpa works fine.

As I remember it, the discussion started with "why do people use Melpa
when there is GNU ELPA", and the more or less accepted answer was that
there is too much red tape for packages to be included in GNU ELPA.
Hence the NonGNU ELPA project, cutting down the requirements and not
even requiring initiative from the package maintainers. The only
requirement was that the package be free and not promote non-free
software.

It's okay to set stricter requirements and to ask maintainers to
comply if they want the privilege of having their package listed in
NonGNU ELPA. But then I won't be surprised if in 1 year the question
of "why do people use Melpa when there is GNU ELPA and NonGNU ELPA"
comes up.

> It also seems inconsistent to have so many packages, both GNU ELPA and non-GNU ELPA packages hosted on a platform which is so far from being acceptable from a FSF philosophical perspective. Makes it feel like the FSF fails to eat their own dog food.

I agree. But I don't think that adding requirements is the answer.



>>
>>
>> I agree that some of the difficulties posed by copyright assignment do
>> not apply for relocation (e.g. that one contributor 7 years ago whom
>> nobody can contact), but there is an effort involved in both.
>
>
> Copyright issues are not relevant for non-GNU ELPA.
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>

Re: non-gnu elpa issue tracking

[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 a mandatory requirement should simply be that any
  > > packages which go into non-GNU ELPA are hosted on an approved
  > > platform. We could point to a list of such hosting providers
  > > e.g. https://www.gnu.org/software/repo-criteria-evaluation.html
  > > and say Grade C or better only. .

  > There is no such requirement for GNU ELPA at the moment.

GNU ELPA packages are hosted inside GNU ELPA itself.  The package
developers update their packages inside GNU ELPA.

NonGNU ELPA will be quite different.  Packages will generally be
hosted elsewhere.  We won't insist that the developers do things
in the way we would consider acceptable in the GNU Project.




-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Tim Cross]

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

On Sun, 13 Dec 2020 at 15:56, 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. ]]]
>
>   > > I think a mandatory requirement should simply be that any
>   > > packages which go into non-GNU ELPA are hosted on an approved
>   > > platform. We could point to a list of such hosting providers
>   > > e.g. https://www.gnu.org/software/repo-criteria-evaluation.html
>   > > and say Grade C or better only. .
>
>   > There is no such requirement for GNU ELPA at the moment.
>
> GNU ELPA packages are hosted inside GNU ELPA itself.  The package
> developers update their packages inside GNU ELPA.
>
> NonGNU ELPA will be quite different.  Packages will generally be
> hosted elsewhere.  We won't insist that the developers do things
> in the way we would consider acceptable in the GNU Project.
>
>
> Sorry, but I don't think this is an accurate statement. The GNU ELPA
repository has external packages where the code is primarily
maintained/developed externally, often on github. A 'regular' process pulls
the data into the GNU ELPA repository to generate new/updated package
versions.

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

Re: non-gnu elpa issue tracking

[Andrea Corallo via Emacs development discussions.]

Tim Cross <theophilusx@gmail.com> writes:

> On Sun, 13 Dec 2020 at 15:56, 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. ]]]
>
>    > > I think a mandatory requirement should simply be that any
>    > > packages which go into non-GNU ELPA are hosted on an approved
>    > > platform. We could point to a list of such hosting providers
>    > > e.g. https://www.gnu.org/software/repo-criteria-evaluation.html
>    > > and say Grade C or better only. .
>
>    > There is no such requirement for GNU ELPA at the moment.
>
>  GNU ELPA packages are hosted inside GNU ELPA itself.  The package
>  developers update their packages inside GNU ELPA.
>
>  NonGNU ELPA will be quite different.  Packages will generally be
>  hosted elsewhere.  We won't insist that the developers do things
>  in the way we would consider acceptable in the GNU Project.
>
> Sorry, but I don't think this is an accurate statement. The GNU ELPA repository has external packages where the code is
> primarily maintained/developed externally, often on github. A 'regular' process pulls the data into the GNU ELPA
> repository to generate new/updated package versions.  

Are you sure?  AFAIK there's no such regular process, merging code from
outside is done manually by the package maintainer or often by Stefan.

Also an 'external package' is just a package hosted in a dedicated
branch in elpa.git (BTW I believe now all packages are external).  And
yes 'external' is probably not the best naming for this.

  Andrea

Re: non-gnu elpa issue tracking

[Tim Cross]

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

On Sun, 13 Dec 2020 at 20:54, Andrea Corallo <akrl@sdf.org> wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>
> > On Sun, 13 Dec 2020 at 15:56, 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. ]]]
> >
> >    > > I think a mandatory requirement should simply be that any
> >    > > packages which go into non-GNU ELPA are hosted on an approved
> >    > > platform. We could point to a list of such hosting providers
> >    > > e.g. https://www.gnu.org/software/repo-criteria-evaluation.html
> >    > > and say Grade C or better only. .
> >
> >    > There is no such requirement for GNU ELPA at the moment.
> >
> >  GNU ELPA packages are hosted inside GNU ELPA itself.  The package
> >  developers update their packages inside GNU ELPA.
> >
> >  NonGNU ELPA will be quite different.  Packages will generally be
> >  hosted elsewhere.  We won't insist that the developers do things
> >  in the way we would consider acceptable in the GNU Project.
> >
> > Sorry, but I don't think this is an accurate statement. The GNU ELPA
> repository has external packages where the code is
> > primarily maintained/developed externally, often on github. A 'regular'
> process pulls the data into the GNU ELPA
> > repository to generate new/updated package versions.
>
> Are you sure?  AFAIK there's no such regular process, merging code from
> outside is done manually by the package maintainer or often by Stefan.
>
> Also an 'external package' is just a package hosted in a dedicated
> branch in elpa.git (BTW I believe now all packages are external).  And
> yes 'external' is probably not the best naming for this.
>
>   Andrea
>


I could be wrong about the process being automated.

However, from the elpa git repository, the externals-list file says

;; List of packages that are maintained externally.
;; The list is made of elements of the form (NAME KIND URL OPTS...).

and that list contains the following -

(("ace-window" :external "https://github.com/abo-abo/ace-window")
 ("ack" :external "https://github.com/leoliu/ack-el")
 ("aggressive-indent" :external "
https://github.com/Malabarba/aggressive-indent-mode")
 ("ahungry-theme" :external "https://github.com/ahungry/color-theme-ahungry
")
 ("async" :external "https://github.com/jwiegley/emacs-async")
 ("avy" :external "https://github.com/abo-abo/avy")
 ("beacon" :external "https://github.com/Malabarba/beacon")
 ("bnf-mode" :external "https://github.com/sergeyklay/bnf-mode")
 ("buffer-expose" :external "https://github.com/clemera/buffer-expose")
 ("bug-hunter" :external "https://github.com/Malabarba/elisp-bug-hunter")
 ("cobol-mode"          :external "
https://gist.github.com/Edward-H/6768e7dc53ea3dd2adca")
 ("clipboard-collector" :external "
https://github.com/clemera/clipboard-collector")
 ("coffee-mode" :external "https://github.com/defunkt/coffee-mode")
 ("compact-docstrings"  :external "
https://github.com/cpitclaudel/compact-docstrings")
 ("company" :external "https://github.com/company-mode/company-mode.git")
 ("company-math" :external "https://github.com/vspinu/company-math.git")
 ("company-statistics" :external "
https://github.com/company-mode/company-statistics")
 ("context-coloring" :external "
https://github.com/jacksonrayhamilton/context-coloring.git")
 ("counsel" :external "https://github.com/abo-abo/swiper")
 ("cpio-mode" :external "https://github.com/dlewan/cpio-mode")
 ("darkroom"            :external "
https://github.com/capitaomorte/darkroom.git")
 ("dash"                :external "https://github.com/magnars/dash.el.git")
 ("dbus-codegen" :external "https://github.com/ueno/dbus-codegen-el.git")
 ("diffview"            :external "
https://github.com/mgalgs/diffview-mode.git")
 ("diff-hl" :external "https://github.com/dgutov/diff-hl.git")
 ("dired-git-info" :external "https://github.com/clemera/dired-git-info")
 ("dts-mode" :external "https://github.com/bgamari/dts-mode.git")
 ("easy-kill" :external "https://github.com/leoliu/easy-kill")
 ("ebdb"                :external "https://github.com/girzel/ebdb.git")
 ("eev" :external "https://github.com/edrx/eev.git") ;branch UTF-8
 ("eglot"               :external "https://github.com/joaotavora/eglot.git")
 ("eldoc-eval" :external "https://github.com/thierryvolpiatto/eldoc-eval.git
")
 ("ergoemacs-mode" :external "
https://github.com/ergoemacs/ergoemacs-mode.git")
 ("expand-region" :external "https://github.com/magnars/expand-region.el")
 ("exwm" :external "https://github.com/ch11ng/exwm.git")
 ("f90-interface-browser" :external "https://github.com/wence-/f90-iface")
 ("frog-menu" :external "https://github.com/clemera/frog-menu")
 ("ggtags" :external "https://github.com/leoliu/ggtags")
 ("gnome-c-style" :external "https://github.com/ueno/gnome-c-style.git")
 ("guess-language" :external "https://github.com/tmalsburg/guess-language.el
")
 ("highlight-escape-sequences" :external "
https://github.com/dgutov/highlight-escape-sequences/")
 ("hydra" :external "https://github.com/abo-abo/hydra")
 ("ioccur" :external "https://github.com/thierryvolpiatto/ioccur.git")
 ("ivy" :external "https://github.com/abo-abo/swiper")
 ("ivy-explorer"        :external "https://github.com/clemera/ivy-explorer")
 ("ivy-posframe"        :external "https://github.com/tumashu/ivy-posframe")
 ("js2-mode" :external "https://github.com/mooz/js2-mode.git")
 ("leaf" :external "https://github.com/conao3/leaf.el")
 ("load-relative" :external "http://github.com/rocky/emacs-load-relative")
 ("loc-changes" :external "http://github.com/rocky/emacs-loc-changes")
 ("loccur" :external "https://github.com/fourier/loccur")
 ("math-symbol-lists" :external "
https://github.com/vspinu/math-symbol-lists.git")
 ("mines" :external "https://github.com/calancha/Minesweeper")
 ("mmm-mode"            :external "https://github.com/purcell/mmm-mode.git")
 ("multishell" :external "https://github.com/kenmanheimer/EmacsMultishell")
 ("muse" :external "https://github.com/alexott/muse") ;FIXME: Not nearly
in-sync
 ("nameless" :external "https://github.com/Malabarba/Nameless")
 ("names" :external "http://github.com/Malabarba/names")
 ("objed"         :external "https://github.com/clemera/objed")
 ("on-screen"           :external "
https://github.com/michael-heerdegen/on-screen.el.git")
 ("pabbrev"             :external "https://github.com/phillord/pabbrev.git")
 ("parsec"              :external "
https://github.com/cute-jumper/parsec.el.git")
 ("peg" :external) ;Was in "https://github.com/ellerh/peg.el"
 ("phps-mode" :external "https://github.com/cjohansson/emacs-phps-mode")
 ("pinentry" :external "https://github.com/ueno/pinentry-el.git")
 ("posframe" :external "https://github.com/tumashu/posframe")
 ("psgml"               :external "https://github.com/lenst/psgml.git")
 ("realgud"             :external "https://github.com/realgud/realgud")
 ("realgud-ipdb"        :external "https://github.com/realgud/realgud-ipdb")
 ("realgud-jdb"         :external "https://github.com/realgud/jdb")
 ("realgud-lldb"        :external "https://github.com/realgud/realgud-lldb")
 ("realgud-node-debug"  :external "
https://github.com/realgud/realgud-node-debug")
 ("realgud-node-inspect" :external "
https://github.com/realgud/realgud-node-inspect")
 ("realgud-trepan-ni"   :external "https://github.com/realgud/realgud-ni")
 ("relint" :external "https://github.com/mattiase/relint")
 ("rich-minority" :external "https://github.com/Malabarba/rich-minority")
 ("sotlisp" :external "https://github.com/Malabarba/speed-of-thought-lisp")
 ("spinner" :external "https://github.com/Malabarba/spinner.el")
 ("sql-indent"          :external "
https://github.com/alex-hhh/emacs-sql-indent")
 ("ssh-deploy" :external "https://github.com/cjohansson/emacs-ssh-deploy")
 ("swiper" :external "https://github.com/abo-abo/swiper")
 ("temp-buffer-browse"  :external "
https://github.com/leoliu/temp-buffer-browse")
 ("test-simple"         :external "
https://github.com/rocky/emacs-test-simple")
 ("validate" :external "https://github.com/Malabarba/validate.el")
 ("vdiff"               :external "https://github.com/justbur/emacs-vdiff")
 ("tiny" :external "https://github.com/abo-abo/tiny")
 ("transient" :external "https://github.com/magit/transient")
 ("valign" :external "https://github.com/casouri/valign")
 ("vlf" :external "https://github.com/m00natic/vlfi")
 ("wcheck-mode" :external "https://github.com/tlikonen/wcheck-mode")
 ("wconf" :external "https://github.com/ilohmar/wconf")
 ("web-server" :external "https://github.com/eschulte/emacs-web-server.git")
 ("websocket" :external "https://github.com/ahyatt/emacs-websocket.git")
 ("which-key"           :external "
https://github.com/justbur/emacs-which-key")
 ("xelb" :external "https://github.com/ch11ng/xelb.git")
 ("xr" :external "https://github.com/mattiase/xr")
 ("yasnippet" :external "https://github.com/capitaomorte/yasnippet.git")
 ("ztree" :external "https://github.com/fourier/ztree")

So copies of the code are hosted in GNU ELPA, but the master code is hosted
and maintained on github for the above packages. So while we can spin it in
many ways, code with copyright assigned to the FSF is maintained
(developed, bug fixed etc) on github.  Furthermore, many of the packages
from the above list I looked at are actively managing issues using Github's
web interface. Finally, when you look at some of these packages in the
package listing and select the package to view its info, the homepage for
the package is listed as github.

I don't have an issue with this, but it does seem inconsistent to argue
github does not comply with FSF philosophy and guidelines while at the same
time using it to maintain code which the FSF holds the copyright for and to
have references to github as the homepage for the package.  To argue this
is all OK because the packages are delivered from a GNU ELPA repository
really just feels like we are playing with semantics. It feels a bit like
saying "While our shoes are made by children in a 3rd world sweat shop, we
only sell them in outlets which are run in an ethical manner."

--
Tim Cross

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

Re: non-gnu elpa issue tracking

[Stefan Monnier]

> and that list contains the following -
>
> (("ace-window" :external "https://github.com/abo-abo/ace-window")
[...]
>  ("ztree" :external "https://github.com/fourier/ztree")
[...]
> I don't have an issue with this, but it does seem inconsistent to argue
> github does not comply with FSF philosophy and guidelines while at the same
> time using it to maintain code which the FSF holds the copyright for and to
> have references to github as the homepage for the package.

Correction: the above URLs are reference to the Git repository, not to
the homepage.  I know Github conflates the two, but the above URLs are
not advertised to the end user.

The URL we advertise as "the homepage" on elpa.gnu.org are taken from
the "URL:" pseudo header in the package's main file (i.e. `<pkg>.el`).
For most (all?) packages hosted on Github, that URL is the same as the
one found in `externals-list` of course but I think the distinction is
important (e.g. we could refrain from including the reference to the
"homepage" on github while keeping the Git reference).


        Stefan

Re: non-gnu elpa issue tracking

[Tim Cross]

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

On Mon, 14 Dec 2020 at 11:33, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > and that list contains the following -
> >
> > (("ace-window" :external "https://github.com/abo-abo/ace-window")
> [...]
> >  ("ztree" :external "https://github.com/fourier/ztree")
> [...]
> > I don't have an issue with this, but it does seem inconsistent to argue
> > github does not comply with FSF philosophy and guidelines while at the
> same
> > time using it to maintain code which the FSF holds the copyright for and
> to
> > have references to github as the homepage for the package.
>
> Correction: the above URLs are reference to the Git repository, not to
> the homepage.  I know Github conflates the two, but the above URLs are
> not advertised to the end user.
>
> The URL we advertise as "the homepage" on elpa.gnu.org are taken from
> the "URL:" pseudo header in the package's main file (i.e. `<pkg>.el`).
> For most (all?) packages hosted on Github, that URL is the same as the
> one found in `externals-list` of course but I think the distinction is
> important (e.g. we could refrain from including the reference to the
> "homepage" on github while keeping the Git reference).
>
> I'm not sure I get the subtle difference you seem to be referring to. From
my simple end user perspective, I find a package in the list of packages by
running M-x list-packages , for example, I have the following in the
current list -

 ack                1.10          available  gnu        interface to
ack-like tools

When I move to that line and hit enter, the following window pops up,
providing details about this package

Package ack is available.

     Status: Available from gnu -- Install
    Archive: gnu
    Version: 1.10
    Summary: interface to ack-like tools
   Homepage: https://github.com/leoliu/ack-el
   Keywords: tools processes convenience
 Maintainer: João Távora <joaotavora@gmail.com>
     Author: Leo Liu <sdl.web@gmail.com>

This tells me the homepage for this package is on github.com. The
repository hosting this package is GNU ELPA, which tells me it is code that
is copyright to the FSF. To my uneducated view, this leads me to the
assumption that the FSF uses github.com, despite their position regarding
ethical software and ethical hosting.


-- 
regards,

Tim

--
Tim Cross

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

Re: non-gnu elpa issue tracking

[Stefan Monnier]

> I'm not sure I get the subtle difference you seem to be referring to. From
> my simple end user perspective, I find a package in the list of packages by
> running M-x list-packages , for example, I have the following in the
> current list -
>
>  ack                1.10          available  gnu        interface to
> ack-like tools
>
> When I move to that line and hit enter, the following window pops up,
> providing details about this package
>
> Package ack is available.
>
>      Status: Available from gnu -- Install
>     Archive: gnu
>     Version: 1.10
>     Summary: interface to ack-like tools
>    Homepage: https://github.com/leoliu/ack-el
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The subtle difference is that this link doesn't come from
`externals-list` but from elsewhere.  We just include it as
a convenience for the end user and for the package maintainer, not as
something we use (the one we use is the one in `externals-list` and we
only use it with Git so we could change it from `https://...` to
`git://...`).

This said, I'm not sure exactly what would be the benefit of removing
this link: I don't think it would convince the package's maintainers to
move to some other hosting platform, and I don't think it would prevent
users from finding that the official homepage is on Github.

Maybe we could adorn the link with some warning text, OTOH (and maybe
refrain from making the URL into a hyperlink).  Is that what you had
in mind?


        Stefan

Re: non-gnu elpa issue tracking

[Tim Cross]

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

>> I'm not sure I get the subtle difference you seem to be referring to. From
>> my simple end user perspective, I find a package in the list of packages by
>> running M-x list-packages , for example, I have the following in the
>> current list -
>>
>>  ack                1.10          available  gnu        interface to
>> ack-like tools
>>
>> When I move to that line and hit enter, the following window pops up,
>> providing details about this package
>>
>> Package ack is available.
>>
>>      Status: Available from gnu -- Install
>>     Archive: gnu
>>     Version: 1.10
>>     Summary: interface to ack-like tools
>>    Homepage: https://github.com/leoliu/ack-el
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> The subtle difference is that this link doesn't come from
> `externals-list` but from elsewhere.  We just include it as
> a convenience for the end user and for the package maintainer, not as
> something we use (the one we use is the one in `externals-list` and we
> only use it with Git so we could change it from `https://...` to
> `git://...`).
>
> This said, I'm not sure exactly what would be the benefit of removing
> this link: I don't think it would convince the package's maintainers to
> move to some other hosting platform, and I don't think it would prevent
> users from finding that the official homepage is on Github.
>
> Maybe we could adorn the link with some warning text, OTOH (and maybe
> refrain from making the URL into a hyperlink).  Is that what you had
> in mind?
>

I don't think any of those suggestions are worth the overhead and
additional complexity. The only thing which probably could be done is
to accept that despite the philosophical and ethical issues associated
with github, it is now a platform which is used as a code repository for
GNU packages and adjust messaging accordingly.

Others will disagree, but for me, statements like the one Richard made
which I responded to, while factually correct are misleading. They are
designed to try and make it look as if what the project is doing is
ethically 'clean'. It isn't. The project, for many complex and quite
justifiable reasons, is benefiting from a platform which it considers
undermines the core philosophical goals of software freedom and should
be open and up-front about this.

--
Tim Cross

Re: non-gnu elpa issue tracking

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

  > >    Homepage: https://github.com/leoliu/ack-el
  >      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don't think we need to "hide" this reference if it refers to GitHub.
What is important is that the users not have to _use_ that reference
for anything users do -- such as reporting bugs.

However, listing a repo as a "homepage" for the package -- regardless
of where that is hosted -- risks misleads users.  The risk is that they
might think they should download from there.

The source code in that repo will, in many cases, be different from
what we distribute.  Users should not download it from there.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Alfred M. Szmidt]

    ("aggressive-indent" :external "https://github.com/Malabarba/aggressive-indent-mode")

I was under the impression that GNU ELPA required copyright
assignments?  And that GNU ELPA was part of Emacs, yet this one is
GPLv2-or-later, "is NOT part of GNU Emacs.", is copyrighted by the FSF
but Artur Malabarba who is the author of this package has no entry in
the copyright.list?

Re: non-gnu elpa issue tracking

[Stefan Monnier]

>     ("aggressive-indent" :external "https://github.com/Malabarba/aggressive-indent-mode")
> I was under the impression that GNU ELPA required copyright
> assignments?  And that GNU ELPA was part of Emacs, yet this one is
> GPLv2-or-later,

The version in GNU ELPA says:

    ;; This program is free software; you can redistribute it and/or
    ;; modify it under the terms of the GNU General Public License
    ;; as published by the Free Software Foundation; either version 3
    ;; of the License, or (at your option) any later version.

It looks like he didn't fold this fix into his upstream code.

> "is NOT part of GNU Emacs.",

GNU ELPA is both part and not-part of Emacs, AFAIC, so I'm fine
with that.

> is copyrighted by the FSF but Artur Malabarba who is the author of
> this package has no entry in the copyright.list?

He sure does (with a few more names between Artur and Malabarba).
His email is `bruce.connor.am@gmail.com`.


        Stefan

Re: non-gnu elpa issue tracking

[Alfred M. Szmidt]

   > "is NOT part of GNU Emacs.",

   GNU ELPA is both part and not-part of Emacs, AFAIC, so I'm fine
   with that.

I don't understand, it cannot be both or neither.  Either it is part
of Emacs, or it is not.

   > is copyrighted by the FSF but Artur Malabarba who is the author of
   > this package has no entry in the copyright.list?

   He sure does (with a few more names between Artur and Malabarba).

Ah, I only searched on the email and name.  Thank you for the
correction.

Re: non-gnu elpa issue tracking

[Stefan Monnier]

>    > "is NOT part of GNU Emacs.",
>    GNU ELPA is both part and not-part of Emacs, AFAIC, so I'm fine
>    with that.
> I don't understand, it cannot be both or neither.  Either it is part
> of Emacs, or it is not.

It's part of "Emacs the project" but it's not part of "Emacs the
program" (because it's not in the tarball).

BTW, there is no need to state in those files whether they're part of
Emacs or not, AFAIC.


        Stefan

Re: non-gnu elpa issue tracking

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Mon, 14 Dec 2020 10:01:40 -0500
> Cc: bugs@gnu.support, rms@gnu.org, thibaut.verron@gmail.com,
>  theophilusx@gmail.com, boruch_baum@gmx.com, emacs-devel@gnu.org,
>  stefankangas@gmail.com, akrl@sdf.org
> 
>    > "is NOT part of GNU Emacs.",
> 
>    GNU ELPA is both part and not-part of Emacs, AFAIC, so I'm fine
>    with that.
> 
> I don't understand, it cannot be both or neither.  Either it is part
> of Emacs, or it is not.

It is "donated to Emacs".

Re: non-gnu elpa issue tracking

[Stephen Leake]

Andrea Corallo via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>>
>> Sorry, but I don't think this is an accurate statement. The GNU ELPA
>> repository has external packages where the code is
>> primarily maintained/developed externally, often on github. A
>> 'regular' process pulls the data into the GNU ELPA
>> repository to generate new/updated package versions.  
>
> Are you sure?  AFAIK there's no such regular process, merging code from
> outside is done manually by the package maintainer or often by Stefan.

Yes, that's true. The point remains that the primary development
repository for some packages is not
git.savannah.gnu.org:/srv/git/emacs/elpa.git; it is some other upstream
repository.

-- 
-- Stephe

Re: non-gnu elpa issue tracking

[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 will also have the added incentive of encouraging better hosting options. It might even encourage GitLab for example, to enhance their environment to meet Class B.

  > Couldn't it just as well be an occasion to encourage Github to improve?

Every day is an occasion for that ;-).  What nobody has found is a way to
have influence on GitHub ;-{.

If someone is willing to focus on organizing this effort, it might do
some good.  One very good step would be to convince GitHub to identify
packages with the modern SPDX identifiers.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Vasilij Schneidermann]

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

> If someone is willing to focus on organizing this effort, it might do
> some good.  One very good step would be to convince GitHub to identify
> packages with the modern SPDX identifiers.

GitHub does already try to recognize the license used by a repository
using heuristics. These can be programmatically fetched:

    $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
        https://api.github.com/repos/melpa/melpa/license | grep spdx
    "spdx_id": "GPL-3.0",

Repeating this process for some packages mentioned previously in this
discussion (the 0x0 one has been omitted as it's hosted on sr.ht):

    $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
        https://api.github.com/repos/davidshepherd7/aggressive-fill-paragraph-mode/license | grep spdx              
    "spdx_id": "GPL-3.0",
    $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
        https://api.github.com/repos/alan-platform/AlanForEmacs/license | grep spdx 
    "spdx_id": "MIT",
    $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
        https://api.github.com/repos/rolandwalker/anaphora/license | grep spdx
    $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
        https://api.github.com/repos/davidshepherd7/anki-mode/license | grep spdx
    "spdx_id": "AGPL-3.0",

That gives me a more precise picture than Jean Louis' analysis I've
taken these packages from. The only license that couldn't be identified
is for the anaphora repository which doesn't have a LICENSE file, but
instead embeds a public domain notice inside the source code.

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

Re: non-gnu elpa issue tracking

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

  > GitHub does already try to recognize the license used by a repository
  > using heuristics.

That is a bad approach on their part.  We will not trust heuristics.
A package should state its licensing clearly, and before we put
a package into NonGNU ELPA (or anything else), we need that to be clear.

If a package doesn't make its licensing clear, we should ask the
developers to fix that.

      > $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
      >     https://api.github.com/repos/melpa/melpa/license | grep spdx
      > "spdx_id": "GPL-3.0",

That is an obsolete, deprecated SPDX identifier.
SPDX deprecated it because it is ambiguous.
Is it "GPL 3 only" or "GPL 3 or later"?

That question is important to us, because we want "GPL 3 or later"
(like Emacs) and will not accept "GPL 3 only".

The vagueness about license versions is one of the harmful things
that GitHub does.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Jean Louis]

On that I did not look into original packages, but only those distributed by Melpa and I do think that many without license on Melpa have their license somewhere.

It does not change the condition that distributing packages without license is license violations, and that nonGnu ELPA has to do it better without comparing to Melpa.


On December 13, 2020 8:56:09 AM UTC, Vasilij Schneidermann <mail@vasilij.de> wrote:
>> If someone is willing to focus on organizing this effort, it might do
>> some good.  One very good step would be to convince GitHub to
>identify
>> packages with the modern SPDX identifiers.
>
>GitHub does already try to recognize the license used by a repository
>using heuristics. These can be programmatically fetched:
>
>    $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
>        https://api.github.com/repos/melpa/melpa/license | grep spdx
>    "spdx_id": "GPL-3.0",
>
>Repeating this process for some packages mentioned previously in this
>discussion (the 0x0 one has been omitted as it's hosted on sr.ht):
>
>    $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
>https://api.github.com/repos/davidshepherd7/aggressive-fill-paragraph-mode/license
>| grep spdx              
>    "spdx_id": "GPL-3.0",
>    $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
>https://api.github.com/repos/alan-platform/AlanForEmacs/license | grep
>spdx 
>    "spdx_id": "MIT",
>    $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
> https://api.github.com/repos/rolandwalker/anaphora/license | grep spdx
>    $ curl --silent -H 'Accept: application/vnd.github.v3+json' \
>https://api.github.com/repos/davidshepherd7/anki-mode/license | grep
>spdx
>    "spdx_id": "AGPL-3.0",
>
>That gives me a more precise picture than Jean Louis' analysis I've
>taken these packages from. The only license that couldn't be identified
>is for the anaphora repository which doesn't have a LICENSE file, but
>instead embeds a public domain notice inside the source code.


Jean

Re: non-gnu elpa issue tracking

[Michael Albinus]

Tim Cross <theophilusx@gmail.com> writes:

Hi,

> Many people have selected Github for hosting simply because it was the
> best known solution. With a little encouragement, they would probably
> be willing to move to at least GitLab, which offers many of the
> similar convenience features of Github.  Being able to host your
> package in non-GNU ELPA might be that encouragement.

We might also consider to give package maintainers an incentive to host
on GitLab. We run already a GitLab instance on emba.gnu.org. This
provides automatic regression tests for all Emacs branches, triggered by
any commit to Emacs git repository.

Currently, I'm thinking about to extend this for GNU ELPA packages. That
is, if a given package provides an ERT test file, we could trigger its
run for every commit in the package repository. Maybe even for different
Emacs versions in parallel, based on what the package says in its
Package-Requires: header.

All of this is in the very early stage of brainstorming, 'tho. I don't
know what would be the implications for GNU ELPA compared with NonGNU
ELPA packages. And this does not cover the problem of issue tracking
yet.

Best regards, Michael.

Re: non-gnu elpa issue tracking

[Stefan Monnier]

> The non-GNU ELPA is supposed to be a repository for packages which are GPL
> compliant and it is a reasonable expectation that those who make their
> packages GPL compliant do so because they support the philosophical goals
> of the FSF.

The overwhelming majority of ELisp packages out there are hosted on
Github (that also applies to many GNU ELPA packages, many of them are
developed by long time contributors to Emacs), so I think the evidence
shows the above expectation doesn't hold at all.


        Stefan

Re: non-gnu elpa issue tracking

[Tim Cross]

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

On Sun, 13 Dec 2020 at 00:50, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > The non-GNU ELPA is supposed to be a repository for packages which are
> GPL
> > compliant and it is a reasonable expectation that those who make their
> > packages GPL compliant do so because they support the philosophical goals
> > of the FSF.
>
> The overwhelming majority of ELisp packages out there are hosted on
> Github (that also applies to many GNU ELPA packages, many of them are
> developed by long time contributors to Emacs), so I think the evidence
> shows the above expectation doesn't hold at all.
>
> Maybe. However, it could also be a combination of the fact github was the
first free git hosting environment and is the better known one. Just
because it is this way now doesn't mean it has to be. If the GNU/FSF
doesn't take a clear position on this and do something to discourage the
use of hosting environments that force the use of proprietary software,
this will not change and eventually all we will have are the proprietary
solutions. It may not have been the right decision to allow code which has
assigned copyright to the FSF to remain on Github. However, as non-GNU ELPA
is just getting started, now would be a good time to try and change things.

I'm also not convinced about arguments suggesting too much inertia or too
much hassle in moving to a new hosting platform. Lots of packages which use
to be hosted on sourceforge have moved to Github. There are few technical
barriers to moving git repositories to a new hosting platform. However,
there has to be some incentive to do so.  It also seems inconsistent to
have so many packages, both GNU ELPA and non-GNU ELPA packages hosted on a
platform which is so far from being acceptable from a FSF philosophical
perspective. Makes it feel like the FSF fails to eat their own dog food.

-- 
regards,

Tim

--
Tim Cross

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

Re: non-gnu elpa issue tracking

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2020-12-12 18:37]:
> On Sun, 13 Dec 2020 at 00:50, Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
> 
> > > The non-GNU ELPA is supposed to be a repository for packages which are
> > GPL
> > > compliant and it is a reasonable expectation that those who make their
> > > packages GPL compliant do so because they support the philosophical goals
> > > of the FSF.
> >
> > The overwhelming majority of ELisp packages out there are hosted on
> > Github (that also applies to many GNU ELPA packages, many of them are
> > developed by long time contributors to Emacs), so I think the evidence
> > shows the above expectation doesn't hold at all.
> >
> > Maybe. However, it could also be a combination of the fact github was the
> first free git hosting environment and is the better known one. Just
> because it is this way now doesn't mean it has to be. If the GNU/FSF
> doesn't take a clear position on this and do something to discourage the
> use of hosting environments that force the use of proprietary software,
> this will not change and eventually all we will have are the proprietary
> solutions. It may not have been the right decision to allow code which has
> assigned copyright to the FSF to remain on Github. However, as non-GNU ELPA
> is just getting started, now would be a good time to try and change
> things.

Exactly.

> I'm also not convinced about arguments suggesting too much inertia or too
> much hassle in moving to a new hosting platform.

That IS the goal of Github to make people become very dependent that
they cannot switch. Using that argument is advertising the Github
indirectly. Every code hosting platform shall not make developers and
software development dependent on it. Github does exactly that with
its proprietary applications served for developers.

> There are few technical barriers to moving git repositories to a new
> hosting platform. However, there has to be some incentive to do so.
> It also seems inconsistent to have so many packages, both GNU ELPA
> and non-GNU ELPA packages hosted on a platform which is so far from
> being acceptable from a FSF philosophical perspective. Makes it feel
> like the FSF fails to eat their own dog food.

Exactly.

Re: non-gnu elpa issue tracking

[Stephen Leake]

Tim Cross <theophilusx@gmail.com> writes:

> On Sun, 13 Dec 2020 at 00:50, Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
>
>> > The non-GNU ELPA is supposed to be a repository for packages which are
>> GPL
>> > compliant and it is a reasonable expectation that those who make their
>> > packages GPL compliant do so because they support the philosophical goals
>> > of the FSF.
>>
>> The overwhelming majority of ELisp packages out there are hosted on
>> Github (that also applies to many GNU ELPA packages, many of them are
>> developed by long time contributors to Emacs), so I think the evidence
>> shows the above expectation doesn't hold at all.
>>
> Maybe. However, it could also be a combination of the fact github was the
> first free git hosting environment and is the better known one. Just
> because it is this way now doesn't mean it has to be. If the GNU/FSF
> doesn't take a clear position on this and do something to discourage the
> use of hosting environments that force the use of proprietary software,
> this will not change and eventually all we will have are the proprietary
> solutions. It may not have been the right decision to allow code which has
> assigned copyright to the FSF to remain on Github. However, as non-GNU ELPA
> is just getting started, now would be a good time to try and change
> things.

+1.

I think we should encourage people to move away from Github, for both
GNU and non-GNU ELPA.

Given that many ELPA packages are now on Github, we could have a
transition policy, with enforceable deadlines (ie, remove package from
*GNU ELPA if still on gitub after deadline). However, I doubt that the
Emacs project is capable of such a thing, or that we want to be.

So we are left with naming and shaming; in list-packages, show the
upstream repository along with the license and other info on a package,
and show unacceptable ones in red. That could still be a lot of effort
to categorize obscure hosts.

Disclaimer; my packages are hosted on Savannah, so any resolution of this
will have no direct impact on me.

-- 
-- Stephe

Re: non-gnu elpa issue tracking

[Alfred M. Szmidt]

   > Maybe. However, it could also be a combination of the fact github was the
   > first free git hosting environment and is the better known one. 

Savannah existed long before Github.

   I think we should encourage people to move away from Github, for both
   GNU and non-GNU ELPA.

Linking to a repository hosted at github isn't the same as encouraging
people to use github, but do you think there is anywhere that the GNU
project or Emacs is encouraging people to move projects to Github?

   So we are left with naming and shaming; in list-packages, show the
   upstream repository along with the license and other info on a package,
   and show unacceptable ones in red. That could still be a lot of effort
   to categorize obscure hosts.

Naming and shaming people or projects who write free softwrae would be
counter productive to our goals -- if there is a package that cannot
be hosted in ELPA or non-GNU ELPA it is simply better to just not host
it.

Re: non-gnu elpa issue tracking

[Christopher Dimech]

> Sent: Saturday, December 12, 2020 at 9:46 PM
> From: "Stephen Leake" <stephen_leake@stephe-leake.org>
> To: "Tim Cross" <theophilusx@gmail.com>
> Cc: "Jean Louis" <bugs@gnu.support>, thibaut.verron@gmail.com, "Stefan Kangas" <stefankangas@gmail.com>, "Boruch Baum" <boruch_baum@gmx.com>, "Emacs developers" <emacs-devel@gnu.org>, "Stefan Monnier" <monnier@iro.umontreal.ca>, "Richard Stallman" <rms@gnu.org>
> Subject: Re: non-gnu elpa issue tracking
>
> Tim Cross <theophilusx@gmail.com> writes:
>
> > On Sun, 13 Dec 2020 at 00:50, Stefan Monnier <monnier@iro.umontreal.ca>
> > wrote:
> >
> >> > The non-GNU ELPA is supposed to be a repository for packages which are
> >> GPL
> >> > compliant and it is a reasonable expectation that those who make their
> >> > packages GPL compliant do so because they support the philosophical goals
> >> > of the FSF.
> >>
> >> The overwhelming majority of ELisp packages out there are hosted on
> >> Github (that also applies to many GNU ELPA packages, many of them are
> >> developed by long time contributors to Emacs), so I think the evidence
> >> shows the above expectation doesn't hold at all.
> >>
> > Maybe. However, it could also be a combination of the fact github was the
> > first free git hosting environment and is the better known one. Just
> > because it is this way now doesn't mean it has to be. If the GNU/FSF
> > doesn't take a clear position on this and do something to discourage the
> > use of hosting environments that force the use of proprietary software,
> > this will not change and eventually all we will have are the proprietary
> > solutions. It may not have been the right decision to allow code which has
> > assigned copyright to the FSF to remain on Github. However, as non-GNU ELPA
> > is just getting started, now would be a good time to try and change
> > things.
>
> +1.
>
> I think we should encourage people to move away from Github, for both
> GNU and non-GNU ELPA.
>
> Given that many ELPA packages are now on Github, we could have a
> transition policy, with enforceable deadlines (ie, remove package from
> *GNU ELPA if still on gitub after deadline). However, I doubt that the
> Emacs project is capable of such a thing, or that we want to be.
>
> So we are left with naming and shaming; in list-packages, show the
> upstream repository along with the license and other info on a package,
> and show unacceptable ones in red. That could still be a lot of effort
> to categorize obscure hosts.

I do not see how putting a copy on GitHub is an offence.  We can discourage it,
But removing packages from GNU ELPA if still on Github after deadline, is
not the way forward.  Removing free software from ELPA is a regressive move
that will not benefit Gnu in any way.

> Disclaimer; my packages are hosted on Savannah, so any resolution of this
> will have no direct impact on me.
>
> --
> -- Stephe
>
>

Re: non-gnu elpa issue tracking

[Tim Cross]

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

Just to clarify a bit.

I am not suggesting we remove packages which fail to migrate from
github/sourceforge to a more complaint hosting environment. A decision
could be that we ask existing maintainers to move and require that all new
packages from a specific date are only on a supported hosting environment.
I raised this suggestion now specifically with respect to non-GNU ELPA
because that is a relatively new repository and as such, it could be a good
place to start with for establishing a repository which is more in line
with FSF philosophy and goals. In some sense, it could be a testbed to
refine a more general repository approach that might be applied to GNU ELPA
at some point in the future.

I would never agree to a 'name and shame' approach. That is seldom an
appropriate course of action and can only be justified when there are very
serious direct consequences. What we want here is increased incentive, a
carrot, not a stick.

With respect to Github and Microsoft, I have little confidence in the
proposition we could put pressure on Github to adopt practices that are
in-line with FSF philosophy. Microsoft is a public company run by a board
of directors who have an obligation to maximise the share prices and
dividends for the shareholders. Ultimately, decisions are based on
maintaining and increasing profit. The ability to make decisions to further
such profit generation is closely tied to control. This makes any decision
which gives up control less likely to be welcomed. I have little confidence
Microsoft would be willing to give up the level of control necessary for it
to become accepted under FSF guidelines as an ethical hosting provider.
Some minor cosmetic changes might be possible, but little more. We would
probably have better success moving Gitlab from Class C to Class B with
respect to providing an FSF compliant hosting platform.

My main point here is that many of the problems associated with maintenance
of packages, such as issue tracking, are being significantly complicated
because the code is being maintained on a platform which does not meet
GNU/FSF guidelines, philosophy and goals. If a key goal of the FSF is to
promote an ethical position with respect to software, it has to prioritise
that ethical position over convenience. Convenience is probably the number
one threat to software freedom.  Rather than focus on the inconvenience of
requiring maintainers to use a more appropriate hosting platform, consider
the potential benefits with respect to issue tracking and maintenance that
would be possible without the limitations and confusion caused by the
current situation.  Furthermore, consider the benefits to the core message
of having an ecosystem which is actually based on more ethically compliant
systems.



On Sun, 13 Dec 2020 at 08:48, Christopher Dimech <dimech@gmx.com> wrote:

> > Sent: Saturday, December 12, 2020 at 9:46 PM
> > From: "Stephen Leake" <stephen_leake@stephe-leake.org>
> > To: "Tim Cross" <theophilusx@gmail.com>
> > Cc: "Jean Louis" <bugs@gnu.support>, thibaut.verron@gmail.com, "Stefan
> Kangas" <stefankangas@gmail.com>, "Boruch Baum" <boruch_baum@gmx.com>,
> "Emacs developers" <emacs-devel@gnu.org>, "Stefan Monnier" <
> monnier@iro.umontreal.ca>, "Richard Stallman" <rms@gnu.org>
> > Subject: Re: non-gnu elpa issue tracking
> >
> > Tim Cross <theophilusx@gmail.com> writes:
> >
> > > On Sun, 13 Dec 2020 at 00:50, Stefan Monnier <monnier@iro.umontreal.ca
> >
> > > wrote:
> > >
> > >> > The non-GNU ELPA is supposed to be a repository for packages which
> are
> > >> GPL
> > >> > compliant and it is a reasonable expectation that those who make
> their
> > >> > packages GPL compliant do so because they support the philosophical
> goals
> > >> > of the FSF.
> > >>
> > >> The overwhelming majority of ELisp packages out there are hosted on
> > >> Github (that also applies to many GNU ELPA packages, many of them are
> > >> developed by long time contributors to Emacs), so I think the evidence
> > >> shows the above expectation doesn't hold at all.
> > >>
> > > Maybe. However, it could also be a combination of the fact github was
> the
> > > first free git hosting environment and is the better known one. Just
> > > because it is this way now doesn't mean it has to be. If the GNU/FSF
> > > doesn't take a clear position on this and do something to discourage
> the
> > > use of hosting environments that force the use of proprietary software,
> > > this will not change and eventually all we will have are the
> proprietary
> > > solutions. It may not have been the right decision to allow code which
> has
> > > assigned copyright to the FSF to remain on Github. However, as non-GNU
> ELPA
> > > is just getting started, now would be a good time to try and change
> > > things.
> >
> > +1.
> >
> > I think we should encourage people to move away from Github, for both
> > GNU and non-GNU ELPA.
> >
> > Given that many ELPA packages are now on Github, we could have a
> > transition policy, with enforceable deadlines (ie, remove package from
> > *GNU ELPA if still on gitub after deadline). However, I doubt that the
> > Emacs project is capable of such a thing, or that we want to be.
> >
> > So we are left with naming and shaming; in list-packages, show the
> > upstream repository along with the license and other info on a package,
> > and show unacceptable ones in red. That could still be a lot of effort
> > to categorize obscure hosts.
>
> I do not see how putting a copy on GitHub is an offence.  We can
> discourage it,
> But removing packages from GNU ELPA if still on Github after deadline, is
> not the way forward.  Removing free software from ELPA is a regressive move
> that will not benefit Gnu in any way.
>
> > Disclaimer; my packages are hosted on Savannah, so any resolution of this
> > will have no direct impact on me.
> >
> > --
> > -- Stephe
> >
> >
>


-- 
regards,

Tim

--
Tim Cross

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

Re: non-gnu elpa issue tracking

[Christopher Dimech]

[-- Attachment #1: Type: text/html, Size: 12319 bytes --]

Re: non-gnu elpa issue tracking

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

  > My main point here is that many of the problems associated with maintenance of
  > packages, such as issue tracking, are being significantly complicated because
  > the code is being maintained on a platform which does not meet GNU/FSF
  > guidelines, philosophy and goals.

We don't have any rules about what platform you can host a GNU package on.
We never had rules about that.

Considering that the packages we put into NonGNU ELPA will not be GNU
packages, we could hardly make a rule about where they can be hosted.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

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

To pressure developers to move their packages off GitHub would cause
resentment -- it would do more harm than good.  But it would be very
useful to start a project to spread awareness of the harm that GitHub
does.

This is a big project, and to do it, we need volunteers.
We need a leader, or a group of a few leaders, to make
a commitment to get this going.

If you would like to do this, please write to me off the list.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Dmitry Gutov]

On 12.12.2020 08:37, Tim Cross wrote:
> With a little encouragement, they would probably be willing to move to 
> at least GitLab, which offers many of the similar convenience features 
> of Github.  Being able to host your package in non-GNU ELPA might be 
> that encouragement.

It would be great to see Emacs development show the way by migrating to 
one such free platform.

That will create a significant practical reason for the package 
developers to do the same: shared workflows and shared users database.

Re: non-gnu elpa issue tracking

[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 non-GNU ELPA is supposed to be a repository for packages which are GPL
  > compliant and it is a reasonable expectation that those who make their
  > packages GPL compliant do so because they support the philosophical goals
  > of the FSF.

I wish this were true, but it is not.  Our influence is limited.  (It
would get stronger if more people showed support for our goals in
a visible way.)

There are some things we must refuse to do, because doing them would
put us in a moral contradiction.  "Please do X", where doing X requires
running a nonfree program, is one thing we must not say.  And we must
not agree to do X ourselves.

However, to go beyond that can be strategically unwise.  To reject
packages simply because the developers release them on GitHub would be
self-defeating.  To try to pressure those users to move off GitHub
when we do not _need_ that would create avoidable friction.

Of course, we won't lead users to download those packages from GitHub.
We will lead users to download them from NonGNU ELPA.


By the way, I think the term "GPL-compliant" has a misunderstanding in
it.  Strictly speaking, the time when you must comply with the GPL (or
whichever license L) is when you reuse material released under that
license.  Thus, a software distribution is GPL-compliant if the
GPL-covered materials in it are used in accord with the GPL.  If it is
NOT GPL-compliant, that means it is a GPL violation.

That is the only valid use of the term "GPL-compliant", and I am
pretty sure it is not what you mean.  You are talking about something
done by the developers themselves, so it must be something else.

Perhaps you mean that the package carries a license compatible with
our license (GPL version 3-or-later).  Is that right?  That is indeed
something we must insist on.  But it does not mean we must insist that
the developers follow all the best practices we recommend, or implore
people to follow.


  > As I understand it, non-GNU ELPA is not supposed to be
  > a repository for all other packages where the author doe snot want to
  > assign copyright to the FSF. It is supposed to be for all other GPL
  > compliant packages where the author does not want to assign copyright to
  > the FSF.

Actually it is not intended as a repository at all.  It is a place for
distributing packages, not for developing them.  It is more similar
to MELPA, but curated.

NonGNU ELPA is our plan for distributing to users any and all packages
which we would like to distribute, and for which there is no big
obstacle to our doing so.

We would like to minimize what we need to ask the developers of those
packages to do for us and with us -- to ask only for what we _need_.

There are some things we need.  For instance, for moral reasons.

In principle, we CAN include (that is, redistribute) a package even if
it has no developers and is unmaintained.  We can say, "Here it is,
use it if you like it, we can't fix it."  But we can't tell users to
run a nonfree program to report bugs.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Christopher Dimech]

> Sent: Sunday, December 13, 2020 at 5:58 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Tim Cross" <theophilusx@gmail.com>
> Cc: emacs-devel@gnu.org, thibaut.verron@gmail.com, stefankangas@gmail.com, bugs@gnu.support, boruch_baum@gmx.com
> Subject: Re: non-gnu elpa issue tracking
>
> [[[ 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 non-GNU ELPA is supposed to be a repository for packages which are GPL
>   > compliant and it is a reasonable expectation that those who make their
>   > packages GPL compliant do so because they support the philosophical goals
>   > of the FSF.
>
> I wish this were true, but it is not.  Our influence is limited.  (It
> would get stronger if more people showed support for our goals in
> a visible way.)
>
> There are some things we must refuse to do, because doing them would
> put us in a moral contradiction.  "Please do X", where doing X requires
> running a nonfree program, is one thing we must not say.  And we must
> not agree to do X ourselves.
>
> However, to go beyond that can be strategically unwise.  To reject
> packages simply because the developers release them on GitHub would be
> self-defeating.  To try to pressure those users to move off GitHub
> when we do not _need_ that would create avoidable friction.
>
> Of course, we won't lead users to download those packages from GitHub.
> We will lead users to download them from NonGNU ELPA.

Quite the right approach.

> By the way, I think the term "GPL-compliant" has a misunderstanding in
> it.  Strictly speaking, the time when you must comply with the GPL (or
> whichever license L) is when you reuse material released under that
> license.  Thus, a software distribution is GPL-compliant if the
> GPL-covered materials in it are used in accord with the GPL.  If it is
> NOT GPL-compliant, that means it is a GPL violation.
>
> That is the only valid use of the term "GPL-compliant", and I am
> pretty sure it is not what you mean.  You are talking about something
> done by the developers themselves, so it must be something else.
>
> Perhaps you mean that the package carries a license compatible with
> our license (GPL version 3-or-later).  Is that right?  That is indeed
> something we must insist on.  But it does not mean we must insist that
> the developers follow all the best practices we recommend, or implore
> people to follow.

In some way, the license needs to be compatible, or has the ability to
re-license for compatibility with Emacs.

>   > As I understand it, non-GNU ELPA is not supposed to be
>   > a repository for all other packages where the author doe snot want to
>   > assign copyright to the FSF. It is supposed to be for all other GPL
>   > compliant packages where the author does not want to assign copyright to
>   > the FSF.
>
> Actually it is not intended as a repository at all.  It is a place for
> distributing packages, not for developing them.  It is more similar
> to MELPA, but curated.

That's right.

> NonGNU ELPA is our plan for distributing to users any and all packages
> which we would like to distribute, and for which there is no big
> obstacle to our doing so.
>
> We would like to minimize what we need to ask the developers of those
> packages to do for us and with us -- to ask only for what we _need_.
>
> There are some things we need.  For instance, for moral reasons.
>
> In principle, we CAN include (that is, redistribute) a package even if
> it has no developers and is unmaintained.  We can say, "Here it is,
> use it if you like it, we can't fix it."  But we can't tell users to
> run a nonfree program to report bugs.

Agreed

> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
>

Re: non-gnu elpa issue tracking

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-12-12 08:35]:
> [[[ 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 far as I remember from a previous discussion, it is possible to use
>   > github with javascript disabled, but creating an account requires
>   > running non-free javascript for the captcha. And it is not possible to
>   > open or comment on issues without an account.
> 
> Assuming someone who knows for certain confirms that information, I
> have to conclude that reporting bugs via GitHub comments is not an
> ethical way to accept bug reports.  We cannot direct users to report
> bugs in the package that way.  We should edit the README file to
> remove that.

For sign up on Github users need to run proprietary Javascript. On the
sign up page there are few Javascript scripts proprietary and few are
free software. Maybe we could ask Github to liberate the remaining
proprietary Javascript:

These are proprietary at their sign up page:
https://github.githubassets.com/assets/environment-f0adafbf.js
https://github.githubassets.com/assets/chunk-frameworks-3bf3525b.js
https://github.githubassets.com/assets/behaviors-0c84c38c.js
https://github.githubassets.com/assets/signup-932f16e0.js
https://github.githubassets.com/assets/sessions-d2e5da85.js
https://github.githubassets.com/assets/unsupported-a85b1284.js

I have seen others of them free software under Apache 2.0. That is why
I say maybe we can ask Github to liberate everything if they already
included few free software Javascript scripts.

Bigger picture there is that Github made plans to trap developres to
depend of Github only by providing various server side apps that
exists only in Github. That is computing for users on the server. They
call it Marketplace: https://github.com/marketplace

So users may get server-side computing services such as:

- CodeScene, A quality visualization tool to identify and prioritize
  technical debt and evaluate your organizational efficiency

- DeepScan, Advanced static analysis for automatically finding runtime
  errors in JavaScript code

- Codacy, Automated code reviews to help developers ship better
  software, faster

- Codecov, Automatic test report merging for all CI and languages into
  a single code coverage report directly into your pull request

- Codetree, Lightweight project management for GitHub issues

- DeepAffects, Metrics for Team Dynamics and Productivity

- Slack + GitHub, Connect your code without leaving Slack

Please somebody make me wrong, but majority of those server side
services recommended by Github are computing for users especially for
free software developers, and all of them are proprietary software,
right?

Some of them are free software. Those that are free softwar I did not
see being offered to "set up a plan" and having heavy proprietary
licenses like those that do have "set up a plan" feature.

So it is new way of selling proprietary software to let it run
server-side. Some server-side packages drive users to use client-side
proprietary software such as it is Slack.

Goal of Microsoft Github is take away control from free software
development. When 50 million developers host at Github they are prone
to get trapped, like they are trapped. Once they start taking and
using server-side applications the trap becomes complete as
dependencies become so strong that developer cannot easily switch from
Github to some other common code hosting platform. Developers also
forget that they can easily host their code themselves.

From: https://sanctum.geek.nz/why-not-github.html

It’s become more widely known that GitHub had a contract with United
States Immigrations and Customs Enforcement (ICE), an ethical
hot-topic at present after similar disputes with config management
software Chef. Again, the issue here is not whether this is good or
bad, it’s that you’re handing GitHub power over your work, while they
may be using their proprietary software to political ends that you
find repugnant, and refusing you the right to fork and apply their
code in the way that suits you, the user. Avoiding these sorts of
problems is the entire basis of Freedom 0.

Reference:
https://www.theverge.com/2019/10/9/20906213/github-ice-microsoft-software-email-contract-immigration-nonprofit-donation

Github will control the repository over political correctness:
https://www.techdirt.com/articles/20150802/20330431831/github-nukes-repository-over-use-word-retard.shtml

https://www.theregister.com/2013/12/19/feminist_software_foundation_c_plus_equality/

You are subject to vendor lock-in: Well, git might be decentralized, but all other tools that you use to collaborate on software development probably aren’t. And if any of these tools is provided by GitHub, you might find out the hard way you have effectively locked yourself in GitHub and you are unable to move to another vendor.

As of September 2015, free GitHub account includes source code hosting, issue tracker, wiki and static website hosting. We have already established that moving git repository to another hosting is easy due to decentralized nature of git. But what about the others?

Issue tracker is probably the most important one; it’s also the hardest to move out of GitHub. The tricky part is not getting your data out (there are plenty of tools for that), but getting it into new system. First of all, your issue tracking software of choice must have some kind of importing tool. Then, that tool must be compatible with whatever format your exporting tool produced. By the way - that pool of exporting tools? Each one of them produces something slightly different.

https://mirekdlugosz.com/blog/2015/why-i-dont-use-github-exclusively/#you-are-subject-to-vendor-lock-in

Then from: New GitHub Terms of Service r̲e̲q̲u̲i̲r̲e̲ removing many Open
Source works from it 2017-03-01 by tg
https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm

The new Terms of Service of GitHub became effective today, which is quite problematic — there was a review phase, but my reviews pointing out the problems were not answered, and, while the language is somewhat changed from the draft, they became effective immediately.

Now, the new ToS are not so bad that one immediately must stop using
their service for disagreement, but it’s important that certain
content may no longer legally be pushed to GitHub. I’ll try to explain
which is affected, and why.

Anything requiring attribution (e.g. CC-BY, but also BSD, …)

Section D.7 requires the person uploading content to waive any and all attribution rights. Ostensibly “to allow basic functions like search to work”, which I can even believe, but, for a work the uploader did not create completely by themselves, they can’t grant this licence.

The CC licences are notably bad because they don’t permit sublicencing, but even so, anything requiring attribution can, in almost all cases, not “written or otherwise, created or uploaded by our Users”. This is fact, and the exceptions are few.
Anything putting conditions on the right to “use, display and perform” the work and, worse, “reproduce” (all Copyleft)

Section D.5 requires the uploader to grant all other GitHub users…

    the right to “use, display and perform” the work (with no further restrictions attached to it) — while this (likely — I didn’t check) does not exclude the GPL, many others (I believe CC-*-SA) are affected, and…
    the right to “reproduce your Content solely on GitHub as permitted through GitHub's functionality”, with no further restructions attached; this is a killer for, I believe, any and all licences falling into the “copyleft” category.

Note that section D.4 is similar, but granting the licence to GitHub (and their successors); while this is worded much more friendly than in the draft, this fact only makes it harder to see if it affects works in a similar way. But that doesn’t matter since D.5 is clear enough. (This doesn’t mean it’s not a problem, just that I don’t want to go there and analyse D.4 as D.5 points out the same problems but is easier.)

This means that any and all content under copyleft licences is also no longer welcome on GitHub.
Anything requiring integrity of the author’s source (e.g. LPPL)

Some licences are famous for requiring people to keep the original intact while permitting patches to be piled on top; this is actually permissible for Open Source, even though annoying, and the most common LaTeX licence is rather close to that. Section D.3 says any (partial) content can be removed — though keeping a PKZIP archive of the original is a likely workaround.
Affected licences

Anything copyleft (GPL, AGPL, LGPL, CC-*-SA) or requiring attribution (CC-BY-*, but also 4-clause BSD, Apache 2 with NOTICE text file, …) are affected. BSD-style licences without advertising clause (MIT/Expat, MirOS, etc.) are probably not affected… if GitHub doesn’t go too far and dissociates excerpts from their context and legal info, but then nobody would be able to distribute it, so that’d be useless.
But what if I just fork something under such a licence?

Only “continuing to use GitHub” constitutes accepting the new terms. This means that repositories from people who last used GitHub before March 2017 are excluded.

Even then, the new terms likely only apply to content uploaded in March 2017 or later (note that git commit dates are unreliable, you have to actually check whether the contribution dates March 2017 or later).

And then, most people are likely unaware of the new terms. If they upload content they themselves don’t have the appropriate rights (waivers to attribution and copyleft/share-alike clauses), it’s plain illegal and also makes your upload of them or a derivate thereof no more legal.

Granted, people who, in full knowledge of the new ToS, share any
“User-Generated Content” with GitHub on or after 1ˢᵗ March, 2017, and
actually have the appropriate rights to do that, can do that; and if
you encounter such a repository, you can fork, modify and upload that
iff you also waive attribution and copyleft/share-alike rights for
your portion of the upload. But — especially in the beginning — these
will be few and far between (even more so taking into account that
GitHub is, legally spoken, a mess, and they don’t even care about
hosting only OSS / Free works).

Self-hosted free software exists to replace Github:

https://gogs.io/ or https://www.gerritcodereview.com/, Gitea, Gitlabs,
and others.

Re: non-gnu elpa issue tracking

[Alfred M. Szmidt]

Can you please move the discussion of what Github does or doesn't to
gnu-misc-discuss?

Re: non-gnu elpa issue tracking

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

  > Bigger picture there is that Github made plans to trap developres to
  > depend of Github only by providing various server side apps that
  > exists only in Github. That is computing for users on the server. They
  > call it Marketplace: https://github.com/marketplace

Most of these facilities of GitHub are SaaSS; we urge users to
reject them and release free programs to do these jobs.

  > - Slack + GitHub, Connect your code without leaving Slack

Slack is not SaaSS -- it is a service that requires running a nonfree
client program.  Therefore we condemn it.  See stallman.org/slack.html.

  > Please somebody make me wrong, but majority of those server side
  > services recommended by Github are computing for users especially for
  > free software developers, and all of them are proprietary software,
  > right?

If I understand right, the software they use to implement this is
_private_.  We do not know anything about it.  It might include some
free software and some nonfree.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

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

  > For sign up on Github users need to run proprietary Javascript. On the
  > sign up page there are few Javascript scripts proprietary and few are
  > free software. Maybe we could ask Github to liberate the remaining
  > proprietary Javascript:

  > These are proprietary at their sign up page:
  > https://github.githubassets.com/assets/environment-f0adafbf.js
  > https://github.githubassets.com/assets/chunk-frameworks-3bf3525b.js
  > https://github.githubassets.com/assets/behaviors-0c84c38c.js
  > https://github.githubassets.com/assets/signup-932f16e0.js
  > https://github.githubassets.com/assets/sessions-d2e5da85.js
  > https://github.githubassets.com/assets/unsupported-a85b1284.js

It would be good to ask them.  But it would be difficult for me to do so.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-12-13 08:03]:
> [[[ 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. ]]]
> 
>   > For sign up on Github users need to run proprietary Javascript. On the
>   > sign up page there are few Javascript scripts proprietary and few are
>   > free software. Maybe we could ask Github to liberate the remaining
>   > proprietary Javascript:
> 
>   > These are proprietary at their sign up page:
>   > https://github.githubassets.com/assets/environment-f0adafbf.js
>   > https://github.githubassets.com/assets/chunk-frameworks-3bf3525b.js
>   > https://github.githubassets.com/assets/behaviors-0c84c38c.js
>   > https://github.githubassets.com/assets/signup-932f16e0.js
>   > https://github.githubassets.com/assets/sessions-d2e5da85.js
>   > https://github.githubassets.com/assets/unsupported-a85b1284.js
> 
> It would be good to ask them.  But it would be difficult for me to
> do so.

I have no idea where to open that issue, I have placed it here for
now:

https://github.com/github/welcome-to-github/issues/22



Jean

Re: non-gnu elpa issue tracking

[Vasilij Schneidermann]

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

> I have no idea where to open that issue, I have placed it here for
> now:
> 
> https://github.com/github/welcome-to-github/issues/22

I've browsed that repo and found the following in a different issue:

> Please describe and send your issue regarding to support@github.com.
> This is not suitable place for talking about Github official UI.
> thanks. best regards.

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

Re: non-gnu elpa issue tracking

[Jean Louis]

* Vasilij Schneidermann <mail@vasilij.de> [2020-12-14 21:50]:
> > I have no idea where to open that issue, I have placed it here for
> > now:
> > 
> > https://github.com/github/welcome-to-github/issues/22
> 
> I've browsed that repo and found the following in a different issue:
> 
> > Please describe and send your issue regarding to support@github.com.
> > This is not suitable place for talking about Github official UI.
> > thanks. best regards.

I wrote to that email address as well, thank you. It would be good
that they liberate it as few other scripts on login are already Apache
2.0 license.

Jean

Re: non-gnu elpa issue tracking

[Boruch Baum]

On 2020-12-14 20:38, Jean Louis wrote:
> For sign up on Github users need to run proprietary Javascript. On the
> sign up page there are few Javascript scripts proprietary and few are
> free software. Maybe we could ask Github to liberate the remaining
> proprietary Javascript:

1) How can JS ever be considered 'free' (and benign) when it's pushed to
   the client browser at run-time from an external server? Until it's
   received (at page load time), no user can possibly know what its
   contents truly are.

   1.1) Even if a user had something like a set of HOSTS file entries
        redirecting the HTTP requests for JS to a local repository, the
        local JS repository would need to be kept up-to-date, BUT ...

   1.2) Once a local repository exists, the JS being pushed no longer
        needs to be 'free' because it won't be used anyway; All that's
        required is API compatibility.

2) For me (IFF: I were to adopt your position re: github) your solution
   sounds insufficient, because it wouldn't impose upon github a legal
   commitment not to inject proprietary JS in the future.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: non-gnu elpa issue tracking

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-12-14 22:14]:
> On 2020-12-14 20:38, Jean Louis wrote:
> > For sign up on Github users need to run proprietary Javascript. On the
> > sign up page there are few Javascript scripts proprietary and few are
> > free software. Maybe we could ask Github to liberate the remaining
> > proprietary Javascript:
> 
> 1) How can JS ever be considered 'free' (and benign) when it's pushed to
>    the client browser at run-time from an external server? Until it's
>    received (at page load time), no user can possibly know what its
>    contents truly are.
> 
>    1.1) Even if a user had something like a set of HOSTS file entries
>         redirecting the HTTP requests for JS to a local repository, the
>         local JS repository would need to be kept up-to-date, BUT ...
> 
>    1.2) Once a local repository exists, the JS being pushed no longer
>         needs to be 'free' because it won't be used anyway; All that's
>         required is API compatibility.
> 
> 2) For me (IFF: I were to adopt your position re: github) your solution
>    sounds insufficient, because it wouldn't impose upon github a legal
>    commitment not to inject proprietary JS in the future.

It is up to them to decide on that, there is nothing wrong to ask. We
cannot impose any legal commitment on third parties.

Best is when entities like Github commit voluntarily. Even then there
is no legal commitment.

It is hypocrisy that they host free software but coerce users to run
non-free software for login.

Jean

Re: non-gnu elpa issue tracking

[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 is hypocrisy that they host free software but coerce users to run
  > non-free software for login.

If they claimed they intended to promote free software, it would be
hypocrisy.  However, what they claim to promote is "open source",
and the basis of open source si that "It isn't a matter of principles,
or right and wrong."  It is not easy to achieve hypocrisy in that ;-{.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

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

  > 1) How can JS ever be considered 'free' (and benign) when it's pushed to
  >    the client browser at run-time from an external server? Until it's
  >    received (at page load time), no user can possibly know what its
  >    contents truly are.

To avoid misunderstanding, let's distinguish two levels for this conversation.

The more specific level is the definition of free software.

Any program can be judged according to that.  A program written in
Javascript could be meant as a browser extension or it could be meant
to be sent in a web page.  Indeed, it is not unusual that the same
code could be useful in both ways.  Javascript code can also be run in
a server.  The definition of free software applies the same to all
these scenarios.

Then there is a deeper question: is it truly wise to run software
sent by a web page?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

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

  > 1) License disclosure: The summaries indicate that RMS is open to having
  >    the repository host packages bearing *any* free license,

Actually no.  The rules, in README.org, say the license has to be
compatible with GPL 3-or-later, which is the licensing of GNU Emacs
itself.

                                                                but there
  >    may be users who are pickier, so a package's license should be
  >    disclosed prominently on the listing page and the package detail
  >    page;

That seems like a good idea.

  > 2) The acceptance or candidacy process for each package should be
  >    documented in some discrete method.

Whether to have a certain package in NonGNU ELPA could be a touchy
question, in some borderline cases.  Stating the reasons could perhaps
hurt feelings, or lead to arguments.  So it is best not to do that.
We will add a package or we won't.

If you know about a package we don't add, you will be able to find it
(without our help).

  > 3) After a package is initially accepted to the repository, the
  >    summaries of Richard Stallman's presentation indicate that subsequent
  >    commits or releases may be rejected or modified. That record should
  >    also be documented.

It could be a good idea to document the reasons for decisions like these.
Future maintainers will need to understand this.

I don't think we should make a commitment to publish this without exception,
but usually there will be no reason not to.

  > 4) There's no link on the repository page[1] to the software being used
  >    to generate it, and the forge at which it is being developed. 

It would be fine to add that info.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Boruch Baum]

On 2020-12-09 23:35, Richard Stallman wrote:
>   > 2) The acceptance or candidacy process for each package should be
>   >    documented in some discrete method.
>
> Whether to have a certain package in NonGNU ELPA could be a touchy
> question, in some borderline cases.  Stating the reasons could perhaps
> hurt feelings, or lead to arguments.  So it is best not to do that.
> We will add a package or we won't.

This speaks to emacs/GNU/FSF "corporate culture" and really has much
wider consequences than for non-GNU ELPA, so I'll fork my comment in
response into a new thread.

>   > 3) After a package is initially accepted to the repository, the
>   >    summaries of Richard Stallman's presentation indicate that subsequent
>   >    commits or releases may be rejected or modified. That record should
>   >    also be documented.
>
> It could be a good idea to document the reasons for decisions like these.
> Future maintainers will need to understand this.
>
> I don't think we should make a commitment to publish this without exception,
> but usually there will be no reason not to.

Re: non-gnu elpa issue tracking

[Eli Zaretskii]

On December 10, 2020 7:03:35 AM GMT+02:00, Boruch Baum <boruch_baum@gmx.com> wrote:
> On 2020-12-09 23:35, Richard Stallman wrote:
> >   > 2) The acceptance or candidacy process for each package should
> be
> >   >    documented in some discrete method.
> >
> > Whether to have a certain package in NonGNU ELPA could be a touchy
> > question, in some borderline cases.  Stating the reasons could
> perhaps
> > hurt feelings, or lead to arguments.  So it is best not to do that.
> > We will add a package or we won't.
> 
> This speaks to emacs/GNU/FSF "corporate culture" and really has much
> wider consequences than for non-GNU ELPA, so I'll fork my comment in
> response into a new thread.

That's fine, but let's please not have that thresd here, as discussing this stuff is a tangent to this list's scope.

TIA

"Open records", "good government principles", "corporate culture"

[Boruch Baum]

From the recent thread "non-gnu elpa issue tracking"

On 2020-12-09 23:35, Richard Stallman wrote:
>   > 2) The acceptance or candidacy process for each package should be
>   >    documented in some discrete method.
>
> Whether to have a certain package in NonGNU ELPA could be a touchy
> question, in some borderline cases.  Stating the reasons could perhaps
> hurt feelings, or lead to arguments.  So it is best not to do that.
> We will add a package or we won't.

The paragraph explicitly evokes three fears:

  1) Avoid touchy questions;

  2) Avoid hurt feelings;

  3) Avoid arguments.

Implicit in the paragraph, I read:

  4) Fear of accountability;

  5) Insecurity and feelings of weakness;

  6) Unwilling to establish boundaries;

  7) Passive aggression;

For a private person conducting interpersonal relations ... Who cares?
Who wants to be judgmental? I can't be bothered.

However, for any professional environment in either the public or
private sector (of the "developed Western secular" world)... Should I
care? I'm an outsider to the emacs/GNU/FSF development team, but when I
read that paragraph, many frustrating interactions that I've had with
the several of the emacs team made a lot more sense.

Because I have limited 'skin in the game', I don't intend to rant or
compose a manifesto; the time I spend writing comes out of my limited
'charity' budget for contributing to FOSS. There's ample relevant
academic and professional literature on the "best practices" for
corporate culture and good governance[1].

  1) Avoid touchy questions

     I have no idea what you mean, but that's usually code for religion,
     sex, and politics. Clearly and openly establish your policies for
     no-go topics of discussion, and when those topics are brought up,
     say so and refer to your policy. Or just adopt the generally
     accepted professional standard.

  2) Avoid hurt feelings

     I have no idea what you mean, but that's usually code for
     intentional dishonesty or intentional unjustifiable decision-making
     (For example, in this case it's the rejection itself that causes
     the 'hurt feeling'. The refusal to disclose the reason for the
     rejection is just CYA).

  3) Avoid arguments

     I have no idea what you mean, but that's usually code for fear of
     oversight. Any exchange of ideas, no matter how polite, can be
     framed as an argument.


[1] Not my PhD. I write based upon personal professional experience
    in small/large/huge private sector companies and in government, in
    several countries. Several of my employers would even send all
    employees to formal internal training classes (with exams) on their
    corporate culture and good governance standards.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: "Open records", "good government principles", "corporate culture"

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-12-10 09:41]:
> From the recent thread "non-gnu elpa issue tracking"
> 
> On 2020-12-09 23:35, Richard Stallman wrote:
> >   > 2) The acceptance or candidacy process for each package should be
> >   >    documented in some discrete method.
> >
> > Whether to have a certain package in NonGNU ELPA could be a touchy
> > question, in some borderline cases.  Stating the reasons could perhaps
> > hurt feelings, or lead to arguments.  So it is best not to do that.
> > We will add a package or we won't.

I could understand that point in different way then you got it. I
think no need for offense here. 

It is trivial to make one's own ELPA, and I consider doing so for the
sake of simplicity and re-using configurations in a speedy manner
without confusing my team members. When I would be doing that I could
keep the private ELPA on Internet even make it available to others,
but I would not need to explain nothing. If I would explain it, it
would cause people to comment back and argue about my decisions. For
person like me such discussions are of no significance but for larger
group of developers they may become.

Look at the Github, when somebody wish to fork a package, they just
click and do. Finished there. No discussion, nothing. i do not see any
bad intentions there. Those repositories are not comparable and
non-GNU ELPA has different purposes then some general package
repositories. I see the purpose in enhancement of the default Emacs.
Packages are not part of Emacs but become available in the same free
software spirit by default.

Emacs maintainers due to its experience and analytical capabilities
may then decide what would package would be useful to enhance Emacs by
including it in non-GNU ELPA as well. Now imagine 500 discussions for
500 packages not included x 5 comments minimum. 

Software authors may propose package to be included in GNU ELPA just
as usual.

All those are my personal opinions. I see nothing wrong.

> Implicit in the paragraph, I read:
> 
>   4) Fear of accountability;

Quite contrary, I see the sense to accountability and sense to
responsibility towards us as users and future users. We have just been
discussing packages that are public domain but not CC0. Obviously such
public domain packages are not acceptable. If package is useful
developers can still ask the author to re-license it at least to CC0
license. The care to include or not include package that is in other
jurisdiction but US probably proprietary is transparent here on the
mailing list, and also shows accountability.

As it is general rule to include GPL compatible software, that rule
alone is transparent and made public and shows accountability. 

>   5) Insecurity and feelings of weakness;

For this I have no idea, as I cannot see your viewpoint. I wish I could.

>   6) Unwilling to establish boundaries;

For that I see it quite contrary, there are free software boundaries,
aren't they? 

>   7) Passive aggression;

Sorry, I cannot see that, it is harder for me to get into that viewpoint.

> However, for any professional environment in either the public or
> private sector (of the "developed Western secular" world)... Should I
> care? I'm an outsider to the emacs/GNU/FSF development team, but when I
> read that paragraph, many frustrating interactions that I've had with
> the several of the emacs team made a lot more sense.

But let us look at purposes. What is good is that we help each other.
I think it is great. Sometimes in discussing things it can be
frustrating. But one has to look at intentions of both parties as
those intentions are almost always good, and intention is to help each
other. 

My experience is that, to me several major bugs have been solved that
enabled me to use Emacs to speed up my management. I look at those
assistances as valuable. It is impossible for every human interaction
to result positively for all parties. Otherwise they would not be
discussing it.

Jean

Re: "Open records", "good government principles", "corporate culture"

[Eli Zaretskii]

I urge everyone to please respond to this on some forum other than
this one; emacs-tangents or gnu-misc-discuss come to mind.  These
issues are off-topic on this list.

TIA

Re: "Open records", "good government principles", "corporate culture"

[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 have good reasons for doing what I do, but you might not appreciate
them since they are based on a context unlike the projects you have
experience with.

Most free software projects have no goal, no agenda, except to be
useful and successful.  Many define whoever develops them as in
charge.  Most of them describe their work as "open source" and believe
that the main virtue is "openness".  They have developed practices
which fit that context.

The GNU Project is very different from that.  I started it to develop
a free operating system, GNU, for a political cause: free software
(free as in freedom).  Every GNU package is part of this effort and
has this as its main goal.  Not "openness".

This situation has consequences that may not be obvious.  Treating the
project like those "open source" projects would make for big trouble.

Nonetheless, you might know ways I could handle this better.  If I
explain the situation and its particular problems, maybe you could
suggest some.  You have no obligation to spend time on this, but if
you want to, please let's talk by voice -- to save time and hands.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: non-gnu elpa issue tracking

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-12-09 15:57]:
> 1) License disclosure: The summaries indicate that RMS is open to having
>    the repository host packages bearing *any* free license, but there
>    may be users who are pickier, so a package's license should be
>    disclosed prominently on the listing page and the package detail
>    page;

For me it was natural that free software license should be GPL
compatible license, so I was consulting this page when reviewing a
pattern of licenses:
https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

Example is public domain but not CC0 where such package is not
compatible with the GPL as it is not compatible with world
jurisdictions. Many would not recognize "public domain" and that
renders software proprietary.

I think that new column or license in the description of the package
would be beneficial. The stance alone that licensing is important and
that GPL compatible licenses are acceptable is also good for people to
get awareness.

> 2) The acceptance or candidacy process for each package should be
>    documented in some discrete method. Melpa does this using github's
>    pull request feature, which documents the entire conversation related
>    to the process of accepting a package.

It should be clear now that some packages do not even bear any license inside.

kiwix-20200714.1357.tar - has no license inside. Maybe it has in the
original repository, but the license must be given explicitly. If not
given explicitly with software it is proprietary. If it was a mistake
by Melpa's workflow then Emacs developers could try to look into the
original repository and fetch software from there. This would be
anyway better.

Those are 2 examples showing that Melpa does not do the job well and
there are hundreds of other examples. 

That shows  that their process of documenting acceptance of the
packages is flowed, and process of distributing packages is flowed.
Melpa distributes proprietary packages. There is no need to compare to
it.

As the major difference between GNU ELPA and Melpa is ethics, one need
not compare ethical repository to the one lacking ethical principles.

Let us say if I wish to make private repository of Emacs packages I
would not be discussing with anybody, I would just make it. 

> 3) After a package is initially accepted to the repository, the
>    summaries of Richard Stallman's presentation indicate that subsequent
>    commits or releases may be rejected or modified. That record should
>    also be documented. Debian does this using its own package tracking
>    software.

If there is a mailing list where people apply with patches it would
get automatically recorded. Just as now for Emacs and GNU ELPA
packages.