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
> document???
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
Copyright).
Alex
>
> 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
> issue.
>
>> 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
>>> https://www.ietf.org/mailman/listinfo/ipr-wg
>>>
>> _______________________________________________ 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
I should say first and foremost that we tempt (in the spirit) to be as
compatible and with as many licenses as possible. Give _them_ priority
and let the mandatory-BSD aspect come after. E.g. if the linux kernel
GPL requires stripping the RFC's license then be ok with it; if no
particular requirement outside IETF only then float the RFC BSD license
everywhere.
RFCs exist in such a rich ecosystem of languages, rules, governments,
super-governments, security control, time - all mean different things to
different lawyers.
Stating BSD upfront reduces RFCs' applicability, customers, implementers.
), and it's
important that RFCs be implementable in such environments. The values in an IANA table cannot be GPL
protected because that pose an obstacle to interoperability with implementations for such environments.
Beyond this is the question of whether an IANA table should be a Code Component. IMHO, there's no inherent
reason why it has to be a Code Component, but treating it as one is a pragmatic way to ensure that
implementers can copy and paste IANA tables from RFCs into their code. While I have no doubt that there are
RSS Feed