From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Drop the Copyright Assignment requirement for Emacs Date: Sat, 9 May 2020 12:35:42 +0100 Message-ID: References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <97DA7804-F647-4A1D-B8E0-AFFE7A324C64@gmail.com> <87d07xamrg.fsf@ericabrahamsen.net> <878silajdl.fsf@ericabrahamsen.net> <87tv18pyh4.fsf@russet.org.uk> <83zhaih0oz.fsf@gnu.org> <83pnbegsvm.fsf@gnu.org> <83imh5hby1.fsf@gnu.org> <83y2q1fn3t.fsf@gnu.org> <83sgg9fm1g.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="40705"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 13:36:41 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 1jXNma-000AVC-Tn for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 13:36:40 +0200 Original-Received: from localhost ([::1]:40826 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXNmZ-000283-De for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 07:36:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56318) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXNls-0001Yn-S1 for emacs-devel@gnu.org; Sat, 09 May 2020 07:35:56 -0400 Original-Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]:40458) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jXNlr-0002hO-G1; Sat, 09 May 2020 07:35:56 -0400 Original-Received: by mail-io1-xd29.google.com with SMTP id s10so4473116iog.7; Sat, 09 May 2020 04:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F/YmR7YRV4ts9CvEWDIRUq4aO10lFD+4dqlNwEGBDT4=; b=f7tjdiRlKgEgFTMeqqis1UZsUbfPv5J7kb6HL1p5sYkiX+TM9D4DADJ8Al6C6RCanI MA1wuEf8nhrq85J+6c+Rgt1GUD/K/FC7XlE8zXvl7McAkhKSZcwganx0xw9oYgcRGF7z 8iOoM0axa1kHR18qPwLv9CoPQcZdo4NmYL4hNI8FOBv/O053WENz/EqEOMtjQM3h0fcn poYq2+Wnbc6gkjV3RnnnVR9WkqFSVP1daBzh69NIytQLennLvmVIYQWAdEQYqAYXSTuv oHoox1i05Ocm5w26vLLj2x8Qjn+93MKgY/FMsIZHtPNC9ZXQluYWKymoQSy1D4o6DL0E QaIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F/YmR7YRV4ts9CvEWDIRUq4aO10lFD+4dqlNwEGBDT4=; b=EykGQv+AJ07HxaafR2R/9Rzu/ec+FCfphDSuRIc9ZBYbCXLMexEHOSY4dvHd3d0VnB 1NO76T2F+q/wiK6hO9Iqs6J3V4XtOn1sUIZT58fzIMcQHkGowbbnjUGx5XzbbW5ajLvQ nDmRt613ce6wBOu8EwJETqsDGmphG9d3Peqvtbj8UXE4mz4ngB2NP/fGZdgEKAAUcUCM qEybTJO/ZTawy03GP47qnSNuQ98YFqvxa3/h1ffSwEjQXK8LKJBxhPaHi+s0QFlO1v40 vtvZ8dhkdLFp7OnOy1LzuNE1SJTtIW5+VFv1dZt5Mjgon4q9m2Yl5KfJYo0hrpE+OZiW D1oA== X-Gm-Message-State: AGi0PuYTpi1w661IMsBENJordGMDyjPDaoE0RbG/kDRtVrlDDf8D+XBh 8Mw2hldW4y6nyUS6sdkRF6D8CTMGkvzP1gW6M3HVG70n2NI= X-Google-Smtp-Source: APiQypIpgZmL39fxnGgD9Fwag1u51VTvp2Y2eDEmb5+0byG99XPheFxHhKTJp8WwvZEIA1PBv3j54Jiz9Z3H2g1a8zA= X-Received: by 2002:a05:6602:164c:: with SMTP id y12mr6089852iow.138.1589024153478; Sat, 09 May 2020 04:35:53 -0700 (PDT) In-Reply-To: <83sgg9fm1g.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::d29; envelope-from=joaotavora@gmail.com; helo=mail-io1-xd29.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:249404 Archived-At: On Sat, May 9, 2020 at 11:19 AM Eli Zaretskii wrote: > So I guess there's no such process at this time. We just have some > packages that are already in core, and are _also_ available from ELPA. > IOW, it's a static situation that is not designed to change. Not 100% sure what you mean by that. But yes, there's no pre-planned route for :core packages. We decide if it's convenient to do it on a case by case. Notice it does have drawbacks. Once you do this for a lisp/foo.el file, you need to add this: ;; Package-Requires: ((emacs "xx.y")) ;; This is an Elpa :core package. Don't use functionality that is not ;; compatible with Emacs xx.y. Most of the times, I think the trade-off is more than acceptable. > Is that really important? Why cannot the authors experiment with that > while outside ELPA? They can, of course, but you're denying that "official" GNU stamp. There's the legitimate ambition of recognition, very common among younger developers, because these kinds of things can matter in job interviews, for example. > > 2. We envisioned (I recall) that Emacs might one day be distributed > > with some of the packages in ELPA, presumably the well behaved > > ones. > This would require the same requirements as we ask for inclusion in > core. Not quite the same. The bar for inclusion in the core is higher. The candidate code has to have technical merit because it's going to be used by other code already in the core, creating a dependency. This is theoretically why including s.el in GNU Elpa would be less bad than including it in Emacs. However some people think, and I agree with them, that this would encourage other packages in GNU Elpa to adopt s.el's prepotent prefix and thus create a larger problem. This is, by the way, why I think this is a technical problem at heart: if s.el's default prefix wasn't so harmful there would be no reason not to include it in GNU Elpa AFAICT. > [Those requirements] doesn't seem to be happening, and AFAIU > it isn't by omission. It's happening de facto for some (or most?), packages in ELPA, AFAIU. I don't remember people requesting it from me explicitly, but my memory is hazy here. Jo=C3=A3o