>
> <snip>It is unsound business practice to ask others how long they keep
> their records, and then adopt something similar.  That is not defensible
> anywhere.  It also does not
> serve your organization because it does not account for your systems,
> workflow, procedures, audits, practices, state reqs and local
> requirements, if any.  Your retention policy needs to serve your
> organization's needs, and protect your organization by satisfying
> federal, state, and local regulatory agency requirements.</snip>


Sorry, I can't agree, broadly and in this particular example. What are the
workflows, procedures, audits, and practices associated with being able to
prove you own software? There's a certain practical responsibility to keep
them in the event you'd need to (and the software would allow you to)
reinstall or install on a different machine; while I haven't gone through
the various fed recordkeeping requirements in detail in a while, and
notwithstanding Larry's example earlier that I don't think is exactly right,
I don't believe there is any guidance that exactly pertains.

So. In the absence of fiscal, legal, regulatory, or historic requirements to
keep software licenses and licensing keys, and while I don't claim to know a
ton about federal recordkeeping requirements NARA's response seems to
indicate that there might be a gap; and given that hte only current
operational requirement would be while the software is operational; and
given that the very origin of the profession was an amalgamation of best
practices then, that have been updated over the course of time to now,
seeking the advice of other professionals is in my opinion not only
defensible but to be encouraged.

It might not be the only approach, but Dawn has indicated that it wasn't. It
appears that NARA asked her to make a recommendation, and rather than simply
going off what she felt was right, she asked this august body with its
collective millenia(!) of experience to opine. I imagine the next step is to
fill out the appropriate forms to submit to NARA for inclusion in the GRS.
Why is this not the appropriate approach again?

And to keep it fresh, lemme add one more wrench into the mix. In many
applications, you can upgrade from a previous version to a newer one.
Sometimes the license and key are the same, sometimes they aren't. Under the
oft-cited, most likely not enforceable, but always present End-User License
Agreement (EULA), once the new keys have been entered and the licenses
upgraded the old licenses might be required to be discarded immediately. So
there's a legal or at least assertion of legal citation that would go
against most of the examples we've cited - and better yet, it would be on an
application-by-application basis. Discuss.

-- 
Regards,

Jesse Wilkins
[log in to unmask]
blog: http://informata.blogspot.com
Twitter: http://www.twitter.com/jessewilkins

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]