From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: non-gnu elpa issue tracking Date: Sat, 12 Dec 2020 22:33:27 +0300 Message-ID: References: <20201209125516.lenqswi7fhiscbr2@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4354"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: stefankangas@gmail.com, boruch_baum@gmx.com, thibaut.verron@gmail.com, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 12 21:28:19 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1koBV5-0000w4-0c for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Dec 2020 21:28:19 +0100 Original-Received: from localhost ([::1]:34110 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koBV4-0000NO-0J for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Dec 2020 15:28:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35758) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koAiY-0001VZ-20 for emacs-devel@gnu.org; Sat, 12 Dec 2020 14:38:10 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:38017) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koAiS-0005Ll-WE; Sat, 12 Dec 2020 14:38:08 -0500 Original-Received: from localhost ([::ffff:41.202.241.30]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 00000000000308F5.000000005FD51C19.00005C14; Sat, 12 Dec 2020 12:38:00 -0700 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:260725 Archived-At: * Richard Stallman [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.