Parsing ASTC's overly restrictive end user license

We've been reviewing the licensing situation for all the GPU texture formats Basis Universal supports. (This is basically every LDR GPU format in existence, so this isn't easy.) Most formats are covered by various open Khronos API standards and standard documents and have been fully documented in a variety of very permissive open source works and publications.

However, the ASTC reference encoder, documentation and specification has its own End User License Agreement, which I believe makes it unique. This license explains what you can and cannot legally do with the ASTC texture format. It's distributed with ARM's "astc-encoder" project on github:

https://github.com/ARM-software/astc-encoder/blob/master/LICENSE.md

At first glance, after a casual reading, you may think this legal agreement grants the end user permission to do basically anything they want with ASTC. Actually, it's very restrictive. There's *a lot* you can't legally do with ASTC.

Here are the key/core lines of the license that matter the most (anything in bold is by me). This is just a subset of the full license linked above:

THIS END USER LICENCE AGREEMENT ("LICENCE") IS A LEGAL AGREEMENT BETWEEN YOU (EITHER A SINGLE INDIVIDUAL, OR SINGLE LEGAL ENTITY) AND ARM LIMITED ("ARM") FOR THE USE OF THE SOFTWARE ACCOMPANYING THIS LICENCE. ....

1. DEFINITIONS

"Authorised Purpose" means the use of the Software solely to develop products and tools which implement the Khronos ASTC specification to;

(i) compress texture images into ASTC format ("Compression Results");
(ii) distribute such Compression Results to third parties; and
(iii) decompress texture images stored in ASTC format.

"Software" means the source code and Software binaries accompanying this Licence, and any printed, electronic or online documentation supplied with it, in all cases relating to the MALI ASTC SPECIFICATION AND SOFTWARE CODEC.

2. LICENCE GRANT

ARM hereby grants to you, subject to the terms and conditions of this Licence, a nonexclusive, nontransferable, free of charge, royalty free, worldwide licence to use, copy, modify and (subject to Clause 3 below) distribute the Software solely for the Authorised Purpose.

No right is granted to use the Software to develop hardware.

Notwithstanding the foregoing, nothing in this Licence prevents you from using the Software to develop products that conform to an application programming interface specification issued by The Khronos Group Inc. ("Khronos"), provided that you have licences to develop such products under the relevant Khronos agreements.

3. RESTRICTIONS ON USE OF THE SOFTWARE
.....
TITLE AND RESERVATION OF RIGHTS: You acquire no rights to the Software other than as expressly provided by this Licence. ...
....

What does all this legalese actually mean? First, note under "Definitions" that "Software" actually means astc-encoder, its documentation, and the Mali ASTC Specification. It doesn't mean just code, it means the docs and spec too.

As far as we can tell, this license means you can only legally use astc-encoder and the Mali ASTC Specification to compress texture images into the ASTC format to create Compression Results, then distribute these Compression Results to third parties. Then you can decompress texture images stored in ASTC format. That's it. Notice the key "and" word under Clause 1 (Definitions): "(ii) distribute such Compression Results to third parties; and".  It's not "or".

You can't do anything else with the "Software" (meaning the astc-encoder, docs, or most importantly the ASTC specification!), because those use cases have been expressly forbidden by Clause 3.

This license apparently forbids all sorts of practical real world use cases, like: real-time encoding textures to ASTC on end-user devices, transcoding from other texture formats to ASTC, compressing ASTC using a .CRN-like system and decompressing or transcoding that to ASTC, or processing or converting ASTC data at run-time.

You also cannot compress anything but "Texture Images" into the ASTC format, which is quite restrictive. If your input signal isn't a texture image, well you're out of luck (at least through this license).

Under Clause 2, there's this paragraph that feels crudely hacked into the license contract: "Notwithstanding the foregoing, nothing in this Licence prevents you from using the Software to develop products that conform to an application programming interface specification issued by The Khronos Group Inc. ("Khronos"), provided that you have licences to develop such products under the relevant Khronos agreements." 

So this basically means "in spite of what was just said or written, nothing in this Licence prevents you from using the Software to develop products that conform to a Khronos API, provided that you have licences to develop such products under the relevant Khronos agreements". However, there are many uses cases that don't involve directly calling a Khronos API. Basis Universal doesn't call any Khronos API's at all. If you are using a rendering API that isn't a Khronos standard, you're out of luck.

Thinking about this further, what actually is a product that "conforms" to a Khronos API? Is this a driver? I can't tell. Does a video game product, or a mapping product conform to a Khronos API? Even if you conform, you still need a license from Khronos.

If you develop a real-time ASTC encoder library or product that will be deployed on end-user devices that doesn't conform to a Khronos API (and have a Khronos license), you are not covered by this license. We think. Because this license sucks.

Another confusing issue we see with this license, under DEFINITIONS: "Authorised Purpose" means the use of the Software solely to develop products and tools which implement the Khronos ASTC specification". Then it says "in all cases relating to the MALI ASTC SPECIFICATION AND SOFTWARE CODEC". So is it the Mali ASTC Specification or the Khronos ASTC Specification? 

My guess is that ARM's lawyers weren't filled in on all the modern ways developers can encode, transcode, and manipulate compressed texture data. Also, the document feels rushed and it's obvious that no engineer involved with ASTC with experience reading legal documents has actually sat down and parsed this thing.

As the situation stands right now, you cannot do much with ASTC except encode it offline, distribute this data, and then use it on a device. If your product uses a Khronos API, you may be able to do more, but I can't really tell for sure.

The whole situation is very fuzzy for what is supposed to be an open, royalty free standard.

Note our IP lawyer is still reviewing this license document. (We're actually spending money on this - that's how serious this is to us.)

ARM's ASTC encoder patents - is it safe to write encoders for this format?

I put this on Twitter earlier. I found this very disturbing comment in the Arm ASTC Encoder:

/** *

@brief

Functions for finding dominant direction of a set of colors. * * Uses Arm patent pending method. */

Source code link.

Wow. I immediately stopped looking at this code and deleted it all once I saw this comment. I will never look at this code again in any way. So basically, ARM seems to be patenting some variant of PCA (Principle Component Analysis)? This is the first software GPU texture *encoder* I've seen that explicitly states that it uses patent pending algorithms.

ASTC is supposed to be "royalty-free": https://khronos.org/news/press/khronos-releases-atsc-next-generation-texture-compression-specification…
Yet, if I implement an ASTC encoder that uses PCA, will ARM sue us for patent infringement?

I was very excited about ASTC, but now it's totally clouded by this encoder patent issue. I cannot support a supposed "royalty-free" standard that apparently has encoder patents hanging over its head. We need ARM to fix this, to basically clarify what's going on here, and make a public statement that software developers can write encoders for its format without being sued because they infringed on ARM encoder patents.

You know, just to illustrate what a slippery slope encoder patents are and why they suck for everybody: We could have patented the living daylights out of our texture encoders, our universal codec, etc. It would have been no problem whatsoever. We could take this entire field and patent it up so tight that nobody could write a practical open or closed source GPU texture encoder without having to pay up. We could then sue for patent infringement any IHV's which ship drivers that implement run-time texture compressors, transcoders, or converters that use our patented encoding algorithms.

However we didn't want to ignite a texture encoder/texture compression patent war, and I'm very allergic to software patents.

The sad reality is, if the IHV's are going to start patenting the algorithms in their reference GPU texture *encoders*, we will have no choice but to start patenting every single GPU texture encoding and transcoding algorithm we can. For defensive purposes, so we can survive.

Taking this further, we could then turn this encoder patent landgrab into a significant part of our business model. These patents are worth several million each to the big tech corps during acquisitions. We could sell out our encoders and patents to the biggest buyer and retire.

Our defense to the software development community would be: "ARM started patenting their encoders first, not us. We needed defensive encoder patents to survive, just in case they sued."

After parsing the astc-encoder's license a few times, it appears we can legally use the ASTC specification to write our own 100% independent ASTC encoders and distribute the resulting compressed texture data. That's great. But if I go and write (for example) a BC7 texture encoder that accidentally infringes on ARM's encoder patents over their variation of PCA, I'm still screwed.

BTW - The author of the "Slug" texture rendering library has started to patent his algorithms. (I only point this out to show that it's very possible for a tiny middleware company to easily acquire patents.) Personally, I'm against software patents, and I hope ARM fixes this.