From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0DC443B2A4 for ; Fri, 23 Dec 2016 15:35:45 -0500 (EST) Received: from [IPv6:2601:648:8380:1921:3c29:b7e4:8dc2:1703] (unknown [IPv6:2601:648:8380:1921:3c29:b7e4:8dc2:1703]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id EC5D5AE79F; Fri, 23 Dec 2016 21:35:42 +0100 (CET) From: Marc Petit-Huguenin To: Dave Taht , "dpreed@reed.com" References: <1482522285.920219937@mobile.rackspace.com> Cc: "cerowrt-devel@lists.bufferbloat.net" Message-ID: <7052499a-e3c8-cd9a-7e65-d37eb7eed8fb@petit-huguenin.org> Date: Fri, 23 Dec 2016 12:35:40 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IRLsNPpG9jENK5sHPJCTL0hNkOWKuWdDX" 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 20:35:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IRLsNPpG9jENK5sHPJCTL0hNkOWKuWdDX Content-Type: multipart/mixed; boundary="tMNGd3G4sReoIwMIi1TJEDjKE0LwHGlPK"; protected-headers="v1" From: Marc Petit-Huguenin To: Dave Taht , "dpreed@reed.com" Cc: "cerowrt-devel@lists.bufferbloat.net" Message-ID: <7052499a-e3c8-cd9a-7e65-d37eb7eed8fb@petit-huguenin.org> Subject: Re: [Cerowrt-devel] Fwd: License File for Open Source Repositories References: <1482522285.920219937@mobile.rackspace.com> In-Reply-To: --tMNGd3G4sReoIwMIi1TJEDjKE0LwHGlPK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/23/2016 12:17 PM, Dave Taht wrote: > On Fri, Dec 23, 2016 at 11:44 AM, wrote: >> My understanding is that it is already settled case law that contribut= ed code to a GPL licensed projects implicitly grants a perpetual, royalty= free license to use any applicable patent the author uses in the code. >=20 > According to this it is not settled case law in the UK. Apache, on the > other hand... >=20 > http://en.swpat.org/wiki/Patent_clauses_in_software_licences#Apache_Lic= ense_2.0 >=20 >=20 >> Of course there is no case law regarding patent s in other licenses, i= n particular MIT and BSD, which have no strong copyleft provisions. >=20 > Yes, I think *mandating* that ietf contributions be under a weak, > unsettled license is fraught with problems. The code inside an RFC is always under a Simplified BSD License, but that= is not what the License described below is about. It is about the text = of the RFC itself, which is under a far more restrictive license (which i= s why Debian, among others, cannot redistribute RFCs) on the copyright si= de, and that require mandatory disclosure on the patent side. >=20 >> >> This issue of submarine patent traps is important in communications pr= otocol invention. Protocol patents are far worse than software patents...= IMO, communications protocols should never be property. IESG is struggli= ng to create a middle ground, where there should be no middle, IMO. >=20 Aren't communication protocols mathematics, e.g. propositions in linear l= ogic, and so unpatentable? > Tend to agree. >=20 >> >> >> >> >> >> -----Original Message----- >> From: "Marc Petit-Huguenin" >> Sent: Fri, Dec 23, 2016 at 2:23 pm >> To: "Dave Taht" , "cerowrt-devel@lists.bufferbloa= t.net" >> Cc: "Dave Taht" , "cerowrt-devel@lists.bufferbloa= t.net" >> Subject: Re: [Cerowrt-devel] Fwd: License File for Open Source Reposit= ories >> >> 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 specific= ation without disclosing that this may be relevant to a patent or patent = application they own or know about. As soon you make a contribution, you= are supposed to disclose such IPR in the IETF database. This text makes= it explicit 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 as the repository does not extend to the RFC-editor or the IETF Trust= , that's, the best that can be done for now. >> >>> >>> >>> ---------- Forwarded message ---------- >>> From: IESG Secretary >>> Date: Fri, Dec 23, 2016 at 7:36 AM >>> Subject: License File for Open Source Repositories >>> To: IETF Announcement List >>> Cc: iesg@ietf.org, ietf@ietf.org >>> >>> >>> 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 styl= e >>> 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 helpf= ul >>> in bringing in some new things such as tooling, or where we need to >>> integrate better between the repository world and the IETF process. A= s >>> an example of the latter, we're wondering whether it would be helpful= to >>> have a standard boilerplate for these repositories with respect to th= e >>> 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 >>> >>> =C3=A2=E2=82=AC=E2=80=9D=C3=A2=E2=82=AC=E2=80=9D >>> >>> This repository relates to activities in the Internet Engineering Tas= k >>> Force(IETF). All material in this repository is considered Contributi= ons >>> to the IETF Standards Process, as defined in the intellectual propert= y >>> 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. Y= ou >>> 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 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --tMNGd3G4sReoIwMIi1TJEDjKE0LwHGlPK-- --IRLsNPpG9jENK5sHPJCTL0hNkOWKuWdDX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlhdip0ACgkQKcRFldZq fsSM0hAAk2SXSye5YeFXrOoZC88fBlWCoC/RrZphcugkjRblDN30CLSkhARZq25a NXo8cuL/ft689m7meTXXHDcsjVNKcVU8xYEOob3VufWizYGGFaCc4X/VwjQtCwg0 1SxPEVhIN1dLl9zWzpPK9fbr98wudFQmbvraStYzk4vZK1CsoL7U4yxshg49P/49 eIBrkfn5p6qWcPmC3KAq3kNzxqlE7VfCG10ENOS2YM31k70llsHIsun0R5rgJml0 r5IqJ9mYQEEzOqePVfZmfYp4pT2JsUsPyldHNLEo1E+WJ03vIrCGYf5DrDu4FcJA Epzxhpkgjkyd1QgRJ7kMyq6PP8Zl2mQvhNpkME9hhNwU7QaqiZDYwwM1Pvg6DxZ6 pbiFH9Jomv+uIldCu4zEo6Xjy0FvpEywouOyqeF2ZT4+J5KU9OYjAximcHFknlwx 6zw1MQTXtYq/lZRNppC+CoV1yenKSdR7wGls0/LHxyp1s21StlaknSJgriJnKkQf 0JtqDP0W2k7w4KrGshVnRLdx4a+n6Aq8UiwaGMxsBndFLTJucaKQfRJWI3jsBW+j 61/DH3NC2ceG91ha9AFmSp+iQEL9iACIULnTmQdYMpB0sGgZrgaHzVcYnSSmL6wV G5sVJwx/RwtcNe5gnM+QderOsHcEcnqv9mRH53kIifYn+yXsSmA= =Dwq8 -----END PGP SIGNATURE----- --IRLsNPpG9jENK5sHPJCTL0hNkOWKuWdDX--