It seems software licensing approaches are as wide and varied as software itself. Just when you think you’ve worked out a good method, another vendor comes along with a different idea of how to sell their product, and IT is left scrambling to figure out how to connect the virtual dots.

As context, you might consider taking a quick look at my other article that details how Higher Education is ALL the verticals…which leads nicely into this software licensing discussion. Because after all, if Higher Education is in fact ALL the verticals, then a one-size-fits-all licensing approach is probably doomed from the start.

Who gets it, and who doesn’t?

Gone are the days where IT would maintain a central set of floppies, or CD/DVD Media, with a text file containing the license key that no one would ever share on the early internet….yeah…that would never happen, ever.

In the past, you could easily control who gets to install Photoshop, because an approved person would have to go desk-side and install it with admin privileges. Deploying software these days in Higher Education can be a difficult task from a technical perspective as IT attempts to figure out who should have access to what, and how much it’s going to cost to make that happen.

Is the software for literally everyone, aka an old-school site license? Is it only for a certain classification of users, say, Knowledge Workers. How about if the licensing is based on being free for academic purposes, but paid for non-academic purposes? In higher education, is everything related to academics? Probably not, considering it’s ALL verticals, right?

How about student use? Can students use it as long as they are enrolled? What about when they’re admitted, but haven’t started their first class yet?What about alumni …. if they are in the same domain and have “accounts for life” can they use it too?

I’m sure every vendor would love to look at login numbers and say how great they are at achieving broad use, but if the school can’t afford to give access to everyone….this benefit of “everyone can use it” quickly falls apart.

It’s obvious that there’s no consistent answer, considering the vast array of kinds of software, and the vast methods for deployment.

On-Demand, SaaS, virtual, local, oh my!

If we’re talking Software-as-a-Service (SaaS) then there’s nothing to “install” and yet there’s still something to license. Allowing or denying access based on user type, versus “everyone with a school dot edu email” has different technical implementations. What about virtualized environments, where an app is installed on a “desktop” that users can log in to. Does the school need to restrict concurrent usage of the app in order to comply with the licensing model;

if you can reach the virtual desktop, then does it matter how many people are running the app at the same time?

This conversation comes up routinely as some software vendors rethink the traditional “install it on lab machines for students” to a more “anytime anywhere” approach to access and licensing.

Historically the number of people using a piece of software was limited to the number of physical devices a person could be seated in front of….but now it’s infinitely more complex as remote-access dominates the tech-landscape.

License only for Staff….Easy!

How about this for an easy example of how the capabilities of a vendor’s platform directly intersects with licensing (and therefore purchasing of software).

1. Vendor offers an awesome new feature, as a paid upgrade/addon. Or vendor offers a built-in addon, but usage of it has usage quotas attached to it (think, only X number of actions can be performed for the domain every month).
2. The school sees immense value in this feature, and wants to roll it out, but due to cost and quota, it really only should be rolled out to Faculty & Staff. Students shouldn’t have access to this feature.
3. In Higher Education, students and faculty/staff are usually in the same service. IE: there’s not 2 separate instances of every cloud service.
4. The admin will need an ability (preferably in a scalable way like via API) to set the technical configuration/permissions so that only designated users/groups have access to this feature.

If that configuration option doesn’t exist, the school (and vendor) are at an impasse. Does the school leave the feature OFF (hopefully there’s a way to do that too), or does the school roll it out to everyone and risk cost/quota impacts that they have no way of preventing?

Choose your own adventure: IPEDS, Knowledge-Workers, Head-Count

Is the goal for the vendor/software to be used by everyone? Yes? Okay, then what’s the licensing approach to make it affordable to the campus?

If the vendor does head-count, then that may include students. At large campuses, that means tens of thousands (or even 100K+ users) who would logically have access. A licensing approach based on headcount for a “site-license” deployment is going to get expensive, quickly…..unless deep discounts are offered, right?

Okay, next approach….knowledge workers!

Knowledge workers are only going to need access to this software, right? And if some additional users need access, that’s fine….we’ll include some buffer/wiggle room on the number of users allowed. Great! But hold up a second….. what’s the definition of knowledge worker….does the vendor have one? Does the school need to attest to their definition and stick to it?

We can all agree that grounds/facilities/house-keeping staff who barely ever see a computer for their job are probably not “knowledge workers.” What about graduate assistants, adjunct faculty, affiliates/contractors, board of trustees members, and every other employment classification….then it gets a little more difficult to define/decide.

Okay fine, next approach. IPEDS will save us all!

IPEDS … a standards-based approach for measuring populations in higher education, so that the decision about “how many” is externally defined and not subjective.

We’ll just get our IPEDS numbers for Full-time Equivalent Students or Full-Time Equivalent Employees and use that. AWESOME!

HOLD UP…..NOT SO FAST

In an effort to over-simplify…IPEDS uses calculations which includes fractions of people to define the population. IE: 2 part-time staff could equal 1 from IPEDS perspective….or 4 part-time students taking a few courses each might add up to 2 full-time equivalent students. So now we have a discrepancy between headcount and licensed users. We might have 15,000 students per IPEDS, but 17,500 students by headcount. That means, if we have software that needs to be deployed to all students, we have a problem if they are named-user-licenses.

Named-user licenses you say?

If I buy 3 licenses, do I have to specify exactly who has those 3? How about another quick walkthrough of the considerations for this approach…

• Purchased Licenses: 3 (based on IPEDS numbers)
  Actual Headcount: 5
• Andy, Bobby, Carl login and use a license each. We’re now using ALL our licenses. Debbie and Elsa attempt to login, but can’t because there isn’t a license for her.
• Andy leaves and takes a job in the private sector….woohoo! We can let Debbie or Elsa use it now! Nope, not so fast…Andy still has an account, he just can’t log into it anymore.
• So we purge Andy’s account, freeing up a license, hoping that he didn’t have any business-continuity-related data in there…fingers-crossed.

Now play this scenario out at scale, thinking about thousands of students or employees above the headcount vs license count numbers AND then consider the population life-cycle of a common institution.

Boom and bust .. accounts come and go

Thousands of new accounts show up every Fall semester as high-schoolers join the college ranks. On the other end, thousands of people graduate or leave the institution every year. Most schools allow their students a grace-period to get their data out after transferring or graduating, before shutting off their account access.

This means at certain times of the year, the headcount is significantly higher as populations shrink and grow.

So maybe a vendor doesn’t put a hard-cap on the number of licenses? And instead only does an annual true-up to see what the school’s average number of licenses used/assigned is in relationship to what they purchased. This approach at least can handle the boom & bust periods of the year.

Talk to the community first

The bottom line is that vendors need to engage with the community first. The vendor’s technical architecture, objectives, licensing model, access method, authentication & provisioning approach….all of these things (and more) will determine what the most friendly licensing model will be for Higher Education. Keeping in mind of course that Higher Education is all verticals, do research first…engage with potential customers….look at what competitors already do, and ask if that licensing approach makes it easy for higher education to make the best use of the software.

Finally, talk to organizations like EDUCAUSE and Internet2 who bring vendors and schools together to create higher-education-focused offerings like the NET+ program.

Attributions

• Photo by Christina Winter on Unsplash
• Photo by Josh Sorenson on Unsplash
• Photo by Jon Tyson on Unsplash
• Photo by Brooke Cagle on Unsplash