Software license management is a complicated topic, but knowing a little bit about its background can help you better understand ICOs, as the tokens being issued very much represent a form of license that floats across users and products.
Nothing wrong with that, in my view its quite the opposite, as you eliminate some of the legal hassles of buying equity in startups, but important fact nonetheless. Hope this article helps better understand what you might be buying the next time you purchase a token on a popular exchange or through a token crowdsale e.g. blocksquare — endorsement intended 🙂
What is software licensing?
A software license is a legal instrument (usually by way of contract law, with or without printed material) governing the use or redistribution of software. The software license usually answers questions such as:
- Where and how and how often can you install the program?
- Can you copy, modify, or redistribute it?
- Can you look at the underlying source code?
To activate a software product usually a license key needs to be entered to turn on the full set of features available in a software package.
For example, if you download a free trial version of a software, you may need to purchase and enter a license key to start using the full paid version. Activation may be done offline or, more frequently, online. If you want to stop using the software on one computer and start using it on a different computer, you may need to deactivate the license on the old computer before you can transfer it to a new computer.
Volume licensing agreements are usually made available by most major vendors in the commercial, government and education sectors, allowing organisations the opportunity to streamline their software purchasing, negotiate discounts, simplify software deployments, achieve management economies and easily maintain a software asset management program to ensure software compliance.
There is a number of different software licensing models currently offered by software vendors, including a number of emergent models.
1- Device — Also known as ‘machine based’. License is locked to an individual machine.
2- User — License is assigned to a named user who must be identified to ensure the license agreement is validated and the license terms are adhered to.
3- Networked (WAN & LAN) — A license that covers machines that is on the same network infrastructure. This is either in Wide Area Network or a Local Area Network format. Also known as ‘concurrent license’.
4- Subscription (user or device) — License only available during the period of subscription. No rights to use it pre or post agreement dates (unless agreement renewed).
5- ‘Cloud based credits’ subscription — Cloud credits are the unit of measurement required to perform certain tasks or rights to run certain applications provided by the vendor. Hosted in the cloud and are usually a subscription model.
6- General Public License (GPL) — License and software available for free. Allows users to use, share, copy and modify the software. Separate legal metrics to ‘freeware’.
7- Client Access License (CAL, includes both device and user metrics) — Allows users to connect to server software to use the software’s features/functions.
8- Capacity Based License — License is based on the capacity of the CPU/Hard Drive or other hardware configuration elements.
9- Font licenses — Font specific license. Related to the fonts used online or internally by an organisation.
10- Freeware — License requires no purchase but the copyrights are still held by the developer.
Token Licensing Origins
When you are developing a new system like Blocksquare, your mind tends to search for parallels to make better sense of what you are creating. So, when the notion of tokens being the equivalent of a software license came to mind, I immediately googled “token license”, and to my surprise, the first few results were links to an IBM community website from 2012.
As it turns out, IBM developerWorks offered a kind of token licensing option to provide greater flexibility to its customers. But the fact that IBM, one of the biggest corporations, offered a novel licensing model back in 2012, was actually not the most astonishing part of my research.
Further exploration of the topic lead me to this article. Published in 2008, the piece writes about Aspen Technology, a company providing software for heavy industrial manufacturing, and the unique way they allowed its customers to purchase its smorgasbord of applications trough tokens, akin to buying a prepaid cell phone card.
After you have purchased tokens from Aspen Technology, you could use them to license any of the company’s products. So if the engineering suite required 50 tokens per user, and the plant manufacturing suite was worth 20 tokens per user, and the supply-chain app was worth, say, 10 tokens, you could divide that up in any combination you chose. Pretty cool, ha?
Token as a License
Opposed to traditional licensing, token based licensing gives you the ability to “reuse” the same licenses for different products and when the need arises. As tokens are sold or purchased on exchanges, the license can easily change hands, so more users can use the software for a limited time. In a token environment, a product may
- require a predefined amount of tokens,
- consume a predefined amount of tokens.
The concept of Tokens as a License is already taking place. Ethereum for instance, consumes Ether tokens to perform different actions on the provided software. Because the consumed tokens are being transferred to miners, and because they carry value, we percieve Ether as a currency rather than a license.
Token licensing could be considered as the most flexible method of licensing. Tokens available on exchanges can be regarded as a maintained “token pool” of cross user licenses enabling users access to the right product at the right time. The users are able to obtain a license as long as sufficient unused tokens are available on the market. When someone stops using a product, he can choose to re-sell the tokens and make them available for someone else to utilize or hold the tokens for later use.
The model may become very effective for software vendors who have a wide portfolio of applications where the usage patterns of individual apps are difficult to predict. This situation often occurs in technical markets, where the portfolio of software is used in a design flow, or to conduct a software experiment. Users may not be able to predict how much software to purchase at the beginning of the purchase cycle as the usage of apps may be dependent upon the challenges in a particular design.
From the perspective of the software vendor, it’s also an effective way to fortress a market position against point-tool competitors. The token software license model makes it financially easy for the customer to utilize the entire portfolio of software, and not try to buy the best-of-breed for every part of a work flow.
Concurrent Token Licensing
When deployed as a token license, the software vendor, instead of creating a license key associated with a product, checks the amount of tokens on a user wallet which is then weighed toward the price list of the product. With the token licensing model, the customer needs to purchase a certain number of tokens that enable the use of the software or a particular app.
Consumptive Token Licensing
A pure-play consumptive token, like a gumball machine, is a “use it up” model. In this model, when a product runs it checks out a certain number of tokens which are then consumed and no longer available to the user. The tokens may be burned (destroyed) or simply pass hands, either go back to the software provider (token issuer) or go to a 3rd party providing a key service or action for the software provider. This type of software license model applies best when licensing software that is transaction-oriented, and the software vendor wants to charge based upon the total number of transactions.
Token licensing for blockchain software solutions
Let’s take a look through a practical example of a blockchain powered solution — Blocksquare.io
Blocksquare is a network of fractional commercial real estate property tokens (i.e. PropTokens), with a decentralised marketplace to buy and sell these tokens, and a platform to conveniently keep track of property performance and communicate with property management. It is also an application that enables certified partners to tokenize CRE properties without technical skill requirements.
Blocksquare participants are a very diverse user group, with needs to access different functionalities and applications within the system. The various user groups are: (1) certified partners, (2) property management companies, (3) property holding companies, (4) PropToken Validators and (5) end users.
Certified partners use Blocksquare to create and issue new PropToken contracts. They offer these services to local real estate professionals looking to sell commercial properties. To deploy a PropToken contract, a certified partner must use three apps: the PropToken Creation Module, the Holding Company Selector and the Management Company Selector. Each app requires a certain amount of BST tokens to be held on the specified user’s wallet account. For purposes of making an example, we can define the following token licensing structure:
- Creation Module → 200,000 BST,
- Holding Company Selector → 50,000 BST
- Managment Company Selector → 100,000 BST.
This in terms means, a certified partner would require to hold a total of 350,000 BST tokens to use the required product suite to be able to tokenise properties. The token license could also be split to separate accounts within a certified partner’s organisation. This could, for example, come in handy when a partner’s tokenization workflow divides tasks to separate departments.
On the other side, Property Holding Companies need to only be licensed to use the Holding Company Selector app. The app enables them to receive, evaluate and confirm new offers for title holding services. In our above example, the token license would require the company account to hold a balance of 50,000 BST.
Similarly, a Property Management Company would need 100,000 BST tokens to be licensed to use the Management Company Selector app — a marketplace for management companies offering services to the network of PropToken properties.
End users of the system may be given a tier based license, where entry level use would require no tokens, but higher level tiers would require certain BST token amounts to be held by the user.
As opposed to the concurrent token licensing for b2b users, end user licensing could be consumptive, requiring the user to pay for access to PropToken Generation Events.
With the regulatory environment still not providing a clear framework in almost all jurisdictions, we can not say for certain, how and if tokens can be regarded as mean for flexible licensing of blockchain based software solutions. In my personal view, the wider blockchain community should consider looking in this direction, as it may prove to be a strong point to clearly define what tokens are to regulators, as software licensing is already well defined by laws in most jurisdiction.
A brief lawyer’s perspective on TaaL
The issued tokens together with the smart contract and terms and conditions could constitute all elements of the license agreement. The license agreement is according to Slovenian law defined as an agreement through which the license provider undertakes to wholly or partly cede to the license acquirer the right to exploit a patented invention, technical know-how or experience, or a trademark, pattern or model, and the license acquirer undertakes to make a specific payment for such.
According to Slovenian law the license agreement must be concluded in a written form. Moreover the Electronic Business and Electronic Signature Act provides that the electronic form shall be deemed to be equivalent to the written form if the information in electronic form is accessible and appropriate for later use. I believe the blockchain technology could reach this standard, so the license agreements could be concluded in electronic form.
The nature of the token is crucial for the TaaL model. It is a question whether the token would be formed as a security or an identification paper or maybe something else? The main difference is that the creditor’s rights are not incorporated in the identification paper (token), so the license acquirer could exercise his rights also without such token. Practical use of such token is questionable. On the other hand a token which would carry a license acquirer’s rights would probably be subject to securities laws.
The license provider is obliged to deliver the subject of the license and is liable for the technical feasibility and the technical usability of the subject of the license. The token would probably not be considered as the subject of the license. This means that in the TaaL model the token issuer would have more obligations towards the token holders as we are currently witnessing in the ICO world.
The following legal aspect is relevant for the secondary exchange market. According to the Slovenian law either party to a bilateral contract may transfer the contract to a third person, who shall thereby become the holder of all the former’s rights and obligations deriving from the contract, if the other party consents thereto. In the TaaL model where the whole license agreement is transferred with the transfer of tokens the consent from the token issuer would be needed in order to validly transfer all rights and obligations from this license agreement to the new token holder. The consent could be given in advance along with the notification to the license provider about the transfer once the transfer occurs. Another solution could be that the acceptance of tokens by the token issuer is considered as an action from which it can be reliably concluded that token issuer’s consent on transfer of licence agreement exists. This means that the token holders would risk that the token issuer would at some point in time not give consent and thereby prevent the exchange of tokens on the secondary exchange market. Furthermore, the token seller (transferor) would be liable to the token buyer (transferee) for the validity of the transferred contract, which would probably be beyond his control.
According to the Slovenian law there is a difference in the TaaL model where only the license acquirer’s claims are transferred with the transfer of tokens. In this case the consent from the token issuer is not needed, but the token issuer (debtor) would need to be notified about the transfer of the licence acquirer’s claims. This means that the token issuer would need to be notified each time the token is exchanged on the secondary market. The token seller (transferor) would be liable to the token buyer (transferee) for the existence of the claims, which would probably be beyond his control. A clear advantage of this TaaL model would be that the token issuer could not prevent the exchange of the tokens on the secondary exchange market, as his consent is not needed for the transfer of license acquirer’s claims.
On the other hand rights and obligations from the license agreement could be transferred according to the rules of securities laws, depending on the nature of the token and the whole structure of the TaaL model.
The above mentioned points represent basic legal review of the TaaL model and just point out legal aspects and restrictions which need to be further analysed and addressed when constructing a TaaL model.
Token licensing has already some history behind its back and, with the adoption of blockchain technology and blockchain based tokens, it may become one of the most widely accepted licensing methods for decentralised applications.