Apr 19, 2018 - 01:22 AM
Source: Richard Spithoven - B.lay The License Management Company
Apr 19, 2018 - 06:07 AM
There are essentially two core business models in use by many publishers, especially these major publishers. End User and Original Equipment Manufacturer (OEM).
End user models at one point in time were easy to categorise, especially before the web became mainstream. These were applications that typically ran directly on a desktop, or accessed via an intranet with no external access. These for the most part were much easier to control and audit if managed by the IT department. If end users procured their software directly then copying was relatively easy until Installsheild and similar tchnologies were created. IT departments are more savvy these days.
OEM usage is a different problem. I have worked in and around the OEM Software business for a couple of decades and the principal problem with this business model is traceability for the purposes of paying royalties. Why is this different from a typical EULA model? Well, if you sell into or procure using an OEM business model then the risks for 'miscounting' copies goes up because the licensor is actually granted rights to duplicate, and build derivatives of the original technology for the purposes of embedding in a product (hardware/software) that is redistributed under a proprietary EULA not the publishers EULA. In addition, for the purposes of mass 'reproduction' the publisher's entitlement mechanisms are often removed and replaced by proprietary methods. All of these rights etc. are outlined in the OEM-In license & other contract terms but not always easy to manage. Also where compensation for the software to the publisher is concerned the fees are typically paid AFTER the software is deployed and so different financial requirements have to be adhered to. So in a manufacturing environment (a typical OEM licensing scenario) different policies and practises are needed to manage the complexity of third party software use. This can be futher complicated by having common suppliers for in house EULA type usage AND OEM style re-distribution usage using a proprietary licensing model that might not equate to the publisher's model.
By now you are probably saying - but Steve what has this got to do with my Java question? Well let me see if I can connect the dots here...
First, large behemoth companies like Oracle and Microsoft etc. have pretty much saturated the market for their core products. The only way they can continue to keep shareholders and employees happy is by maintaining and growing revenue which is hard in a saturated market. These companies are also seeing competition from Open Source texchnologies. Additionally they are investing in technology improvements and advances that cost money so they need an appropriate compensation model (as we all appreciate). When your original business model (pre subscription) essentially locks you out of increasing revenue from existing customers then you resort to other means and an audit is one of the natural by-products. Additionally, post acquisition, most major companies will initiate an audit campaign simply because they "need"to understand the business they have acquired - and most audits will turn up license violations: easy revenue! Regarding Oracle and Java check out this article:
Oracle finally targets Java non-payers - six years after plucking Sun Microsystems
One of the companies I used to deal with "a lot" in the past was Sun Microsystems. Sun invented Java and had a very interesting business model that most people are not completely aware of. Sun as a company was very shrewd in many ways. When they invented Java they wanted to beat Netscape (remember them?) to the punch to be THE internet company. Java was the first ubiquitous technology for deploying applications and Sun wanted to own the market. They did this by creating "free access" - not to be confused with Open Source - to Java to drive development dependency and get deployment on a massive scale. They did this using their Community Source license (which later was joined by an Open Source version which Sun also managed to create a tight licensing context around using its ownership of the TCK). The key to this license (and the business model for Java) was that it restricted the use of the Commercial use of Java. Key to the Java SE licensing terms is this phrase...
"General Purpose Desktop Computers and Servers" means computers, including desktop and laptop computers, or servers, used for general computing functions under end user control (such as but not specifically limited to email, general purpose Internet browsing, and office suite productivity tools). The use of Software in systems and solutions that provide dedicated functionality (other than as mentioned above) or designed for use in embedded or function-specific software applications, for example but not limited to: Software embedded in or bundled with industrial control systems, wireless mobile telephones, wireless handheld devices, netbooks, kiosks, TV/STB, Blu-ray Disc devices, telematics and network control switching equipment, printers and storage management systems, and other related systems are excluded from this definition and not licensed under this Agreement."
This language has always been a bone of contention in my dealings with Sun (and subsequently Oracle) and has improved dramatically from what I originally dealt with. Most people download the Java SDK or RTE and then develop an app on it. This is OK and free if you don't redistribute the RTE or SDK. The app can be redistributed without royalty. However if the SDK/RTE changes and your development of the app or usage of the app has a dependency that results in the need to re-distribute the JDK or RTE then you need to talk to Oracle because this has the potential to be a commercial use case and come at a cost. This is a similar model to MySQL and other technologies that a lot of engineers and end users perceive to be "free" but have subtle licensing terms.
The Open Source TCK limitation is the revenue lock in for Oracle. All versions of Java have to conform to the Technology Compatbility Kit (TCK) or the implementation can't be called Java or guarentee that a java app will execute successfully.
Five Years of open-source Jave: Freedom isn't (quite) free
Oracle and Microsoft and other companies also have and encourage large developer communities. Developers typically have free or discounted access to the core technologies from these companies to try out new features and target new product releases. These can sometimes find their way into production if a company doesn't have strict policies and processes for managing this.
Linking back to the OEM and EULA models. As most companies have become more sophisticated and the web evolved to facilitate some creative and advance technology uses, so the lines have blurred between what is a typical IT or EULA scoped software usage, and what is an OEM style usage. The clearest example of how this manifests itself is with the recent SAP - Diageo dispute. Diageo clearly thinking in "Traditional" EULA software licensing terms and NOT considering the OEM usage they were starting to adopt.
As soon as ANY company enables access to their ERP systems from non-employees via an internet connection either directly OR indirectly then that company has probably stepped out of a EULA licensing model and into the twilight zone of OEM publisher.
I apologise for the length of this response but to wrap up.
Note: web services can be reverse engineered, to some extent, so its not beyond the realm of possibility that SAP and others can web crawl to servers to check if their technology is being used. This can help an audit department target possible violations.
In Summary - large software publishing companies need to keep the cash flow going. All you can eat (no such thing really) or enterprise wide licenses don't always prevent audits - no contract is that watertight sadly. Not every use case in today's modern corporation should be thought of as traditional "End User" and therefore may not be covered by standard EULA terms or an IT style license. Integrations between REST based web services and other cloud applications may create futher audit risks. Lastly, Open Source is NOT your friend here either and should not be ignored.
Governance is key and unless a company has solid Policies, Processes and "relevant" tools to effectively inventory and track software use then at a minimum, they should have an effective Audit response policy and team - they will probably need it!
Apr 25, 2018 - 07:55 AM