1. Licensing Scope and Boundaries
Discussion

2. © 2006 Infoblox Inc. All Rights Reserved. 2
Today’s Objectives
 We obviously cannot cover every scenario which may
present itself in the future
 BUT, we have to define some scope and boundaries
around what we want a LICENSING model include/exclude.
 We may decide we need several models depending upon
the scope. (eg May not want to force fit model X to cover
all scenarios)
 Purpose today is start identifying and agreeing upon the
scope and boundary of the project.

3. © 2006 Infoblox Inc. All Rights Reserved. 3
Scope/Boundary Discussion
 Our model today covers two broad categories
 Protocol/Software Entitlements on a SPECIFIC piece of Hardware
– We enable product features such as DNS, GRID
– These entitlements are (typically) perpetual
– The appliance ‘needs to know’ what it can run
 Support Entitlements for a SPECIFIC piece of Hardware
– Support ‘entitled’ for a specific period of time
– Allows access to Support, RMA, etc
– Supposed to allow/disallow software upgrades (not enabled)
– Even though an appliance may have many support keys, they
simply could be distilled to a single key to allow upgrades. True?

4. © 2006 Infoblox Inc. All Rights Reserved. 4
Scope/Boundary Discussion
 Let’s walk through some other scenarios and decide if we
need to consider or not.

5. © 2006 Infoblox Inc. All Rights Reserved. 5
Scope/Boundary Discussion
OEM Strategy
Could we be in the situation whereby we license our code to a 3rd party
who would bundle it with hardware and sell it under their name?
Would we expect to continue to manage licensing in this scenario?
Would we need to be involved with Support Keys for each appliance?
Or would the 3rd
party be responsible?

6. © 2006 Infoblox Inc. All Rights Reserved. 6
Scope/Boundary Discussion
Software Only Strategy
Could we be in the situation whereby we simply sell our software to an
end customer who, in turn, may run it on their own hardware?
Would we expect to continue to manage individual entitlements (eg DNS,
GRID, Maintenance) in this scenario? Would we need to be involved
with Support Keys for each appliance? Might be a separate model.

7. © 2006 Infoblox Inc. All Rights Reserved. 7
Scope/Boundary Discussion
Virtualization Strategy
Could we be in the situation where we allow our software to ride on top
of, for example, VMware?
Subset of an OEM strategy? Version of Software Only strategy?

8. © 2006 Infoblox Inc. All Rights Reserved. 8
Scope/Boundary Discussion
Certificate (or LAC) model
Allow the purchase of rights to an entitlement (software/maintenance) we
offer for a SPECIFIC model of hardware.
In it’s simplest form, we would create a new SKU for every entitlement we
would offer as a certificate. ‘Customer’ to marry certificate to
appropriate hardware.

9. © 2006 Infoblox Inc. All Rights Reserved. 9
Scope/Boundary Discussion
Support SKUs
There have been brief conversations of creating exactly 2 support
SKUs – Premium or 3rd Level. Pricing would be x% of the
current list price of whatever is being supported
This would apply to our existing licensing structure and may not be
applicable for others discussed.

10. © 2006 Infoblox Inc. All Rights Reserved. 10
Scope/Boundary Discussion
 Other Scope Issues we should consider?
 Where does this fall on the priority list?
 Who all should be engaged in spec development? Inputs
should be what Infoblox wants without considering
implementation at this point.
 I’ll make sure whatever is proposed passes the Revenue test
 Steve Schall
 Sales?
 Support?
 Any outside intelligence anyone wants to offer?