Game Licenses

From K.R. Engineering Support Wiki
Revision as of 23:52, 17 January 2019 by Karsten (Talk | contribs) (So the games are now copyable, but not really copyable?)

Jump to: navigation, search

K.R. Engineering Game Licenses in Second Life

What games need licenses?

All of our games in Second Life are licensed, and always have been. However, starting in June of 2018 this licensing system has become more prominent and more obvious to game owners as a result of a permissions change from TRANSFER-ONLY to COPY-ONLY. The information presented on this page largely deals with why that change was made and what the effects of it are compared to the older system. Prior to June of 2018, our games still had a licensing system, but it was less obvious to game owners because it was secondary to Second Life's own builtin licensing system ("permissions"). Our licensing system has now moved up to take the primary position of controlling how our games are used in Second Life.

What is the difference between the old licensing system and the new licensing system?

Second Life has a builtin licensing system known as "permissions." A creator can set forth in the permissions of an object what they wish to allow licensees (customers) to do with their product. The permissions that Second Life allows are Modify, Copy, or Transfer. These permissions can be selected in most, but not all, possible combinations. For example, you MUST have either COPY, or TRANSFER. You can also have both COPY/TRANSFER, but you can't have neither. It must be one, the other, or both.

Before: In the past, our games have been TRANSFER/NO-COPY. With these permissions, Second Life itself would only ever allow you to rez a single instance of the game. It was enforcing "one purchase equals one instance of the game" up front with the builtin permissions system. Our own licensing system still allocated and assigned a license key to your game, but this was largely only used for tracking game activity in our own database and verifying ownership. You may have noticed when rezzing a new game (or an update to an old game) that it would say "Obtained unique Gaming.SL ID for this game." That was the licensing system assigning a license key to your newly rezzed game object.

Now: As of June 2018, our games now have COPY/NO-TRANSFER permissions. With these permissions, Second Life takes a backseat and does not enforce "one purchase equals one instance of the game" on its own. The COPY permission built into Second Life allows for infinite copies of a purchased object to be made. As a result, our licensing system has stepped up to enforce this. While you can rez infinite copies of our games, they will refuse to let you play them unless you have purchased sufficient numbers of licenses for the amount that you have rezzed.

So the games are now copyable, but not really copyable?

In-world licensing information on vendors. Click to enlarge.

In effect, this is true. They have copy permissions now instead of transfer permissions, but the extra licensing that we put on top of Second Life's own licensing system means that it is still "one purchase equals one instance of the game." It is kind of a hybrid between TRANSFER-ONLY and COPY-ONLY, with some aspects of both.

We realize this may seem confusing at first, and may go against your initial expectations for what "copyable" means in Second Life. This is why we have gone to great length to explain our system up front before you make a purchase. We include the licensing information on all of our Marketplace purchases (where permissions are marked as "LICENSED / SEE DESCRIPTION" so you know it is different), as well as including this information on every applicable vendor in our in-world store. (see picture on the right).

Why did you change all of this?

Creators in Second Life have been asking for a more granular permission system since Second Life first opened, but this has never happened. The permission system we are using now is the same one that Second Life opened with in 2003. As a result, some creators have taken to using secondary layers of licensing control to augment the basic one that Second Life has.

Second Life's permission system is overly simplistic and offers no comfortable middle ground between "everything is permitted" and "nothing is permitted." There are pros and cons to each option with the Second Life permission system, and it often boils down to having to make 1 out of 3 terrible choices. To understand why we use an additional licensing layer, it is necessary to look at what 3 options are available to us WITHOUT an additional licensing layer.


This is the term for an object that has the TRANSFER permission enabled, but the COPY permission is disabled. This is the way our games used to be setup before June 2018. A transfer-only object can only be rezzed a single time once purchased. While rezzed, the object is removed from your inventory and placed into the world. This effectively enforces the "one purchase equals one instance" rule, but it also comes with tremendous downsides. The biggest downside is potential loss of inventory. There are dozens of ways that a transfer-only object can be lost permanently, such as...

  • You may accidentally delete the inventory folder that it is in without realizing it.
  • The sim you rez it on may crash after you rez it, resulting in the loss of anything that was recently rezzed on it.
  • You may try to rez the object, but it gets lost between your inventory and the sim (errors such as "failed to rez", "not found in database", etc.), and is now gone.
  • Your object may get returned (evicted) by the owner of the land you rezzed it on.
  • You may leave the object rezzed and then forget where you left it.

These are just SOME of the most common ways for residents of Second Life to lose transfer-only inventory items.

As a result of the ability to lose transfer-only objects, around 90% of the customer service issues that I had to deal with on a daily basis from the old system were inventory loss problems. This is very frustrating for us, because it consumes a huge amount of time that could be spent making new things or fixing bugs. It's very frustrating for customers because they have lost an expensive purchase and often do not understand why, and are not sure whether they can get a replacement or not. In most cases, we can and do make replacements for these situations because we value our customers, but it is unnecessary stress and a waste of time for everyone.

Transfer permissions have also resulted in our games being extensively pirated (using loopholes to make copies of them, even though the COPY option is disabled, see the Piracy in Second Life), and then selling them as "used" games on Marketplace and in-world.


This is the term for an object that has the COPY permission enabled, but the TRANSFER permission is disabled. The biggest benefit of copy-only permissions (for our products) is that it is very difficult to ever lose an item that you have purchased. When you rez a copyable item from your inventory, not only does it appear in-world for you to use, but also stays in your inventory! This means all of the most common ways that you can lose a transfer-only object are protected against, because you always have a backup copy in your inventory no matter what happens to the one that you rezzed.

And in the event that you accidentally delete a copyable item from your inventory, you can always get it back immediately by visiting the store and using the REDELIVER terminal to recover past purchases. REDELIVER terminals are not possible on transfer-only objects, because it effectively gives them COPY/TRANSFER permissions (discussed in the next section below) by allowing infinite copies of a transferable object.

So that sounds like a great benefit to copy-only, why don't we just use that? The reason is because there is no middle ground between "making 1 copy" and "making 1000 copies." If we sold our games with copy permissions, that means 1 person could rez thousands of our games all over the grid for free. "one purchase equals infinite instances" is not a sustainable business model for games. Imagine if you bought a video game for yourself, or an app for your phone, and by virtue of you buying it everyone you knew got free copies of it as well. Rather than purchase their own copy of one of our games, someone could just say "Oh, my friend GamerBob already has one of those, I'll just get him to rez a copy for me at my house too." We would in effect have all of our customers competing against us, but they're giving away our games for free to other people, and we're asking for money. That's not a functioning business model.

A real example of this: We have had multiple landlords ask us for copyable versions of Greedy on the old system (which we refused) so that they could rez "a complimentary copy of Greedy" at every single property they rent on the entire grid, to make their rental properties seem more valuable to prospective tenants, but leaving us with no payment for all of those copies.


This is the term for an object that has the TRANSFER permission enabled and also has COPY permission enabled. This option is the worst of all, because it means not only can customers rez infinite copies of the games they buy, it means they can also give away (or sell) infinite copies of our products to anyone they choose. This means we can not functionally run a business, because every customer is also a competitor to us, profiting from all of our hard work but having none of the time commitments or costs.


This is where our own custom licensing system comes into effect. We love the benefits of COPY permissions (no inventory loss), but we also need the benefit of TRANSFER permissions (one purchase equals one copy) to have a sustainable business model.

By giving our games COPY permissions in Second Life, but also requiring the games to have an additional license for each running copy, then we get the best of both worlds! We get no inventory loss, and we also get control over how MANY copies of the object are used.

What if I still have questions or concerns?

Please contact Karsten Rutledge in Second Life or send an email to with any questions you may have after reading this article.