Re: Simplified BSD License for Code Components and linux GPL kernel
Alexandru Petrescu <alexandru.petrescu <at> gmail.com>
2010-02-12 16:15:06 GMT
Le 12/02/2010 13:37, Todd Glassey a écrit :
> What if there was a simple way to restructure the licensing model so
> that all of the rights per any protocol were contained in 'its
> current BCP document' and not in the technology specification
That sounds good to me.
> So the IETF's entire practice could be simplified so that it
> pertained to
> 1) Technical protocol specifications - this is the RFC on the design
> and controls the protocol uses. The protocol RTU and the
> Specification for how it is used are spit off of this document so
> that the entire IP package is used rather than pieces or 'cuttings'
> from it.
> 2) Approved BCP's for the use of that protocol which are actually
> where the right to use license would need to be inserted to protect
> the legal standing of being able to say "hey you must implement the
> whole enchilada or nothing" and no misuse.
I agree with this separation guideline. I am not sure I follow
precisely your proposal but I fully agree with the full decoupling
between the protocol spec and its license specification (sometimes
> Since the protocol interactions have no license to do anything with,
> except use this protocol per the rules of the BCP then this becomes
> almost too easy. The technology control document is easily protected
> and through its any use defined in the approved BCP type IP transfer
> it makes this process seamless and easily enforced.
>> As such, that needs to apply to tables of IANA values as well.
> Sure but these would be a BCP specification for the use of this
> protocol Maybe just reference the IANA specification RFC's and your
> done there from the proposed BCP document.
>> For drafts which assign a lot of values, people are likely to want
>> to take the table, reformat it, and use it in their code. We want
>> to permit this, as it encourages accuracy and interoperability.
> Yes but it also opens another door to abuse and sloppy engineering
> which is rampant in a number of documents on file.
>> Yes, as a side-effect this means that they can replace the values
>> in their code. If they want to use the sample as a starting point
>> for an experiment (which needs different values), one can
>> understand doing that.
> The problem is that someone could take a formulae and change the text
> wording in it but leave the formulae functionally intact claiming its
> new genesis because the labels were changed. Its not... and tha'ts an
>> And trying to write the rules to permit one kind of change and not
>> another is simply a losing proposition.
> Maybe not...
>> Yours, Joel
>> Marshall Eubanks wrote:
>>> On Feb 11, 2010, at 1:30 PM, SM wrote:
>>>> Hi Marshall, At 05:02 11-02-10, Marshall Eubanks wrote:
>>>>> Can you describe your concerns here ? IANA did not complain
>>>>> about the TLP, and to my recollection no one else has brought
>>>>> this up.
>>>> I don't have any strong concerns about the TLP. The IETF Trust
>>>> has done its best. What follows should not be read as legal
>>>> advice. It is not an argument to support any change.
>>>> The code components list, effective on 23 April 2009, lists
>>>> "tables of values" as a code component. The finer details
>>>> require a reading of the RFC and the TLP. Changes to a protocol
>>>> parameter registry generally goes in the IANA Considerations
>>>> section. It's not up to me to determine whether the assigned
>>>> values are code components. If the assigned values fall under
>>>> the Simplified BSD License, they can be modified.
>>>> "All assigned values are to be published and made available
>>>> free of any charges and free of any constraints relating to
>>>> further redistribution, with the caveat that the assignment
>>>> information may not be modified in any redistributed copy."
>>>> The rationale for that is probably the same as for IETF change
>>>> control. That makes the "text" copyright a better fit.
>>> OK, thanks for this. We might want to put IANA registries and
>>> other parameter values as not suitable for code components in
>>> some future TLP.
>>> However, just because you can change something in code (I want my
>>> protocol to be protocol # 1 !) doesn't mean it would be wise to
>>> do so. The same thing could be said for many indisputable code
>>> components. If RFC-FOO says that (say)
>>> RTT = t_reception - t_transmission
>>> and I use that as code, the BSD license does mean that I can
>>> change "-" to "+" if I want to. Doesn't mean that I should, but
>>> conversely no license policy would say "you can change this code
>>> anyway you want, as long as you don't introduce errors." So I
>>> personally agree with you, and think that this is "not an
>>> argument to support any change."
>>>> Regards, -sm
>>> Regards Marshall
>>> _______________________________________________ Ipr-wg mailing
>>> list Ipr-wg <at> ietf.org
>> _______________________________________________ Ipr-wg mailing
>> list Ipr-wg <at> ietf.org https://www.ietf.org/mailman/listinfo/ipr-wg
>> No virus found in this incoming message. Checked by AVG
>> -www.avg.com Version: 8.5.435 / Virus Database: 271.1.1/2679 -
>> Release Date: 02/10/10 07:40:00
> _______________________________________________ Ipr-wg mailing list
> Ipr-wg <at> ietf.org https://www.ietf.org/mailman/listinfo/ipr-wg