all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: PJ Weisberg <pjweisberg@gmail.com>
Cc: Emacs-Devel devel <emacs-devel@gnu.org>
Subject: Re: Tests and copyright
Date: Wed, 14 Aug 2013 21:50:21 -0400	[thread overview]
Message-ID: <jwv1u5vivkl.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <877gfoq7ou.fsf@engster.org> (David Engster's message of "Wed, 14 Aug 2013 23:33:05 +0200")

>>> I'm currently migrating our EIEIO test suite to Emacs, and I'm wondering
>>> if files in the tests/ directory fall under the same rules w.r.t. to
>>> copyright/papers?
>> I don't see why they wouldn't,  if they're distributed.  They're just
>> as much the original work of an author.
> AFAIK, they are not distributed with the tarballs.  Also, at least I do
> not consider them part of "the Emacs source code", but I'm not a lawyer.

Actually, this question has popped up in the past, and until now we
haven't had any reason to find a good answer, so we haven't dug
any deeper.

There are sound reasons to consider that the test suite could follow
different guidelines in this respect:
- in case of a legal challenge, we could drop the relevant tests without
  suffering any direct consequence.
- test cases may come simply from bug-reports from many people who
  aren't likely to contribute any further.

My opinion is that it is not necessary to get copyright assignments for
the test cases themselves (e.g. the files in emacs/test/indent, or the
compile-tests--test-regexps-data var in test/automated/compile-tests.el).

That still leaves open the question for the code written to actually run
the tests (e.g. the functions compile--test-error-line and
compile-test-error-regexps in that same
test/automated/compile-tests.el).  To the extent that this code is
likely to have parts that can be reused between different sets of tests
for different packages, I tend to think that it falls in the camp of
"it's just code like any other".

> Anyway, I was just hoping that I wouldn't have to wade through years of
> log history, as if porting test code wasn't boring enough already.

Is the above rule "lax enough" to significantly lighten your workload?


        Stefan



  reply	other threads:[~2013-08-15  1:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-13 19:49 Tests and copyright David Engster
2013-08-14 16:04 ` PJ Weisberg
2013-08-14 21:33   ` David Engster
2013-08-15  1:50     ` Stefan Monnier [this message]
2013-08-15 16:10       ` David Engster
2013-08-15 16:48         ` Stefan Monnier
2013-08-16  0:54           ` Eric M. Ludlam
2013-08-16 15:35             ` David Engster
2013-08-19 21:06             ` David Engster
2013-08-15  4:16     ` Stephen J. Turnbull

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv1u5vivkl.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=pjweisberg@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.