Subject: Re: [ntpwg] Please license the NTPv4 MIB under the NTP Copyright

From: Dave Hart <[email-masked]>
Date: Thu, 30 Sep 2010 15:23:28 +0000

On Thu, Sep 30, 2010 at 12:34 UTC, Brian Haberman
<[email-masked]> wrote:
> >From my reading of the TLP, I don't think we need to do anything else.
> The MIB DESCRIPTION clause contains the following:
>
>         Copyright (c) 2010 IETF Trust and the persons identified as
>         authors of the code.  All rights reserved.
>
>         Redistribution and use in source and binary forms, with or
>         without modification, is permitted pursuant to, and subject
>         to the license terms contained in, the Simplified BSD License
>         set forth in Section 4.c of the IETF Trust's Legal Provisions
>         Relating to IETF Documents
>         (http://trustee.ietf.org/license-info).
>
> If you read Section 4.e of the TLP states that for Code Components
> extracted from an IETF document, they either have to reproduce the
> entire Simplified BSD license *or* include the text contained in Section
> 6.d.  And Section 6.d contains the text included in the above
> DESCRIPTION clause.
>
> So if the correct copyright and licensing is included in the MIB, why
> would we need to do anything else?

"TLP" == IETF Trust Legal Provisions, for those that don't recognize
it, at http://trustee.ietf.org/license-info/

Would a binary distribution which includes ntpsnmpd also include
ntpv4-mib.mib?  In that case, perhaps there is no problem.  This is
the paragraph of the IETF BSD license that concerns me:

"Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution."

And that following disclaimer is about 10 lines of ALL CAPS, THANK YOU
LAWYERS.  If we interpret that the MIB is never redistributed in
binary form, only in original text form, than we can assume that
doesn't apply and we're not complicating licensing for binary
distributions including ntpsnmpd.

Thanks for diving in, Brian.

Cheers,
Dave Hart
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Karen O'Donoghue <[email-masked]>
Date: Fri, 01 Oct 2010 13:53:06 -0400

Folks,

As Brian indicated, I have asked for guidance on this topic, and I am 
currently awaiting clarification.

The options as I currently understand them are:

1. Do nothing - The MIB DESCRIPTION clause, that is included by 
definition with the
MIB, contains both the copyright and the license. Nothing more is required.

2. Include additional license information for the Simplified BSD license 
in the ntp distribution
adding yet another license to the package.

3. Have the individual authors license the NTPv4 MIB under the NTP 
copyright statement. This
seems to me to require an additional step that should not be needed.

If my brief summary of the three options on the table is not correct, 
please correct me. Also,
as Dave Hart and others have noted, I am not a lawyer so bear with me. I 
believe getting this
right and providing feedback on the confusion to the IETF Trust will 
enable them
to add additional clarity for the next case. A win for all involved.

Thanks Dave for taking the time to wade through all this, and thanks to 
the WG for your patience.
Karen

On 9/30/10 1:11 PM, todd glassey wrote:
> On 9/29/2010 7:44 PM, Dave Hart wrote:
>> Dr. Mills,
>>
>> I respectfully disagree.  The NTP copyright statement distributed as
>> html/copyright.html and COPYING is also a license, granting permission
>> to use and copy under specific terms.
> True
>
>> Granted, it does not call
>> itself a license agreement.  But I really don't want to get into a
>> semantic argument over this.
>>
>> This issue I see is that the NTPv4 MIB is distributed in
>> ntpsnmpd/ntp4v-mib.mib, and I'd like to update it to the most recent
>> version (with the permanent "IANA" assigned SNMP OID).  And I am
>> concerned that would require those distributing the source, or the
>> ntpsnmpd binary, to comply with the IETF Trust's license covering the
>> MIB (as noted in RFC 5907, referring to "Code Components", defined
>> basically as elements which are formatted machine-readable).
> Agreed - but the MIBS need to be able to have the OIDS they rely on
> changed at any time as well. So that needs to be designed into the USE
> MODEL the IETF has all but banned through the actions of their WG
> members from being mandatory for the use of their IP.
>
>> Here's the text of the IETF Trust's Simplified BSD License which
>> applies to those extracting and using the MIB from RFC 5907, lacking
>> another license from the authors:
>>
>> <quote>
>> Copyright (c)<insert year>  IETF Trust and the persons identified as
>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided that the following conditions are
>> met:
>>
>> ·    Redistributions of source code must retain the above copyright
>> notice, this list of conditions and the following disclaimer.
>>
>> ·    Redistributions in binary form must reproduce the above copyright
>> documentation and/or other materials provided with the distribution.
>>
>> ·    Neither the name of Internet Society, IETF or IETF Trust, nor the
>> names of specific contributors, may be used to endorse or promote
>> products derived from this software without specific prior written
>> permission.
>> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> </quote>
>>
>> I believe we can, with the permission of the MIB authors, bypass the
>> requirement to reproduce that license in documentation accompanying
>> NTP binaries.  The source is not an issue, the MIB itself points to
>> the license on the web.
>>
>> Cheers,
>> Dave Hart
>>
>> On Thu, Sep 30, 2010 at 1:56 AM, David L. Mills<[email-masked]>  wrote:
>>> Dave,
>>>
>>> Maybe there is a misunderstanding. The NTP reference implementation is not
>>> licensed; it is copyrighted. The copyright statement has been reviewed and
>>> approved by the UDel intellectual property attorneys. This has nothing to do
>>> with any license that the MIB might be encumbered with.
>>>
>>> Dave
>>>
>>> Dave Hart wrote:
>>>
>>>> This message is addressed to all three contributors listed in RFC
>>>> 5907, the NTPv4 MIB RFC, and to the ntpwg@ mailing list to preserve a
>>>> record for posterity.
>>>>
>>>> I've been swimming around in IETF trust legal documents trying to wrap
>>>> my head around the licensing issues associated with updating the
>>>> distribution source file ntpsnmpd/ntpv4-mib.mib to the final MIB
>>>> published in RFC 5907, triggered by this standard notice in the RFC
>>>> and the understanding that the NTPv4 MIB is a Code Component:
>>>>
>>>>   Code Components extracted from this document must
>>>>   include Simplified BSD License text as described in Section 4.e of
>>>>   the Trust Legal Provisions and are provided without warranty as
>>>>   described in the Simplified BSD License.
>>>>
>>>> I think that's the obvious approach and it would work, but it has a
>>>> downside in my view, namely, it complicates licensing of the NTP
>>>> Reference Implementation by adding yet another license to our
>>>> collection, so that those distributing the reference implementation
>>>> are bound to, for example, reproduce the IETF Trust Simplified BSD
>>>> License in accompanying documentation.
>>>>
>>>> After reading for quite a while, though, I think I see a way of
>>>> avoiding complication of the NTP Reference Implementation's licensing.
>>>> IETF trust own the copyright to RFC 5907 and controls publication _in
>>>> RFC form_, but BCP 78 makes it clear the original contributors retain
>>>> their copyright to their contributions in the original form, that is,
>>>> not presented as an RFC.  You are not restricted from licensing your
>>>> contribution separately, outside RFC form, so long as your licensing
>>>> does not interfere with the rights granted to the IETF Trust, as
>>>> explained in BCP 78.
>>>>
>>>> So, I am asking each of you to license your work, the NTPv4 MIB, under
>>>> the NTP Copyright statement,
>>>> http://www.eecis.udel.edu/~mills/ntp/html/copyright.html, and also
>>>> asking each of you for permission to include your name and email
>>>> address in the list of contributors contained in the NTP Copyright
>>>> statement.  I suggest entries along the following lines:
>>>>
>>>> Chris Elliot<[email-masked]>  NTPv4 MIB
>>>> Heiko Gerstung<[email-masked]>  ntpsnmpd, NTPv4 MIB
>>>> Brian Haberman<[email-masked]>  NTPv4 MIB
>>>>
>>>> If you would prefer another email address, or have other changes you
>>>> would like to those suggested lines, please speak up.
>>>>
>>>> I notice that in the MIB header comment, Brian is not listed as an
>>>> author, but his contact information does appear a few lines later in
>>>> the MODULE-IDENTITY CONTACT-INFO.  I suppose this may mean we only
>>>> need ask Chris and Heiko to license the MIB under the NTP Copyright to
>>>> have the right to reproduce it outside the terms of the IETF Trust's
>>>> Simplified BSD License, but personally I would feel better if all
>>>> three agree to contribute the MIB to the reference implementation
>>>> under the NTP Copyright.
>>>>
>>>> Remind me never to pursue a second career in law.  My head hurts.
>>>>
>>>> Thanks to everyone for your time and attention to this matter,
>>>> Dave Hart
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.856 / Virus Database: 271.1.1/3167 - Release Date: 09/29/10 12:50:00
>>
>