I guess that depends on what they want, and what their agreement with Steinberg is, and maybe the EULA, and maybe how much money and time they have to maintain an auth server machine.
What you’re actually complaining about is the fact that the software was remotely authorized in the first place, starting over 3 decades ago, not that it was discontinued and will stop. It’s fine and fair to be against the idea of releasing software that requires remote authorization, I’m not arguing against that idea. But if you are, then don’t buy it in the first place. Software that is remotely authorized always comes with the risk that authorization will go away, it would be pretty silly to assume otherwise.
Why should their agreement with Steinberg factor into this?
There is no need to maintain the auth server just make the one-time cost of removing the requirement of the auth server.
As for this particular EULA, if the publisher stops selling the software, they shouldn't be able to revoke existing licenses based on it. The license was granted in exchange for a fee, creating an expectation that the software could be used indefinitely under the agreed terms. Their EULA specifies that revocation is linked to breaches by the licensee, not the publisher's business decisions.
Their EULA lacks any clause that allows revocation simply because the software is no longer sold. Revoking a license under these circumstances would remove their right to use a product they legally purchased, which is a violation of their consumer rights. The publisher's decision to withdraw the software from the market shouldn’t negate the licensee's ability to continue using it as originally intended.
Software being remotely authorized is an implementation detail not a contractual one. It literally doesn't matter. It's their job to allow software legally purchased to continue to function however they are able to do it.
> Why should their agreement with Steinberg factor into this?
I’m speculating, but it could be possible that turning off authorization is Steingberg’s request or stipulation for offering a Dorico discount. Was that not clear before this point? If true, does it change your calculus at all?
> Software being remotely authorized is an implementation detail not a contractual one.
Section 9 “Authorization” of the June 2021 EULA disproves that claim.
> It’s their job to allow software legally purchased to continue to function however they are able to do it.
Says who? Do you have any laws or contracts you can cite to back that up? I know you’re just trying to convince me that they shouldn’t be able to turn off remote authorization of new installs next year, however turning off authorization is a thing that can happen with any software packages that use remote authorization, because remote authorization is a common practice. Again, I’m not debating the ethics of said practice. But if you think that remote auth should be illegal, then you should never have bought Finale in the first place.
> Section 9 “Authorization” of the June 2021 EULA disproves that claim.
Yes, that binds the user to authorize their copy. The company must therefore provide the means for them to authorize.
As for the legality, this is pretty contentious issue in many countries which is why we are having this discussion rather than it simply being an open and shut case. A fair amount of this Wikipedia article is dedicated to this subject:
Authorize contractually. It is not an implementation detail, right? It’s specified that it will authorize by internet connection, or otherwise by manual key entry on every subsequent launch.
> The company must therefore provide the means for them to authorize.
That’s a logical assumption, if the company wants to do business, but isn’t stated in the EULA or the law. Pay special attention to Finale EULA sections 5, 7, 11, 12, 13, 14, and 15.
All this gets extra problematic when a product or a company dies or is transferred. There are very few laws that try to force a product to continue existing once its creator decides to shelve it for any reason, even if it would be trivial for the creator to do so.
Personally, I agree with the guiding principles of the First Sale Doctrine. What we’re concluding here is that your beef is with the idea of software authorization for purchase-once (non-subscription) software that is locally installed and doesn’t depend on cloud services. As a principle, that’s fine, I don’t disagree with it. Given the specifics in this case, it’s not known yet how many people the auth server shutdown will affect next year, but it is possible (I speculate!) that the discounted upgrade path to Dorico might not exist in it’s current form if Finale left the auth server on.
Nobody who bought is unaware that it’s remotely authorized. And, there’s a 30 day refund policy, so if they find out after purchase, they can change their mind.
You might have a point when it comes to, say, MS Windows, but not Finale.
Maybe, but the problems with your new argument are 1) Finale requires explicit authorization, it’s a manual process the user has to do when first launching so you seem to be speculating or making things up, 2) this moved the goal posts for the thread and you’re undermining @wvenable’s argument and others by suggesting they didn’t understand what they were doing 3) it doesn’t matter what your or I think about consumers, what matters is what the EULA and/or sales contract said.
And why did you quote “IT people”, who said anything about IT people?
> And why did you quote “IT people”, who said anything about IT people?
I'm not the person you're replying to but I interpreted what they were saying as meaning "tech savvy."
The average, non-tech-savvy user doesn't necessarily understand the concept of client/server applications let alone realize that what makes the software that they purchased work is bound to a remote server / someone else's computer that could one day disappear.
I've been following this thread and in another reply it was pointed out that Finale has a 30 day money back guarantee, that "everyone" who uses Finale knows about the remote activation mechanism and that if they discover it after purchase and do not agree they can take advantage of that 30 day money back guarantee.
I think this argument is weak.
What a user typically experiences after installing new software is a dialogue asking them to enter their email and password that was used at the time of purchasing.
What happens after that is not necessarily clear.
Does it need to send the email and password to a remote server in order to verify the license every single time the application starts, or is this a one time activation?
From the user's perspective, is it made blatantly clear that the software is asking for the information for the purpose of product activation or is it merely for personalization purposes?
For that matter, does it actually serve any functional purpose at all, or is it just annoying data collection that can't be skipped?
20 years ago, EULAs were one of the big talking points online when it came to software companies. There was a question as to whether EULAs would actually be enforceable, binding contracts that courts would recognize at all. This came up time and time again because of some of the content that these EULAs included. I can't remember any specifics, but I remember that there was some really eyebrow raising stuff in some EULAs. Regardless, it was well understood that most end users blindly clicked "I Agree" without ever reading the EULA. It was seen by most as an annoying thing that you had to do when installing software, and few understood the point or gave it a second thought.
My argument is that when it comes to product activation, most end users probably view it as similar to clicking "I Agree" on the EULA. I doubt very much that most non-tech-savvy users are really thinking about the fact that someone else's computer is going to need to be running in order to activate their software should they need to re-install or if they lose access to the Internet. And very few are thinking about the possibility that the company could go out of business or one day just decide to stop activating the software on re-installs because they feel like it.
I'm repeating some of what I've said in earlier replies of mine ... but this really comes down to contracts and by "contract" I don't necessarily mean a hand-written and signed document laying out terms, I just mean the agreement that was between the vendor and purchaser. That agreement can be complicated because you've got the EULA on the one hand, the company's marketing on the other and what a court would recognize and enforce if it were litigated.
I'm personally more concerned with the implied agreement because I doubt anyone will choose to litigate over this (unless there is an institution somewhere that invested a lot of money in Finale and expected to be able to use the software in perpetuity). The implied agreement matters because this speaks to what promises MusicMaker was making to their customers and if they reneg on that promise, when money is at stake, it makes them a shit company that no one should ever do business with in the future.
I also really don't understand why you're "simping" so hard for MusicMaker. Is it that you've taken a position and you're debating it as an academic exercise or out of boredom? Or are they paying you? I mean ... I've never seen anyone go to bat so hard in favour of a company screwing over their paying customers.
> I'm not the person you're replying to but I interpreted what they were saying as meaning "tech savvy."
I certainly meant "tech savvy" at the last-- if not out right someone who works in IT. The kinds of questions you rhetorically asked re: the activation process are the kinds of questions I'd ask as an IT worker evaluating a product for use in a business. Those kinds of questions are well beyond what the average tech saavy person would even think to ask. They are "unknown unknowns" to people who haven't dealt with intricate software licensing arrangements.
> I also really don't understand why you're "simping" so hard for MusicMaker. Is it that you've taken a position and you're debating it as an academic exercise or out of boredom? Or are they paying you? I mean ... I've never seen anyone go to bat so hard in favour of a company screwing over their paying customers.
Thanks for articulating this. I was thinking the same thing-- particularly as I watched your interaction the grandparent poster in other parts of these comments. I wanted to say something like this but couldn't come up with an articulate way to do it quickly.
It’s much better you didn’t before, except now you did which sadly undermines the rest of your argument. I wasn’t particularly defending MakeMusic, I was just resisting a pitchfork mob thread that was posting misinformation by people who have absolutely zero actual intent to run Finale next year, and no they’re not paying me :eyeroll:. @gspencley just didn’t understand my position before deciding to troll with multiple mean-spirited low-class and ad-hominem attacks that are wildly against HN guidelines. Unfortunately for him, that demonstrates his argument is weak and that he knows it, since he didn’t feel like he could make his point without stooping to name-calling. Now you know it too.
> I guess that depends on what they want, and what their agreement with Steinberg is, and maybe the EULA, and maybe how much money and time they have to maintain an auth server machine.
Their agreement with Steinberg doesn't absolve them of their rights to me.
What you’re actually complaining about is the fact that the software was remotely authorized in the first place, starting over 3 decades ago, not that it was discontinued and will stop. It’s fine and fair to be against the idea of releasing software that requires remote authorization, I’m not arguing against that idea. But if you are, then don’t buy it in the first place. Software that is remotely authorized always comes with the risk that authorization will go away, it would be pretty silly to assume otherwise.