Re: [codec] Format for the codec specification

[Stephan Wenger <[e-mail]>]

I forgot that you are currently working under the BSD license.  Keep it that
way, and I have no concerns on the licensing front, as IETF code components
are under essentially the same license.
Stephan



On 9.24.2010 13:37 , "Jean-Marc Valin" <[e-mail]>
wrote:

> On 10-09-24 03:33 PM, Stephan Wenger wrote:
>> I also think we should make the code normative, as the speech codec people
>> commonly do for their bit-exact encoder/decoder specs.  However, someone
>> will have to explain to me how this can be done without requiring
>> bit-exactness.
> 
> There is no need to mandate bit-exactness. Many codecs are actually
> specified in floating-point. For example, if I'm not mistaken, the
> following codecs have a floating-point reference: MP3, EVRC-A/B, G.719
> (probably others). As far as I know, the spec says how much you can
> deviate from the float reference (not to mention that it's impossible to
> always be bit-exact with a float reference in the first place).
> 
>> If we were deciding to use code as the normative description, then I would
>> prefer to have that code ONLY in a single document.  It may be worthwhile to
>> consider zipping the source code directory, coding it in BASE64, and then
>> copy-pasting it into the RFC.  This way we could overcome many of the
>> shortcomings of putting a large software project into a printout format.  We
>> should check with the AD and the RFC editor first, how they view such a
>> submission.
> 
> I'm not against base64 encoding if the IETF will allow it. We could even
> have a C version of the base64 decoder to make sure that the RFC is
> "self-contained".
> 
>> Finally, it should be clear that the code RFC (as all RFCs) falls under the
>> IETF's copyright and patent policies.  As for the copyright part, people
>> should be aware that the IETF does not allow any other copyright notices but
>> its own in such an RFC.  In other words, if the code maintainers want to
>> make the code available also under a non-IETF license (one of the open
>> source licenses, for example), they a) have to make sure that this license
>> allows for such dual licensing (GPL, for example, does IMO not),
> 
> The BSD license is compatible with the GPL, which means that it is OK,
> to take BSD code, modify it, and then slap a GPL license on top of the
> modified version (without removing the existing BSD license). In
> general, there are many cases of dual licensing involving the GPL. Also,
> note that the code we're talking about has been available under the BSD
> (and not the GPL) right from the start.
> 
> Jean-Marc
> 
>> and b)
>> remove the statements of this license from the code provided to the IETF,
>> and c) (depending on that license) remove the IETF license text from the
>> code provided to the open source repository.  Tedious, but doable, I think.
>> 
>> Stephan
>> 
>> 
>> 
>> 
>> 
>> 
>> On 9.24.2010 12:09 , "Jonathan Rosenberg"<[e-mail]>  wrote:
>> 
>>> One of the open issues we need to close on - and document in the
>>> guidelines specification - is what the format of our codec specification
>>> deliverable will be.
>>> 
>>> Firstly - one thing is clear - whatever the format is (code or textual
>>> descriptions) - it needs to be in an RFC. Including source code into an
>>> RFC is not ideal, but for purposes of IETF process that is the only
>>> thing we can officially produce. Participants can of course place that
>>> code in any repository they like, and we can even include a link to it
>>> in the RFC. However, the formal normative specification of the codec
>>> must be within a standards track RFC.
>>> 
>>> In terms of whether the specification is code, text, or both - we need
>>> to gain consensus on this. It is my understanding that source code is
>>> ultimately the most exact way to specify the codec. A detailed
>>> description is also included, and in case of conflict, the code would
>>> win. In IETF terms this means that the code is actually the normative
>>> specification.
>>> 
>>> iLBC includes the code itself in an appendix. As such, it would seem to
>>> make sense to follow this precedent. Thus, our deliverable would be a
>>> single document, containing a reasonably detailed codec description,
>>> along with an appendix containing the actual code.
>>> 
>>> Comments?
>>> 
>>> -Jonathan R.
>> 
>> 
>> _______________________________________________
>> codec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/codec
>> 
>>