Capturing Licensing Models - ECP-1

Post Reply
jonathan.carter

This meta model extension enables modellers to more accurately and flexibly capture and analyse license models.


Initial requirements so far:
  • Associated with Cost Management
  • Manage types of licenses, e.g. different license models such as Open Source, Commercial etc., as a modeller-defined extensible set
  • Manage models of licensing, per user, per CPU, etc.
  • Define licenses to be of a particular type, capture the cost, OSI approved
  • Associate the license with any artefact in the core meta model, e.g. business process, applications, technology
  • Also something to relate if a licence can be mixed with other (GPL compatibility for example)
  • Ability to create an association between licences.
Please contribute the requirements that you have for this capability.

Jonathan
jonathan.carter

License Model Meta Model Extension

The following UML class diagram describes the proposed approach for extending the meta model to manage licenses that apply to anything in the core meta model, e.g. applications, technology products, business processes, information.

All classes in the License_Model_Extension package are new and define the scope of the extension.

Please review the proposed classes and the following comments. When these are agreed, we'll create an update pack to apply to your repository to start testing this extension.

Image

Download a larger version of this image

The licensing information will be managed in a new section of the EA_Support class hierarchy, called Cost_Management.

A License instance is used to capture the details of a particular license in your enterprise (e.g. our Oracle 11g license) and provides the constructs to capture all the potential variations that might need to be captured about a license.
In the diagram, the simple slots are represented by attributes, the instance slots by the relations, and are named by the relationship end-point names.

NOTE: where a relationship endpoint has no name, no slot should be created. Where a relationship has names on both endpoints, an inverse-slot relationship should be constructed.

License_Model and License_Type provides means of classifying the License. Extending the Enumeration abstract class, these provide the modeller with the ability to easily define new License_Models (the basis on which a license is applied and charged) and License_Types (classes of licenses, such as commercial, Open Source, Shareware etc.)

In reality, licensing is often defined as part of a deal for your enterprise and therefore the specifics of any license may have many unique variations. Additionally, many suppliers, software suppliers in particular, devise novel approaches to how products can be used and paid for.
To manage this variation, we have defined subclasses of Attribute and Attribute_Value to enable the modeller to define and manage the particular relevant details about their particular licenses. License_Attributes, define 'classes' of attributes that can be attached to a license, and the License_Attribute_Value represent the particular instances of a such an attribute on the license, with its defined value.
In this way, the modeller can define the relevant, specific details that they need to capture about a license, such as the subscription term, renewal date, review date, monthly cost etc.

Jonathan
gioppo

Wonderful.
This is right what I needed.
I see you have added an osi_approved; there could be also a place for FSF (Free Software Foundation) approved since the two approval are not equal.
I also was wandering on how to map compatibility licence (it could be the combination/combined_with self relationship, but in this case I would shift all (osi, fsf, combined in the licence type class).
Licence seems to map directly cost stuff and the licence type can be more the legal part.
The same licence type (GPL or MS-EULA) can be the same for different product, but there can be different commercial offernigs and so differente licence instance (in your model).
If you bring in the licence type all the legal definition you get a reusable instance (as you know open source software can have a price).
Also I would place a Licence text in the licence type so that is possible to copy the text of the licence.
Also in the combine relationship could be useful to add a relationship type (can be combined in static link, in package etc); just an enumeration so that is possible to take into account different variation even if it could map just "can combine" value.
Luca

P.S.
Sorry for the absence, had some work to finish for the last week
jonathan.carter

Hi Luca,
Thanks for getting back to me. Apologies for taking so long to get back to you.

You make some very interesting points here - and I think we're nearly there in getting this right.

In answer to your point about the OSI or FSF approved, I think the answer is to make a new enumeration called License_Approval, in which we can have OSI, FSF and any others we might need later. So, the slot for osi_approved would change to license_approved, which could contain multiple instances of the License_Approval enumeration.

- Compatibility. This is probably a multiple instance slot on license types - as you suggest. I think we need to take the same approach as with the combination.
However, what is the difference between compatibility and combination? Is it that compatibility applies to the License Type, whereas Combination applies to the License instance? That is, compatibility states whether we CAN combine to licenses but it's only at the specific License instance that we capture that they have been?

Interesting point on whether this should be in a Legal rather than Cost area. We don't normally have a meta class be part of more than one place in the hierarchy. We went with Cost Management because that's an area that we've been looking at recently and licenses were/are a big part of that in an IT scenario. However, what might work would be to create a Legal area that references the licenses that are managed in the cost area. Can you think of other things that would go into the Legal area at the moment (to test this further)?

On your point about the License_Type, can we always assume that, e.g. all Microsoft products have exactly the same MS-EULA? i.e. are the terms the same? If so, then I agree that the License Type meta class needs to have additional attributes and is no longer simply an enumeration. If, however, each instance of an MS-EULA can have different terms, then I think the specific details need to be on the license instance.

Adding the license text makes sense - again pointing the fact that the License_Type needs to be a something other than an Enumeration (as long as any instance of, e.g. MS-EULA, has the same license text), otherwise, we will end up with a very long list of License Types!

Look forward to hearing your thoughts
Thanks

Jonathan
gioppo

My point was that I believe that you must divide the cost attributes of the class from the legal attributes (wheather they are enumeration or other) because maybe the same product can be present in tha same organization with the same licence, but different costs.
Is the same difference between contract and license.
The same Oracle product has the same license (that may change over time) but have different costs becouse I have in one case payed per cpu, but than made a new contract that is an "all you can eat for a bunch of money (usually much money ;-) "
The license of the product is the same, the commercial agreement and the price is different, but I may have two product covered by different "cost" instances, but the same licence_type instance
Dividing the two world can help having a higher degree of movement in mapping possible contexts.
On conpatibility, I'm sorry being italian I may have difficulties on understanding the little difference you were talking.
Sure we can say that if a licence_type is compatible with one (in legal terms) the relatinship should remain in the license_type class, is you place all the legal attributes there you should not have any problem with the license cost class.
Maybe you should rename licence in contract (so cost stuff is more correct) and licence_type in licence so that all the legal aspetcs fit well inside.
By definition the licence has nothing to do with money, but with rights do to with the stuff.
Contracts speak about money, contracts change in time (also licence, but at different times so +1 on separating the classes).
Hopes this explain better my idea.
jonathan.carter

Sorry for the delay in getting back to you.

This is all great stuff - exactly the sort of thing we were looking for in doing this ECP process. I think this has made the requirements a lot clearer.

It's interesting - just before you sent this, Jason and I were discussing your previous post and whether we should separate the legal and cost aspects of this. And your latest post has confirmed that we should.

I'll put together a revised solution and post it here. If that seems to work, I'll get the meta model update put together so that we can all start testing this.

Thanks very much for your input into this requirement

Jonathan
jonathan.carter

This is the latest version of the proposed meta model enhancement for ECP-1.
Image

Please click on the image to view it full size.

The main changes that have been made are as follows:
  • Moved the License class to a new top-level EA_Support class, Legal_Management
  • Created a new License_Contract class under Cost_Management, which includes the cost/deal details of an instance of a license
  • The approved_by attribute is now a reference to an extensible enumeration list of approval bodies for the license, e.g. OSI, FSF.
  • Compatibility between licenses is managed by the addition of an Instance slot on the License itself
These changes separate the legal and cost aspects of licensing - and each has a separate relation to the element that is being licensed.
Hopefully, if we agree with this meta model, the first implementation can be tested in the Essential Meta Model - using the sample repository to start with.

Thanks for your comments and thoughts

Jonathan
jason.powell

Looks good to me Jon.

I have been involved in a number of commercial negotiations for both products and services with a wide variety of licensing models and I believe that the model you have handles all of the use cases that I have encountered.

Great stuff :) .

Jason
gioppo

It seems really good.
It maps all the cases I had in mind.
Thanks
Luca Gioppo
jonathan.carter

I've just uploaded version 0.1 of the meta model extension and a sample repository to test out that what we've designed works.
In doing this, I have made a couple of updates to the meta model design (nothing big).

Here is the version that has been implemented:
Image


Download the meta model extension and the sample repository (with this extension applied) from the Share area

Meta Model Extension

ECP-1 Sample Repository

The meta model extension is a Protege Script Tab script that you should download and save to your workstation. Then, open Protege and open your Essential repository project.
Go to the Script Console Tab.
type the following at the prompt:
execfile("<full file path>/legalCostManagement.txt")
Note: the Unix-style '/' even on Windows.
Once the script has completed, you will see a success message, which means that the meta model extension has been applied.

Jonathan
jonathan.carter

Thanks to Mirek for pointing out the problems with capturing the difference between having a deal/contract that covers the use of a Technology Product for a number of instances, and the application of that contract to each of the instances.

One way to model this would be to define relationships from the Contract instance to both the (logical) Technology Product and the (physical) instances but we felt that there was a different relationship between the Contract and the Product and the Contract and the instances of the Product.

To manage this, I've added a relationship - contract_applied to the Contract class that enables you to relate the deployments of an element (e.g. a deployment of an application, an instance of a Technology Product). See the updated meta model, below:

Image

Also, to demonstrate how maintenance and support costs can be captured, there's an Annual Maintenance Contract_Attribute defined in the sample repository, which has been applied to the sample Contract.

Download the meta model extension and the sample repository (with this extension applied) from the Share area

Meta Model Extension

ECP-1 Sample Repository

The meta model extension is a Protege Script Tab script that you should download and save to your workstation. Then, open Protege and open your Essential repository project.
Go to the Script Console Tab.
type the following at the prompt:
execfile("<full file path>/legalCostManagement.txt")
Note: the Unix-style '/' even on Windows.
Once the script has completed, you will see a success message, which means that the meta model extension has been applied.


Jonathan
charugauri

We are using the Essential tool for our EA, and were attempting to model the license and contract information for our software using the license and contract classes under EA_Support.
In the case of our ERP, we have a single contract for the ERP product, but the licensing and pricing terms (such as max users/servers/CPU/license fee etc.) are separately defined for each functional area (such as HR, AP) provided by the ERP product. I was wondering how we can model this relationship?
jonathan.carter

Thanks for your post.

To reflect the different licenses that apply to the separate components, we capture these components as separate Application Providers, one for each of HR, AP etc. We then apply the license element to each of these separate components.
You can use the Application class to group these separate Application Providers into the 'ERP' Application.

For more background and details about this approach, please see this recent topic.

Jonathan
Post Reply