In article <memo.20220427170059.3264G@jgd.cix.co.uk>, jgd@cix.co.uk
(John Dallman) writes:

> > They'd probably be willing to accept accept a lump sum to transfer the
> > copyrights and walk away.
>
> Yes, but it would be quite a large lump sum.

Where is Elon Musk when you need him? :-)

OK, it was about 25 years ago, but Compaq paid 9 billion for DEC and
Musk paid 44 billion for Twitter. I would argue that DEC was worth more
in any sense meaningful to me. :-)

I'll see if I can get Musk interested in a web browser for VMS. :-D

On Wednesday, April 27, 2022 at 11:27:32 AM UTC+12, Dave Froble wrote:
> On 4/26/2022 5:48 PM, David Goodwin wrote:
> > On Wednesday, April 27, 2022 at 7:11:54 AM UTC+12, Phillip Helbig (undress to reply) wrote:
> >> In article <3a643f5c-5df8-4743...@googlegroups.com>,
> >> David Goodwin <dgso...@gmail.com> writes:
> >>
> >>> But I don't see that happening. Too risky, too hard. And I suspect many
> >>> OpenVMS users would rather see the platform go extinct than be
> >>> open-sourced.
> >> If VMS were open source, it wouldn't work. Many point out the
> >> differences between VMS and other operating systems. One of them is
> >> that if open source works for some, it doesn't necessarily work for all.
> >>
> >> The main problem is the lack of perpetual licenses.
> >
> > I don't see any sensible explanation for why having access to the source
> > code is a bad thing or why it couldn't work for OpenVMS. If you're worried about
> > some hidden security vulnerability then those exist whether the source is public
> > or not. Closed source for security reasons is nothing more than quite a bad
> > implementation of security through obscurity.
> >
> > Perpetual licenses only solve the problem in the short term. Regardless of what
> > VSI does the customers they have today will over time leave (out of business,
> > whatever OpenVMS was doing is no longer needed, etc). VSI needs to win new
> > customers to replace those that leave. Perpetual licenses alone won't encourage
> > *anyone* to switch from Linux.
> >
> > Closed source with perpetual licenses guarantees that one day it will no longer
> > be possible to buy new licenses. It guarantees that one day security updates
> > will no longer be available. It guarantees that one day when those hidden
> > security vulnerabilities are discovered no one will be legally allowed to fix them.
> >
> Ok, let's take a look at these claims ...
>
> What guarantees that one day it will no longer be possible to buy new licenses?

Over time existing customers will leave. Either they go out of business, change the
sort of work they're doing, or whatever it it is their OpenVMS systems are doing is
simply no longer required. Some will probably even migrate to Linux because its
cheaper and easier to find people familiar with it.

Replacing customers who leave requires some how convincing a business to switch
from some other vastly more popular and almost certainly significantly cheaper
platform.

If VSI doesn't replace every customer that leaves eventually they'll reach an unviable
number of customers and either move to doing something else or go out of business.

> What guarantees that one day security updates will no longer be available?

The number of paying customers getting so low that its no longer a viable business
causing sales, support and maintenance to be discontinued. This already very nearly
happened once with HPE. If the number of OpenVMS users continues to shrink it will
eventually happen with VSI too.

> What guarantees that one day security vulnerabilities would not be legally fixable?

Its a closed source operating system and the license most likely forbids reverse
engineering and modifying the code yourself. Illegal to patch the vulnerability yourself
if there is no vendor to pay for fixes.

> Please be specific in answering each of those questions. Frankly, I cannot
> understand such guarantees.

Of course nothing in this world is guaranteed. Perhaps OpenVMS will be the exception
to the rule and it will still be available and maintained in a century. But I'm not entirely
sure OpenVMS is in the same seemingly irreplaceable category as whatever IBM sells.
If it were I don't think HPE would have tried to drop it.

To me it seems like unless something drastic changes OpenVMS will follow the same
path as so many other operating systems, just a few decades behind the others
because its been ported to new CPU architectures. There haven't been a lot of security
updates for Tru64 lately...

On Thursday, April 28, 2022 at 8:08:46 AM UTC+12, ruzsinsz...@gmail.com wrote:
> I asked about OpenVMS for VAX license.
>
> VSI doesn't work with VAX.
> I'd like to use SIMH VAX program with OpenVMS.
> Learning or testing. Without real VAX hardware ...
>
> So there isn't any solution?
> It sounds bad! :-(

No solution that doesn't involve paying thousands of dollars or running it without a license

Den 2022-04-27 kl. 16:36, skrev Dave Froble:
> On 4/27/2022 3:09 AM, Jan-Erik Söderholm wrote:
>> Den 2022-04-27 kl. 01:14, skrev Dave Froble:
>>> On 4/26/2022 5:57 PM, Jan-Erik Söderholm wrote:
>>>> Den 2022-04-26 kl. 20:11, skrev Dave Froble:
>>>>> On 4/26/2022 1:09 PM, Simon Clubley wrote:
>>>>>> On 2022-04-26, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>> On 4/26/2022 8:09 AM, Simon Clubley wrote:
>>>>>>>> On 2022-04-26, gah4 <gah4@u.washington.edu> wrote:
>>>>>>>>> On Tuesday, April 26, 2022 at 1:28:10 AM UTC-7, John Dallman wrote:
>>>>>>>>>
>>>>>>>>> (snip)
>>>>>>>>>
>>>>>>>>>> As an additional logistical point, open-sourcing VMS while
>>>>>>>>>> building it
>>>>>>>>>> requires using out-of-production Itanium servers would be
>>>>>>>>>> suicidal: it
>>>>>>>>>> has to be sustainable on commodity hardware first.
>>>>>>>>>
>>>>>>>>> DEC nicely released the 36 bit OS for us to use, though with only
>>>>>>>>> (from them) out of production hardware.   I am not so sure when
>>>>>>>>> emulators came out, but it would not have been hard to write one
>>>>>>>>> by then.
>>>>>>>>>
>>>>>>>>> I suspect VAX is nicer to write an emulator for than Alpha or
>>>>>>>>> Itanium,
>>>>>>>>> but all are possible to keep VMS running on new hardware.
>>>>>>>>>
>>>>>>>>
>>>>>>>> There are full system emulators for all architectures I am aware of
>>>>>>>> apart from Itanium, which should tell you something. I once spent a
>>>>>>>> weekend looking at the possibility of writing one, and came to the
>>>>>>>> conclusion of basically "forget that!".
>>>>>>>>
>>>>>>>> Even with the initial help from Ski for the instruction set component,
>>>>>>>> writing an Itanium emulator would be a massive job and not all the
>>>>>>>> required bits and knowledge are freely available.
>>>>>>>>
>>>>>>>> For example, you can no longer freely download the Itanium firmware
>>>>>>>> that such an emulator would require.
>>>>>>>>
>>>>>>>> Simon.
>>>>>>>>
>>>>>>>
>>>>>>> If emulators for building VMS is the issue, Alpha emulators already
>>>>>>> exist.
>>>>>>> Don't need no stinkin itanic.
>>>>>>>
>>>>>>
>>>>>> Read the original quote above. Itanium is currently used for things
>>>>>> that Alpha cannot be used for.
>>>>>
>>>>> I don't see anything like that?
>>>>>
>>>>> What can itanic do that Alpha cannot?  It's a shared code base.
>>>>
>>>> You can lookup he SPD's or similar. There are a lot of tools
>>>> that are available on IA64 but not on Alpha.
>>>>
>>>
>>> You don't seem to be missing them ...
>>>
>>> :-)
>>>
>>
>> Why do you think that? And why do you think that our needs
>> are the same as for everyone else?
>
> You have mentioned multiple times that your customer has 3 DS20E systems.

Yes, we have. And *you* have no idea, what so ever, why. You said that
we would not have any use of the things that are IA64-only, and
you have absolutely no knowledge about that.

The reason is of course that we have some things that are Alpha-only.

>
> Of course, you may also have access to an itanic ...
>

I had once for s short while. In my office. And I only installed
VMS on it, nothing more.

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Phillip Helbig
> undress to reply via Info-vax
> Sent: April-27-22 9:03 AM
> To: info-vax@rbnsn.com
> Cc: Phillip Helbig undress to reply <helbig@asclothestro.multivax.de>
> Subject: Re: [Info-vax] vax vms licenses
>
> In article <t4aeqg$vk1$1@dont-email.me>, Dave Froble <davef@tsoft-
> inc.com> writes:
>
> > I do find it interesting that the worst doomsayers are those without
> > any relationship with VSI. Any current customers with VSI support out
> > there have much to say about the issue?
>
> There is an obvious selection effect here: those who are fine with the
license
> policy are fine being VSI customers. Those who aren't, aren't.
>
>

Keep in mind that there are major SW licensing changes happening with other
vendors as well.

Case in point - Microsoft changing their SQL licensing to a core based model
similar to how Oracle does its licensing.

With HW vendors increasing their core counts on even small servers to be
more competitive, this typically means higher overall licensing costs.

Sample reference:
<https://redmondmag.com/articles/2019/11/08/sql-server-2019-licensing.aspx>

OpenVMS used to be core based back in the HP OpenVMS pre-V8.4 days and
moving to socket based was viewed by Customers as a major positive move.

Imho adopting either core or socket based HW licensing with all of the
variants and options is just way, way to complex these days. Most Customers
want simple licensing terms that do not need a license sales specialist to
explain exactly how many licenses are required.

Subscription models with exceptions for some Customers who require perpetual
is the way to go in the future and that appears to be the way VSI is
heading.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG.
https://www.avg.com

On Wednesday, April 27, 2022 at 1:37:16 PM UTC+12, Arne Vajhøj wrote:
> On 4/25/2022 10:06 PM, David Goodwin wrote:
> > Most open-source
> > projects are also going to have no interest in maintaining any level of support
> > for some obscure proprietary operating system too so maintaining ports is
> > going to be all on VSI.
>
> It is all about trust in the future.
>
> Open source does not have a problem supporting Windows despite it
> being closed source. Nobody expect it to go away.

Yeah, I guess that really is the bigger issue. There is never any guarantee I'll
have access to OpenVMS beyond the end of my current community license. So
I'm never going to invest more time and effort into OpenVMS than I'd be willing
to loose should VSI decide to discontinue community licenses for some reason.

> > Of course it doesn't have to be this way - Sun has proven that. OpenSolaris
> > is still being actively maintained and enhanced under the name Illumos.
> > There are a variety of Illumos distributions to choose from, Joyent use Illumos
> > as the basis for their cloud platform (SmartOS), and there is some NAS
> > product that uses it too. Meanwhile the closed-source variant of Solaris
> > will probably disappear when support for 11.4 ends in 2034.
> The Solaris path does not look attractive to me.

I guess the Solaris path is the best worst case scenario. The owner is abandoning
it so the community and a few small companies have taken up maintenance. If you
absolutely had to run something that looks like Solaris beyond Oracles end of support
date then Illumos is there. Though I imagine anyone with source code will probably
just port to Linux if they haven't already.

At the moment you don't have this option if/when support for OpenVMS ends. You're
either stuck on an unsupported and unmaintained platform (if you managed to get
a permanent license) or you're forced to port to something else very quickly.

Perhaps if the source was available under suitably open terms then having to renew
your VSI OpenVMS licenses every year would be less of a business risk because worst
case scenario if VSI stops renewing licenses you don't suddenly loose access to
OpenVMS forever. You just loose access to the VSI supported version of OpenVMS.

> > This is probably the only realistic path forward for OpenVMS that doesn't see
> > it managed into extinction.
> Both Windows and commercial Linux seems to do fine. VMS could as well.

I'm not so sure Windows is doing fine in the server space. Microsoft runs more
instances of Linux in Azure than Windows, they've added Linux binary compatibility
to Windows and they've ported a bunch of their server software to Linux.

To me it kind of seems like Microsoft has realized Linux and cloud services will
eventually replace Windows Server and they don't want their other products to go
down with the ship.

> > If it were open-sourced then the rest of the industry
> > might pay it some attention, perhaps a community might form and pick up
> > some of the maintenance and porting burden. It might get used in some new
> > products and solutions.
> VMS users are infamous for their lack of enthusiasm when it comes to
> actually do something.
>
> :-(
>
> And even outside the VMS world recent years has shown huge problems
> with getting open source maintained.

Yes, too many equate open source with no cost. Companies depending on open
source projects really need to contribute in some way - either financially or by
helping out with maintenance.

On 2022-04-27, Attila Ruzsinszky <ruzsinszky.attila@gmail.com> wrote:
> I asked about OpenVMS for VAX license.
>
> VSI doesn't work with VAX.
> I'd like to use SIMH VAX program with OpenVMS.
> Learning or testing. Without real VAX hardware ...
>
> So there isn't any solution?
> It sounds bad! :-(

If you are not running real VAX hardware, but just an emulator, then
switch to an Alpha emulator, install the VSI community version of
Alpha VMS, and then call it job done.

There are some Linux based Alpha emulators but their emulation
accuracy is suspect, so I continue to use FreeAXP running on an
old Windows box. This runs VSI Alpha VMS just fine for me.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 04/27/22 23:22, Kerry Main wrote:
>
>> -----Original Message-----
>> From: Info-vax<info-vax-bounces@rbnsn.com> On Behalf Of Phillip Helbig
>> undress to reply via Info-vax
>> Sent: April-27-22 9:03 AM
>> To: info-vax@rbnsn.com
>> Cc: Phillip Helbig undress to reply<helbig@asclothestro.multivax.de>
>> Subject: Re: [Info-vax] vax vms licenses
>>
>> In article<t4aeqg$vk1$1@dont-email.me>, Dave Froble<davef@tsoft-
>> inc.com> writes:
>>
>>> I do find it interesting that the worst doomsayers are those without
>>> any relationship with VSI. Any current customers with VSI support out
>>> there have much to say about the issue?
>>
>> There is an obvious selection effect here: those who are fine with the
> license
>> policy are fine being VSI customers. Those who aren't, aren't.
>>
>>
>
> Keep in mind that there are major SW licensing changes happening with other
> vendors as well.
>
> Case in point - Microsoft changing their SQL licensing to a core based model
> similar to how Oracle does its licensing.
>
> With HW vendors increasing their core counts on even small servers to be
> more competitive, this typically means higher overall licensing costs.
>
> Sample reference:
> <https://redmondmag.com/articles/2019/11/08/sql-server-2019-licensing.aspx>
>
> OpenVMS used to be core based back in the HP OpenVMS pre-V8.4 days and
> moving to socket based was viewed by Customers as a major positive move.
>
> Imho adopting either core or socket based HW licensing with all of the
> variants and options is just way, way to complex these days. Most Customers
> want simple licensing terms that do not need a license sales specialist to
> explain exactly how many licenses are required.
>
> Subscription models with exceptions for some Customers who require perpetual
> is the way to go in the future and that appears to be the way VSI is
> heading.
>
>
> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com
>
>

Perhaps VSI have presented this issue in the wrong way. Had
they stressed from the start that the licensing was subscription
based, there may not have been such a negative response. As you
say, that seems to be the direction in industry and even apps
such as Photoshop have been subscription based for a while now.

The show stopper is if the machine is bricked at the expiration of
the subscribed license period. The usual thing would be for the machine
to be operative, but the revision, patches etc frozen at that for the
most recent subscription payment...

Chris

>
>
>
>
>

On 2022-04-27, Kerry Main <kemain.nospam@gmail.com> wrote:
>
> Subscription models with exceptions for some Customers who require perpetual
> is the way to go in the future and that appears to be the way VSI is
> heading.
>

People don't have to worry about either Microsoft or Oracle going
bust in a few years.

They do have to worry about if they go with this small non-mainstream
company called VSI, will they lose their job in a couple of years if
VSI goes bust and their VMS systems stop working ?

Human factors, Kerry, human factors.

Many of the people making the final decisions in customer companies
are not emotionally invested in VMS, and they are going to go with
the option which is safer for their company (and for their pension).

It's VSI's job to make themselves appear to be the safer option and
they don't appear to be doing a very good job of it.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 4/26/22 6:56 PM, Arne Vajhøj wrote:
> On 4/26/2022 2:35 PM, Dave Froble wrote:
>> On 4/26/2022 1:21 PM, Simon Clubley wrote:
>>> On 2022-04-26, Dave Froble <davef@tsoft-inc.com> wrote:

>> Yes, I have.  Now address my question.  Can you name one VMS customer
>> that intended to stay on VMS but then walked away because of the
>> licensing?  Not someone complaining.  Someone who actually walked away.
>
> Probably only a handful of people at VSI knows that number.
>
> My best guess is that the number is very very small.
>
> Why? Because if it was not then VSI would have changed
> license policy!

It mostly just hasn't come up yet. Where I work we have done 3-year
contracts with VSI, first in 2017 and then renewed once in 2020, so 2023
will be the first time we will be up for renewal when *possibly* there
will be an opportunity to migrate to x86. Naturally we got perpetual
licenses for our Itanium systems at the time since that was the only way
it was done then.

I made a point of ensuring in 2017 that our support contract included
upgrade rights to x86 when available. Of course I never dreamed at the
time that five years later the upgrade still wouldn't be possible or
that the upgrade might actually be a downgrade in licensing terms. If
the only path forward a year from now is moving to a time-limited x86
license, I can't imagine anyone (including me) wanting to bother with it.

In article <t4cl6b$6un$4@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2022-04-27, Kerry Main <kemain.nospam@gmail.com> wrote:
> >
> > Subscription models with exceptions for some Customers who require perpetual
> > is the way to go in the future and that appears to be the way VSI is
> > heading.
> >
>
> People don't have to worry about either Microsoft or Oracle going
> bust in a few years.
>
> They do have to worry about if they go with this small non-mainstream
> company called VSI, will they lose their job in a couple of years if
> VSI goes bust and their VMS systems stop working ?

Indeed. The fact that many here can't get a VAX license shows that the
fear is real. We have seen VMS owned, and neglected, by DEC, Compaq,
and HP. While I think that VSI really cares about VMS, I see a real
problem in the license stuff.

I'm just a hobbyist now. I used VMS in academia for almost 10 years,
then worked at a big VMS shop for a bit more than 20. I don't know what
the future holds. Personally, wearing my hobbyist hat, it might be
better to stick to small Alphas and the few commercial licenses I
actually bought back in the day rather than move to VSI. It's just not
worth the trouble to move and then live with the fear that it can go
away at any time. Yes, I could go back, but then I would have to
rewrite things or make sure that I use no new features. If it's not
worth it for a hobbyist, how could it be worth it for a commercial
entity.

As a hobbyist, I am happy that the hobbyist license existed and that the
community license exists. It allowed me to play with many things. But
life is short and I don't want to invest too much in something which
could go away at any time. I'll probably never have the need to buy a
commercial VSI license. On the other hand, I would, even as a hobbyist,
and pay a (for me) substantial sum, if it were non-expiring. That is
revenue which VSI would not otherwise have.

Why not some sort of escrow setup? VSI creates for each customer a
non-expiring license and deposits it with a notary or whatever. The
license comes with paperwork describing how to access that license
should VSI stop producing licenses. According to VSI, there is no real
danger, so that would never come to pass. Even if it did, only if VSI
ceases to exist, so no loss to VSI. Potentially many customers who
would otherwise leave VMS and thus VSI, and perhaps even some new
customers.

It would be nice if someone from VSI could say what is wrong with that
idea and how it would negatively impact VSI.

On 2022-04-28, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>
> Why not some sort of escrow setup? VSI creates for each customer a
> non-expiring license and deposits it with a notary or whatever. The
> license comes with paperwork describing how to access that license
> should VSI stop producing licenses. According to VSI, there is no real
> danger, so that would never come to pass. Even if it did, only if VSI
> ceases to exist, so no loss to VSI. Potentially many customers who
> would otherwise leave VMS and thus VSI, and perhaps even some new
> customers.
>

I suggested that in detail here in COV.

IIRC, the French people suggested it to VSI and VSI rejected the idea
outright.

> It would be nice if someone from VSI could say what is wrong with that
> idea and how it would negatively impact VSI.
>

There were suggestions here that such an idea might affect the future
resale value of VSI if they go bust and there isn't a quick sale to
someone else who can continue issuing licences.

I did point out however, that such a scheme should make people more
confident about staying with VSI and hence it should improve the profits
for VSI overall.

So no, I don't understand why VSI would be opposed to such a scheme either.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <t4ejjt$orl$1@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2022-04-28, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
> >
> > Why not some sort of escrow setup? VSI creates for each customer a
> > non-expiring license and deposits it with a notary or whatever. The
> > license comes with paperwork describing how to access that license
> > should VSI stop producing licenses. According to VSI, there is no real
> > danger, so that would never come to pass. Even if it did, only if VSI
> > ceases to exist, so no loss to VSI. Potentially many customers who
> > would otherwise leave VMS and thus VSI, and perhaps even some new
> > customers.
> >
>
> I suggested that in detail here in COV.
>
> IIRC, the French people suggested it to VSI and VSI rejected the idea
> outright.

Right. The question is what VSI's justification is.

> > It would be nice if someone from VSI could say what is wrong with that
> > idea and how it would negatively impact VSI.
>
> There were suggestions here that such an idea might affect the future
> resale value of VSI if they go bust and there isn't a quick sale to
> someone else who can continue issuing licences.

But did that come from VSI?

> I did point out however, that such a scheme should make people more
> confident about staying with VSI and hence it should improve the profits
> for VSI overall.

Indeed.

> So no, I don't understand why VSI would be opposed to such a scheme either.

Does anyone?

In article <t4ek6e$a0e$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

> In article <t4ejjt$orl$1@dont-email.me>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
> > On 2022-04-28, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
> > >
> > > Why not some sort of escrow setup? VSI creates for each customer a
> > > non-expiring license and deposits it with a notary or whatever. The
> > > license comes with paperwork describing how to access that license
> > > should VSI stop producing licenses. According to VSI, there is no real
> > > danger, so that would never come to pass. Even if it did, only if VSI
> > > ceases to exist, so no loss to VSI. Potentially many customers who
> > > would otherwise leave VMS and thus VSI, and perhaps even some new
> > > customers.
> > >
> >
> > I suggested that in detail here in COV.
> >
> > IIRC, the French people suggested it to VSI and VSI rejected the idea
> > outright.
>
> Right. The question is what VSI's justification is.

If the lack of perpetual licenses is a potential show-stopper for me as
a hobbyist, it must be even more so for many commercial customers. I am
still amazed that VSI is insisting on the subscription model as opposed
to non-expiring licenses. I would have no problem with VSI stipulating
that an annual fee has to be paid in order to legally use VMS as long as
VSI exists; the problem is the fear that VSI might go away.