From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: wgreenhouse-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org (W. Greenhouse) Newsgroups: gmane.emacs.devel Subject: Re: Copyright/Distribution questions (Emacs/Orgmode) Date: Thu, 14 Mar 2013 16:00:27 +0000 Message-ID: <87y5dqdl9g.fsf@riseup.net> References: <87ober717z.fsf@gmail.com> <87mwu9iwcp.fsf@gmail.com> <87mwu9fiu0.fsf@uwakimon.sk.tsukuba.ac.jp> <87d2v4f5bb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a9q7eynu.fsf@uwakimon.sk.tsukuba.ac.jp> <87ip4ug5m0.fsf@riseup.net> <874ngefej8.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1363276931 28064 80.91.229.3 (14 Mar 2013 16:02:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Mar 2013 16:02:11 +0000 (UTC) To: emacs-devel-mXXj517/zsQ@public.gmane.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org-mXXj517/zsQ@public.gmane.org Thu Mar 14 17:02:30 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UGAbs-0008LM-S5 for ged-emacs-devel@m.gmane.org; Thu, 14 Mar 2013 17:02:29 +0100 Original-Received: from localhost ([::1]:49417 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGAbV-00084e-P3 for ged-emacs-devel@m.gmane.org; Thu, 14 Mar 2013 12:02:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGAaZ-0006gY-9m for emacs-devel-mXXj517/zsQ@public.gmane.org; Thu, 14 Mar 2013 12:01:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGAaM-0001nv-U7 for emacs-devel-mXXj517/zsQ@public.gmane.org; Thu, 14 Mar 2013 12:01:07 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:41102) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGAaM-0001nT-2s for emacs-devel-mXXj517/zsQ@public.gmane.org; Thu, 14 Mar 2013 12:00:54 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UGAaa-0006lA-KO for emacs-devel-mXXj517/zsQ@public.gmane.org; Thu, 14 Mar 2013 17:01:08 +0100 Original-Received: from 91.219.237.161 ([91.219.237.161]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Mar 2013 17:01:08 +0100 Original-Received: from wgreenhouse by 91.219.237.161 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Mar 2013 17:01:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 212 Original-X-Complaints-To: usenet-dbVV3NMTNubNLxjTenLetw@public.gmane.org X-Gmane-NNTP-Posting-Host: 91.219.237.161 X-Archive: encrypt User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) Cancel-Lock: sha1:MSa8eVMUH0RNpTsyjlc4UEfUcFg= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel-mXXj517/zsQ@public.gmane.org X-Mailman-Version: 2.1.14 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.org-mXXj517/zsQ@public.gmane.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org-mXXj517/zsQ@public.gmane.org Xref: news.gmane.org gmane.emacs.devel:157854 Archived-At: "Stephen J. Turnbull" writes: > W. Greenhouse writes: > > > Your 10 line program likely does not pass the de minimis threshold to be > > copyrightable in the first place, > > I think you'll find there is no such de minimis in copyright law. Eg, > surely individual haiku are copyrightable. There is de minimis originality and creativity, rather than de minimis length. The haiku has a stronger claim to copyright--because it is an original and entirely non-functional work--than would fifty lines of the typical Emacs user's initfile, some variable settings, perhaps a defadvice or two, and some snippet from the Emacswiki. The three lines are creativity without having any function at all, while the fifty lines are a mix of creative and functional, probably more functional than creative. At the extremes of this functional-vs-creative dichotomy, things like phone directory data do not meet the de minimis standards for copyrightability at all, even if it's a database of millions of phone numbers (e.g. Feist v. Rural Telephone, where the court rejected a copyright challenge by a phone company hoping to get royalties from a rival phone directory publisher). That's outside copyright because the way a phone directory is organized is completely devoid of creativity. If it were creative, it wouldn't be useful; plumbers would be listed under B for blacksmith and you'd never find what you were looking for. Magazine and journal database publishers, too, have a very weak and contentious copyright claim, for the same reason. Their work, although voluminous, is not creative and is organized in a very nearly purely functional way. To go further down the rabbit hole, there is actually de minimis length in copyright. Slogans and catchphrases from advertising campaigns have been held too short to be protected under copyright; rights to the use of such can only be enforced under trademark law. > > but that aside, I don't think a court would have any problem > > recognizing it as not a "change to Emacs," if it's not distributed > > with something calling itself Emacs. > > Jambunathan claims that his files haven't been distributed with > something calling itself Emacs, either. They're been distributed with > what (as a maintainer of a fork of Emacs considering incorporating > org-mode) I too consider a separate work, org-mode -- of which Emacs > itself is now a derivative, and IIRC org-mode is a component of > another separate collective work called "GNU ELPA". > > I'm asking for clarification about how and where the lines are drawn. > I would be perfectly happy if that line is drawn so that org-mode is > part of Emacs: that doesn't stop XEmacs from distributing it, and > that's obviously what org-mode developers want. I just don't see how > to draw the line between org-mode and my init file without using > concepts that don't seem to be reflected in law. Not to speak for the project, but according to http://orgmode.org/worg/org-contribute.html Org developers must "grant the right to include [their] works in GNU Emacs to the FSF" by signing assignment papers in which "the Work" is Emacs. Only contributors of "tiny changes" and contributors to contrib/ are exempted. Prior to an Org release's inclusion in Emacs, it is *also* embodied in a work called ELPA. But it seems to me that Org has taken pretty much all the affirmative steps it can as a project to be seen as "part of Emacs." Even the core files in the ELPA and Git versions say "This file is a part of GNU Emacs." > Note that your interpretation is also at variance with the FSF's > statements and behavior regarding dynamic linking. The FSF does not > believe that "distribution with" is required under copyright law to > establish a work composed of several components. I'm aware of the FSF's policy on dynamic linking, but I don't really see it as apposite to interpreted languages like Emacs Lisp. In copyright terms, Emacs is a "compilation," a category of work recognized as being made of smaller works--in this case, those would be the C core, the Info manuals, the various Lisp features/packages included in the standard distribution, the pictures, etc. If you are disturbed by the phrase "distributed with," read for it "included in the compilation." Because of the considerable lag involved in upstream versions of Org being drawn down into the compilation known as GNU Emacs, Jambunathan may well be right that two of his files have never been included in "GNU Emacs." However, there's nothing in copyright law to prevent someone from assigning some or all of their rights to a work in advance; this happens all the time, e.g. when a writer is commissioned by a magazine to write an article. > > Your initfile would be "an original work of authorship," not a > > "change to Emacs"--even though it's not usable or useful without an > > Emacs to run it on. > > In copyright, all changes are original works of authorship. The fact > that they may require composition with another work to be useful > doesn't change that. AFAICS there is no concept of "change" in US > copyright law (or Japanese, for that matter). Works are *fixed* in a > medium and then *copied*. "Modified version" is an abbreviation for > "some parts of a work were copied into another work which is not > identical to the work being copied", as far as I can see. It does not > establish a relationship of "modifications to an existing work" > between the original parts of the derived work and the copied work, > when those original parts are considered separately. > > In short, legally a derived work contains a *copy of*, but not > *changes to*, another work. > > > Jambunathan modified a repository of software the authors of which > > (himself included) assigned their copyright to the FSF, and, > > Irrelevant, unless all copyrights held by the FSF are part of Emacs. > > > specifically, he worked on files which identified themselves as a > > "part of GNU Emacs." I think we're both saying--and I agree--that "changes to" is shorthand for "derivative work," which your initfile clearly isn't. I took RMS's statement in this thread to mean that the FSF's policy is to operate on the assumption that copyright is still assigned to the FSF when someone who has already assigned copyright to a contribution to Emacs makes a derivative work (i.e. a fork) of that contribution to Emacs. I don't see how that applies to your initfile or why you'd think it would, unless perhaps if your initfile copies and redefines a bunch of stuff from a library also in Emacs that you contributed to. > I'm aware that's probably true. That's why I specified a > counterfactual assuming that he received and changed files that had > not yet been accepted into the Emacs fold, and identified themselves > as part of a separate work. I'm not trying to defend Jambunathan's > behavior, I want to know just how much of my oeuvre the FSF thinks > I've signed away. > > > Which the files in Org do. Everything in Org's core contains "This > > file is a part of GNU Emacs." > > "Core" and does now, yes. The point of my hypothetical is that the > files Jambunathan started from, and committed, may not have. Those > bags of bits therefore may not have been part of Emacs at the time in > copyright law, and I don't see how to establish that he "modified > Emacs" under those (possibly counterfactual) conditions. Especially > considering that AIUI in copyright law works can be "fixed" and > "copied", but there is no formal concept of modification, only of > derivation. > > I'm not particularly fond of that conclusion in the case in point. I > don't think what Jambunathan proposes to do serves anyone or any > project well, least of all himself. (And I've told him that, > privately.) "You can't do that, legally" would be the simplest > resolution. But simple resolutions in law often have unpleasant > consequences, and I would like to know about those consequences. > > It's possible that the assignment contract creates a new concept of > "work", different from that of copyright law. But if so, I have a > rather different concept of "what Emacs is" from the one which claims > files in the contrib directory of the org-mode repository as "part of > Emacs" (even though the files themselves may claim to be such a part), > and I wonder how a court would deal with that difference of opinion. > I suspect it would take my opinion seriously (not necessarily uphold > it, but surely not summarily dismiss it as prima facie untenable). I think it's right that the concept of "work" in an assignment contract is not exactly analogous to the concept of "work" in copyright, for the following reason: US copyright law, as you rightly point out, governs only works which are already "fixed in tangible form." OTOH, an assignment contract may permissibly (and often does in cases other than software, as I pointed out with the example of the writer and the magazine publisher) assign rights over an as-yet-nonexistent work, in contemplation of its eventually being fixed in tangible form. As the assignment papers are contract law rather than copyright, the limits on them would presumably be drawn from contract law; i.e. a court will not enforce an "unconscionable" contract. In much of the EU and other Civil Code jurisdictions, *any* contract to assign author's rights is unconscionable, or contra bonos mores. In the US, it would depend on whether the contributor understood what they were doing when they assigned their rights. I think a contract that assigned to the FSF all your future works in Emacs Lisp would be unconscionable, but one that assigned to the FSF all your future works to improve or extend particular libraries that you had already assigned to the FSF would not. Again with the writer/publisher example, contracts that cover the current edition of a work and also assign the publisher rights to future editions are within the realm of what people already do under the law, so they're not likely to be deemed unconscionable. > Aside: > > > My understanding is that he'd already assigned copyright on his > > work in Org (and his patches elsewhere in Emacs) to the FSF, and > > now wanted to "withdraw his pleasure" at that assignment--i.e. to > > withdraw specific things that he'd already committed to Org so that > > they'd revert to being joint works, their copyright unenforceable > > (or, rather, not easily enforceable) in the US without his consent. > > Of course the FSF cannot enforce copyright on unassigned parts of a > joint work without cooperation of the copyright holder(s), but I think > the premise of individual copyright on joint works being "difficult to > enforce" is false nowadays. VCS history passes all the tests > necessary for computer records to be admitted in court. > > But that's irrelevant to Emacs policy, the policy is what it is, and > as Mr. Fogel points out, today it serves social purposes as well as > legal ones. It may be that at some point the policy won't be needed anymore, due to things like the high quality of VCS records.* It was always an ad hoc hack to address the needs of copyright assignment in one particular jurisdiction (the US); it does nothing elsewhere. *Until the courts realize that most VCSes allow people to rewrite history. I don't think any of us want to be around for some judge trying to reconcile chain of custody with `git rebase'. ;-) -- Regards, WGG