Skip to main content

 

https://www.linkedin.com/pulse/what-happened-sonos-app-technical-analysis-andy-pennell-wigwc/

 

What happened to the Sonos app? A technical analysis

 

 

Andy Pennell

Principal Software Engineer at Xbox, Microsoft

 

July 6, 2024

On May 7th, 2024, Sonos, the successful home-audio company, released a new mobile app. This had been hyped in the press and was going to make product setup easier and greatly improve the user experience. However, when the app was actually released, it was, and somewhat remains, a disaster. As a certified Sonos fanboy/hacker/almost-employee I'm going to try and explain what happened, as best I can based on my reverse engineering skills, honed over the last decade and more of creating independent Sonos apps.

How The "Old" App Worked

Sonos speakers have been the Gold-standard UPnP device since their creation. I remember around 2005 the lobby to Microsoft Building 50, which was the home of the Windows Media Division at that time, was completely full of boxes of Sonos devices. It was being used as the definitive test device for the engineers adding UPnP support to Windows.

Every Sonos device on the network (which nowadays can be Ethernet, Wifi or SonosNet, their proprietary wireless network) exposes many UPnP services in the standard way, and can be found via the SSDP discovery process. There are around 200 individual APIs exposed via their UPnP services, though you can write a fully functional Sonos app using less than half of them. UPnP calls are SOAP calls over TCP, sending and receiving xml. SSDP works via UDP broadcast and multicast. All of this works very well, the common problems customers have with device discovery (changing IP addresses, inability to route between 2.4GHz/5GHz devices) are usually solved by fixing router settings or, occasionally, replacing a router with something better.

Sonos devices also use an interface known as SMAPI to communicate with third party music services. This standardization means that the onus on adding a music service to a Sonos system is on the music provider, which has allowed Sonos to support over a hundred music services, something no-one else has come close to. The app uses SMAPI to find and enumerate music from a provider, and the speakers themselves use SMAPI to stream the music and share with other speakers in their group in real-time.

The SMAPI interface is reasonably well documented (well, it was until last year), but the Sonos UPnP APIs have never been openly documented. Fortunately, UPnP is a self-describing interface so any decent tool can show you the APIs and let you experiment - I use Intel's UPnP Spy to do this. As traffic is in the clear, network traces can reveal exactly how the app uses these APIs to find and playback music.

A third API set for Sonos is their cloud API: this has been around for around five years, and is somewhat documented. However it's never been rich enough to write a decent app: it was designed for music service integrators (think Spotify Direct), not app creators. It offers basic transport control but no way of enumerating music, unless you are also a music service provider.

How The "New" App "Works"

For the new app, Sonos threw out all of the old app code, a "clean slate" approach, replacing the front-end (the UX everyone loves to hate) and also the back-end (that actually communicates with speakers and music services).

Device Discovery

When the app starts, it must find your speakers as a critical precursor to anything else, but for some inexplicable reason they decided to drop SSDP and rely entirely on mDNS for device discovery. I don't know much about mDNS (as my own Sonos apps have never used it), but evidently this new way of finding speakers on the network has proven hugely problematic. My reading of how mDNS works is that it should suffer from similar problems to SSDP on routers that can't broadcast/multicast between radios, but it shouldn't offer new problems. But evidently it does: the huge amount of users who had perfectly working systems that suddenly had no devices found in the app shows that either mDNS is not a reliable discovery system on many home networks, or their code has some gigantic flaws. Me? I'm fine, my carefully-configured Ubquiti network has never had a problem with the new app finding my 15 Sonos devices. Others have not been so lucky, and right now, two months after the new app's release, something still stinks in the Sonos device discovery code, based on Facebook and Reddit anecdotal data.

App Performance

The old S1 app, which I am very familiar with (details later), used the native UX frameworks of the devices, ported to each platform. So Windows used WPF and the other platforms used whatever the "normal" UX frameworks were at the time. This gave solid experiences on all platforms, but obviously at substantial cost: every new feature in the UX had to be implemented in four different UX codebases. (The back-end was C/C++ and shared between all of them). For the new app, Sonos decided to use the same front-end on both mobile platforms so went with a Javascript framework (I try not to follow JS-UX-frameworks-du-jour so can't say which) so the UX code would only need writing once. (The Windows/Mac apps have been feature-frozen since the S1 split so no chance of their UX changing). I'm not sure how much of a performance impact the UX framework has on the app (that's not an area I know too much about), but a change that has clearly had a notable impact on app performance is the back-end change, moving away from UPnP.

Network traffic with the new app is all encrypted, so a definitive analysis will take me a lot more work and time. However, my most educated guess based on what I see in the traces is that the speakers now expose a version of the Sonos cloud API, but on the local network. In addition eventing, which used to be UPnP based (essentially you run a simple http server in the app and it gets calls from the speakers when an event is sent) is now based on a websocket.

As all traffic is now encrypted, it takes more CPU cycles for every network call: client encrypts it, sends it (TLS is a lot more chatty), and the speakers have to decrypt it before they can do anything. Even if the API was still UPnP under the hood (which I don't think it is), the crypto overhead is going to be a challenge on the older Sonos devices, which have tiny amounts of RAM (as low as 64MB compared to 8GB of the latest Sonos devices) with a similar disparity in CPU power. Also the cloud API is more "chatty" than the UPnP API, multiplying the network overhead.

The best example of how bad this can be is the Device Volume UX: in a group of, say, 8 speakers, you can pop up the device volume panel, which will show all 8 device volumes, along with the Group volume. (Group volume is a weighted average of every device volume). Users like to drag volume sliders all over the place, but in a Sonos group this generates a cacophony of volume-changed events: changing the group volume will change the volume on every device, and every device will send an event back declaring its new volume. As many volume changes can be generated per second with a user's finger, and the fact that the event ordering is not guaranteed, it takes great care to get this UX smooth and responsive. This is the one area of my own Sonos apps that I fear the most: I never want to change any of the volume UX code. Sonos even publish recommendations on how to deal with this problem at https://docs.sonos.com/docs/volume. Seemingly they did not follow their own advice with the new app's volume control, and the switch from UPnP events to websockets seems to have made things a lot worse.

The New User Interface

I'm not going to rant about this too much, I know from decades in the business that you can't please all the people all the time, especially when it comes to UX. Also glass houses: my apps have not been renown for their glorious UX. However I have an iPhone SE 3 and that means I only get a tiny amount of vertical space in the new app to select music, plus I hate sliding UX as the iPhone likes to pop its system UX up when I do this. I always use my own app to select music anyway, I love the huge 4K display on my PC.

Can it get better?

Sonos have been mostly in denial as to how bad things are, with the app release officially described as "courageous" - well, pissing off a sizable chunk of your existing user base could be called that, I guess. An immediate revert to the old version would have been my suggestion.

Also thanks to the device discovery problems, not only are existing users frustrated with the app not working, but new users who get their shiny Sonos device out of the box and then can't get the app to work are just going to put it back in the box and return it.

The new app shipped with a lot of features missing from the old app (never a good idea), but over the last two months some of those features have returned in various updates. However Queue management is still AWOL, and that was a key Sonos feature. (It's also a UX challenge, handling a list of over 30,000 items that can change at any time in a performant way).

While device discovery remains a crapshoot for many the app store scores are likely to stay in the 1.0 range that they have fallen to in the last two months.

Options

As many have discovered, the Sonos speakers themselves are still working fine, despite the contrary impression the new mobile apps may give. You can verify this by using the official Desktop apps (which are feature-frozen), or third party software like SonoPhone (for iOS https://apps.apple.com/us/app/sonophone-for-sonos/id815251931) or my own Phonos Universal (for Windows/Xbox https://apps.microsoft.com/detail/9nblggh4x6j0). All of these apps use the UPnP APIs, which still work great, for the moment anyway. However, Sonos have stated that they want to deprecate their desktop apps at some unspecific point in the future. If they do, they can then remove UPnP support from the speakers, killing the entire third-party ecosystem built around their products. That would be "courageous" indeed.

About Me

I've been a Sonos customer since the CR100/ZP100 released and been reverse engineering it since shortly after it arrived. My Sonos app for Windows Phone was one of the most successful employee-made paid apps in the store and had over 200,000 downloads. I worked with Sonos on Phish, the official Sonos app for Windows Phone 8 (never released). I was so impressed with Sonos engineering I applied for a job there and got an offer to join their Seattle office, but I declined, because reasons. I live in NetMon.

Views expressed here are my own, and not those of my employer, Microsoft Corp.

@press250: What you describe sounds like a pretty cumbersome process. I had thought —utterly clueless about such things as I am — that the same or similar processing involved in ‘trueplay’ could assess amplitude during the first moments of a track and adjust it to a predetermined norm before the remainder of the track is played.

Of course I have no idea precisely how that would be accomplished, but it would be a neat trick and a lot more essential to music playback than the many other buzzers and bells on offer… like ‘Alexa, play Kick Out The Jams by the MC5.’

I mean really now. When I reach the point that it’s too much effort to pick up a device and tap an icon to play music… just dig a hole, toss me in and throw dirt on it. 


@press250:...

I mean really now. When I reach the point that it’s too much effort to pick up a device and tap an icon to play music… just dig a hole, toss me in and throw dirt on it. 

Lazy and proud am I. Voice activated speakers is the whole point.


I’m not that fanatic about voice control, except for when cooking.  I use it almost exclusively when my hands are cutting up a chicken or stirring something on the stove and can’t pick up a device.  Then it is irreplaceable.


@press250: What you describe sounds like a pretty cumbersome process. I had thought —utterly clueless about such things as I am — that the same or similar processing involved in ‘trueplay’ could assess amplitude during the first moments of a track and adjust it to a predetermined norm before the remainder of the track is played.

Re-stating for clarity @chambolle: the entire process is automatic, but it does need to run in advance. Determining “I’m this loud” is tricky in the sense that human perception is involved. There are standardized algorithms that are acknowledged to produce good results.

My main work computer runs a fabulous music library program called Audirvana that optionally performs “volume levelling” and it works great! Every time I add a new album to my local library, Audirvana runs the aforementioned “I’m this loud” algorithm and saves the result. Playback is automagically adjusted and It Just Works™️


Wow, this thread is skipping around quickly! In just over one page we’ve gone from invaluable technical background on Sonos’ new app to voice control and volume levelling! :)

Yes, I know I contributed…!

 


I’m not that fanatic about voice control, except for when cooking.  I use it almost exclusively when my hands are cutting up a chicken or stirring something on the stove and can’t pick up a device.  Then it is irreplaceable.

Voice control of my smart lights is all i use really, great for turning whole room off/on with 6 bulbs in 4 fittings


Back on the original topic here, now I have found it thank you @press250 ….

Just wondering out loud here - it seems to me both from this topic and as @Allen J Goldberg and others have surmised, Sonos have changed direction.  Ignoring whether that works out for them or not, is there an opportunity here to get the ‘old’ system enabled by a third party.  Most of it is there - the issue seems to be rolling back the firmware.  Has anyone any idea if that is technically possible (ignoring legal issues for the moment).    I could imagine an aftermarket for rolling back, possibly even for current new devices to 16.1 firmware.   If thats possible then the app we know can be made available by a third party (again parking legal issues).   Both would be easier with Sonos ‘approval’.     

Since Sonos seem to have backed themselves into a corner by refusing to rollback, maybe there is a business opportunity for someone to give them a way out.   Might even be a competitor?   Since they are clearly no longer interested in “local based music Library’ systems.   I have thought for years that they have been struggling with “home Theatre’ v “Audiophile’, add in “streamers” and “moblie” and then ‘headphones’, well this could be an opportunity for them to ease their pain,  From the technical backend descriptions to the UI they are clearly in the “Jack of all Trades Master of None” category.   At least this way they could have a legacy brand that can play music reliably (or at least as reliable as it was).

First step is it technically feasible?  Then it becomes a business decision.   


@DSLA 

”Ignoring whether that works out for them or not, is there an opportunity here to get the ‘old’ system enabled by a third party.  Most of it is there - the issue seems to be rolling back the firmware”

While your suggestion sounds like a good idea….remember there’s this stumbling block to fully implement an identical clone (or Lazuarus revival) of the recently jettisoned Sonos OS called “patent infringement”. 

I’m not talking SonoPhone nor Google who finally won in a reversal for allegedly cherry-picking certain features as was brought by Sonos legal.  


Hi @DSLA, it is technically feasible to install a bespoke (say, v16.1) version of firmware; downgrading to S1 does exactly that.

It is not entirely clear to me what the v16.1 firmware would accomplish. That version was already ‘bilingual’ in that it supported the old APIs (legacy desktop apps) and the new APIs (new mobile apps). The v16.2 firmware was a modest update* that was released hot on the heels of the new mobile apps to fix the alarms-cannot-be-edited snafu. The v16.2 firmware remains bilingual with respect to the old and new APIs.

Re-stating for clarity: the bilingual v16.2 firmware works with the old APIs—used by the desktop apps, SonoPhone/Pad apps, sideloaded v16.1 Android app—and the new APIs used by the new mobile apps.
If someone was set on tilting at the windmills of a Sonos The Way It Was™️ app, the v16.2 firmware supports such a quest.

 

* There is at least one, uhh, inadvertent tweak in the v16.2 firmware: it kills device support for SMBv1


I’m pretty sure that the Sonos devices check the digital signature on any file you try to load. Faking that is about impossible.

If you grab a copy of the signed Sonos software and distribute it you might expect a call from the Sonos legal folks. I have seen mentions of folks hosting the older software and allowing downloads, no clue how Sonos is looking at that.

Now if you could get past the software loading issue there are a lot of possibilities.


I’m pretty sure that the Sonos devices check the digital signature on any file you try to load. Faking that is about impossible.

Hi @Stanley_4, one imagines that Sonos devices “call home” for any firmware update. While one never know with anything running Linux, I’d be surprised if there was any path to sideloading. So I agree with you 100% that any firmware install requires the full support of Sonos.

As noted in my post above, it seems to me that the existing v16.2 firmware would be a copacetic choice for a would be Don Quixote.


Thanks @press250 - I suggested 16.1 as I stuck with that and dont know whats new in 16.2 because I had a very old SMBv1 server that runs both an S1 (which requires that) and S2 system.  Bought a new NAS now, but still not upgrading anything !

I  am also well aware of patents @AjTrek1 and legal issues on doing this (hence my caveat).   But if this was something thats technically possible, it opens up a different discussion with Sonos about licensing (or even purchase) of software and/or patents.  Now given their current stance they may just refuse,  but that decision may be more difficult to defend (especially to their Shareholders) than the current refusal to rollback.  Turns that discussion into something more Board friendly than just give us the old one back.   Maybe someone is already having that discussion - can but hope?

As I say, just a thought process.  As a business with this much bad press and a struggling dev team, this could be way for them to remove that support overhead that they dont want to deal with, and leave a door open for more sales.  License the Sonos The Way It Was™️ app for a $1 (yeah) but then dont have to deal with support AND means we just might help revenue by buying that extra speaker.   And you never know we might come back to the “new improved app” in a few years when they make headphones we really want.   


I admittedly fail to follow the technical discussion here; but here’s what I know, as a Sonos owner who just wants to listen to music on my system as I’ve been doing for years.

Another community commenter turned me on to a3rd party app that cost the princely sum of 99 cents. Using that app, I can now list, open and play all of my Sonos playlists… this after months spent wondering if I would ever be able to retrieve and listen to that accumulated music library. 

That’s all I want from my system, along with basic functions like volume control, the rudimentary Sonos bass/treble/balance ‘EQ,’ and the ability to select which speaker pairs will play. I can get that by choosing a playlist in the 3rd party app; which then appears in the Sonos app. 

I now have all I need, other than the ability to edit and create new playlists, which would be a nice addition.

As I read recent comments, Sonos legal may step in and demand the 3rd party developer ‘cease and desist’ or face patent infringement litigation.

Is that a possibility? I’ll say this: I’ve been unhappy with Sonos for two months, but at this point I can live with what I’m now able to do with my system. If Sonos relegates me to where I was before I tried my 99 cent solution, I’m going to be one ticked off geezer.


Hi again @DSLA, two things to consider …

Sonos kinda-sorta supports third-party apps via the APIs. Beyond my beloved SonoPhone/Pad, there are shiny folks like Roon. I point this out as a sign that “Sonos Legal” has proven copacetic with third parties.

The most significant factor here—one that has not been mentioned yet—is simply money. If someone is going to develop and supportSonos The Way It Was™️ app, how much do they need to charge? Perhaps check out Roon’s pricing as a datapoint ... it is, shall we say, spendy.

 


Just to play “devils advocate” companies are very litigious when it comes to protecting their intellectual properties. Even those that are replaced for more advanced programming. One major reason is that each future generation of coded software typically retains a vestige of the original until the system is completely rewritten with no chance of current products utilizing the old code (OS) to function properly.

Think MS-DOS. Although it took approximately 36 years to remove it from Windows. Microsoft didn’t until 2018 re-license it under MIT License to make it free a version. Today no self respecting Windows system will dance with MS-DOS.

My point here is that I seriously doubt that Sonos would allow a Sonos The Way It Was because it follows that some entity would eventually hack its hardware under some legal loophole. Then the next step is producing speakers that look, sound and work like Sonos without the Sonos price tag. Thus causing confusion and loss of revenue.

Here’s another example although not tech related but it shows to what lengths a company will go to protect its brand….

FedEx was originally known to the public as Federal Express. It still holds the latter for incorporation purposes.  The FedEx moniker came about because the general public always likes to shorten things for quick communication. If someone wanted to send something overnight across country they would say FedEx it. Well Federal Express saw what might happen next…another company calling themselves FedEx. So, FedEx made a preemptive move and registered the name FedEx. The rest is history.

Therefore, I doubt Sonos would allow an identical clone of its software to run alongside its official version unless it could wall-off its product line from that version. Doing so IMO would cause an even bigger uproar for loss of functionality for current Sonos owners than is being experienced now with the new app.

However, as I said in the beginning..,just playing “devils advocate”.


Something I thought of after my post above, Sonos could also push a firmware update that would make the previous controller versions less functional. That happens already as with my old android tablet that has been an alarm clock / Sonos controller for some time now. It does still do the basics but most functionality is disabled, requiring a newer device and software.


I have no problem with the fact that Sonos wants and needs to protect its intellectual property. But there is a problem when Sonos force-feeds users with software that does not work for them; and then declines to respond to entreaties to fix it. Evidently there is a reasonably simple solution to one of the major problems that came with the ‘upgrade’ of S2: loss of access to Sonos playlists that are the tool many thousands of us use to listen to music which we ‘archived.’ Which makes one wonder whether there is an undisclosed reason Sonos hasn’t provided us with a solution or even promised to provide one as part of its ongoing ‘update’ process.

If it’s Sonos’ intent to deny access to our playlists as part of its future business plan, it behooves Sonos to candidly advise us of that fact, rather than simply ignore the many users who want to know whether and when we will regain access, along with the ability to edit existing playlists and save new ones.

Once we know what Sonos intends, we can exercise our option to stay with Sonos or go. Right now I’m staying because I’ve regained - with help from a 3rd party app — what was for me a key music playback function. I’m not staying if Sonos takes steps to disable that function for its own business reasons. 

 

 


I’m pretty sure that the Sonos devices check the digital signature on any file you try to load. Faking that is about impossible.

Hi @Stanley_4, one imagines that Sonos devices “call home” for any firmware update. While one never know with anything running Linux, I’d be surprised if there was any path to sideloading. So I agree with you 100% that any firmware install requires the full support of Sonos.

As noted in my post above, it seems to me that the existing v16.2 firmware would be a copacetic choice for a would be Don Quixote.

Sonos devices have had a locked bootloader for many years now. Unless an option is made available by Sonos for end users to request a bootloader unlock and give up all warranty, Sonos Online Platform integration and support from Sonos, then I don’t really see a jailbreak or sideload option being viable.

Over the years people have looked at the hardware and firmware, decoded it, made their limited progress publicly available, but the reality is the effort involved isn’t worth it when there are alternative hardware options available at more reasonable prices for music playback.

Any calling home could be blocked or redirected, but without an easy way to unlock the bootloader and install an alternative firmware it’s pretty irrelevant.

Security companies who find exploits and perform responsible disclosure with Sonos have had mixed results with Sonos. Sonos usually patch the firmwares based off their disclosure, but rarely provide any public disclosure or raise CVEs themselves and the patches will be hidden in the magic bucket of ‘Bug fixes and improvements’ on the release notes. They prefer the old security via obscurity approach than openness adopted by modern companies and that is unlikely to change without an exec level change.

https://tnpitsecurity.com/blog/gaining-root-on-sonos-speakers/
https://research.nccgroup.com/2023/12/04/shooting-yourself-in-the-flags-jailbreaking-the-sonos-era-100/

 


I just don’t see Sonos allowing a Sonos the Way it Was OS version. Here’s another real life case of a failed attempt to allow clones that resulted in financial crisis.

Xerox at one time back in the early 80’s manufactured copiers for a competitor. The agreement was to use identical Xerox machines branded with the competitors logo. 

At that time copiers were sold by boots-on-the -ground sales reps. The agreement between Xerox and the competitor further stipulated that the competitors sales force could not inform their clients that their machines were identical to Xerox machines just with their competitive  branding. Well, as you can image that worked quite well…NOT! If the competitors sales force was about to lose to a Xerox sales rep selling the identical machine the competitor spilled the beans to secure the sale.

Xerox at the time basically told their sales force to work harder to sell their branded gear. Xerox corporate didn‘t care because the copiers built for the competitor were already considered revenue earned. Xerox saw that arrangement as a win/win as the competitor still had to buy Xerox toners which was another revenue stream.

Well…fast forward and Xerox finally realized that their customer base was shrinking because of the arrangement. So what seemed like a good idea in the beginning soon became an albatross. 

IMO Sonos could fall into the same quagmire if they allowed a Sonos the Way it Was version of their OS. I’m not saying that the idea has no merit…just that it doesn’t IMO in the long run make good business sense.


I just don’t see Sonos allowing a Sonos the Way it Was OS version. Here’s another real life case of a failed attempt to allow clones that resulted in financial crisis.

Xerox at one time back in the early 80’s manufactured copiers for a competitor. The agreement was to use identical Xerox machines branded with the competitors logo. 

At that time copiers were sold by boots-on-the -ground sales reps. The agreement between Xerox and the competitor further stipulated that the competitors sales force could not inform their clients that their machines were identical to Xerox machines just with their competitive  branding. Well, as you can image that worked quite well…NOT! If the competitors sales force was about to lose to a Xerox sales rep selling the identical machine the competitor spilled the beans to secure the sale.

Xerox at the time basically told their sales force to work harder to sell their branded gear. Xerox corporate didn‘t care because the copiers built for the competitor were already considered revenue earned. Xerox saw that arrangement as a win/win as the competitor still had to buy Xerox toners which was another revenue stream.

Well…fast forward and Xerox finally realized that their customer base was shrinking because of the arrangement. So what seemed like a good idea in the beginning soon became an albatross. 

IMO Sonos could fall into the same quagmire if they allowed a Sonos the Way it Was version of their OS. I’m not saying that the idea has no merit…just that it doesn’t IMO in the long run make good business sense.

Sonos actually already provide one… it’s called S1.

The only thing stopping Sonos doing the same with S2 and having the new one as S3 is Sonos themselves. It is possible they considered it and decided the S1/S2 debacle was too much to go through again 🤷

Will Sonos endorse an alternative OS on their devices or unlock the bootloader for their own devices? Not a chance. Originally, when first released and focussed on local music playback, they had an unlocked bootloader. No chance of that now as their 3rd party streamings contracts would disappear overnight if people could modify the Sonos provided firmware easily.

The best anyone could possibly hope for would be for Sonos to white label and license the tech platform to other companies who could brand and develop their own controller apps, but unless they want to become a platform/api provider, and get out the hardware side, then no chance of that either.

The hardware only revenue side of Sonos is actually a problem they need to solve because purely selling hardware to pay for continued support, software development and running large scale online services isn’t realistic. 


S1 is significantly watered down receiving no updates. The original post is suggesting a fully functional OS that also serves current and future products… to my understanding.


S1 is significantly watered down receiving no updates. The original post is suggesting a fully functional OS that also serves current and future products… to my understanding.

The only real new feature that S2 has over S1 is lossless playback. (Well and newer hardware support, along with SMBv2/3).

It’s a pretty good choice for Sonos The Way It Was.


Functionally, there's still almost no difference to S1 and S2 all these years later. Groups and not much more really. You STILL can't multi-select items in a list to add/move/remove…

The Desktop controller remains way more efficient for so many tasks.


I prefer the desktop controller because everything is presented, rather than forcing me to scroll and dig for everything. As I watch younger computer/phone/pad users I find that they prefer sparse screens because that seems “easy”. I also think that they enjoy scrolling and drop downs. For me this constant need for digging is “complicated”.


OK…we’re all just throwing things at the wall to see what sticks. But I ask you…what company has their proprietary software being used by a 3rd party to circumvent the use of their software to lend functionality to the proprietary companies product. BTW… Open Source and Android which is owned by parent company Alphabet can’t be used as examples 😊 You have 60 seconds 😂