[738] in athena10
Re: External contributors to Athena 10
daemon@ATHENA.MIT.EDU (William Cattey)
Wed Dec 17 19:32:51 2008
In-Reply-To: <alpine.DEB.2.00.0812110038440.10997@vinegar-pot.mit.edu>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <225B6948-CA80-4F4F-B165-E8CC55B18224@mit.edu>
Cc: athena10@mit.edu
Content-Transfer-Encoding: 7bit
From: William Cattey <wdc@MIT.EDU>
Date: Wed, 17 Dec 2008 19:28:24 -0500
To: Tim Abbott <tabbott@mit.edu>
I have done some investigating and some pondering.
The IS&T folks I spoke to said, YES! Assigning intellectual property
rights is very important to get right. They sent me to the Kerberos
team to find out what they do. The Kerberos team has accepted
amendments from outsiders for some time. They don't have anything
for submitters to sign, but might do so in the future. The guidance
I got was:
We have talked about setting up contribution agreements in the future.
At present, we prefer that contributors assign all copyright to us,
but where that is not practical, we ask them to license the
contribution under terms substantially identical to or compatible with
ours (BSD-like without advertising clause, GPL-compatible, but not the
GPL itself).
Contribution agreements would (as I understand it) allow the
contributors to retain copyright but grant us enough rights to
relicense as we see fit. We have not implemented this yet.
So what we need is a simple statement that lets the contribution be
licensed under the same license as the source being modified.
tabbott pointed me to what Linux Torvalds does for the Linux kernel
which seems to exactly fit the bill. See:
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/
linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;hb=v2.6.26#l282
Submitters affirm they're allowed to assign rights, and then assign
rights appropriately, and do so by adding a line "Signed-off-by:"
with their full name.
tabbott also educated me about how "Signed-off-by" is an SVN
convention that we're not currently using.
So in answer to tabbott's questions 1 and 2 I advocate that we adopt
the convention of, sign-off to assign rights appropriately to the
upstream license. Perhaps this can be done by creating a page on the
debathena site that echos the Kernel sign-off conventions and says
those are our adopted conventions.
To venture an answer to questions 3 and 4 we need to decide whether
athena10 or debathena hosts the technical discussions. tabbot does
make a good point that athena10 will need to deal with policy issues
that are not technical, of which Dash sunset is one example.
I advocate that we tell outsiders to join the technical list,
whichever we decide that it is, and to submit patches there.
At the moment, I'm undecided if athena10 or debathena is the most
correct one to dedicate to technical issues.
Bottom line: Yes, we can let this guy in. We do need to have him
sign off on his patches when he submits them.
QUESTION: athena10 or debathena as the contact point?
-Bill
----
Important: IS&T IT staff will *NEVER* ask you for your password, nor
will MIT send you email requesting your password information. Please
continue to ignore any email messages that claim to require you to
provide such information.
----
William Cattey
Linux Platform Coordinator
MIT Information Services & Technology
N42-040M, 617-253-0140, wdc@mit.edu
http://web.mit.edu/wdc/www/
On Dec 11, 2008, at 1:13 AM, Tim Abbott wrote:
> Apparently, there is interest in external contributions to
> Debathena/Athena 10 (see below) and membership on debathena@mit.edu
> (which is on athena10@mit.edu). I see a few issues that this
> brings up that I'd like to briefly discuss before we add people not
> affiliated with MIT:
>
> (1) Licensing. Currently, Athena 10 has code under the GPL, MIT
> license, and some of the Debian packaging are "public domain". I
> think that the standard OSS model of accepting contributions under
> the same license as the existing software is probably fine.
>
> (2) I think we should change the "public domain" notices for the
> Debian packages to "MIT license" statements, since it's more
> standard in the OSS world and makes life easier for dealing with
> external contributions.
>
> (3) How should they submit patches? I intend to ask them to email
> athena10@mit.edu, since that is currently the primary development
> list (debathena@ is now fairly low-traffic).
>
> (4) Is having someone not associated with MIT on athena10@ is
> likely to cause any problems? It does have more MIT internal
> policy discussion than might be ideal for this purpose currently.
>
> The alternative model is probably to try to use debathena@mit.edu
> (currently low-traffic because we've tried to move essentially all
> debathena@ technical discussions to athena10@) for discussions that
> aren't in the MIT internal policy space (e.g. Dash sunset effort
> discussions), and redoing the membership structures so that instead
> athena10@ is on debathena@ (or similar).
>
> (5) Are there any important issues here that I've forgotten?
>
> -Tim Abbott
>
> ---------- Forwarded message ----------
> Date: Thu, 11 Dec 2008 00:15:31 -0500
> From: Daniel Gomez <gomez@Teragram.com>
> To: "debathena-request@mit.edu" <debathena-request@mit.edu>
> X-Spam-Score: 0.14
> Subject: Subscription request
>
> Hello,
>
> I would like to request a subscription to the Debathena mailing
> list for the address <oss@teragram.com>.
>
> This is on behalf of Teragram, a local company (offices up near
> Alewife) that makes extensive use of Ubuntu and Debian Linux plus
> OpenAFS in its IT infrastructure. We have been cherry-picking
> various components of Debathena to implement our own Athena-like
> environment on top of AFS, and in addition to having a queue of
> patches and other work that we would like to send upstream, we
> would like to stay informed of the general progress being made in
> the Debathena project.
>
>
> --Daniel
>
>
> --
> Daniel Gomez || gomez@teragram.com || (617) 576-6800 x230
> Software Developer, Teragram Corp. (a division of SAS)
> http://www.teragram.com/
