*** Please be aware that since this article was published, Abbott have issued a DMCA take down notice to GitHub to remove the linked repository so this is no longer available ***

Last week, I posted a link to a github page on Facebook and Twitter, providing details of how to patch the LibreLink app on Android to allow it to present the output it produces to other apps for display. That link was:

https://github.com/user987654321resu/Libre2-patched-App

Unfortunately, Abbott saw it fit to issue a DMCA take down notice to Github to cease making this available. As the github repo never contained any of their app code and wasn’t distributing it, this seems a little unfair.

Following that announcement. there have been multiple questions about what it does, how it works and whether it is legal. Here I hope to answer many of those questions and reduce the FUD that’s being spread in relation to this product, given how it competes with existing third party add-ons that are already on the market.

Okay then, what does it do?

The github repository contains code and instructions for an Android LibreLink user to extend the LibreLink app to pass the glucose values that it interprets from the data it receives over bluetooth from Libre2 out to another listener app. It effectively creates an external interface for the LibreLink app. 

To be very clear here, the output is not the raw data from the sensor, rather it is the output of the Abbott algorithm that “doesn’t require” calibration. 

xDrip has been updated to include a receiver for this data and is then able to use it as it would any other CGM source. There is a calibration option for the data within xDrip, but it only allows calibration within 20mg/dl.

That’s essentially all there is to it. 

I’ve got that. How does this work then?

Essentially, what you are doing when you are adding the patch to the code is adding a small, precise incision to the app at the point where the values are generated to create an interface to distribute them out to a receiver app instead of just providing them to the alarm functions within the application. 

But doesn’t this affect the copyright?

***Please note that this is not a legal opinion. I am not a lawyer***

Perhaps surprisingly, this seems to be covered by the European Software Directive in article 6 which was implemented in member states years back, which allows for decompilation of the code by a licensed user in order to enable interoperability with another application (xDrip in this case). 

1. The authorisation of the rightholder shall not be required where reproduction of  the code and translation of its form within the meaning of points (a) and (b) of Article (1) are indispensable to obtain the information necessary to achieve the interoperability of an independently created computer program with other programs, provided that the following conditions are met:

(a) those acts are performed by the licensee or by another person having a right to use a copy of a program, or on their behalf by a person authorised to do so;

(b) the information necessary to achieve interoperability has not previously been readily available to the persons referred to in point (a); and

(c) those acts are confined to the parts of the original program which are necessary in order to achieve interoperability.

2. The provisions of paragraph 1 shall not permit the information obtained through its application:

(a) to be used for goals other than to achieve the interoperability of the independently created computer program;

(b) to be given to others, except when necessary for the interoperability of the independently created computer program; or

(c) to be used for the development, production or marketing of a computer program substantially similar in its expression, or for any other act which infringes copyright.

3. In accordance with the provisions of the Berne Convention for the protection of Literary and Artistic Works, the provisions of this Article may not be interpreted in such a way as to allow its application to be used in a manner which unreasonably prejudices the rightholder’s legitimate interests or conflicts with a normal exploitation of the computer program.

Or in other words, if you were to decompile and modify LibreLink yourself in order to provide an interface for the data that it creates which is not readily available from the app already at a programmatic level, then you appear to be covered by this clause of the directive.

You as the user of LibreLink for Libre2 have signed up to the license, and that license is not allowed to stop you doing the following under this directive, as stated in paragraph 16 (emphasis mine). 

Protection of computer programs under copyright laws should be without prejudice to the application, in appropriate cases, of other forms of protection. However, any contractual provisions contrary to the provisions of this Directive laid down in respect of decompilation or to the exceptions provided for by this Directive with regard to the making of a back-up copy or to observation, study or testing of the functioning of a program should be null and void.

At the same time, it’s very clear from the directive that if you were to undertake the patching process and then make the patched app available to others to use, you’d be breaching the copyright of the original software. 

So what about things like MiaoMiao, Droplet, Bluecon, etc?

That’s a very good question. Let’s ensure we’re clear on a few things in relation to these systems first:

1. If you want the raw sensor data, rather than that which has been processed by Abbott’s algorithm, then you have no choice but to use one of the third party add-on transmitters;
2. If you want to use a watch as a collector, this process doesn’t allow you to do that, so you’ll still need a transmitter, and;
3. If you want to use Spike on an iPhone, this process isn’t going to work for you, and guess what, you’ll still need a transmitter.

Okay, so now we’ve cleared that up, what about the legality of creating and distributing third party transmitters?

Well there’s an interesting question in itself. The original Libre provided data in an unprotected form that could be read and transferred to an app to interpret the data. Effectively the hardware that was being produced was simply using standard NFC protocols to pass data between two devices. 

With the advent of Libre2, the data is now encrypted, which changes things slightly, as in order to create an interface, you need to break the encryption.

Now if you were to do this yourself, then you’d be fine, based on the previously discussed article, however, if you redistribute the code to do this as an app or device, then it seems to be a bit of a grey area as to whether this is now in breach of the directive, and I’d not be confident that it wasn’t, but as I’ve said, I’m not a lawyer.

Where does this leave potential users?

If what you’re looking for is an app on your Android phone that turns the Libre2 into a source of real-time glucose data using the Abbott non-calibrated algorithm, then it looks as though undertaking the process defined yourself in order for your independent application to use that data looks fine. 

If you want to get the data on another device, then this isn’t going to work, and if you choose to use another device to enable that, it’s questionable whether breaking the encryption and then selling the app/device to do that fulfills the rules in place.