Imagine if - software licensing

Adherence to standards should be very high up the list. Our approach to IT at the University focuses less on vendor-specific technologies and more on interoperability. It would be great to set minimum compliance thresholds to keep standard support alive beyond the version that wins the RFP.

Additionally, protection of proprietary information is of increasing importance. With "The Google" making better strides everyday toward new services, where does the line get drawn for trust?

Thanks for the comment, Chris.

Standards rose early in the conversation - are there any in particular, or a particular way that you think standards adherence could be framed in a "principles" document?

Interesting. Is the discussion just about contracts for commercial software, or does it include requirements for open-source software that we use? It seems to me that most of what's been said (standards-compliant, interoperable, etc) would be just as important for all systems. So perhaps the conversation should be recast to requirement for software, which could then drive contract negotiation.

One of the goals is to streamline negotiations, yes. However, the discussion isn't limited to commercial solutions but rather software of all types.

First Principals informing standards requirements:

1: Interoperability, sure, but perhaps more importantly, suites/apps must support forward migration, with vectors toward open, non-proprietary formats. This is worth pure gold, not only when moving forward among platforms, but (again, perhaps more importantly) as we begin to think realistically about long-term repository implementation.

2: Standards ought to be understood to include APIs into suites/apps permitting us to mix/match/build our own suites from vendor and open source products.

As to specific formats - wiser voices than mine hopefully will chip in, but certainly we might desire a forward path from MS formats toward non-proprietary formats. PDF/A (PDF Archival) is a good present example of a destination format for repository preparation.

Oh yeah - standards ought to extend into means by which auto-generated and user-generated metadata might accrue to files/objects as they pass through their life cycles, from birth, to editing, to co-editing, to "publication"/distribution, to re-use, to ultimate preparation for deposit in the repository. Done right, things ought to be self-describing by the time we're ready to wrap them up neatly for retention/retrieval.

Why archive it if we can't retrieve it and reproduce it in, say, fifty years?

Not certain that we can put our foot down on all of this right this second, but the vendors ought to know we're thinking about it: that there is a booted foot, and that it might come down...

There are excellent points - I have included them in the draft version of what's being built. The API concept would seem to have a duality to it - in that in an open source world, a changing API can always be worked around. In a proprietary, commercial relationship there would need to be terms associated with API availability and change management.

"Site" is a term that has often been detrimental to our multi-location environment. Generally it is viewed as some single geographical space, but we've used incremental arguments to leverage more-encompassing arrangements at various times. (What about a building across the street? A few miles down the road? A few buildings a few miles down the road? A building on university land in the next county? A few buildings...? etc.) Where the line is drawn varies (most of our interest was in satellite-based program/licensing agreements)...but just another aspect to keep in mind, given the number of locations where Penn State folks are at...(

Another good point - I will introduce this as well into the document. It's about who you are, not where you are.