From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3B5113B2A4 for ; Fri, 23 Dec 2016 14:44:46 -0500 (EST) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0C8F95694; Fri, 23 Dec 2016 14:44:46 -0500 (EST) Received: from app17.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F3F33567B; Fri, 23 Dec 2016 14:44:45 -0500 (EST) X-Sender-Id: MAILER-DAEMON Received: from app17.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 23 Dec 2016 14:44:46 -0500 Received: from reed.com (localhost [127.0.0.1]) by app17.wa-webapps.iad3a (Postfix) with ESMTP id E12D86003A; Fri, 23 Dec 2016 14:44:45 -0500 (EST) Received: by mobile.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 23 Dec 2016 14:44:45 -0500 (EST) Date: Fri, 23 Dec 2016 14:44:45 -0500 (EST) From: dpreed@reed.com To: "Marc Petit-Huguenin" Cc: "Dave Taht" , "cerowrt-devel@lists.bufferbloat.net" MIME-Version: 1.0 Content-Type: text/plain;charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <1482522285.920219937@mobile.rackspace.com> X-Mailer: mobile/4.0.0 Subject: Re: [Cerowrt-devel] Fwd: License File for Open Source Repositories X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 19:44:46 -0000 My understanding is that it is already settled case law that contributed co= de to a GPL licensed projects implicitly grants a perpetual, royalty free l= icense to use any applicable patent the author uses in the code. Of course there is no case law regarding patent s in other licenses, in par= ticular MIT and BSD, which have no strong copyleft provisions. This issue of submarine patent traps is important in communications protoco= l invention. Protocol patents are far worse than software patents... IMO, c= ommunications protocols should never be property. IESG is struggling to cre= ate a middle ground, where there should be no middle, IMO. -----Original Message----- From: "Marc Petit-Huguenin" Sent: Fri, Dec 23, 2016 at 2:23 pm To: "Dave Taht" , "cerowrt-devel@lists.bufferbloat.net= " Cc: "Dave Taht" , "cerowrt-devel@lists.bufferbloat.net= " Subject: Re: [Cerowrt-devel] Fwd: License File for Open Source Repositories On 12/23/2016 08:05 AM, Dave Taht wrote: > I have no idea what they are trying to do. This is to prevent people to propose text to be included in a specification= without disclosing that this may be relevant to a patent or patent applica= tion they own or know about. As soon you make a contribution, you are supp= osed to disclose such IPR in the IETF database. This text makes it explici= t that anything done in such repository is covered by the same requirements= . An alternative would have been a variant of the Signed-off-by header, but a= s the repository does not extend to the RFC-editor or the IETF Trust, that'= s, the best that can be done for now. >=20 >=20 > ---------- Forwarded message ---------- > From: IESG Secretary=20 > Date: Fri, Dec 23, 2016 at 7:36 AM > Subject: License File for Open Source Repositories > To: IETF Announcement List=20 > Cc: iesg@ietf.org, ietf@ietf.org >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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-1= 7. >=20 > The IESG >=20 > =E2=80=94=E2=80=94 >=20 > 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). >=20 > 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. >=20 >=20 >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel