Re: License File for Open Source Repositories

Nadeau Thomas <tnadeau@lucidvision.com> Wed, 04 January 2017 21:27 UTC

Return-Path: <tnadeau@lucidvision.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009AF129413; Wed, 4 Jan 2017 13:27:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lucidvision.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDllKbJsknRT; Wed, 4 Jan 2017 13:27:33 -0800 (PST)
Received: from lucidvision.com (lucidab1.miniserver.com [78.31.106.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B418129406; Wed, 4 Jan 2017 13:27:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1483565201; bh=3Ltg9RniiBE/yxrf5eGYJCY0/3Sk4bCOGGw3NPJz1ug=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=c2VArhP6SH0AiA8+1zIfrctpzPhXLIRWC3yXPJl/Scwn9jVtGNW2wNPQR98WFz+pA XiTv3Ynkfp5V4TOuAJ60ZaqyDrEM40RuXyttqFTcFQKct5Q+6cvkohdwvfgMLer2Z1 a06sXQR9Vzu4Un8w16Aixqv6muuTAWXvRGPwBFRA=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181;
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: License File for Open Source Repositories
From: Nadeau Thomas <tnadeau@lucidvision.com>
In-Reply-To: <1EB0F8AB-6828-4A00-B157-E80CE86B7A7C@ietf.org>
Date: Wed, 04 Jan 2017 16:27:07 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7C55256-829F-4575-A083-85C78197CD12@lucidvision.com>
References: <148250741312.16852.14743474459827703109.idtracker@ietfa.amsl.com> <1EB0F8AB-6828-4A00-B157-E80CE86B7A7C@ietf.org>
To: ietf@ietf.org, IESG <iesg@ietf.org>
X-Mailer: Apple Mail (2.3124)
X-Authenticated-User: tnadeau@lucidvision.com
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=1 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 601, in=4627, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/YLiJE220TThozlR_Lc4FUHxtNeA>
Cc: IETF Announcement List <ietf-announce@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2017 21:27:35 -0000

	I have no issues with the license text, but will suggest a clarification or
two. We have been using basically the same text for IETF models on the Yang repo on github for about 
2 years with no issues.   I’ll note that that we hashed through these in great detail with the 
netmod/conf community and arrived at how we operate. We also work with the IEEE/MEF/ODL communities
on the same repo, and everyone seems to get along happily with these rules in place. The license 
statement we have been using for about 2 years is available here if you are interested.

	https://github.com/YangModels/yang

	The first clarification I think is necessary is around how “repository” is
defined. In the case of github, that might be taken to mean the *entire* repository, which
practically speaking is not how things work, at least in our case because the repository 
holds files created by various organizations (and vendors for that matter). Instead, the approach we 
have taken is to require that each main/top-level subdirectory contain a license statement
that applies to all files and subdirectories therein. Committers explicitly agree to those terms
by virtue of checking in a file (or posting a comment/issue on that file).

	This also reveals a finer point about the license statement pertaining to comments.
Again, our statement defines comments as falling under whatever licensing terms are defined
for the file in question.  This is a gray area in our case due to having multiple files that fall under
multiple licenses. So for example, one comment about one file might refer to another file covered by 
another license.  Does that mean that now the first file falls under the licensing terms of the other
file?  Let me give you an example. We have IEEE models that do rely on advice given from Yang doctors 
either explicitly or via references to some of the guiding documents/RFCs that exist. In discussing the 
IEEE model, there might be a discussion around such a recommendation for how to build a model. In this 
case, is this IEEE model suddenly now under the IETF’s license (or the part of the model being discussed)?  
The working assumption by us is that it is not. However, this is something you might want to clarify.

	—Tom


> On Jan 4, 2017:11:20 AM, at 11:20 AM, IETF Chair <chair@ietf.org> wrote:
> 
> With the holidays over, this is a re-send of the request to
> review the suggested license file.
> 
> Jari
> 
> ----
> 
>> The IESG has observed that many working groups work with open source
>> repositories even for their work on specifications. That's great, and
>> we're happy to see this development, as it fits well the working style
>> of at least some of our working groups. This style is also likely to be
>> more popular in the future.
>> 
>> As always, we'd like to understand areas where we can either be helpful
>> in bringing in some new things such as tooling, or where we need to
>> integrate better between the repository world and the IETF process. As
>> an example of the latter, we're wondering whether it would be helpful to
>> have a standard boilerplate for these repositories with respect to the
>> usual copyright and other matters. The intent is for such text to be
>> placed in a suitable file (e.g., "CONTRIBUTING"), probably along with
>> some additional information that is already present in these files in
>> many repositories. The idea is that people should treat, e.g., text
>> contributions to a draft-foo.xml in a repository much in the same way as
>> they treat text contributions on the list, at least when it comes to
>> copyright, IPR, and other similar issues.
>> 
>> We have worked together with the IETF legal team and few key experts
>> from the IETF who are actively using these repositories, and suggest the
>> following text.
>> 
>> We're looking to make a decision on this matter on our January 19th,
>> 2017 IESG Telechat, and would appreciate feedback before then. This
>> message will be resent after the holiday period is over to make sure it
>> is noticed. Please send comments to the IESG (iesg@ietf.org) by 2017-01-17.
>> 
>> The IESG
>> 
>> ——
>> 
>> This repository relates to activities in the Internet Engineering Task
>> Force(IETF). All material in this repository is considered Contributions
>> to the IETF Standards Process, as defined in the intellectual property
>> policies of IETF currently designated as BCP 78
>> (https://www.rfc-editor.org/info/bcp78), BCP 79
>> (https://www.rfc-editor.org/info/bcp79) and the IETF Trust Legal
>> Provisions (TLP) Relating to IETF Documents
>> (http://trustee.ietf.org/trust-legal-provisions.html).
>> 
>> Any edit, commit, pull-request, comment or other change made to this
>> repository constitutes Contributions to the IETF Standards Process. You
>> agree to comply with all applicable IETF policies and procedures,
>> including, BCP 78, 79, the TLP, and the TLP rules regarding code
>> components (e.g. being subject to a Simplified BSD License) in
>> Contributions.
>> 
>