Time until synchronized - NTP

This is a discussion on Time until synchronized - NTP ; Hello, I've been trying to figure out a couple of details during the last few days concerning NTP/ntpd. I now have the following unanswered questions. * The ntpdc -> kerninfo -> status bits, are these set by NTP when it ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 48

Thread: Time until synchronized

  1. Time until synchronized

    Hello,

    I've been trying to figure out a couple of details during
    the last few days concerning NTP/ntpd. I now have the
    following unanswered questions.

    * The ntpdc -> kerninfo -> status bits, are these set
    by NTP when it considers itself "synchronized"?
    * If so, what are ntp:s criteria for setting it to 0001 (pll)?
    * How long should it take for ntpd to reach "synchronized"/pll?
    * Is three (3) days acceptable?
    * Can this time be improved in any way, if so, how?

    Best regards,
    Anton Persson

  2. Re: Time until synchronized

    Anton Persson A wrote:

    > I've been trying to figure out a couple of details during
    > the last few days concerning NTP/ntpd. I now have the
    > following unanswered questions.
    >
    > * The ntpdc -> kerninfo -> status bits, are these set
    > by NTP when it considers itself "synchronized"?


    Yes.

    > * If so, what are ntp:s criteria for setting it to 0001 (pll)?


    The time source is not a special one (specifically modem clocks) for
    which PLL mode is not appropriate, and the measured offset is
    consistently within 128ms of the system time.

    > * How long should it take for ntpd to reach "synchronized"/pll?


    No more than about 20 minutes, and as little as under a minute,
    depending on whether this is a cold start and how far off the clock was
    on startup. This can be compromised by trying to prevent the time being
    stepped.

    > * Is three (3) days acceptable?


    No. If it thinks it is doing a warm start, but the saved frequency data
    is wrong (e.g. because someone, incorrectly, created /etc/ntp.drift
    manually, it may go through the 20 minute cycle several times, but it
    should lock up stably in minutes to hours, not days, unless something is
    broken.

    As I asked you before, the output of ntpq peers and ntpq rv 0 and rv for
    each association, is much more useful than ntpdc kerninfo.

    > * Can this time be improved in any way, if so, how?


    Fix what is broken. If you don't get your first synchronise within
    about 20 minutes, something is broken.

    Don't use -x, or otherwise inhibit stepping.

    Make sure that /etc/ntp.drift does not exist on the first start.

    Make sure that the time is accurate to about a millisecond, or out by
    more than 128 ms, before you start ntpd.

    Use of iburst can reduce the best case from about 5 minutes to under 1
    minute, but you should understand the sever load implications, and
    beware of any multiplexing due to NATting.

    Note that these get you to a synchronized state fairly quickly, but it
    can still take some time for the residual error to converge to the noise
    level, but generally less than three days.

  3. Re: Time until synchronized

    > David Woolley wrote:
    > > Anton Persson A wrote:

    >
    > > I've been trying to figure out a couple of details during the last

    few
    > > days concerning NTP/ntpd. I now have the following unanswered
    > > questions.
    > >
    > > * The ntpdc -> kerninfo -> status bits, are these set
    > > by NTP when it considers itself "synchronized"?

    >
    > Yes.
    >
    > > * If so, what are ntp:s criteria for setting it to 0001 (pll)?

    >
    > The time source is not a special one (specifically modem clocks) for

    which PLL mode is not appropriate, and the > measured offset is
    consistently within 128ms of the system time.
    >
    > > * How long should it take for ntpd to reach "synchronized"/pll?

    >
    > No more than about 20 minutes, and as little as under a minute,

    depending on whether this is a cold start and
    > how far off the clock was on startup. This can be compromised by

    trying to prevent the time being stepped.
    >
    > > * Is three (3) days acceptable?

    >
    > No. If it thinks it is doing a warm start, but the saved frequency

    data is wrong (e.g. because someone,
    > incorrectly, created /etc/ntp.drift manually, it may go through the 20

    minute cycle several times, but it
    > should lock up stably in minutes to hours, not days, unless something

    is broken.
    >
    > As I asked you before, the output of ntpq peers and ntpq rv 0 and rv

    for each association, is much more useful > than ntpdc kerninfo.

    ntpq> rv 0
    assID=0 status=06f4 leap_none, sync_ntp, 15 events,
    event_peer/strat_chg,
    version="ntpd 4.2.4p0@1.1472-o Sat Dec 1 06:59:06 UTC 2007 (1)",
    processor="ppc", system="Linux/2.6.21.7-hrt1-WR2.0bl_standard", leap=00,
    stratum=4, precision=-19, rootdelay=2.367, rootdispersion=68.721,
    peer=59945, refid=192.168.10.207,
    reftime=cbf76e3a.35b92725 Mon, Jun 9 2008 8:54:18.209, poll=6,
    clock=cbf76f25.47f90c7d Mon, Jun 9 2008 8:58:13.281, state=4,
    offset=1.835, frequency=13.325, jitter=0.041, noise=0.015,
    stability=0.007, tai=0

    These are quite OK values, are they not?

    >
    > > * Can this time be improved in any way, if so, how?

    >
    > Fix what is broken. If you don't get your first synchronise within

    about 20 minutes, something is broken.
    >
    > Don't use -x, or otherwise inhibit stepping.


    This was infact enabled by default, for some reason. By disabling it I
    managed
    to get "synchronized"/pll status in "kerninfo".

    > Make sure that /etc/ntp.drift does not exist on the first start.
    >
    > Make sure that the time is accurate to about a millisecond, or out by

    more than 128 ms, before you start ntpd.

    So, what you are saying: the time offset should not be in the 1ms <
    128ms interval? Why is this important, and
    what happens if it IS within this interval?

    > Use of iburst can reduce the best case from about 5 minutes to under 1

    minute, but you should understand the
    > sever load implications, and beware of any multiplexing due to

    NATting.
    >
    > Note that these get you to a synchronized state fairly quickly, but it

    can still take some time for the
    > residual error to converge to the noise level, but generally less than

    three days.

    Yes, without the -x option we get to synchronized quite fast.

    Kind regards,
    Anton

  4. Re: Time until synchronized

    Anton Persson A wrote:

    >> As I asked you before, the output of ntpq peers and ntpq rv 0 and rv

    > for each association, is much more useful > than ntpdc kerninfo.


    All of these are useful. ntpq peers gives an overview and makes it easy
    to see if you are synchronized.
    >
    > ntpq> rv 0
    > assID=0 status=06f4 leap_none, sync_ntp, 15 events,


    You are synchronized. You don't need to wait any longer.

    > event_peer/strat_chg,
    > version="ntpd 4.2.4p0@1.1472-o Sat Dec 1 06:59:06 UTC 2007 (1)",
    > processor="ppc", system="Linux/2.6.21.7-hrt1-WR2.0bl_standard", leap=00,
    > stratum=4, precision=-19, rootdelay=2.367, rootdispersion=68.721,
    > peer=59945, refid=192.168.10.207,
    > reftime=cbf76e3a.35b92725 Mon, Jun 9 2008 8:54:18.209, poll=6,
    > clock=cbf76f25.47f90c7d Mon, Jun 9 2008 8:58:13.281, state=4,
    > offset=1.835, frequency=13.325, jitter=0.041, noise=0.015,
    > stability=0.007, tai=0
    >
    >
    >>> * Can this time be improved in any way, if so, how?

    >> Fix what is broken. If you don't get your first synchronise within

    > about 20 minutes, something is broken.
    >> Don't use -x, or otherwise inhibit stepping.

    >
    > This was infact enabled by default, for some reason. By disabling it I
    > managed


    That may be a problem with the (human) packager. -x is undesirable for
    NTP, but prevents grief with software that absolutely cannot stand
    backward time steps. Packagers tend to chose options that are least
    likely to result in support calls, rather than those that are optimum.

    > to get "synchronized"/pll status in "kerninfo".


    The reason I mentioned -x is that, if you start with a large time error,
    you cannot synchronise until that has been cleared by slewing, which can
    take an arbitrarily long time. However, setting -x is equivalent to
    setting a parameter value that is incompatible with the kernel PLL, so
    the time discipline is run in user mode. The time is still adjusted,
    but the offset sawtooths around the correct value, by a small amount.

    >
    >> Make sure that /etc/ntp.drift does not exist on the first start.
    >>
    >> Make sure that the time is accurate to about a millisecond, or out by

    > more than 128 ms, before you start ntpd.
    >
    > So, what you are saying: the time offset should not be in the 1ms <
    > 128ms interval? Why is this important, and
    > what happens if it IS within this interval?


    If it is within that interval, it is too accurate for an initial step
    and not as accurate as it might be immediately after an initial step, so
    you will have to wait for the error to converge from the initial value
    to around 1ms or less. Having it greater than 128ms, with the standard
    configuration (no -x, no tinkers) forces an initial step.

    >
    > Yes, without the -x option we get to synchronized quite fast.


    With -x you will also get to synchronised quite fast, but you will never
    get the kernel PLL turned on. You will be using a user space PLL.

  5. poll interval - RFC compliance question

    Hi,

    we are using the ntp v3 protocol, as defined in RFC1305, however
    I have a question running through my head when I consider the poll
    interval.

    According to RFC 4330: (yes I know, SNTP v4)
    A client SHOULD increase the poll interval using exponential
    backoff as performance permits and especially if the server does
    not respond within a reasonable time.

    Is this requirement also valid for ntp v3, I can't quite find it
    but I'm unsure? The reason I'm asking is that we have quite
    a blood thirsty testing squad here and I need to clarify
    if this is a compliance requirement or not.

    If it is I have other questions too; we have configured
    our machine like this:

    server 127.127.1.0 # local clock
    fudge 127.127.1.0 stratum 10
    driftfile /var/lib/ntp/drift
    server 192.168.0.207 version 3

    * Should the poll interval not be, by default, 64 to 1024?
    * If so, why does the "poll" value not increase when we yank
    the connection to the server configured? (using ntpq peers)

    The best regards,
    Anton Persson

  6. Re: poll interval - RFC compliance question

    Anton,

    You are familiar with the draft NTPv4 spec, which includes SNTP, right?

    More info at http://support.ntp.org/IETF/WebHome .

    Several of your questions would be useful on the IETF NTP workgroup mailing
    list, and would be useful and interesting topics for the Support or Dev
    areas of http://support.ntp.org .

    Finally, I encourage you and everybody else who is working for a company
    that has an interest in NTP to get your company to join the the NTP Forum,
    http://ntpforum.isc.org . I am happy to do whatever I can to make
    membership in the NTP Forum a valuable experience.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  7. Re: poll interval - RFC compliance question

    Anton Persson A wrote:
    > Hi,
    >
    > we are using the ntp v3 protocol, as defined in RFC1305, however
    > I have a question running through my head when I consider the poll
    > interval.
    >
    > According to RFC 4330: (yes I know, SNTP v4)
    > A client SHOULD increase the poll interval using exponential
    > backoff as performance permits and especially if the server does
    > not respond within a reasonable time.
    >
    > Is this requirement also valid for ntp v3, I can't quite find it
    > but I'm unsure? The reason I'm asking is that we have quite
    > a blood thirsty testing squad here and I need to clarify
    > if this is a compliance requirement or not.
    >


    A little history is in order here!

    There have been at least two incidents in which poorly
    designed/implemented NTP or SNTP clients have caused serious problems by
    polling a server at one second intervals. In one case, many thousands
    of Netgear Routers polled the University of Wisconsin's NTP server at
    one second intervals and brought it to its knees! See:
    http://pages.cs.wisc.edu/~plonka/netgear-sntp/

    In another case DLink was the culprit and Poul Henning-Kamp (PHK) was
    the victim. I believe that there was also a problem with a software
    product named "TARDIS".

    I would say that the "requirement" is valid for ANY NTP or SNTP version!
    This is especially true if you are going to distribute hardware with
    built in firmware implementing SNTP or NTP.

    If you screw this one up, your name will be "mud" forever! It will be
    many years before the Netgear and Dlink screwups will be forgotten if,
    indeed, they are ever forgotten.

  8. Re: poll interval - RFC compliance question

    Harlan Stenn wrote:
    []
    > Finally, I encourage you and everybody else who is working for a
    > company that has an interest in NTP to get your company to join the
    > the NTP Forum, http://ntpforum.isc.org . I am happy to do whatever I
    > can to make membership in the NTP Forum a valuable experience.


    But that's a closed club to paying members only, is it? I've heard
    nothing for months, despite expressing an interest.....

    Thanks,
    David



  9. Re: poll interval - RFC compliance question

    >>> In article , "David J Taylor" writes:

    David> Harlan Stenn wrote: []
    >> Finally, I encourage you and everybody else who is working for a company
    >> that has an interest in NTP to get your company to join the the NTP
    >> Forum, http://ntpforum.isc.org . I am happy to do whatever I can to make
    >> membership in the NTP Forum a valuable experience.


    David> But that's a closed club to paying members only, is it? I've heard
    David> nothing for months, despite expressing an interest.....

    David> Thanks, David

    And here's another slant - Anton wrote his post apparently as part of a
    commercial need his employer has. This need encompasses clarifications of
    the NTP specification (progress on which has been *painfully* slow for a
    variety of reasons), perhaps some regulatory compliance, and
    interoperability needs.

    I don't think those needs are being met by the current process. Some folks
    agree with me. Some do not.

    David, you participate here a fair amount. Are you satisfied with the
    "state" of NTP? Is this involvement of yours (just) a personal choice or do
    you have other reasons for being interested in NTP?

    If it's more than a personal project for you, what are *you* doing to help
    the project flourish?

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  10. Re: poll interval - RFC compliance question

    Harlan Stenn wrote:
    []
    > David, you participate here a fair amount. Are you satisfied with the
    > "state" of NTP? Is this involvement of yours (just) a personal
    > choice or do you have other reasons for being interested in NTP?
    >
    > If it's more than a personal project for you, what are *you* doing to
    > help the project flourish?


    Harlan,

    Thanks for your clarification of the "NTP Forum" status. As a private
    individual, I cannot afford corporate membership level fees.

    I am simply interested in helping people deploy NTP on client systems as
    widely as possible, as I feel that good timekeeping is beneficial to us
    all (when diagnosing fault chains, for example). I have no business or
    commercial interest in NTP.

    Despite that, I have spent some time trying to get NTP compiled on
    Windows, so that I could contribute more and, for example, perhaps
    experiment with some of the problems I see on Windows Vista. However,
    despite the best efforts of people here to help, I have not been able to
    get the software to compile, so my ability to help in that way has been
    curtailed.

    I have also reported bugs, tried to add to the Wiki, and put up Web pages
    about my experiences with NTP including making a simple GPS-based NTP
    stratum one server.

    I hope these "help the project flourish".

    David



  11. Re: poll interval - RFC compliance question

    Anton Persson A wrote:

    > we are using the ntp v3 protocol, as defined in RFC1305, however
    > I have a question running through my head when I consider the poll
    > interval.


    You are going to have limited success getting help on that specification
    here as it is considered obsolete, even though the version 4
    specification is still only, officially, a draft. As such people are
    going to give you the answers for version 4 or have to cast their minds
    back several years.

  12. Re: poll interval - RFC compliance question

    Anton Persson A wrote:

    > Is this requirement also valid for ntp v3, I can't quite find it
    > but I'm unsure? The reason I'm asking is that we have quite
    > a blood thirsty testing squad here and I need to clarify
    > if this is a compliance requirement or not.


    Why aren't you just using the reference implementation code? The only
    issue I'm aware of about the licence is that that OpenBSD claim the
    wording means it doesn't meet their free for commercial use requirements
    whereas Dave Mills claims that the licence already meets that
    requirement, and doesn't need rewording.

  13. Re: poll interval - RFC compliance question

    David, Anton,

    As I have reminded folks many, many times, please read the copyright
    statement in the distribution. Note very carefully that there is no
    license, only a copyright statement that clearly specifies no fee, no
    restictions on use other than including the copyright statement itself
    in derived products.

    Except for one minor word change, the copyright statement is identical
    to the one used by MIT in Project Athena and has not chenged since 1988.

    Be advised, lawyers have already stalked me about restictive licenses; I
    threw the one from IBM, who showed up unannounced, right back out the door.

    Dave

    David Woolley wrote:
    > Anton Persson A wrote:
    >
    >> Is this requirement also valid for ntp v3, I can't quite find it
    >> but I'm unsure? The reason I'm asking is that we have quite
    >> a blood thirsty testing squad here and I need to clarify
    >> if this is a compliance requirement or not.

    >
    >
    > Why aren't you just using the reference implementation code? The only
    > issue I'm aware of about the licence is that that OpenBSD claim the
    > wording means it doesn't meet their free for commercial use requirements
    > whereas Dave Mills claims that the licence already meets that
    > requirement, and doesn't need rewording.


  14. Re: poll interval - RFC compliance question

    David L. Mills wrote:

    > statement in the distribution. Note very carefully that there is no
    > license, only a copyright statement that clearly specifies no fee, no


    If that were really true (that there was no licence), almost no-one
    would be able to use the code. A copyright notice says what is
    copyright and who owns the copyright. It just removes doubt as to
    whether a licence is needed (not much software was written by people who
    have been dead for 70 years, so most software needs a licence; software
    written by the US government, at least within the USA, is a special
    case), and tells you who is able to give that licence.

    A licence is a statement of permission to do things which would
    otherwise be illegal. Copying the ntpd code would be illegal without a
    licence.

    > restictions on use other than including the copyright statement itself
    > in derived products.


    The statement that there are no restrictions is actually the licence.

    You may be confused by commercial software, which doesn't use a bare
    licence, but uses a licence agreement, which is actually a contract.
    Note that some people argue that bare licences are not possible in many
    countries. Some people even argue that bare licences are not valid in
    the USA.

    To the extent that copyright agreements are optional, their purpose is
    normally to give you a copy only on the condition that you do not
    exercise some of the rights that you would have if given the copy
    without making the agreement.

    I suspect Open BSD's problem is that the statement of permission doesn't
    actually give all the rights that are restricted by copyright. In
    particular, if it says "use", that has a technical meaning that doesn't
    include copying to give to others.

    People in the ntpd community generally assume that the copyright owners
    will act as though the licence you intended exists, but others may want
    to act on the basis of what the licence actually says.

    Normally the following would be taken as implied, but I will make them
    explicit, as an example. I'm not a lawyer, so they may well not be
    watertight. You should independently verify any statements about the
    law made here.

    Copyright notice: This article is Copyright 2008 David J Woolley of
    London England.
    Parts prefixed ">" are Copyright 2008 Doctor David L Mills and/or the
    University of Delaware (and are included under the doctrine of fair use
    for criticism or review).

    Licence: David J Woolley grants permission for all acts covered by
    copyright law which contributors to a USENET newsroup gatewayed to a
    public mailing list would normally expect to be permitted.

  15. Re: poll interval - RFC compliance question

    David Woolley said the following on 06/14/2008 04:34 PM:

    > To the extent that copyright agreements are optional, their purpose is
    > normally to give you a copy only on the condition that you do not
    > exercise some of the rights that you would have if given the copy
    > without making the agreement.
    >
    > I suspect Open BSD's problem is that the statement of permission doesn't
    > actually give all the rights that are restricted by copyright. In
    > particular, if it says "use", that has a technical meaning that doesn't
    > include copying to give to others.


    Good point, David. The US copyright law lists five exclusive rights
    that the copyright holder possesses. "Use" isn't one of them, and that
    does make software copyright issues more interesting. The five rights
    are the right to: copy, create derivative works, distribute, perform
    publicly (applies only to certain types of works), and to display
    publicly (also applies only to certain types of works).

    The reason that "use" normally works in the software context is that to
    make software function you almost always need to copy it (for example,
    from hard disk to RAM). In some situations, "use" would also trigger
    the display right. But it's also possible to conceive of a computing
    device with nonvolatile memory such that there is no copying involved in
    running the the software. So, a right to "use" is inherently ambiguous
    from a copyright perspective.

    I believe (pretty strongly) that "use" would not normally be interpreted
    to include the right to distribute copies to third parties. However,
    that right could be implied by the circumstances (if I publish my
    software on a web site and encourage downloads with no restrictions, it
    might well be that I've granted an implied license to those who download
    to further distribute.

    By the way -- relying on copyright notices drafted in the early '80s
    isn't necessarily a good idea. At least in the US, there was still
    significant debate on whether software could even be copyrighted up
    until 1983, when Apple v. Franklin pretty much laid that to rest.
    Rights notices of the time were experimental, to say the least...

    John

  16. Re: poll interval - RFC compliance question

    David,

    You can tell by my tone that I violently disagree. If what you say is
    true in a strict legal sense, then for the last almost three decades
    nobody could use the code, not Sun, not Digital/HP, not anybody. What
    you see is what MIT saw and is absolutely all you get.

    Dave

    David Woolley wrote:
    > David L. Mills wrote:
    >
    >> statement in the distribution. Note very carefully that there is no
    >> license, only a copyright statement that clearly specifies no fee, no

    >
    >
    > If that were really true (that there was no licence), almost no-one
    > would be able to use the code. A copyright notice says what is
    > copyright and who owns the copyright. It just removes doubt as to
    > whether a licence is needed (not much software was written by people who
    > have been dead for 70 years, so most software needs a licence; software
    > written by the US government, at least within the USA, is a special
    > case), and tells you who is able to give that licence.
    >
    > A licence is a statement of permission to do things which would
    > otherwise be illegal. Copying the ntpd code would be illegal without a
    > licence.
    >
    >> restictions on use other than including the copyright statement itself
    >> in derived products.

    >
    >
    > The statement that there are no restrictions is actually the licence.
    >
    > You may be confused by commercial software, which doesn't use a bare
    > licence, but uses a licence agreement, which is actually a contract.
    > Note that some people argue that bare licences are not possible in many
    > countries. Some people even argue that bare licences are not valid in
    > the USA.
    >
    > To the extent that copyright agreements are optional, their purpose is
    > normally to give you a copy only on the condition that you do not
    > exercise some of the rights that you would have if given the copy
    > without making the agreement.
    >
    > I suspect Open BSD's problem is that the statement of permission doesn't
    > actually give all the rights that are restricted by copyright. In
    > particular, if it says "use", that has a technical meaning that doesn't
    > include copying to give to others.
    >
    > People in the ntpd community generally assume that the copyright owners
    > will act as though the licence you intended exists, but others may want
    > to act on the basis of what the licence actually says.
    >
    > Normally the following would be taken as implied, but I will make them
    > explicit, as an example. I'm not a lawyer, so they may well not be
    > watertight. You should independently verify any statements about the
    > law made here.
    >
    > Copyright notice: This article is Copyright 2008 David J Woolley of
    > London England.
    > Parts prefixed ">" are Copyright 2008 Doctor David L Mills and/or the
    > University of Delaware (and are included under the doctrine of fair use
    > for criticism or review).
    >
    > Licence: David J Woolley grants permission for all acts covered by
    > copyright law which contributors to a USENET newsroup gatewayed to a
    > public mailing list would normally expect to be permitted.


  17. Re: poll interval - RFC compliance question

    John,

    I can tell you haven't read the statement. Please do. Perhaps a lawyer
    would have phrased it differently and maybe modern times are different
    than mellow old MIT days, but I am loath to change it on advice, as this
    might compromise prior use and interpretation of the statement.

    Dave

    ************************************************** *********************
    * *
    * Copyright (c) David L. Mills 1992-2008 *
    * *
    * Permission to use, copy, modify, and distribute this software and *
    * its documentation for any purpose with or without fee is hereby *
    * granted, provided that the above copyright notice appears in all *
    * copies and that both the copyright notice and this permission *
    * notice appear in supporting documentation, and that the name *
    * University of Delaware not be used in advertising or publicity *
    * pertaining to distribution of the software without specific, *
    * written prior permission. The University of Delaware makes no *
    * representations about the suitability this software for any *
    * purpose. It is provided "as is" without express or implied
    *
    * warranty. *
    * *
    ************************************************** *********************John
    Ackermann N8UR wrote:

    > David Woolley said the following on 06/14/2008 04:34 PM:
    >
    >
    >>To the extent that copyright agreements are optional, their purpose is
    >>normally to give you a copy only on the condition that you do not
    >>exercise some of the rights that you would have if given the copy
    >>without making the agreement.
    >>
    >>I suspect Open BSD's problem is that the statement of permission doesn't
    >>actually give all the rights that are restricted by copyright. In
    >>particular, if it says "use", that has a technical meaning that doesn't
    >>include copying to give to others.

    >
    >
    > Good point, David. The US copyright law lists five exclusive rights
    > that the copyright holder possesses. "Use" isn't one of them, and that
    > does make software copyright issues more interesting. The five rights
    > are the right to: copy, create derivative works, distribute, perform
    > publicly (applies only to certain types of works), and to display
    > publicly (also applies only to certain types of works).
    >
    > The reason that "use" normally works in the software context is that to
    > make software function you almost always need to copy it (for example,
    > from hard disk to RAM). In some situations, "use" would also trigger
    > the display right. But it's also possible to conceive of a computing
    > device with nonvolatile memory such that there is no copying involved in
    > running the the software. So, a right to "use" is inherently ambiguous
    > from a copyright perspective.
    >
    > I believe (pretty strongly) that "use" would not normally be interpreted
    > to include the right to distribute copies to third parties. However,
    > that right could be implied by the circumstances (if I publish my
    > software on a web site and encourage downloads with no restrictions, it
    > might well be that I've granted an implied license to those who download
    > to further distribute.
    >
    > By the way -- relying on copyright notices drafted in the early '80s
    > isn't necessarily a good idea. At least in the US, there was still
    > significant debate on whether software could even be copyrighted up
    > until 1983, when Apple v. Franklin pretty much laid that to rest.
    > Rights notices of the time were experimental, to say the least...
    >
    > John


  18. Re: poll interval - RFC compliance question

    >>> In article , "David J Taylor" writes:

    David> Harlan Stenn wrote: []
    >> David, you participate here a fair amount. Are you satisfied with the
    >> "state" of NTP? Is this involvement of yours (just) a personal choice or
    >> do you have other reasons for being interested in NTP?
    >>
    >> If it's more than a personal project for you, what are *you* doing to
    >> help the project flourish?


    David> Thanks for your clarification of the "NTP Forum" status. As a
    David> private individual, I cannot afford corporate membership level fees.

    No worries, and this thread has, so far, been addressing *institutional*
    memberhsip of the NTP Forum, not *individual* membership in that group.

    David> I am simply interested in helping people deploy NTP on client systems
    David> as widely as possible, as I feel that good timekeeping is beneficial
    David> to us all (when diagnosing fault chains, for example). I have no
    David> business or commercial interest in NTP.

    Understood, and I appreciate your efforts.

    I just wanted to be clear that I was addressing issues faced by
    *institutions* when using NTP, and their needs are different from those of
    *individuals*.

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  19. Re: poll interval - RFC compliance question

    I'll follow-up to Dave's post about the copyright/license by saying the NTP
    Forum recently took the steps needed to get the NTP license approved by the
    Open Source Initiative, and NTP's License is now an OSI-approved "Open
    Source License: http://www.opensource.org/licenses/ntp-license.php .

    As I understand it, the OpenBSD folks had a problem with a potential
    ambiguity in the original license. That ambiguity has since been resolved.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  20. Re: poll interval - RFC compliance question

    > * *
    > * Copyright (c) David L. Mills 1992-2008 *


    The above is the copyright notice. Everything else is the licence, so
    rather than not having a licence, all but one line is actually the licence.
    > * *
    > * Permission to use, copy, modify, and distribute this software and *


    This uses more than the term "use", so your summary was wrong. It also
    sounds like the licence has heen changed since the OpenBSD objections,
    but anyone trying to implement version 3 (presumably because they have a
    mandate to only implement official standards, although I'm waiting for
    the actual answer on that question), would see the old licence on the
    reference implementation and therefore might not treat it as having new
    style BSD type licence.

    I'd have to search the archives to work out what the exact OpenBSD
    objection was.

    Note that my statement about use being illegal was rhetorical, based on
    your claim that is didn't have a licence. You were wrong in saying that
    it didn't have a licence, and I tried to explain that common commercial
    use of "licence agreement" for what is actually a contract limiting
    rights, might be the source of your confusion.

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast