Joel M. Halpern wrote: > I do not understand the problem you want addressed. The way this is > worded, it doesn't matter what "open source" or "free software" is or > becomes. The intention is to grant anyone to do anything with the code > segments. That's what we ask the trust to do. Further in line. I think Simon is suggesting that we provide some guidance to the Trust in choosing a license. IANAL, however the phrase "grant anyone to do anything" sounds nice in theory but needs to be translated into a functioning license. As far as I can see there are three licenses that would fit the bill: 1. The MIT license 2. A BSD-style license 3. A designation that the code is in the public domain Some people allege that it is not possible to put a work directly into the public domain (although I disagree), which is why they prefer to use a license. As a point of comparison, the XMPP Standards Foundation recently worked to make sure that its specifications are safe for inclusion in free sofware, and decided upon a slightly-modified MIT license (modified in order to make clear that we were publishing specifications, not code). The resulting license is here: http://www.xmpp.org/extensions/ipr-policy.shtml > Simon Josefsson wrote: >> Regarding -outbound section 4.3: >> > ... >> As such, the rough consensus is that the IETF Trust is to grant >> rights such that code components of IETF contributions can be >> extracted, modified, and used by anyone in any way desired. To >> enable the broadest possible extraction, modification and usage, the >> IETF Trust should avoid adding software license obligations beyond >> those already present in a contribution. The granted rights to >> extract, modify and use code should allow creation of derived works >> outside the IETF that may carry additional license obligations. > This says that the trust is to grant rights so that code can be > extracted, modified, and used by ANYONE. I.e. our grant will not place > restrictions on people. Correct. But we need to have a license over the code, not just say that anyone can use it, which legally is void for vagueness (IMO IANAL etc.). >> ... >> >> I believe the intention here is good, but it leaves the IETF Trust with >> no guidelines on how to write the license declaration that is likely to >> work well in practice with actual products. There are no reference to >> what "open source" means in this context, and references to "free >> software" is missing. >> >> I believe it would be a complete failure if code-like portions of RFCs >> cannot be included into open source and free software products such as >> the Debian project. > If we grant anyone the right to use the code any way they want, which > means that we specifically can not require preservation of notices or > anything else, how could it fail to meet the requirements of the > specific cases you list? Because it is not covered by a license. >> To give the Trust something concrete to work with I propose to add the >> following: >> >> To make sure the granted rights are usable in practice, they need to >> at least meet the requirements of the Open Source Definition [OSD], >> the Free Software Definition [FSD], and the Debian Free Software >> Guidelines [DFSG]. >> >> For those who fear that this will lead to complexity: releasing >> something that is compatible with those requirements is simple. The >> modified BSD license meets those requirements, as does a number of other >> methods, including releasing the work into the public domain. > My concern is not complexity. Referencing the specific documents is > more restrictive than what the working group recommended. I don't see > why that would help anything. See above. Perhaps it would be more helpful to reference some specific licenses that would realize the stated intent? Peter -- Peter Saint-Andre https://stpeter.im/
<<attachment: smime.p7s>>
_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf