For more than four years, a small team of devoted volunteers has put open source tools onto OpenVMS servers. The effort is focusing on OpenVMS 8.4 for the IA-64 servers from HP Enterprise. In the latest development for the project, the volunteers are bringing the new x86 version of OpenVMS from VMS Software Inc. into the picture.

This isn't the first proposed project expansion. Volunteers say one stretch goal makes open source serve the OpenVMS VAX 7.3 release, too. One of the prizes of this work is perl, operating on OpenVMS.

GNUlib makes open source software a reality on any platform. The HP 3000 community got this vital bootstrap during the 1990s. Open source was spreading its wings at the time, so tools like the Apache webserver and Samba pulled up for MPE/iX duty. GNUlib is the porting tool to bring open source to OpenVMS.

Read more...
https://LegacyOS.org/making-open-source-tools-work-for-vms/

I would really like to see a developers' guide Wiki for OpenVMS for
those of us, and I think there are quite a few, who have been writing
software for decades yet don't have a feel for doing so under (Open)VMS.

Jon

In article <j018pcF1dl2U1@mid.individual.net>, Jon Schneider
<jon@jschneider.tenreversed> writes:

> I would really like to see a developers' guide Wiki for OpenVMS for
> those of us, and I think there are quite a few, who have been writing
> software for decades yet don't have a feel for doing so under (Open)VMS.

It would be nice if there were some sort of standard BUILD.COM which
would do everything (perhaps with parameters to determine whether one
wants to use supplied .EXE, link supplied .OBJ, or compile from supplied
sources). When finished, it can print out the required symbol
definition (which one would presumably place with others), command to
add the HELP to some library (ideally one would have a separate HELP
library for such third-party products), and so on.

On 11/22/21 4:12 AM, Jon Schneider wrote:
> I would really like to see a developers' guide Wiki for OpenVMS for
> those of us, and I think there are quite a few, who have been writing
> software for decades yet don't have a feel for doing so under (Open)VMS.

You mean something like this?

<https://sourceforge.net/p/gnv/wiki/Home/>

On 11/22/2021 6:28 AM, Phillip Helbig (undress to reply) wrote:
> In article <j018pcF1dl2U1@mid.individual.net>, Jon Schneider
> <jon@jschneider.tenreversed> writes:
>> I would really like to see a developers' guide Wiki for OpenVMS for
>> those of us, and I think there are quite a few, who have been writing
>> software for decades yet don't have a feel for doing so under (Open)VMS.
>
> It would be nice if there were some sort of standard BUILD.COM which
> would do everything (perhaps with parameters to determine whether one
> wants to use supplied .EXE, link supplied .OBJ, or compile from supplied
> sources). When finished, it can print out the required symbol
> definition (which one would presumably place with others), command to
> add the HELP to some library (ideally one would have a separate HELP
> library for such third-party products), and so on.

Yes.

I have been thinking about that - it would be very nice with a standard
for that.

My thoughts are:

foobar-1_2_3-src.zip with source

foobar-1_2_3-bin-vax.zip, foobar-1_2_3-bin-axp.zip,
foobar-1_2_3-bin-i64.zip and foobar-1_2_3-bin-x64.zip with obj and exe

all zip contains path foobar-1_2_3/bla/bla

build.com builds from source

link.com link obj (are called from build.com)

setup_logicals.com that define logicals and has a p1 so one can specify
"/system" and a p2 "yes" to specify that hlp$library_n to be defined

setup_symbols.com that define symbols and define verbs

Arne

On 22/11/2021 14:23, Craig A. Berry wrote:
> <https://sourceforge.net/p/gnv/wiki/Home/>

More without the GNU blinkers and lower level.

I'd like to see a guide to

* Interprocess (not network) communications
* Synchronisation
* The process model, debugging
* The (Files-11 I guess) filesystem
* Clustering features (and no seeing somebody gaffer tape a load of
Raspberry Pis together doesn't tell me much)
* Any features that are novel or handled quite differently in VMS

aimed at those with some knowledge of these thing in Unixen and MS Windows.

On Monday, November 22, 2021 at 4:55:27 PM UTC, Jon Schneider wrote:
> On 22/11/2021 14:23, Craig A. Berry wrote:
> > <https://sourceforge.net/p/gnv/wiki/Home/>
>
> More without the GNU blinkers and lower level.
>
> I'd like to see a guide to
>
> * Interprocess (not network) communications
> * Synchronisation
> * The process model, debugging
> * The (Files-11 I guess) filesystem
> * Clustering features (and no seeing somebody gaffer tape a load of
> Raspberry Pis together doesn't tell me much)
> * Any features that are novel or handled quite differently in VMS
>
> aimed at those with some knowledge of these thing in Unixen and MS Windows.
have you read the OpenVMS Programming Concepts Manual - volumes 1&2 ?

On 11/22/2021 11:55 AM, Jon Schneider wrote:
> On 22/11/2021 14:23, Craig A. Berry wrote:
>> <https://sourceforge.net/p/gnv/wiki/Home/>
>
> More without the GNU blinkers and lower level.
>
> I'd like to see a guide to

Can I guess that RTFM doesn't apply?

> * Interprocess (not network) communications

Mailboxes, global sections, both in the "fine manual" ...

> * Synchronisation

DLM (Distributed lock manager) and again, in the "fine manual" ...

> * The process model, debugging

Not sure of the question, but, manuals and ISDM ...

> * The (Files-11 I guess) filesystem

It's in there ...

> * Clustering features (and no seeing somebody gaffer tape a load of Raspberry
> Pis together doesn't tell me much)

I'd read the manual on clustering ...

> * Any features that are novel or handled quite differently in VMS
>
> aimed at those with some knowledge of these thing in Unixen and MS Windows.

Honestly, I'm not trying to be a smartass. (Well, actually I am a smartass, but
wasn't trying in this reply.)

The VMS documentation is quite extensive. So extensive that at times it's a bit
hard to know where to look. Recently I was looking for some info on ASTs, and I
went through at least 3 manuals before I found the info. But, "it's in there."

Thinking about that search, perhaps a tool to find references to particular
subjects would be rather helpful. For example, enter "AST" and get a list of
the manuals that mention ASTs and briefly what's in each manual.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2021-11-22 10:12:59 +0000, Jon Schneider said:

> I would really like to see a developers' guide Wiki for OpenVMS for
> those of us, and I think there are quite a few, who have been writing
> software for decades yet don't have a feel for doing so under (Open)VMS.

The VSI OpenVMS Programming Concepts manuals are the introduction to
this, and the OpenVMS Calling Standard manual.

https://docs.vmssoftware.com

The old Modular Procedures manual (no longer part of the doc set) and
the really-hard-to-find DIGITAL Software Engineering Manual,1988,
document identifier A-DG-ELEN571-00-0, have some more information on
how DEC envisioned designing, packaging, shipping, and supporting apps.

https://www.computerhistory.org/collections/catalog/102773805
https://www.nassi.com/VAX-11_SoftwEngrMan_Feb77.pdf (this is the 1977
predecessor version, though the 1988 version is vastly improved)

OpenVMS itself has no opinion on build procedures, though builds
inherently do presume compilers and related tooling and which may not
be or will not be available.

Compilations weren't something most DEC layered products did.

Which is why you see suggestions around a procedure for building and
another for linking.

Oh, and for C code there's one of my absolute favorite OpenVMS feature
of all time, the absolutely spectacular idea that are the feature
logical names. A mechanism which allows an out-of-band setting from
elsewhere in the build environment to re-tune or alter your source
build output and app run-time behavior in exceedingly arcane and subtle
ways. Even better, this is built atop logical names for app
configuration, a scheme which fell out of the 1970s and the corpse of
RSX-11M, and—outside of _maybe_ redirecting file paths—somebody should
dig up that corpse and re-bury the whole idea with it, then pour some
concrete over the grave with some engraved warnings for future
generations of developers that some ideas can come at too high a cost.

Some PCSI kits might link objects at install time, but providing
executables within install kits is commonplace.

Troubleshooting site-built executables is more difficult than
vendor-built executables, too—kits and users might build the necessary
listings and maps, or might not, or those files might get deleted and
which makes symbolicating and debugging crashes that much more
difficult.

There are various means to start apps. One being a manually-edited
startup file and a pair of manually-edited shutdown files, which is
common and quaint and error-prone. The other means is using the SYSMAN
tool, which would be preferred but for ~nobody using it, including PCSI
kits having had some hooks here but not using this. (I can think of
better ways to deal with all of this startup stuff, but manual edits
and PCSI—or maybe VMSINSTAL—is what we have.) There are other and
somewhat less-common means too, such as the auxiliary server (inetd).

There are many discussions of how to package and structure installed
apps too, though again OpenVMS itself and its tooling has few or no
opinions here. Some apps and kits scatter files through the system
directories, some create an app-specific directory structure. And
clustering complicates this, as now you can have two or more different
object file formats and executable formats involved, and can have both
a host-specific and a cluster-shared common directory. About the
biggest opinion in the PCSI tooling is a flat filename address space,
multi-architecture kits aren't all that well documented, and there can
be comparative difficulty in installing apps anywhere but on the system
disk.

For building, look around, and you'll find a mix of DECset MMS, MMK,
DCL, gmake, bash, and other tools used to build the apps, too.

OpenVMS has no means to package together and isolate app-related
features and dependencies (e.g. sandbox, container, jail, app bundle,
etc), and conflict avoidance is via facility prefixes and naming
conventions. Manual. No automation. Collisions with usernames and IP
ports and UICs and such can and do and have arisen. There's no facility
name coordination and no facility registrar at present AFAIK—x86-64
might be a good time to see that restarted—and which means name
collisions are possible. (These collisions happen less often due mostly
to few OpenVMS servers and few layered product kits and comparatively
few apps. This manually-coordinated by-convention model doesn't scale
all that well, but that hasn't been a problem in this millennium.)

One of the biggest mistakes I've encountered with OpenVMS apps is
incorporating flexibility around meaningless details—TCP/IP Services
configuration tool is one such example, where it's massively flexible
around what clients and what services get configured and how, and for
no benefit, and—with the different UICs and the rest of the
differences—with added complexity and costs. In 2021, nobody cares
about that, and it'd be easier to have everything configured, with the
only remaining decision being whether to start a particular service at
boot. And we still trip over the occasional bugs in all that
complexity. For... naught. The other is maintaining old and bad ideas
and broken APIs and limited APIs for far too long if not for forever,
but that's all fodder for several other debates.

Until and unless OpenVMS itself and the OpenVMS tooling has some
opinions here, I'd expect there can and will be as many different
opinions on how to name and organize and label build procedures and
source code distributions as there are developers involved. If not
more. Above comments obviously included.

BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
Really. Outright rejected that. Put slightly differently, some of the
open-source preferences around here can be... unexpected. Even among
folks that have worked with OpenVMS for decades.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-11-22 16:55:24 +0000, Jon Schneider said:

> I'd like to see a guide to
>
> * Interprocess (not network) communications

Use IP, or use TLS for sensitive traffic, or maybe use ICC
intra-cluster communications services.

The use cases for mailboxes and shared-memory sections and such do
exist, but are more limited in my experience, tend not to scale all
that well, and you can find yourself re-implementing IP networking and
locking and memory cache management and the rest and for little gain
over IP and with much added effort. I've done all this stuff with all
these mechanisms and with DECnet and and DLM-based comms and more,
and—until and unless IP ran out of performance—I'd use IP as the
baseline for even local communications.

TLS is a quagmire on OpenVMS too, as it's little better than a
bag-on-the-side, with no integrated root certificate list, and a whole
pile of command-line tooling to get anywhere. A framework to deal with
IPv4, IPv6, DNS, TLS, VPNs, and the rest has been discussed,
but—outside of some open source here—that won't happen until well after
OpenVMS x86-64 ships. If then.

> * Synchronisation

The distributed lock manager (the Linux distributed lock managers were
patterned on the OpenVMS lock manager, so it should look familiar),
interlocked bitlocks and interlocked queues. There's a chapter or three
in the programming concepts manuals on these topics.

And you'll want to read the processor architectural manuals for shared
memory caching, as Alpha memory caching and re-ordering is...
aggressive.

Or use IP.

> * The process model, debugging

That's not well documented anywhere, though the debugger manual is a
reasonable start. I once had some stuff on remote debugging and
debugging detached processes posted a whole while back, but that's all
been offline for some years now.

> * The (Files-11 I guess) filesystem

There's a manual or two on that in the doc set. Expect and assume
ODS-5, and expect to get derailed by some C feature logical name or
some ancient volume still stuck at ODS-2.

> * Clustering features (and no seeing somebody gaffer tape a load of
> Raspberry Pis together doesn't tell me much)

The cluster pricing rendered most cluster features infrequently
commercially used. There are a couple of manuals on this topic. One at
a higher level, one at a lower level. For programming, there's rather
less available in the docs. And app failover and the rest have
scattershot documentation.

> * Any features that are novel or handled quite differently in VMS

The only weird (useful) feature I can think of off-hand is software
RAID-1; Host-based Volume Shadowing. Pretty much the entirety of the
rest of the OpenVMS feature-set will have a corollary, analog, or
alternative on other platforms. Variously different, and variously
better. LDAP versus SYSUAF, for instance—outside of add-on
bag-on-the-side external authentication support, OpenVMS knows zilch
about LDAP. Which is just quaint from here in 2021.

> aimed at those with some knowledge of these thing in Unixen and MS Windows.

Trying to port over knowledge of Unix or Windows features and
expectations to OpenVMS tends to end badly, from a very long history of
folks trying to learn OpenVMS around here.

OpenVMS expects the developer to read much of the whole wall of
documentation, and doesn't really provide a cookbook-style
examples-based approach to app development. And there are gaps in the
docs that are less than fully visible to long-time developers. All of
which has been fodder for various previous discussions.

I've done day-long training sessions on these topics for various sites
and for experienced developers. But this whole area is one that starts
out very different from other platforms, and the resulting discussions
then go in myriad directions depending on local needs and expectations.

--
Pure Personal Opinion | HoffmanLabs LLC

In article <619bb33e$0$704$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:

> I have been thinking about that - it would be very nice with a standard
> for that.
>
> My thoughts are:
>
> foobar-1_2_3-src.zip with source
>
> foobar-1_2_3-bin-vax.zip, foobar-1_2_3-bin-axp.zip,
> foobar-1_2_3-bin-i64.zip and foobar-1_2_3-bin-x64.zip with obj and exe
>
> all zip contains path foobar-1_2_3/bla/bla
>
> build.com builds from source
>
> link.com link obj (are called from build.com)
>
> setup_logicals.com that define logicals and has a p1 so one can specify
> "/system" and a p2 "yes" to specify that hlp$library_n to be defined

I think that the ZIP file should create a directory which includes the
version number. Maybe one for all architectures, as the non-binary
files will be the same and some folks might have mixed clusters.

On 11/22/2021 3:43 PM, Phillip Helbig (undress to reply) wrote:
> In article <619bb33e$0$704$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>
>> I have been thinking about that - it would be very nice with a standard
>> for that.
>>
>> My thoughts are:
>>
>> foobar-1_2_3-src.zip with source
>>
>> foobar-1_2_3-bin-vax.zip, foobar-1_2_3-bin-axp.zip,
>> foobar-1_2_3-bin-i64.zip and foobar-1_2_3-bin-x64.zip with obj and exe
>>
>> all zip contains path foobar-1_2_3/bla/bla
>>
>> build.com builds from source
>>
>> link.com link obj (are called from build.com)
>>
>> setup_logicals.com that define logicals and has a p1 so one can specify
>> "/system" and a p2 "yes" to specify that hlp$library_n to be defined
>
> I think that the ZIP file should create a directory which includes the
> version number.

That is what:

>> all zip contains path foobar-1_2_3/bla/bla

means.

Arne

On 11/22/2021 4:09 PM, John Dallman wrote:
> In article <sngnui$bhh$1@dont-email.me>, seaohveh@hoffmanlabs.invalid
> (Stephen Hoffman) wrote:
>> BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS.
>> Yes. Really. Outright rejected that. Put slightly differently,
>> some of the open-source preferences around here can be...
>> unexpected.
>
> I have encountered companies who wanted nothing to do with open source
> because it "threatened their intellectual property"

There are a few rare problematic cases like (A)GPL and libraries,
but generally there is no problem.

> or "was communist."

I can not remember any open source software that comes
from a communist country.

Arne

On 11/22/2021 1:36 PM, Stephen Hoffman wrote:
> BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS.  Yes.
> Really. Outright rejected that. Put slightly differently, some of the
> open-source preferences around here can be... unexpected. Even among
> folks that have worked with OpenVMS for decades.

If it was HP(E) that made the offer then I would actually
have been skeptical as well - it could be part of a plan
to offload maintenance cost to the community aka drop support.

Arne

On 11/22/2021 1:36 PM, Stephen Hoffman wrote:

> BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
> Really. Outright rejected that. Put slightly differently, some of the
> open-source preferences around here can be... unexpected. Even among
> folks that have worked with OpenVMS for decades.

No surprise. People who use VMS like VMS. People who use VMS don't
like some open-source code, and don't like Richard
if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
Stallman and his ilk driving the community. (Yes, Stallman---who by all
accounts seems to be a rather creepy guy---really said that, insulting
millions of victims of real crimes against humanity.)

Has VMS been handled badly by its owners, including DEC? Sure. Should
the solution be open source? Probably not. The world is not black and
white, though it seems that more and more people try to see it that way,
e.g. either one supports Trump or one is woke. Whatever happened to
old-fashioned common sense?

On 22/11/2021 17:01, Ian Miller wrote:
> have you read the OpenVMS Programming Concepts Manual - volumes 1&2 ?

Ah no but I should (seriously).

Jon

On 11/23/2021 2:19 AM, Phillip Helbig (undress to reply) wrote:
> On 11/22/2021 1:36 PM, Stephen Hoffman wrote:
>> BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
>> Really. Outright rejected that. Put slightly differently, some of the
>> open-source preferences around here can be... unexpected. Even among
>> folks that have worked with OpenVMS for decades.
>
> No surprise. People who use VMS like VMS. People who use VMS don't
> like some open-source code,

Almost all VMS people use lots of open source.

Arne

In article <619ce9b1$0$698$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:

> On 11/23/2021 2:19 AM, Phillip Helbig (undress to reply) wrote:
> > On 11/22/2021 1:36 PM, Stephen Hoffman wrote:
> >> BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
> >> Really. Outright rejected that. Put slightly differently, some of the
> >> open-source preferences around here can be... unexpected. Even among
> >> folks that have worked with OpenVMS for decades.
> >
> > No surprise. People who use VMS like VMS. People who use VMS don't
> > like some open-source code,
>
> Almost all VMS people use lots of open source.

Yes. Not all is bad, by any means. I use some myself. But there are
many things to criticize about Gnu philosophy. I can understand people
not wanting VMS to go that route.

On 11/23/2021 8:38 AM, Phillip Helbig (undress to reply) wrote:
> In article <619ce9b1$0$698$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>> On 11/23/2021 2:19 AM, Phillip Helbig (undress to reply) wrote:
>>> On 11/22/2021 1:36 PM, Stephen Hoffman wrote:
>>>> BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
>>>> Really. Outright rejected that. Put slightly differently, some of the
>>>> open-source preferences around here can be... unexpected. Even among
>>>> folks that have worked with OpenVMS for decades.
>>>
>>> No surprise. People who use VMS like VMS. People who use VMS don't
>>> like some open-source code,
>>
>> Almost all VMS people use lots of open source.
>
> Yes. Not all is bad, by any means. I use some myself. But there are
> many things to criticize about Gnu philosophy. I can understand people
> not wanting VMS to go that route.

There is a very long line of people that don't like Stallman.

But an OS under GPL is not a license problem for users.

But GPL VMS by HE would have looked like an escape plan. And
GPL VMS by VSI sound like a bad business plan.

Arne

I went to several FreeBSD events in the before times and found several
companies with products where a major selling point was that it was free
of GPL (though not saying whether proprietary or some other license).

Just keep in mind open source does not necessarily GPL.

Jon

On 11/23/21 8:38 AM, Phillip Helbig (undress to reply) wrote:
> In article <619ce9b1$0$698$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>
>> On 11/23/2021 2:19 AM, Phillip Helbig (undress to reply) wrote:
>>> On 11/22/2021 1:36 PM, Stephen Hoffman wrote:
>>>> BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
>>>> Really. Outright rejected that. Put slightly differently, some of the
>>>> open-source preferences around here can be... unexpected. Even among
>>>> folks that have worked with OpenVMS for decades.
>>>
>>> No surprise. People who use VMS like VMS. People who use VMS don't
>>> like some open-source code,
>>
>> Almost all VMS people use lots of open source.
>
> Yes. Not all is bad, by any means. I use some myself. But there are
> many things to criticize about Gnu philosophy. I can understand people
> not wanting VMS to go that route.
>

I agree. GPLed software is not free it is encumbered and controlled
by the FSF. "Free" Opensource Software needs to come under something
like the BSD license which makes it truly free with no controlling
strings attached.

bill

On 11/23/2021 1:00 PM, Bill Gunshannon wrote:
> On 11/23/21 8:38 AM, Phillip Helbig (undress to reply) wrote:
>> In article <619ce9b1$0$698$14726298@news.sunsite.dk>,
>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>
>>> On 11/23/2021 2:19 AM, Phillip Helbig (undress to reply) wrote:
>>>> On 11/22/2021 1:36 PM, Stephen Hoffman wrote:
>>>>> BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS.  Yes.
>>>>> Really. Outright rejected that. Put slightly differently, some of the
>>>>> open-source preferences around here can be... unexpected. Even among
>>>>> folks that have worked with OpenVMS for decades.
>>>>
>>>> No surprise.  People who use VMS like VMS.  People who use VMS don't
>>>> like some open-source code,
>>>
>>> Almost all VMS people use lots of open source.
>>
>> Yes.  Not all is bad, by any means.  I use some myself.  But there are
>> many things to criticize about Gnu philosophy.  I can understand people
>> not wanting VMS to go that route.
>>
>
> I agree. GPLed software is not free it is encumbered and controlled
> by the FSF.  "Free" Opensource Software needs to come under something
> like the BSD license which makes it truly free with no controlling
> strings attached.

I think you are mixing some things up.

Most GNU projects has a policy of assigning copyright to FSF,
but that has nothing to do with GPL. Lot of GPL software has
nothing to do with FSF (except that FSF created the GPL license
text decades ago).

Whether permissive or copyleft licenses are most free depends
perspective. Permissive licenses allow for proprietary forks
while copyleft licenses ensure the code remains open source.
Is it more or less free if you restrict someone from restricting
others?

Strong copyleft licenses (GPL, AGPL) does not work for commercial
usage of libraries. That is a well known issue and often a topic for
heated debate. The practical impact is pretty small as very few
libraries are under such licenses. Libraries for obvious reasons
tend to pick weak copyleft licenses (LGPL, GPL with linking exception,
MPL etc.) - or permissive licenses.

Which permissive license to pick (BSD 2 clause, BSD 3 clause, Apache,
MIT etc.) is not so important. And it seems like the choice is
mostly determined by who is releasing the open source than the
specific license text. C code to be released under permissive
license are very often one of the BSD license flavors.

Arne

On Tuesday, November 23, 2021 at 8:19:21 PM UTC+13, Phillip Helbig (undress to reply) wrote:
> On 11/22/2021 1:36 PM, Stephen Hoffman wrote:
>
> No surprise. People who use VMS like VMS. People who use VMS don't
> like some open-source code, and don't like Richard
> if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
> Stallman and his ilk driving the community. (Yes, Stallman---who by all
> accounts seems to be a rather creepy guy---really said that, insulting
> millions of victims of real crimes against humanity.)

It has been some years since RMS had any real influence. Most open-source
software is unaffiliated with the Free Software Foundation or the GNU project.
Quite a lot these days is built by companies like Intel, IBM, Apple, Microsoft and
Google.

>
> > BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
> > Really. Outright rejected that. Put slightly differently, some of the
> > open-source preferences around here can be... unexpected. Even among
> > folks that have worked with OpenVMS for decades.
> No surprise. People who use VMS like VMS. People who use VMS don't
> like some open-source code, and don't like Richard
> if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
> Stallman and his ilk driving the community. (Yes, Stallman---who by all
> accounts seems to be a rather creepy guy---really said that, insulting
> millions of victims of real crimes against humanity.)
>
> Has VMS been handled badly by its owners, including DEC? Sure. Should
> the solution be open source? Probably not. The world is not black and
> white, though it seems that more and more people try to see it that way,
> e.g. either one supports Trump or one is woke. Whatever happened to
> old-fashioned common sense?

If it had been open sourced then VAX hobbyists wouldn't be loosing access
to OpenVMS at the end of this year. Same goes for people with older Alpha
hardware.

I think the main thing open-sourcing it would have achieved is securing *a*
future for it. It would have guaranteed access indefinitely to anyone with an
interest in running it.

Now is there is no guarantee VMS will be available long term - its continued
availability depends on it being profitable. If VSI is not replacing every customer
that leaves then eventually everyone who is not the original owner of a permanent
license will find themselves in the same situation as VAX hobbyists.

On 11/24/2021 2:26 PM, David Goodwin wrote:
> On Tuesday, November 23, 2021 at 8:19:21 PM UTC+13, Phillip Helbig (undress to reply) wrote:
>> On 11/22/2021 1:36 PM, Stephen Hoffman wrote:
>>> BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
>>> Really. Outright rejected that. Put slightly differently, some of the
>>> open-source preferences around here can be... unexpected. Even among
>>> folks that have worked with OpenVMS for decades.
>> No surprise. People who use VMS like VMS. People who use VMS don't
>> like some open-source code, and don't like Richard
>> if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
>> Stallman and his ilk driving the community. (Yes, Stallman---who by all
>> accounts seems to be a rather creepy guy---really said that, insulting
>> millions of victims of real crimes against humanity.)
>>
>> Has VMS been handled badly by its owners, including DEC? Sure. Should
>> the solution be open source? Probably not. The world is not black and
>> white, though it seems that more and more people try to see it that way,
>> e.g. either one supports Trump or one is woke. Whatever happened to
>> old-fashioned common sense?
>
> If it had been open sourced then VAX hobbyists wouldn't be loosing access
> to OpenVMS at the end of this year. Same goes for people with older Alpha
> hardware.
>
> I think the main thing open-sourcing it would have achieved is securing *a*
> future for it. It would have guaranteed access indefinitely to anyone with an
> interest in running it.
>
> Now is there is no guarantee VMS will be available long term - its continued
> availability depends on it being profitable. If VSI is not replacing every customer
> that leaves then eventually everyone who is not the original owner of a permanent
> license will find themselves in the same situation as VAX hobbyists.

I don't think there is much point as I don't think VSI can make VMS
open source and HPE won't make VMS open source.

But even if they could and would, then I am not so sure about how
well it would work out.

The VMS community is notorious for how few that actually contribute
to open source, so the VMS community could not drive the development.

VSI can drive the development, but need to make money. Redhat makes
a lot of money from Linux, but there is a lot of Linux systems out there
and Redhat can keep the price so low that their commercial offering
still sell despite various free clones. But VMS does not have that
volume.

Arne

On Thursday, November 25, 2021 at 9:20:55 AM UTC+13, Arne Vajhøj wrote:
> On 11/24/2021 2:26 PM, David Goodwin wrote:
> > On Tuesday, November 23, 2021 at 8:19:21 PM UTC+13, Phillip Helbig (undress to reply) wrote:
> >> On 11/22/2021 1:36 PM, Stephen Hoffman wrote:
> >>> BTW: OpenVMS customers REJECTED an offer to open-source OpenVMS. Yes.
> >>> Really. Outright rejected that. Put slightly differently, some of the
> >>> open-source preferences around here can be... unexpected. Even among
> >>> folks that have worked with OpenVMS for decades.
> >> No surprise. People who use VMS like VMS. People who use VMS don't
> >> like some open-source code, and don't like Richard
> >> if-your-code-is-not-open-source-then-that-is-a-crime-against-humanity M.
> >> Stallman and his ilk driving the community. (Yes, Stallman---who by all
> >> accounts seems to be a rather creepy guy---really said that, insulting
> >> millions of victims of real crimes against humanity.)
> >>
> >> Has VMS been handled badly by its owners, including DEC? Sure. Should
> >> the solution be open source? Probably not. The world is not black and
> >> white, though it seems that more and more people try to see it that way,
> >> e.g. either one supports Trump or one is woke. Whatever happened to
> >> old-fashioned common sense?
> >
> > If it had been open sourced then VAX hobbyists wouldn't be loosing access
> > to OpenVMS at the end of this year. Same goes for people with older Alpha
> > hardware.
> >
> > I think the main thing open-sourcing it would have achieved is securing *a*
> > future for it. It would have guaranteed access indefinitely to anyone with an
> > interest in running it.
> >
> > Now is there is no guarantee VMS will be available long term - its continued
> > availability depends on it being profitable. If VSI is not replacing every customer
> > that leaves then eventually everyone who is not the original owner of a permanent
> > license will find themselves in the same situation as VAX hobbyists.
> I don't think there is much point as I don't think VSI can make VMS
> open source and HPE won't make VMS open source.
>
> But even if they could and would, then I am not so sure about how
> well it would work out.
>
> The VMS community is notorious for how few that actually contribute
> to open source, so the VMS community could not drive the development.
>
> VSI can drive the development, but need to make money. Redhat makes
> a lot of money from Linux, but there is a lot of Linux systems out there
> and Redhat can keep the price so low that their commercial offering
> still sell despite various free clones. But VMS does not have that
> volume.

Yeah, it seems unlikely the OpenVMS community would jump in and keep
the operating system alive. But I expect if the code was available someone
would eventually compile it and a free distribution of OpenVMS would then
exist.

Supposedly HPE was considering open-sourcing it but if that was ever going
to happen it had to happen back when HPE announced OpenVMS was dead.
When there were still people at HPE who knew what OpenVMS was and
before VSI stepped in. I expect by the time OpenVMS is no longer
commercially viable at VSI there will be no one left at HPE with the ability
to open-source it. Most likely at some point in the next few decades
OpenVMS will join Tru64, Ultrix and all the other operating systems that can
not be licensed anymore.