Removing licence check for lifetime users

Just bought a lifetime licence and think it would be fair, at the price, to have a “lifetime access” to Roon independently from any Internet connection (namely dropping the 30-days limitation). It’s obviously more a question of principle than a question of practicality since I’ll need to update the softwares.

Hi @rulbricht,

Other than if Roon folds (or perhaps these days Harman) I don’t foresee Roon ever doing this as it would open the door to license abuse.

Not so long ago Roon actually needed constant online connection, just to function but that was subsequently reverted.

1 Like

Probably unlikely at least because of this:

In addition, how would it then know on how many servers it is being run on?

3 Likes

In addition, how would it then know on how many servers it is being run on?

You attribute lifetime token once. So you can’t connect to another client before removing the connection from the last one. It sounds pretty basic to me.

For example, we must report to copyright authorities every month on how many lyrics have been viewed, and which lyrics those are.

OK but how could you access lyrics if the server cannot reach distant servers? I don’t want to be too conspirationistic but my guess is that they make somehow profits on metadata collection.

OK, so it’s online after all. I figured you wanted total offline.

Cached ones? I haven’t tried it, but the quote suggested that lyrics can be accessed when offline:

… but then you totally are anyway

… but then you totally are anyway

Have a look here:

Analytics data gathered by Roon Labs software

Roon captures information about how and where You use the software, and statistical reports about this information are stored on our servers for analysis and possibly also stored on servers of our third party cloud providers. The data is generally transmitted and stored without any reference to Your personal information. The purpose of the analytics data is to help us understand Our users and how they utilize Roon.

Your geographic location. We are contractually obligated by some of our data providers and service partners to filter the content You see based on where You’re located. Yes, this feels very “21stcentury” to Us, too, but draconian laws are draconian laws.

Information about Your music collection. Roon transmits some summary information about the files in Your music collection to our servers and possibly using those of our third party cloud providers.

Information about what music You play. For the development of radio and other features, Roon builds musical taste profiles based on Your play history.

Information about how You use Roon. In order to understand our members and their needs better, We capture data about how You use Roon, including, but not limited to: the features You use, how often You use Roon, statistics about Your music library, geographic location, and the audio devices You stream to.

My bet is this is the REAL reason.

The conspiracy stuff happens when you invent supposed „real“ reasons without any evidence while deliberately ignoring openly stated other reasons without cause.

Anyway, you accepted the license terms when you purchased the license.

3 Likes

Yeah but this is not an argument against my point. This is a feature request thread which basically says: when I buy something, I’d like to be using it at any time under any circumstances. And I don’t see any good argument to prevent the user from owning the software without having to check at the police station every month.

Sorry, the stupid iOS forum bug made me edit the previous post forever while you were already replying.

Yeah but, from my edited above post:

And those terms were different - this is all detailed in the old feature suggestion about the same thing that I quoted and linked above.

Not sure why you don’t see it after it was literally quoted. Given that you invented a supposed “real” reason without any evidence, it seems to me that you don’t WANT to see it.

I understand that you chose to believe the reasons the company gives his customers to explain why such a request would not be possible.

All I’m saying is those reasons don’t hold. 1. There’s rarely a technical reason as to why a software supposed to be run locally needs an Internet connection to access those “local features”. I mean we can do that during 30 days… 2. Lyrics are not stored (just checked). So I can’t read lyrics without an Internet connection. The legal argument is here pointless.

Conclusion: there must be other reasons.

How I love people who think they are the only ones who have seen the truth and everyone else is sheeple.

/ignore

4 Likes

I’m making an argument. If I’m presented with a good reason to accept one the premises, I’ll happily change my conclusion.

Hi @rulbricht

To be clear, you never own the Roon-software, not as a yearly subscriber, neither as a Lifetimer. When you have paid your license, you are only allowed to use the software, not to own it.
If Roon would not check the license each 30 days, it would be very easy for not so honest persons to copy the disk of a Roon-server and multiply it on hundreds of other disks and sell it for the half of the price. No, the fact that a Roon-server checks each 30 days to know that you have a legitimate license is 100% logic in my opinion.
Kind regards, Frank.

3 Likes

If Roon would not check the license each 30 days, it would be very easy for not so honest persons to copy the disk of a Roon-server and multiply it on hundreds of other disks and sell it for the half of the price.

I disagree. The user who would like to connect another client to the same server couldn’t as a token has been given to another client. He would have first to clear the token from the previous client in order to connect the new client (requiring here of course a temporary access to the distant database). This is common practice with licensed softwares. There’s nothing logical in this 30-day limitation in the context of a lifetime account.

I think this is explanation enough why Roon labs have to test the license periodically.

1 Like

Indeed. And this is essentially what the ‘unauthorize’ button in the screen shot below does:

Here, I have disconnected my Roon client from my normal roon server and attempted to connect to a new Roon Server using the same login. Roon has detected that the license associated with the login is already in use by my existing Roon Server and so has offered me a number of solutions - including the ‘Unauthorize’ option. If I select ‘Unauthorize’, then it allows me to connect to the new server using the existing license - this is necessary in the event of, for example, a complete hardware failure requiring the setup of a new server. However, if the old server is still working but is not periodically checking license state, then it will continue to behave as if it was the authorized server when it isn’t. This would result in two servers being used with the same license.

The procedure that you are outlining here with the requirement to have temporary access to the server being unauthorized would cause significant issues. Imagine what would happen if this was just not possible because the old Roon server had suffered a catastrophic failure. You would have no way of moving your license from the dead server to a new one. Whilst there are ways around this, they would make the process more difficult for the user and would likely increase the load on the Roon support infrastructure as well and, without a regular ‘authorization state’ check being made over an internet connection, such mechanisms could still open up the system to misuse.

For lifetime subscriptions, I regard this maximum of 30 days without an internet connection present to be more in about checking the ‘Authorization status’ of the server rather than the license status ie. it is policing the number of servers associated with the license rather than the license availability itself. In that respect, being able to go a long as 30 days without an internet connection (and thus without these checks) is pretty good IMHO.

You also have to bear in mind that it is an accepted use pattern for people to use more than one server with one Roon license - as long as only one is used at a time. The current system makes it possible to ‘move’ the license use from one server to another (by unauthorizing) without requiring access to either both servers or to Roon Support. I suspect that this is more more important to many than the need to provide an internet connection to the Roon server.

Imagine someone who has two houses some distance appart. They install a Roon Server in each house. Using your system, they could free the ‘token’ from the server in the house that they are leaving, travel to the new house and then acquire the ‘token’ on the new server. There are two problems with this compared to the current system:

  1. It requires two operations - one one each server - to move the license
  2. Whilst travelling between homes, no server is available and so ARC cannot be used.

You can’t just wait until you get to the second house, because once there, you have no access to the server in the first house in order to tell it to release the ‘token’. Yes - there are ways around this with VPN’s or other remote access systems but they require a degree of knowledge that not everyone will have - and they still might not work if, for example, there has been a power cut at the old house which has caused the Roon Server to power down and not powerup (not all servers offer Wake-On-Lan and not every user has the ability, or inclination to set it up if their server does support Wake-On-Lan.

By contrast, the current system, allows you to continue to use ARC connected the first house server during the journey and only move the license to the new server on arrival at the second house - even if the server in the first house is not powered on.

6 Likes

Thanks Wade for your comprehensive reply.

Let me quickly reply to your counter-examples.

  1. The failure of the Roon server would indeed need to be taking care of by the technical support. However, how many users have experienced a fatal flaw with the server? This must be answered by the technicians. My intuition is that this isn’t common for a locally run infrastructure. But let’s say a user lies about it. Then the support frees the authorization for a new server. There you would have two servers running under one licence which would indeed be problematic. But a) the same liar with a monthly subscription could do the same or b) support could require to connect to the failed server before giving the new access or some sort of instructions to reinstall the server. This is to me a very borderline case and I don’t see the point to buy a lifetime licence for a software that could not be updated.

  2. The example you give would not be suitable for someone willing to keep the server running locally. We can’t have both worlds with my suggestion. The user would have to chose between both options or reconnect the server while travelling. Again, I don’t see this as a problem.

As I said in my first post, this proposal is more a question of principle than a question of practical use of the software. When you pay $800 for a system, you may desire to access it in every context. For instance, it is perfectly acceptable to consider (as I tend to do) that a server running with root privileges, constantly connected to the Internet, may appear as a security risk for some users. Closing the ports to the www and not worrying about being able to use Roon should be part of the deal of acquiring a lifetime licence.