Discussion:
Python and various libraries updated
(too old to reply)
Jean-François Piéronne
2020-06-06 08:53:11 UTC
Permalink
I have released an update of Python 2.7.

Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.

I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.

Mercurial 5.4 and evolve extension is also included.

The full list of updated libraries is on https://www.vmspython.org/

Sources on https://foss.vmsgenerations.org/

Next version will be 3.10, probably in a few months, maybe early.

We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST

Version 2, Release 2.3
"""


I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,

Jean-François
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jean-François Piéronne
2020-06-06 08:58:02 UTC
Permalink
Post by Jean-François Piéronne
Sources on https://foss.vmsgenerations.org/
Sorry it's https://foss.vmsgenerations.fr/
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Dave Froble
2020-06-06 20:57:45 UTC
Permalink
Post by Jean-François Piéronne
I have released an update of Python 2.7.
Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.
I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.
Mercurial 5.4 and evolve extension is also included.
The full list of updated libraries is on https://www.vmspython.org/
Sources on https://foss.vmsgenerations.org/
Next version will be 3.10, probably in a few months, maybe early.
We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST
Version 2, Release 2.3
"""
I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,
Jean-François
Why aren't you contacting VSI for a developer account?

I don't have decent internet or I'd let you use one of my systems.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jean-François Piéronne
2020-06-06 21:22:15 UTC
Permalink
[snip]
Post by Dave Froble
Why aren't you contacting VSI for a developer account?
I don't have decent internet or I'd let you use one of my systems.
The problem is not the software, it's the hardware, my ia64 box is not
accessible, and will not be accessible before a long time.
JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
IanD
2020-06-07 09:44:33 UTC
Permalink
Surely VSI is able to assist people who provide such useful fundamental open source distributions such as this by providing some type of access to an actual environment they have?

Python 3 is sorely needed and the extra work done on rdb integration and VMS specific calls is something that's more than just a straight out port of opensouce to VMS
Phillip Helbig (undress to reply)
2020-06-07 10:46:02 UTC
Permalink
Post by IanD
Surely VSI is able to assist people who provide such useful fundamental
open source distributions such as this by providing some type of access
to an actual environment they have?
How fundamental Python is depends on the user, but I take your point.
Post by IanD
Python 3 is sorely needed and the extra work done on rdb integration
and VMS specific calls is something that's more than just a straight
out port of opensouce to VMS
Perhaps SMS can get such an account to get ZIP and UNZIP up to speed on
x86. Maybe just compile and go, but maybe not.

A good place to start would be to make sure that everything at Hunter's
VMS-package site works on x86.
Simon Clubley
2020-06-08 12:17:33 UTC
Permalink
Post by IanD
Surely VSI is able to assist people who provide such useful fundamental open source distributions such as this by providing some type of access to an actual environment they have?
In the absence of a free full-system IA64 emulator, I wonder if VSI
could consider providing a VSI version of the old HP Testdrive cluster
so that people could compile and test their open source programs on it.

That would be to VSI's benefit as well.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-06-08 14:40:12 UTC
Permalink
Post by Simon Clubley
Post by IanD
Surely VSI is able to assist people who provide such useful fundamental open source distributions such as this by providing some type of access to an actual environment they have?
In the absence of a free full-system IA64 emulator, I wonder if VSI
could consider providing a VSI version of the old HP Testdrive cluster
so that people could compile and test their open source programs on it.
That would be to VSI's benefit as well.
Simon.
Don't they already? DECUSserve, or whatever it's called provides
accounts, doesn't it? I've never had to use it, so I'm not familiar
with it.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2020-06-08 17:17:15 UTC
Permalink
Post by Dave Froble
Post by Simon Clubley
In the absence of a free full-system IA64 emulator, I wonder if VSI
could consider providing a VSI version of the old HP Testdrive cluster
so that people could compile and test their open source programs on it.
That would be to VSI's benefit as well.
Don't they already? DECUSserve, or whatever it's called provides
accounts, doesn't it? I've never had to use it, so I'm not familiar
with it.
Eisner is Alpha, not Itanium.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-06-08 20:17:29 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
In the absence of a free full-system IA64 emulator, I wonder if VSI
could consider providing a VSI version of the old HP Testdrive cluster
so that people could compile and test their open source programs on it.
That would be to VSI's benefit as well.
Don't they already? DECUSserve, or whatever it's called provides
accounts, doesn't it? I've never had to use it, so I'm not familiar
with it.
Eisner is Alpha, not Itanium.
Simon.
From the OP ..

"I'm also looking for a development 8.4 environment Alpha and IA64,"

So, Eisner would then satisfy half of his requirements?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2020-06-09 12:11:02 UTC
Permalink
Post by Dave Froble
From the OP ..
"I'm also looking for a development 8.4 environment Alpha and IA64,"
So, Eisner would then satisfy half of his requirements?
Maybe, but there are Alpha emulators out there, including one
(constrained) free version of a commercial product, which can
be run locally.

There are no such freely available IA64 system level emulators.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Jan-Erik Söderholm
2020-06-09 12:38:05 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
From the OP ..
"I'm also looking for a development 8.4 environment Alpha and IA64,"
So, Eisner would then satisfy half of his requirements?
Maybe, but there are Alpha emulators out there, including one
(constrained) free version of a commercial product, which can
be run locally.
There are no such freely available IA64 system level emulators.
Simon.
I have had some communication with Jean-François rearding a Alpha
environment (that was when I had my DS25 up and running). As far
as I understand even a DS10 is on the limit to run this Python build.

An emulator would, as far as I understand, be out of the question.

The Alpha build is today years behind the IA64...
Terry Kennedy
2020-06-11 00:53:02 UTC
Permalink
Post by Jan-Erik Söderholm
An emulator would, as far as I understand, be out of the question.
The Alpha build is today years behind the IA64...
FWIW, my purchased copy of AlphaVM-Pro runs rings around the actual DS10 it replaced, and that is on ancient Xeon X5680 (10 year old) host CPUs. Modern CPUs are much faster and include new instructions AlphaVM can use to improve performance even further. You do want a smaller number of faster cores, instead of the more cores = better of most products.
Jean-François Piéronne
2020-06-15 07:59:04 UTC
Permalink
Current status:

$ python3
Python 3.10.0a0 (default, Jun 14 2020, 21:22:18) [C] on OpenVMS
Type "help", "copyright", "credits" or "license" for more information.
import sys
print('Hello %s world!!!' % sys.platform)
Hello OpenVMS world!!!
Exit
$

A big thanks to Jeremy Begg who gives me access to one of his system.

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jan-Erik Söderholm
2020-06-20 09:35:32 UTC
Permalink
Post by Jean-François Piéronne
I have released an update of Python 2.7.
Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.
I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.
Mercurial 5.4 and evolve extension is also included.
The full list of updated libraries is on https://www.vmspython.org/
Sources on https://foss.vmsgenerations.org/
Next version will be 3.10, probably in a few months, maybe early.
We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST
Version 2, Release 2.3
"""
I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,
Jean-François
If I just might ask...

The latest Alpha kit is from 31-oct-2014. Since then no new Alpha
LD kit has been compiled (or at least not published).

Now, *if* there would be a suitable Alpha build environment, would it
be correct to expect that all the new and updated modules mentioned
on the "history" page would also be available on Alpha? Or are there
any that are IA64 specific or are hard to build on Alpha?

https://www.vmspython.org/doku.php?id=history
Jean-François Piéronne
2020-06-20 09:49:12 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Jean-François Piéronne
I have released an update of Python 2.7.
Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.
I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.
Mercurial 5.4 and evolve extension is also included.
The full list of updated libraries is on https://www.vmspython.org/
Sources on https://foss.vmsgenerations.org/
Next version will be 3.10, probably in a few months, maybe early.
We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST
Version 2, Release 2.3
"""
I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,
Jean-François
If I just might ask...
The latest Alpha kit is from 31-oct-2014. Since then no new Alpha
LD kit has been compiled (or at least not published).
Now, *if* there would be a suitable Alpha build environment, would it
be correct to expect that all the new and updated modules mentioned
on the "history" page would also be available on Alpha? Or are there
any that are IA64 specific or are hard to build on Alpha?
https://www.vmspython.org/doku.php?id=history
As I have mentioned in a previous note, I don't have any Alpha system so
I wasn't able to build up-to-date libraries/Python versions.

Except this, it is probably easy, to build a new release for Alpha.

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jan-Erik Söderholm
2020-06-20 10:07:05 UTC
Permalink
Post by Jean-François Piéronne
Post by Jan-Erik Söderholm
Post by Jean-François Piéronne
I have released an update of Python 2.7.
Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.
I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.
Mercurial 5.4 and evolve extension is also included.
The full list of updated libraries is on https://www.vmspython.org/
Sources on https://foss.vmsgenerations.org/
Next version will be 3.10, probably in a few months, maybe early.
We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST
Version 2, Release 2.3
"""
I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,
Jean-François
If I just might ask...
The latest Alpha kit is from 31-oct-2014. Since then no new Alpha
LD kit has been compiled (or at least not published).
Now, *if* there would be a suitable Alpha build environment, would it
be correct to expect that all the new and updated modules mentioned
on the "history" page would also be available on Alpha? Or are there
any that are IA64 specific or are hard to build on Alpha?
https://www.vmspython.org/doku.php?id=history
As I have mentioned in a previous note, I don't have any Alpha system so
I wasn't able to build up-to-date libraries/Python versions.
Except this, it is probably easy, to build a new release for Alpha.
JF
Thanks for your quick reply. And yes, this might have been mentioned
before, as you say... :-) I'll take a another look for a possible
Alpha system...

JE
Mark Daniel
2020-06-20 14:33:03 UTC
Permalink
Post by Jean-François Piéronne
Post by Jan-Erik Söderholm
Post by Jean-François Piéronne
I have released an update of Python 2.7.
Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.
I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.
Mercurial 5.4 and evolve extension is also included.
The full list of updated libraries is on https://www.vmspython.org/
Sources on https://foss.vmsgenerations.org/
Next version will be 3.10, probably in a few months, maybe early.
We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST
Version 2, Release 2.3
"""
I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,
Jean-François
If I just might ask...
The latest Alpha kit is from 31-oct-2014. Since then no new Alpha
LD kit has been compiled (or at least not published).
Now, *if* there would be a suitable Alpha build environment, would it
be correct to expect that all the new and updated modules mentioned
on the "history" page would also be available on Alpha? Or are there
any that are IA64 specific or are hard to build on Alpha?
https://www.vmspython.org/doku.php?id=history
As I have mentioned in a previous note, I don't have any Alpha system so
I wasn't able to build up-to-date libraries/Python versions.
EISNER? https://eisner.decus.org

VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2

Might need additional disk quota.
Post by Jean-François Piéronne
Except this, it is probably easy, to build a new release for Alpha.
JF
Robert A. Brooks
2020-06-20 18:34:27 UTC
Permalink
Post by Jean-François Piéronne
As I have mentioned in a previous note, I don't have any Alpha system so
I wasn't able to build up-to-date libraries/Python versions.
EISNER?  https://eisner.decus.org
VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2
Might need additional disk quota.
If anyone needs any additional disk space on EISNER::, please let me know.
--
-- Rob
Jean-François Piéronne
2020-06-20 11:52:47 UTC
Permalink
Current status of 3.10 port:

$ python3
Python 3.10.0a0 (default, Jun 20 2020, 19:33:47) [C] on OpenVMS
Type "help", "copyright", "credits" or "license" for more information.
import os
os.uname()
posix.uname_result(sysname='OpenVMS', nodename='HAVEN', release='0',
version='V8
.4-2L1', machine='HP_rx2660__(1.40GHz/6.0MB)')
Exit
All OpenVMS extension ported to Python3, libffi upgraded to 3.3, ctypes
built with this version, so it is fairly easy to move vms specific
programs from 2.7 to 3.10.

Currently, missing the subprocess module and to apply various OpenVMS
fix from 2.7 in the .py libraries files, some already done

Rdb module, also missing. Mainly because the system I used doesn't have
Rdb installed.


JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jean-François Piéronne
2020-06-25 06:05:51 UTC
Permalink
A first release of Python 3.10a0 for OpenVMS is online.
http://downloads.vmspython.org/anonymous/kits/ia64/images_ld/

All the VMS modules have been ported, so any 2.7 program using these
extensions can be easily ported to Python 3.

The Rdb module is, not yet, ported, but is high in my to-do list.

As usual, sources, issues on https://foss.vmsgenerations.fr/ (will be
.org soon)

I will add other modules, like in 2.7 version, later. Let me know which
are required.

Jean-François
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jean-François Piéronne
2020-06-30 15:46:14 UTC
Permalink
Post by Jean-François Piéronne
A first release of Python 3.10a0 for OpenVMS is online.
http://downloads.vmspython.org/anonymous/kits/ia64/images_ld/
All the VMS modules have been ported, so any 2.7 program using these
extensions can be easily ported to Python 3.
The Rdb module is, not yet, ported, but is high in my to-do list.
A new version of the LD image is online with the rdb module, and a few
fixes.
lxml module is also included.

Jean-François
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
John H. Reinhardt
2020-07-01 03:11:40 UTC
Permalink
Post by Jean-François Piéronne
I have released an update of Python 2.7.
Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.
I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.
Mercurial 5.4 and evolve extension is also included.
The full list of updated libraries is on https://www.vmspython.org/
Sources on https://foss.vmsgenerations.org/
Next version will be 3.10, probably in a few months, maybe early.
We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST
Version 2, Release 2.3
"""
I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,
Jean-François
I seem to be doing something wrong. All I find are older releases when I look at <http://downloads.vmspython.org/anonymous/kits/axp/images_ld/> I see

Index of /anonymous/kits/axp/images_ld/:
jfplib0007a.zip 15-Oct-2014 13:38 39444243
jfplib0008A.zip 31-Oct-2014 08:19 41162971
jfppy0601a_278.zip 15-Oct-2014 12:28 70414439
jfppy0700a_278.zip 31-Oct-2014 08:24 72044024


The dates and file names don't match what I see in the history pages. Am I looking in the wrong place?

The individual kits seem to be old, too.

Index of /anonymous/kits/axp/
../
images_ld/ 31-Oct-2014 08:33 -
FREETYPE-V0203-7-1.zip 16-Sep-2014 18:54 1424062
LIBBZ2-V0100-6-1.zip 16-Sep-2014 18:54 245385
LIBGD-V0200-35-1.zip 16-Sep-2014 18:54 1475174
LIBIMAGING-V0101-6-1.zip 16-Sep-2014 18:54 373812
LIBJPEG-V0804--1.zip 16-Sep-2014 18:54 1471118
LIBPNG-V0105-13-1.zip 16-Sep-2014 18:54 986101
LIBXML2-V0209-1-1.zip 16-Sep-2014 18:56 25298464
LIBXSLT-V0101-28-1.zip 16-Sep-2014 18:56 1695401
MYSQL051-V2301-0-1.zip 16-Sep-2014 18:56 16733728
PCCTS-V0133-13-1.zip 16-Oct-2014 14:15 429826
PYTHON278-V0100-0-1.zip 16-Sep-2014 19:00 38733025
PYTHON278-V0101-0-1.zip 15-Oct-2014 12:35 39536062
PYTHON278-V0102-0-1.zip 30-Oct-2014 22:14 41084052
SQLITE3-V0717-1-1.zip 30-Oct-2014 21:06 1719786
WEBWARE093-V0100-0-1.zip 16-Sep-2014 19:00 930478
ZLIB-V0102-7-1.zip 16-Sep-2014 19:00 1321766
ZLIB-V0102-8-1.zip 15-Oct-2014 12:53 740281

Thanks.
--
John H. Reinhardt
Jean-François Piéronne
2020-07-01 05:28:37 UTC
Permalink
Post by Jean-François Piéronne
I have released an update of Python 2.7.
Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.
I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.
Mercurial 5.4 and evolve extension is also included.
The full list of updated libraries is on https://www.vmspython.org/
Sources on https://foss.vmsgenerations.org/
Next version will be 3.10, probably in a few months, maybe early.
We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST
Version 2, Release 2.3
"""
I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,
Jean-François
I seem to be doing something wrong.  All I find are older releases when
I look at <http://downloads.vmspython.org/anonymous/kits/axp/images_ld/>
I see
jfplib0007a.zip                                    15-Oct-2014
13:38            39444243
jfplib0008A.zip                                    31-Oct-2014
08:19            41162971
jfppy0601a_278.zip                                 15-Oct-2014
12:28            70414439
jfppy0700a_278.zip                                 31-Oct-2014
08:24            72044024
The dates and file names don't match what I see in the history pages. 
Am I looking in the wrong place?
That's correct, currently, only IA64.
But build AXP version is, now, high on my to-do list.
My plan is to build 2.7.18 environment on AXP 8.3 and 3.10 on 8.4-2-Lx
I will have to take a look at pointers posted for AXP system available.

I expect, if I found a system, to build 2.7.18 and 3.10 this month.

Regards,

Jean-François
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jan-Erik Söderholm
2020-07-01 06:32:14 UTC
Permalink
Post by Jean-François Piéronne
Post by Jean-François Piéronne
I have released an update of Python 2.7.
Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.
I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.
Mercurial 5.4 and evolve extension is also included.
The full list of updated libraries is on https://www.vmspython.org/
Sources on https://foss.vmsgenerations.org/
Next version will be 3.10, probably in a few months, maybe early.
We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST
Version 2, Release 2.3
"""
I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,
Jean-François
I seem to be doing something wrong.  All I find are older releases when
I look at <http://downloads.vmspython.org/anonymous/kits/axp/images_ld/>
I see
jfplib0007a.zip                                    15-Oct-2014
13:38            39444243
jfplib0008A.zip                                    31-Oct-2014
08:19            41162971
jfppy0601a_278.zip                                 15-Oct-2014
12:28            70414439
jfppy0700a_278.zip                                 31-Oct-2014
08:24            72044024
The dates and file names don't match what I see in the history pages.
Am I looking in the wrong place?
You are looking at the right place, if you want the Alpha kits.
They are currently behind IA64:

Index of /anonymous/kits/ia64/images_ld/

jfplib0009I.zip 22-Jan-2017 08:05 78926414
jfplib0010I.zip 19-May-2020 15:24 84295485
jfplib0020i.zip 30-Jun-2020 07:42 123767761
jfppy1200i_2713.zip 01-Feb-2019 14:25 78608422
jfppy1201i_2713.zip 08-May-2020 17:02 72235920
jfppy1300i_2713.zip 19-May-2020 15:24 71965289
jfppy1400i_2718.zip 08-Jun-2020 14:18 41523190
jfppy3100i_3100.zip 30-Jun-2020 12:55 134067035

I am/was planning to setup and make an DS15 or DS25 available for
my own testing, but it cold also be used to build the Python kits.

I do not know if (or think that) I will make a 8.3 system available,
only 8.4-2L2. So if someone absolutelly must have a Python kit for
Alpha 8.3, my system will probably not help.

But this is stalling due to licencing questions. Will probably have
to wait for the Community License after the summer vacations.

Jan-Erik.
Post by Jean-François Piéronne
That's correct, currently, only IA64.
But build AXP version is, now, high on my to-do list.
My plan is to build 2.7.18 environment on AXP 8.3 and 3.10 on 8.4-2-Lx
I will have to take a look at pointers posted for AXP system available.
I expect, if I found a system, to build 2.7.18 and 3.10 this month.
Regards,
Jean-François
John H. Reinhardt
2020-07-01 09:49:28 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Jean-François Piéronne
Post by Jean-François Piéronne
I have released an update of Python 2.7.
Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.
I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.
Mercurial 5.4 and evolve extension is also included.
The full list of updated libraries is on https://www.vmspython.org/
Sources on https://foss.vmsgenerations.org/
Next version will be 3.10, probably in a few months, maybe early.
We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST
Version 2, Release 2.3
"""
I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,
Jean-François
I seem to be doing something wrong.  All I find are older releases when
I look at <http://downloads.vmspython.org/anonymous/kits/axp/images_ld/>
I see
jfplib0007a.zip                                    15-Oct-2014
13:38            39444243
jfplib0008A.zip                                    31-Oct-2014
08:19            41162971
jfppy0601a_278.zip                                 15-Oct-2014
12:28            70414439
jfppy0700a_278.zip                                 31-Oct-2014
08:24            72044024
The dates and file names don't match what I see in the history pages.
Am I looking in the wrong place?
You are looking at the right place, if you want the Alpha kits.
Index of /anonymous/kits/ia64/images_ld/
jfplib0009I.zip           22-Jan-2017 08:05            78926414
jfplib0010I.zip           19-May-2020 15:24            84295485
jfplib0020i.zip           30-Jun-2020 07:42           123767761
jfppy1200i_2713.zip       01-Feb-2019 14:25            78608422
jfppy1201i_2713.zip       08-May-2020 17:02            72235920
jfppy1300i_2713.zip       19-May-2020 15:24            71965289
jfppy1400i_2718.zip       08-Jun-2020 14:18            41523190
jfppy3100i_3100.zip       30-Jun-2020 12:55           134067035
I am/was planning to setup and make an DS15 or DS25 available for
my own testing, but it cold also be used to build the Python kits.
I do not know if (or think that) I will make a 8.3 system available,
only 8.4-2L2. So if someone absolutelly must have a Python kit for
Alpha 8.3, my system will probably not help.
But this is stalling due to licencing questions. Will probably have
to wait for the Community License after the summer vacations.
Jan-Erik.
Post by Jean-François Piéronne
That's correct, currently, only IA64.
But build AXP version is, now, high on my to-do list.
My plan is to build 2.7.18 environment on AXP 8.3 and 3.10 on 8.4-2-Lx
I will have to take a look at pointers posted for AXP system available.
I expect, if I found a system, to build 2.7.18 and 3.10 this month.
Regards,
Jean-François
Now I get it. Somehow it didn't all sink in that Jean-Francois was having a problem getting the Alpha built. I'm officially dense.
--
John H. Reinhardt
Rich Jordan
2020-07-02 23:18:15 UTC
Permalink
Post by Jean-François Piéronne
I have released an update of Python 2.7.
Python 2.7.18 which is the 2.7 final version is available, I have also
updated most of the libraries to the latest version.
I have removed (temporary ?) some very old Python module, if some needed
modules are missing let me know, I will add them.
Mercurial 5.4 and evolve extension is also included.
The full list of updated libraries is on https://www.vmspython.org/
Sources on https://foss.vmsgenerations.org/
Next version will be 3.10, probably in a few months, maybe early.
We have also Open Source the Zabbix agent and a tool to check if a VMS
system follows the security rules mentioned in a document named
"""OpenVMS SECURITY CHECKLIST
Version 2, Release 2.3
"""
I'm also looking for a development 8.4 environment Alpha and IA64, mine
is only 7.3-2 on Alpha and 8.3 on IA64.
Thanks,
Jean-François
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Thank you for keeping this going! It'll be a while unfortunately before I have time to update (too many microsoft diapers to change) but I'm keeping track of things Python on VMS for future use.
Jean-François Piéronne
2020-07-03 05:56:35 UTC
Permalink
Le 03/07/2020 à 01:18, Rich Jordan a écrit :
[snip]
Post by Rich Jordan
Thank you for keeping this going! It'll be a while unfortunately before I have time to update (too many microsoft diapers to change) but I'm keeping track of things Python on VMS for future use.
Thanks,
I have, yesterday, put online a new version of the Python 3.10a0 LD
image (IA64 VMS 8.4-2L1). I have converted all vms.* examples and fixed
a few issues. I have started to included more modules.
Currently, PyMySQL, dateutil, lxml, six, cython are included in the
latest LD.
Paramiko, cjson, pyyaml, pika and openpyxl requested by some customers
will be added soon.

I have, I hope..., solved the AXP 8.3 problems, so I will be able to
build 2.7.18 and Mercurial 5.4 (maybe 5.4.1) on AXP.

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jean-François Piéronne
2020-07-10 11:58:20 UTC
Permalink
A new LD image is online.

Add some modules, a new version of the subprocess module.

Repositories site moved to .org, so now
https://foss.vmsgenerations.org/

How to manage sources using modern tools:
https://www.mercurial-scm.org/doc/evolution/user-guide.html

https://www.mercurial-scm.org/doc/evolution/

And this can be used on VMS, this is how I develop.

Sure, to do this, you have to publish sources and not violate open
source licenses, but I digress...

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jan-Erik Söderholm
2020-07-10 12:05:33 UTC
Permalink
Post by Jean-François Piéronne
A new LD image is online.
Add some modules, a new version of the subprocess module.
Repositories site moved to .org, so now
https://foss.vmsgenerations.org/
https://www.mercurial-scm.org/doc/evolution/user-guide.html
https://www.mercurial-scm.org/doc/evolution/
And this can be used on VMS, this is how I develop.
Sure, to do this, you have to publish sources and not violate open
source licenses, but I digress...
JF
Are those "you have to" points a must to use Mercurial??
Can't you use Mercurial for your own closed sources?
Jean-François Piéronne
2020-07-10 12:15:58 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Jean-François Piéronne
A new LD image is online.
Add some modules, a new version of the subprocess module.
Repositories site moved to .org, so now
https://foss.vmsgenerations.org/
https://www.mercurial-scm.org/doc/evolution/user-guide.html
https://www.mercurial-scm.org/doc/evolution/
And this can be used on VMS, this is how I develop.
Sure, to do this, you have to publish sources and not violate open
source licenses, but I digress...
JF
Are those "you have to" points a must to use Mercurial??
Now I have using evolve, what I can say is that I will not go back, for
all my development I used it.
Post by Jan-Erik Söderholm
Can't you use Mercurial for your own closed sources?
Sure I used it for my closed sources, I have a customer who is setting a
heptapod private environment.
But if you work on Open Source projects, you have to respect the license
of those projects.

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jean-François Piéronne
2020-07-10 12:55:12 UTC
Permalink
Just a little more information, the workflow I used is described in
https://heptapod.net/pages/quick-start-guide.html#quick-start-guide

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jan-Erik Söderholm
2020-07-10 12:59:51 UTC
Permalink
Post by Jean-François Piéronne
Post by Jan-Erik Söderholm
Post by Jean-François Piéronne
A new LD image is online.
Add some modules, a new version of the subprocess module.
Repositories site moved to .org, so now
https://foss.vmsgenerations.org/
https://www.mercurial-scm.org/doc/evolution/user-guide.html
https://www.mercurial-scm.org/doc/evolution/
And this can be used on VMS, this is how I develop.
Sure, to do this, you have to publish sources and not violate open
source licenses, but I digress...
JF
Are those "you have to" points a must to use Mercurial??
Now I have using evolve, what I can say is that I will not go back, for
all my development I used it.
Post by Jan-Erik Söderholm
Can't you use Mercurial for your own closed sources?
Sure I used it for my closed sources, I have a customer who is setting a
heptapod private environment.
OK.
Post by Jean-François Piéronne
But if you work on Open Source projects, you have to respect the license
of those projects.
Sure! But that has nothing to do with Mercurial as such, has it?
Post by Jean-François Piéronne
JF
Jean-François Piéronne
2020-07-10 13:22:44 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Jean-François Piéronne
But if you work on Open Source projects, you have to respect the license
of those projects.
Sure! But that has nothing to do with Mercurial as such, has it?
A little, just to mention that we have the tools to set up a modern
environment to federate open-source projects on vms, but as I have said,
I have digressed...

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jean-François Piéronne
2020-07-25 09:13:45 UTC
Permalink
Most of the libraries and Python 2.7 for AXP has been updated.
Python 2.7.18, Mercurial 5.4-2.

As usual, I will put online two new LD images, next week. VMS 8.3 required.

So, Python 3.10a0 can be ported to AXP 8.4-2Lx if someone needs it.


JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jan-Erik Söderholm
2020-08-02 21:33:31 UTC
Permalink
Post by Jean-François Piéronne
Most of the libraries and Python 2.7 for AXP has been updated.
Python 2.7.18, Mercurial 5.4-2.
As usual, I will put online two new LD images, next week. VMS 8.3 required.
So, Python 3.10a0 can be ported to AXP 8.4-2Lx if someone needs it.
JF
Hi. And many thanks for your efforts!

I can now see two new LD images but I do not understand the naming.
There are two "jfppy0700a_278.zip", one with, and one w/o, ";1".
And then one new "jfppy1400a.zip".

You wrote that "most of the libraries and Python 2.7 for AXP has
been updated". Should one of these been named "jfplibxxxxx.zip"?

Index of /anonymous/kits/axp/images_ld/

jfplib0007a.zip 15-Oct-2014 13:38 39444243
jfplib0008A.zip 31-Oct-2014 08:19 41162971
jfppy0601a_278.zip 15-Oct-2014 12:28 70414439
jfppy0700a_278.zip 31-Oct-2014 08:24 72044024
jfppy0700a_278.zip;1 27-Jul-2020 17:31 72044024
jfppy1400a.zip;1 27-Jul-2020 17:31 68755034

You also mention Python 3.10a0.

But "https://docs.python.org/dev/" says:

Docs by version:
Python 3.10 (in development)
Python 3.9 (pre-release)
Python 3.8 (stable)

Any specific reason to port a "in development" version?
Or have I missed that 3.8 is already ported (?).

Best Regards, Jan-Erik.
Jean-François Piéronne
2020-08-03 12:57:46 UTC
Permalink
Post by Jan-Erik Söderholm
Hi. And many thanks for your efforts!
I can now see two new LD images but I do not understand the naming.
There are two "jfppy0700a_278.zip", one with, and one w/o, ";1".
And then one new "jfppy1400a.zip".
You wrote that "most of the libraries and Python 2.7 for AXP has
been updated". Should one of these been named "jfplibxxxxx.zip"?
Index of /anonymous/kits/axp/images_ld/
[snip]
Thanks, this is fixed.
Post by Jan-Erik Söderholm
You also mention Python 3.10a0.
Python 3.10 (in development)
Python 3.9 (pre-release)
Python 3.8 (stable)
Any specific reason to port a "in development" version?
Or have I missed that 3.8 is already ported (?).
Python 3.10 is will be release next year, so my goal is to have the
latest Python version available when VMS on X86 will be production ready.

Another goal is to have a version which will be maintained for many years.

Not porting 3.8 or, now 3.9, is just because I do not have enough time.
But it is doable, need to back port the patches to the corresponding
branches. Having patches include in the default branch will make release
of future version simple.

I have included some of the patches included in the old 3.5 port, but
not all sources are provided, or are not usable on recent Python 3 version.

With one customer, we have started to port a fairly large application
without, currently, many problems. The 2to3 tools work much better than
I have initially expected. Also having the same extensions than in
Python2 is a big help.



JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jan-Erik Söderholm
2020-08-03 13:18:23 UTC
Permalink
Post by Jean-François Piéronne
Post by Jan-Erik Söderholm
Hi. And many thanks for your efforts!
I can now see two new LD images but I do not understand the naming.
There are two "jfppy0700a_278.zip", one with, and one w/o, ";1".
And then one new "jfppy1400a.zip".
You wrote that "most of the libraries and Python 2.7 for AXP has
been updated". Should one of these been named "jfplibxxxxx.zip"?
Index of /anonymous/kits/axp/images_ld/
[snip]
Thanks, this is fixed.
Ah, right. That was differnt. I notice that the "lib" part is now
more then 3 times larger than the previous kit while the basic
Python LD disk actually is slightly smaller...

Index of /anonymous/kits/axp/images_ld/
jfplib0008A.zip 31-Oct-2014 08:19 41162971
jfplib0020a.zip 03-Aug-2020 09:58 137831060
jfppy0700a_278.zip 31-Oct-2014 08:24 72044024
jfppy1400a_2718.zip 03-Aug-2020 09:58 68755032

Time to download to our test system. I do not really remember if
I have patched anything directly into our current LD disks...
Post by Jean-François Piéronne
Post by Jan-Erik Söderholm
You also mention Python 3.10a0.
Python 3.10 (in development)
Python 3.9 (pre-release)
Python 3.8 (stable)
Any specific reason to port a "in development" version?
Or have I missed that 3.8 is already ported (?).
Python 3.10 is will be release next year, so my goal is to have the
latest Python version available when VMS on X86 will be production ready.
OK. probably the right goal... :-)
Post by Jean-François Piéronne
Another goal is to have a version which will be maintained for many years.
Not porting 3.8 or, now 3.9, is just because I do not have enough time.
But it is doable, need to back port the patches to the corresponding
branches. Having patches include in the default branch will make release
of future version simple.
I have included some of the patches included in the old 3.5 port, but
not all sources are provided, or are not usable on recent Python 3 version.
With one customer, we have started to port a fairly large application
without, currently, many problems. The 2to3 tools work much better than
I have initially expected. Also having the same extensions than in
Python2 is a big help.
So that port is using the current IA64 3.10 port? I guess you expect
3.10 to be reasonable stable from now and up to the formal release?

Is VSI involved in any way at all in these Python related work?
Post by Jean-François Piéronne
JF
Jean-François Piéronne
2020-08-05 05:40:41 UTC
Permalink
[snip]
Post by Jan-Erik Söderholm
Post by Jean-François Piéronne
Another goal is to have a version which will be maintained for many years.
Not porting 3.8 or, now 3.9, is just because I do not have enough time.
But it is doable, need to back port the patches to the corresponding
branches. Having patches include in the default branch will make release
of future version simple.
I have included some of the patches included in the old 3.5 port, but
not all sources are provided, or are not usable on recent Python 3 version.
With one customer, we have started to port a fairly large application
without, currently, many problems. The 2to3 tools work much better than
I have initially expected. Also having the same extensions than in
Python2 is a big help.
So that port is using the current IA64 3.10 port? I guess you expect
3.10 to be reasonable stable from now and up to the formal release?
Correct, and we upgrade the Python 3.10 LD only when we need some fixes
or specific VMS updates.
Post by Jan-Erik Söderholm
Is VSI involved in any way at all in these Python related work?
Do you see VSI involve in any open-source project ?
Have you ever seen any VSI contribution to an open-source project ?

And not, a port without release sources updates is not a contribution,
it is a license violation...

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Craig A. Berry
2020-08-05 13:19:44 UTC
Permalink
Post by Jean-François Piéronne
Post by Jan-Erik Söderholm
Is VSI involved in any way at all in these Python related work?
Do you see VSI involve in any open-source project ?
Have you ever seen any VSI contribution to an open-source project ?
They have released quite a few packages. Of course that is not the same
thing as contributing.
Post by Jean-François Piéronne
And not, a port without release sources updates is not a contribution,
it is a license violation...
It depends on the license, of course, and also on what they have done
with the sources, if anything. With Perl, they just used my kit
building procedure, made themselves the producer, and signed the
resulting PCSI kits. I'm fine with that (and actually encouraged them
to do so) since I don't like distributing unsigned kits and have no way
to sign them myself. Since they didn't modify the sources, there's no
license violation.

But we know they must have done quite a bit to get SAMBA, for example,
working on VMS, and since it's GPL, they are required to release their
changes. It would be nice to know if they have done so, but they have
certainly not advertised the fact if they have.
Arne Vajhøj
2020-08-05 23:08:06 UTC
Permalink
Post by Jean-François Piéronne
Do you see VSI involve in any open-source project ?
Have you ever seen any VSI contribution to an open-source project ?
And not, a port without release sources updates is not a contribution,
it is a license violation...
Not necessarily. It depends on what open source license it is.

Whether it is a copyleft or a permissive license.

As I read the Python license then one can create a
version with closed source parts as long as one
"include in any such work a brief summary of the changes
made to Python".

Smart? No.
Ethical? Questionable.
Legal? Yes.

Arne
Jean-François Piéronne
2020-08-06 05:42:09 UTC
Permalink
Post by Arne Vajhøj
Post by Jean-François Piéronne
Do you see VSI involve in any open-source project ?
Have you ever seen any VSI contribution to an open-source project ?
And not, a port without release sources updates is not a contribution,
it is a license violation...
Not necessarily. It depends on what open source license it is.
Whether it is a copyleft or a permissive license.
As I read the Python license then one can create a
version with closed source parts as long as one
"include in any such work a brief summary of the changes
made to Python".
Smart? No.
Ethical? Questionable.
Legal? Yes.
I don't speak especially for Python, it's a general remark. There are
many libraries/tools with a license which required you to publish the
sources like GPL for examples, SAMBA is one of them as mentioned by Craig.

I suggest you list all the VSI ports and give us how many doesn't
violate the associated license, and how many violate their license...

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Stephen Hoffman
2020-08-06 06:33:50 UTC
Permalink
Post by Arne Vajhøj
Not necessarily. It depends on what open source license it is.
Whether it is a copyleft or a permissive license.
There are many libraries/tools with a license which required you to
publish the sources like GPL for examples, SAMBA is one of them as
mentioned by Craig.
Which is what the text you were citing (also) states.

Various commercial vendors can and do avoid copyleft licenses,
preferring to work with other and more permissive licenses.
I suggest you list all the VSI ports and give us how many doesn't
violate the associated license, and how many violate their license...
VSI doesn't tend to push fixes upstream nor did HPE/HP/Compaq/DEC tend
to do that, and that proclivity has been fodder for previous
discussions.

There have been efforts there, though. For one open-source package I
was porting back at HP, I tried pushing the fixes upstream, and the
fixes were then ignored by the upstream folks.

Having done a very quick check of the VSI Samba port, and recent Samba
uses GPL3 of course, and by all appearances (IANAL) the folks at VSI do
appear to be in compliance with the Samba GPL3 requirements.

Also noted that there's no PDC/BDC and no AD support in the Samba port,
too. Ah, well.

I do expect to load Samba too, though that's centrally to allow access
to software development tooling available else-platform, and that's all
fodder for a different discussion or three.

VSI hasn't moved to the current LLVM, so there's not much reason to
push LLVM changes upstream as yet, should the folks at VSI decide to
push their changes upstream. But they're not required to push those
changes with LLVM.

As for scanning all of VSI's open-source for license compliance, that's
work I'm not interested in pursuing. That's for VSI and the VSI legal
folks, and for anyone else that might choose to research that
particular topic.
--
Pure Personal Opinion | HoffmanLabs LLC
g***@gmail.com
2020-08-06 07:07:02 UTC
Permalink
If a student or anybody wants to fix a bug or add a feature in a VSI port, without access to the sources, how does he do?
Arne Vajhøj
2020-08-06 13:14:55 UTC
Permalink
Post by g***@gmail.com
If a student or anybody wants to fix a bug or add a feature in a VSI port, without access to the sources, how does he do?
You obviously need access to the source (unless you feel comfortable
doing a binary patch :-) ).

If change relate to generic source code => you get code code from and
submit changes to the open source project

If change relate to VMS specific code where open source project has
accepted changes from VSI => you get code code from and submit changes
to the open source project

If change relate to VMS specific code where open source project has not
accepted changes from VSI and VSI has released source code => you get
code code from and submit changes to VSI

If change relate to VMS specific code where open source project has not
accepted changes from VSI and VSI has not released source code => you can't

Regarding the 4th scenario then as stated in another post then I
certainly expect VSI to comply with license terms. And it is also
my impression that VSI is very much pro open source, so that their
preference is scenario 2 is better than scenario 3 that is better
than scenario 4. So I would expect scenario 4 to only happen if license
allows it *and* VSI cannot legally release the source code (most
like reason being that the code is owned by HPE and VSI only have
right to use the code not release it).

Arne
g***@gmail.com
2020-08-06 14:19:04 UTC
Permalink
I would have expected something as easy as click on

new PR (pull request), or MR on gitlab

for example for stunnel, click on

https://github.com/mkschreder/stunnel/pulls

Or on a clone like gitlab or bitbucket or hetpatod or any other
Arne Vajhøj
2020-08-06 14:59:10 UTC
Permalink
Post by g***@gmail.com
I would have expected something as easy as click on
new PR (pull request), or MR on gitlab
for example for stunnel, click on
https://github.com/mkschreder/stunnel/pulls
Or on a clone like gitlab or bitbucket or hetpatod or any other
If the changes are available, then Github or similar
is a very convenient way to make it all happen.

Arne
David Goodwin
2020-08-07 00:50:46 UTC
Permalink
Post by Arne Vajhøj
Post by g***@gmail.com
If a student or anybody wants to fix a bug or add a feature in a VSI port, without access to the sources, how does he do?
You obviously need access to the source (unless you feel comfortable
doing a binary patch :-) ).
If change relate to generic source code => you get code code from and
submit changes to the open source project
If change relate to VMS specific code where open source project has
accepted changes from VSI => you get code code from and submit changes
to the open source project
If change relate to VMS specific code where open source project has not
accepted changes from VSI and VSI has released source code => you get
code code from and submit changes to VSI
If change relate to VMS specific code where open source project has not
accepted changes from VSI and VSI has not released source code => you can't
Regarding the 4th scenario then as stated in another post then I
certainly expect VSI to comply with license terms. And it is also
my impression that VSI is very much pro open source, so that their
preference is scenario 2 is better than scenario 3 that is better
than scenario 4. So I would expect scenario 4 to only happen if license
allows it *and* VSI cannot legally release the source code (most
like reason being that the code is owned by HPE and VSI only have
right to use the code not release it).
I don't know about pro-open-source. That would surely mean actively negotiating with HPE to open-source all the abandoned layered products and anything else that they don't really make a profit on selling licenses for. Compared to what Sun would have gone through to open source Solaris this would surely be pretty easy.

VSI just seems to use open-source stuff where it makes sense to save time and money. Standard practice these days - no point in reinventing the wheel.
Arne Vajhøj
2020-08-06 13:04:48 UTC
Permalink
Post by Jean-François Piéronne
Post by Arne Vajhøj
Post by Jean-François Piéronne
Do you see VSI involve in any open-source project ?
Have you ever seen any VSI contribution to an open-source project ?
And not, a port without release sources updates is not a contribution,
it is a license violation...
Not necessarily. It depends on what open source license it is.
Whether it is a copyleft or a permissive license.
As I read the Python license then one can create a
version with closed source parts as long as one
"include in any such work a brief summary of the changes
made to Python".
Smart? No.
Ethical? Questionable.
Legal? Yes.
I don't speak especially for Python, it's a general remark.
Fair enough. But I thougth Python would be a relevant example.
I could have picked Apache httpd instead.
Post by Jean-François Piéronne
There are
many libraries/tools with a license which required you to publish the
sources like GPL for examples, SAMBA is one of them as mentioned by Craig.
Strictly speaking it only requires you to provide the source to those
that got the binary and allows those getting the source to redistribute
it to everybody. But that is practically the same as publish public.

My complaint was about your statement "a port without release sources
updates is not a contribution, it is a license violation" without any
note about that it only applies for some licenses. That was misleading.
Post by Jean-François Piéronne
I suggest you list all the VSI ports and give us how many doesn't
violate the associated license, and how many violate their license...
I am not the one that claims that they are violating any license.

I am assuming VSI is complying with all licenses.

Those that think otherwise should raise the issue.

Arne
Jean-François Piéronne
2020-08-06 13:51:20 UTC
Permalink
Post by Arne Vajhøj
Post by Jean-François Piéronne
Post by Arne Vajhøj
Post by Jean-François Piéronne
Do you see VSI involve in any open-source project ?
Have you ever seen any VSI contribution to an open-source project ?
And not, a port without release sources updates is not a contribution,
it is a license violation...
Not necessarily. It depends on what open source license it is.
Whether it is a copyleft or a permissive license.
As I read the Python license then one can create a
version with closed source parts as long as one
"include in any such work a brief summary of the changes
made to Python".
Smart? No.
Ethical? Questionable.
Legal? Yes.
I don't speak especially for Python, it's a general remark.
Fair enough. But I thougth Python would be a relevant example.
I could have picked Apache httpd instead.
Post by Jean-François Piéronne
                                                            There are
many libraries/tools with a license which required you to publish the
sources like GPL for examples, SAMBA is one of them as mentioned by Craig.
Strictly speaking it only requires you to provide the source to those
that got the binary and allows those getting the source to redistribute
it to everybody. But that is practically the same as publish public.
My complaint was about your statement "a port without release sources
updates is not a contribution, it is a license violation" without any
note about that it only applies for some licenses. That was misleading.
You're right, they don't violate license of all products, just for some.

If this makes you happy and you think that's VSI has a great
contribution to the open source world that's your choice.

But for me a port without release any sources is not contributing to the
open-source world, it is just a contribution to the VSI business.
Post by Arne Vajhøj
Post by Jean-François Piéronne
I suggest you list all the VSI ports and give us how many doesn't
violate the associated license, and how many violate their license...
I am not the one that claims that they are violating any license.
I am assuming VSI is complying with all licenses.
Those that think otherwise should raise the issue.
And what am I doing ?

Each time we have asked for VSI to publish updates the reply has been:
no, sorry no time.

But, again, if you're happy with this, no problem, and in fact, I know
many customers who have no problems with this.

If you want other examples: stunnel ,openjdk
"""
Stunnel uses the OpenSSL library for encryption and is distributed
under the GNU GPL version 2 license or later with an OpenSSL exception.
"""

"""
OpenJDK is licensed under the GNU General Public License (GNU GPL)
Version 2 with a linking exception such that components linked to the
Java Class library are not subject to the terms of the GPL license.
"""

Just found this in a few minutes.

But, I agree for those under, for example, the Apache 2.0 license, you
are allowed to distribute binaries without providing the source code
with it.

Give me one example of a port done by VSI with sources available. Maybe
it's just so hidden that if haven't found.

Maybe I should have said that the contribution of VSI to the open-source
world is so light that it is near null, I don't think that's change the
facts.

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jan-Erik Söderholm
2020-08-06 14:05:47 UTC
Permalink
Post by Jean-François Piéronne
Post by Arne Vajhøj
Post by Jean-François Piéronne
Post by Arne Vajhøj
Post by Jean-François Piéronne
Do you see VSI involve in any open-source project ?
Have you ever seen any VSI contribution to an open-source project ?
And not, a port without release sources updates is not a contribution,
it is a license violation...
Not necessarily. It depends on what open source license it is.
Whether it is a copyleft or a permissive license.
As I read the Python license then one can create a
version with closed source parts as long as one
"include in any such work a brief summary of the changes
made to Python".
Smart? No.
Ethical? Questionable.
Legal? Yes.
I don't speak especially for Python, it's a general remark.
Fair enough. But I thougth Python would be a relevant example.
I could have picked Apache httpd instead.
Post by Jean-François Piéronne
                                                            There are
many libraries/tools with a license which required you to publish the
sources like GPL for examples, SAMBA is one of them as mentioned by Craig.
Strictly speaking it only requires you to provide the source to those
that got the binary and allows those getting the source to redistribute
it to everybody. But that is practically the same as publish public.
My complaint was about your statement "a port without release sources
updates is not a contribution, it is a license violation" without any
note about that it only applies for some licenses. That was misleading.
You're right, they don't violate license of all products, just for some.
If this makes you happy and you think that's VSI has a great
contribution to the open source world that's your choice.
But for me a port without release any sources is not contributing to the
open-source world, it is just a contribution to the VSI business.
Post by Arne Vajhøj
Post by Jean-François Piéronne
I suggest you list all the VSI ports and give us how many doesn't
violate the associated license, and how many violate their license...
I am not the one that claims that they are violating any license.
I am assuming VSI is complying with all licenses.
Those that think otherwise should raise the issue.
And what am I doing ?
no, sorry no time.
But, again, if you're happy with this, no problem, and in fact, I know
many customers who have no problems with this.
If you want other examples: stunnel ,openjdk
"""
Stunnel uses the OpenSSL library for encryption and is distributed
under the GNU GPL version 2 license or later with an OpenSSL exception.
"""
"""
OpenJDK is licensed under the GNU General Public License (GNU GPL)
Version 2 with a linking exception such that components linked to the
Java Class library are not subject to the terms of the GPL license.
"""
Just found this in a few minutes.
But, I agree for those under, for example, the Apache 2.0 license, you
are allowed to distribute binaries without providing the source code
with it.
Give me one example of a port done by VSI with sources available. Maybe
it's just so hidden that if haven't found.
Maybe I should have said that the contribution of VSI to the open-source
world is so light that it is near null, I don't think that's change the
facts.
JF
Maybe it is simply that the goal for VSI is not to contribute to the
open soure world as such, just to provide their customers access to
some open source tools that might be of value (to the customers).

I'm perfectly fine with that, *I* will never read any source code
for Python, or any other open source tool...

I feel somewhat guilty for this discussion since I asked about the
Python 3 ports... Sorry about that. :-)
Arne Vajhøj
2020-08-06 14:56:38 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Jean-François Piéronne
But, I agree for those under, for example, the Apache 2.0 license, you
are allowed to distribute binaries without providing the source code
with it.
Give me one example of a port done by VSI with sources available. Maybe
it's just so hidden that if haven't found.
Maybe I should have said that the contribution of VSI to the open-source
world is so light that it is near null, I don't think that's change the
facts.
Maybe it is simply that the goal for VSI is not to contribute to the
open soure world as such, just to provide their customers access to
some open source tools that might be of value (to the customers).
I'm perfectly fine with that, *I* will never read any source code
for Python, or any other open source tool...
Today most open source users have no intention of ever looking
at the source code.

But it is still in their interest that the code gets released.
In case VSI decides to drop support for the open source product,
then someone from the community may pick it up.

Arne
Duane Krahn
2020-08-06 16:21:08 UTC
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Jean-François Piéronne
But, I agree for those under, for example, the Apache 2.0 license, you
are allowed to distribute binaries without providing the source code
with it.
Give me one example of a port done by VSI with sources available. Maybe
it's just so hidden that if haven't found.
Maybe I should have said that the contribution of VSI to the open-source
world is so light that it is near null, I don't think that's change the
facts.
Maybe it is simply that the goal for VSI is not to contribute to the
open soure world as such, just to provide their customers access to
some open source tools that might be of value (to the customers).
I'm perfectly fine with that, *I* will never read any source code
for Python, or any other open source tool...
Today most open source users have no intention of ever looking
at the source code.
But it is still in their interest that the code gets released.
In case VSI decides to drop support for the open source product,
then someone from the community may pick it up.
Arne
I just took a look at the recent release notes for VSI Samba for OpenVMS 4.6-5F (August 2020) - in the What's Missing? section on page 10: A copy of the source code for Samba on OpenVMS is not included with the installation kit; however we will provide a copy of the code on request (email ***@vmssoftware.com).

Based on that statement, it would seem that VSI would make its open source modifications available to anyone upon request.
Arne Vajhøj
2020-08-06 16:24:29 UTC
Permalink
Post by Duane Krahn
I just took a look at the recent release notes for VSI Samba for
OpenVMS 4.6-5F (August 2020) - in the What's Missing? section on page
10: A copy of the source code for Samba on OpenVMS is not included
with the installation kit; however we will provide a copy of the code
Based on that statement, it would seem that VSI would make its open
source modifications available to anyone upon request.
And being compliant with GPL.

Arne
Jean-François Piéronne
2020-08-06 16:53:03 UTC
Permalink
Post by Arne Vajhøj
Post by Duane Krahn
I just took a look at the recent release notes for VSI Samba for
OpenVMS 4.6-5F (August 2020) - in the What's Missing? section on page
10:  A copy of the source code for Samba on OpenVMS is not included
with the installation kit; however we will provide a copy of the code
Based on that statement, it would seem that VSI would make its open
source modifications available to anyone upon request.
And being compliant with GPL.
No
Post by Arne Vajhøj
Arne
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Jean-François Piéronne
2020-08-06 16:57:27 UTC
Permalink
Post by Arne Vajhøj
Post by Duane Krahn
I just took a look at the recent release notes for VSI Samba for
OpenVMS 4.6-5F (August 2020) - in the What's Missing? section on page
10:  A copy of the source code for Samba on OpenVMS is not included
with the installation kit; however we will provide a copy of the code
Based on that statement, it would seem that VSI would make its open
source modifications available to anyone upon request.
And being compliant with GPL.
From
https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLRequireAvailabilityToPublic

"""
Yes. You can charge any fee you wish for distributing a copy of the
program. Under GPLv2, if you distribute binaries by download, you must
provide “equivalent access” to download the source—therefore, the fee to
download source may not be greater than the fee to download the binary.
If the binaries being distributed are licensed under the GPLv3, then you
must offer equivalent access to the source code in the same way through
the same place at no further charge.
"""
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Arne Vajhøj
2020-08-06 17:29:33 UTC
Permalink
Post by Jean-François Piéronne
Post by Arne Vajhøj
Post by Duane Krahn
I just took a look at the recent release notes for VSI Samba for
OpenVMS 4.6-5F (August 2020) - in the What's Missing? section on page
10:  A copy of the source code for Samba on OpenVMS is not included
with the installation kit; however we will provide a copy of the code
Based on that statement, it would seem that VSI would make its open
source modifications available to anyone upon request.
And being compliant with GPL.
From
https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLRequireAvailabilityToPublic
"""
Yes. You can charge any fee you wish for distributing a copy of the
program. Under GPLv2, if you distribute binaries by download, you must
provide “equivalent access” to download the source—therefore, the fee to
download source may not be greater than the fee to download the binary.
If the binaries being distributed are licensed under the GPLv3, then you
must offer equivalent access to the source code in the same way through
the same place at no further charge.
"""
Hmmm. I can see where you get the idea from.

But I don't think that FAQ matches the actual license texts well.

GPL 2.0 is pretty simple.

https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

<quote>
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections 1 and
2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your cost of
physically performing source distribution, a complete machine-readable
copy of the corresponding source code, to be distributed under the terms
of Sections 1 and 2 above on a medium customarily used for software
interchange; or,
</quote>

Which says either:

provide source with binary on "medium customarily used for software
interchange"

or:

offer to provide source "valid for at least three years", "charge no
more than your cost of physically performing source distribution" and
"medium customarily used for software interchange"

Telling people that they can email and ask for a copy and get
a link to a ZIP file seems compliant with the second. Assuming
that download is considered a medium and considering how much GPL 2
software get downloaded then that seems pretty obvious.

GPL 3.0 is a bit more complex.

https://www.gnu.org/licenses/gpl-3.0.en.html

<quote>
6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of
sections 4 and 5, provided that you also convey the machine-readable
Corresponding Source under the terms of this License, in one of these ways:

a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium customarily used
for software interchange.
b) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a written
offer, valid for at least three years and valid for as long as you offer
spare parts or customer support for that product model, to give anyone
who possesses the object code either (1) a copy of the Corresponding
Source for all the software in the product that is covered by this
License, on a durable physical medium customarily used for software
interchange, for a price no more than your reasonable cost of physically
performing this conveying of source, or (2) access to copy the
Corresponding Source from a network server at no charge.
...
d) Convey the object code by offering access from a designated place
(gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to copy the
Corresponding Source along with the object code. If the place to copy
the object code is a network server, the Corresponding Source may be on
a different server (operated by you or a third party) that supports
equivalent copying facilities, provided you maintain clear directions
next to the object code saying where to find the Corresponding Source.
Regardless of what server hosts the Corresponding Source, you remain
obligated to ensure that it is available for as long as needed to
satisfy these requirements.
</quote>

A physical distribution is the same rules as V2.

But they changed the rules for download.

"equivalent access to the Corresponding Source in the same way through
the same place at no further charge", "If the place to copy the object
code is a network server, the Corresponding Source may be on a different
server" and "maintain clear directions next to the object code saying
where to find the Corresponding Source" do say free download, but it can
be a different server - and it requires clear directions for where to
find source.

I guess you can claim that an email address to request source and
a response with a download link is not clear direction. But I think
that is being a bit picky.

Arne
Arne Vajhøj
2020-08-06 17:52:33 UTC
Permalink
Post by Jean-François Piéronne
Post by Arne Vajhøj
Post by Duane Krahn
I just took a look at the recent release notes for VSI Samba for
OpenVMS 4.6-5F (August 2020) - in the What's Missing? section on page
10:  A copy of the source code for Samba on OpenVMS is not included
with the installation kit; however we will provide a copy of the code
Based on that statement, it would seem that VSI would make its open
source modifications available to anyone upon request.
And being compliant with GPL.
From
https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLRequireAvailabilityToPublic
"""
Yes. You can charge any fee you wish for distributing a copy of the
program. Under GPLv2, if you distribute binaries by download, you must
provide “equivalent access” to download the source—therefore, the fee to
download source may not be greater than the fee to download the binary.
If the binaries being distributed are licensed under the GPLv3, then you
must offer equivalent access to the source code in the same way through
the same place at no further charge.
"""
https://www.gnu.org/licenses/gpl-faq.en.html#AnonFTPAndSendSources

may actually be more direct on the topic.

<quote>
Can I make binaries available on a network server, but send sources only
to people who order them? (#AnonFTPAndSendSources)

If you make object code available on a network server, you have to
provide the Corresponding Source on a network server as well. The
easiest way to do this would be to publish them on the same server, but
if you'd like, you can alternatively provide instructions for getting
the source from another server, or even a version control system. No
matter what you do, the source should be just as easy to access as the
object code, though. This is all specified in section 6(d) of GPLv3.

The sources you provide must correspond exactly to the binaries. In
particular, you must make sure they are for the same version of the
program—not an older version and not a newer version.
</quote>

Which I will paraphrase as: one can do whatever one likes as long as:
1) the source code is available on a network server
2) it must be as easy to get the source code as it was to get the binary

Arne
Dave Froble
2020-08-06 22:14:41 UTC
Permalink
Post by Duane Krahn
Based on that statement, it would seem that VSI would make its open source modifications available to anyone upon request.
Storage and bandwidth aren't much of a problem these days. VSI would
save themselves some hassle if they just included sources with the
installation kit and be done with it. Just my thought.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2020-08-06 22:17:05 UTC
Permalink
Post by Duane Krahn
Based on that statement, it would seem that VSI would make its open source modifications available to anyone upon request.
Storage and bandwidth aren't much of a problem these days. VSI would
save themselves some hassle if they just included sources with the
installation kit and be done with it. Just my thought.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2020-08-07 00:09:26 UTC
Permalink
Post by Duane Krahn
I just took a look at the recent release notes for VSI Samba for
OpenVMS 4.6-5F (August 2020) - in the What's Missing? section on page
10:  A copy of the source code for Samba on OpenVMS is not included
with the installation kit; however we will provide a copy of the code
Based on that statement, it would seem that VSI would make its open
source modifications available to anyone upon request.
Storage and bandwidth aren't much of a problem these days.  VSI would
save themselves some hassle if they just included sources with the
installation kit and be done with it.  Just my thought.
Distribute the source with the binary or put the source up on Github
are two very obvious ways to handle such requirements.

It should make users happy and would probably reduce the administrative
burden.

Arne
Scott Dorsey
2020-08-08 16:32:06 UTC
Permalink
Post by Arne Vajhøj
Today most open source users have no intention of ever looking
at the source code.
And this, in short, is everything wrong with the open source community today.
Post by Arne Vajhøj
But it is still in their interest that the code gets released.
In case VSI decides to drop support for the open source product,
then someone from the community may pick it up.
This is true, which is why some people prefer the GPL.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arne Vajhøj
2020-08-08 17:53:13 UTC
Permalink
Post by Scott Dorsey
Post by Arne Vajhøj
Today most open source users have no intention of ever looking
at the source code.
And this, in short, is everything wrong with the open source community today.
That is the natural consequence of open source changing status from
"something for hard core developers" to "something everybody uses".

Arne
Arne Vajhøj
2020-08-08 18:36:34 UTC
Permalink
Interesting read:

https://www.redhat.com/en/enterprise-open-source-report/2020

About the survey:

<quote>
This survey of 950 IT leaders was commissioned by Red Hat to better
understand the unique role of enterprise open source. Respondents were
unaware that Red Hat was the sponsor of this research.
</quote>

So this is basically the people that VSI need to convince to
stay on, increase usage of or switch to VMS.

Arne
Dave Froble
2020-08-08 19:58:45 UTC
Permalink
Post by Arne Vajhøj
https://www.redhat.com/en/enterprise-open-source-report/2020
<quote>
This survey of 950 IT leaders was commissioned by Red Hat to better
understand the unique role of enterprise open source. Respondents were
unaware that Red Hat was the sponsor of this research.
</quote>
So this is basically the people that VSI need to convince to
stay on, increase usage of or switch to VMS.
Arne
I'd reserve judgment until I know who and what type of respondents were
involved. If those already dedicated to open source were in the
majority, then what other results would one expect.

I'm betting there were no respondents that say, control nuclear power
stations.

Lies, damn lies, statistics, and finally polls.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2020-08-09 01:12:31 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
https://www.redhat.com/en/enterprise-open-source-report/2020
<quote>
This survey of 950 IT leaders was commissioned by Red Hat to better
understand the unique role of enterprise open source. Respondents were
unaware that Red Hat was the sponsor of this research.
</quote>
So this is basically the people that VSI need to convince to
stay on, increase usage of or switch to VMS.
I'd reserve judgment until I know who and what type of respondents were
involved.  If those already dedicated to open source were in the
majority, then what other results would one expect.
I'm betting there were no respondents that say, control nuclear power
stations.
Based on description is must be 950 CIO's and similar for
large companies.

There could be companies owning nuclear power plants among
them. Or not.

And open source could be used for some of he truly critical
stuff. Linux is becoming very common for SCADA today. And
they could use GNAT for software development.

Arne
Simon Clubley
2020-08-10 01:50:55 UTC
Permalink
Post by Arne Vajhøj
And open source could be used for some of he truly critical
stuff. Linux is becoming very common for SCADA today. And
they could use GNAT for software development.
That reminded me that VSI hasn't said anything recently about the
possibility of Ada support coming to x86-64 VMS.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Craig A. Berry
2020-08-10 12:24:32 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
And open source could be used for some of he truly critical
stuff. Linux is becoming very common for SCADA today. And
they could use GNAT for software development.
That reminded me that VSI hasn't said anything recently about the
possibility of Ada support coming to x86-64 VMS.
I thought they said there was no possibility the last time this came up,
but I don't think gnat-llvm was on the horizon yet:

<https://github.com/AdaCore/gnat-llvm>

It's listed as experimental, but perhaps by the time VSI has a
self-hosting, up-to-date clang/llvm environment on VMS in a couple years
it will be less experimental.
gérard Calliet
2020-08-10 15:09:50 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
And open source could be used for some of he truly critical
stuff. Linux is becoming very common for SCADA today. And
they could use GNAT for software development.
That reminded me that VSI hasn't said anything recently about the
possibility of Ada support coming to x86-64 VMS.
Simon.
Last meeting (UK users group by zoom). Bret Cameron: we have no plans on
Ada.

Since 2015 I had to rebuild Gnat Ada for Itanium OpenVMS, I didn't get
any collaboration from VSI (except from individuals).

It is another figure of how VSI thinks about collaborating businesses.
And by the way it is totally different on the way bug businesses (Red
Hat) have been built, or on the way the Ada langage itself has been
saved and transformed in a good business.

And - not because we are alltogether frenchies - I agree with JFP that
VSI doesn't understand how the open source universe works (and wins).

About Ada itself, yes the way Adacore tries LLVM as a complementary back
end is a good thing for the future of Ada on x86/OpenVSM. And yes Ada
(and Spark) on OpenVMS (or "thin OpenVMS") could be promising for SCADA
and other demanding environments. It's another topic.

Gérard Calliet
Arne Vajhøj
2020-08-10 15:25:26 UTC
Permalink
Post by gérard Calliet
Post by Simon Clubley
Post by Arne Vajhøj
And open source could be used for some of he truly critical
stuff. Linux is becoming very common for SCADA today. And
they could use GNAT for software development.
That reminded me that VSI hasn't said anything recently about the
possibility of Ada support coming to x86-64 VMS.
Last meeting (UK users group by zoom). Bret Cameron: we have no plans on
Ada.
Since 2015 I had to rebuild Gnat Ada for Itanium OpenVMS, I didn't get
any collaboration from VSI (except from individuals).
VSI has limited resources. They have to prioritize.

People can disagree on how they prioritize, but everybody
should be able to agree that they have to prioritize.

And I understand why Ada is not a priority. I believe that
the Ada approach to safe programming is good. But the world
chose a different path many years before VSI was founded.

Arne
gérard Calliet
2020-08-10 17:12:35 UTC
Permalink
Post by Arne Vajhøj
Post by gérard Calliet
Post by Simon Clubley
Post by Arne Vajhøj
And open source could be used for some of he truly critical
stuff. Linux is becoming very common for SCADA today. And
they could use GNAT for software development.
That reminded me that VSI hasn't said anything recently about the
possibility of Ada support coming to x86-64 VMS.
Last meeting (UK users group by zoom). Bret Cameron: we have no plans
on Ada.
Since 2015 I had to rebuild Gnat Ada for Itanium OpenVMS, I didn't get
any collaboration from VSI (except from individuals).
VSI has limited resources. They have to prioritize.
Agreed. But.

It's now for more than five years I'm only saying "help us to help you".
Ada cannot be a priority. ok. Some invest in Ada for you. Take your
phone, perhaps for a very low effort something can be done and worth it
for all.

It's my general opinion on interest of VSI being more fair in the Open
Source realm. Just do a little bit more to gain trust and help from a
large enthousiast (and new) community.

The times have changed - it's a pain for us thinking about the huge
success of internet compared to the Digital decline - and business
around Open Source paradigm proved it to be very good.

*If* you play the game as it is played by the majority. Is someone using
now MySql? No. MariaDB. Why? Oracle didn't play the game.
Post by Arne Vajhøj
People can disagree on how they prioritize, but everybody
should be able to agree that they have to prioritize.
And I understand why Ada is not a priority. I believe that
the Ada approach to safe programming is good. But the world
chose a different path many years before VSI was founded.
Have a look at how Adacore business is good and growing. And the huge
role of community in their success. They play the game.
Post by Arne Vajhøj
Arne
Dave Froble
2020-08-10 17:52:24 UTC
Permalink
Post by gérard Calliet
Post by Arne Vajhøj
Post by gérard Calliet
Post by Simon Clubley
Post by Arne Vajhøj
And open source could be used for some of he truly critical
stuff. Linux is becoming very common for SCADA today. And
they could use GNAT for software development.
That reminded me that VSI hasn't said anything recently about the
possibility of Ada support coming to x86-64 VMS.
Last meeting (UK users group by zoom). Bret Cameron: we have no plans
on Ada.
Since 2015 I had to rebuild Gnat Ada for Itanium OpenVMS, I didn't
get any collaboration from VSI (except from individuals).
VSI has limited resources. They have to prioritize.
Agreed. But.
One has to feel that VSI understands their priorities better than anyone
else. For example, look at the inclusion of DECnet in x86 VMS. VSI
went to their customers, and they listened.
Post by gérard Calliet
It's now for more than five years I'm only saying "help us to help you".
Ya know, I really do agree with this concept. So, what's it take for a
little bit of help for you? Then a little bit of help for me? Then a
little bit of help for *

I do understand their refusal to start down this rather steep slope. At
least until the port to x86 is completed.

I offered to provide some help with the lock manager. But I understand
their position of "no new anything until it is ported".

Your, and my, help to VSI takes some of their valuable time. That's the
reality.
Post by gérard Calliet
Ada cannot be a priority. ok. Some invest in Ada for you. Take your
phone, perhaps for a very low effort something can be done and worth it
for all.
It's my general opinion on interest of VSI being more fair in the Open
Source realm. Just do a little bit more to gain trust and help from a
large enthousiast (and new) community.
See above about "the port isn't everything, it's the only thing".
Post by gérard Calliet
The times have changed - it's a pain for us thinking about the huge
success of internet compared to the Digital decline - and business
around Open Source paradigm proved it to be very good.
Depends. For generic stuff, yeah, great. For specific stuff, no.
Post by gérard Calliet
*If* you play the game as it is played by the majority. Is someone using
now MySql? No. MariaDB. Why? Oracle didn't play the game.
Post by Arne Vajhøj
People can disagree on how they prioritize, but everybody
should be able to agree that they have to prioritize.
And I understand why Ada is not a priority. I believe that
the Ada approach to safe programming is good. But the world
chose a different path many years before VSI was founded.
Have a look at how Adacore business is good and growing. And the huge
role of community in their success. They play the game.
Yet when I look around, no Ada. Users are not monolithic. What is good
for you is not necessarily good for others. Well, except the port,
which is essential for everyone.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
gérard Calliet
2020-08-10 19:52:00 UTC
Permalink
Post by Dave Froble
Post by gérard Calliet
Post by Arne Vajhøj
Post by gérard Calliet
Post by Simon Clubley
Post by Arne Vajhøj
And open source could be used for some of he truly critical
stuff. Linux is becoming very common for SCADA today. And
they could use GNAT for software development.
That reminded me that VSI hasn't said anything recently about the
possibility of Ada support coming to x86-64 VMS.
Last meeting (UK users group by zoom). Bret Cameron: we have no plans
on Ada.
Since 2015 I had to rebuild Gnat Ada for Itanium OpenVMS, I didn't
get any collaboration from VSI (except from individuals).
VSI has limited resources. They have to prioritize.
Agreed. But.
One has to feel that VSI understands their priorities better than anyone
else.  For example, look at the inclusion of DECnet in x86 VMS.  VSI
went to their customers, and they listened.
Post by gérard Calliet
It's now for more than five years I'm only saying "help us to help you".
Ya know, I really do agree with this concept.  So, what's it take for a
little bit of help for you?  Then a little bit of help for me? Then a
little bit of help for *
I do understand their refusal to start down this rather steep slope.  At
least until the port to x86 is completed.
I offered to provide some help with the lock manager.  But I understand
their position of "no new anything until it is ported".
Your, and my, help to VSI takes some of their valuable time.  That's the
reality.
I have to say: 1° snip (don't no why they say that when something is
hard to be said ("ils sont fous ces anglais"))
2° Your help is not like my help :) : you propose something where they
will have a lot to do to take your help, I speak about helps where their
effort is a lot lighter.
Post by Dave Froble
Post by gérard Calliet
Ada cannot be a priority. ok. Some invest in Ada for you. Take your
phone, perhaps for a very low effort something can be done and worth it
for all.
It's my general opinion on interest of VSI being more fair in the Open
Source realm. Just do a little bit more to gain trust and help from a
large enthousiast (and new) community.
See above about "the port isn't everything, it's the only thing".
Post by gérard Calliet
The times have changed - it's a pain for us thinking about the huge
success of internet compared to the Digital decline - and business
around Open Source paradigm proved it to be very good.
Depends.  For generic stuff, yeah, great.  For specific stuff, no.
Post by gérard Calliet
*If* you play the game as it is played by the majority. Is someone using
now MySql? No. MariaDB. Why? Oracle didn't play the game.
Post by Arne Vajhøj
People can disagree on how they prioritize, but everybody
should be able to agree that they have to prioritize.
And I understand why Ada is not a priority. I believe that
the Ada approach to safe programming is good. But the world
chose a different path many years before VSI was founded.
Have a look at how Adacore business is good and growing. And  the huge
role of community in their success. They play the game.
Yet when I look around, no Ada.  Users are not monolithic.  What is good
for you is not necessarily good for others.  Well, except the port,
which is essential for everyone.
1° snip
2° see above "you speak about what you know, as I do"; no Ada you know,
some Ada I know which could be sufficient to have a little company doing
things for that; and taking a miminum help (just for example saying "we
know x who does something: one sentence); and a day another customer I
don't know but that VSI knows says: "I need Ada, elsewhere goodbye".

1° snip
2° can I try something not all the computer scientists (they talk only
with computers) are able to do: understanding a chain of ideas, a little
bit long and abstract?

The problem is about "the port is everything". I don't agree and I think
this theorem is false, and causes of a lot of troubles we are in.

a) in the beginnings the port was a mean, not an end. *if* (i) we want
to go ahead on VMS we have to (ii) port to x86. {the mean (ii) and the
end (i)}

a') the mean is easy to describe and cannot be thought of as easy and on
a short journey to get
a'') the end is very difficult to describe (what are the reasons we
think it is good to continue with VMS) a lot more difficult to expose,
and in a contradictory situation: *because* VMS is a long term solution
we have to wait now in a difficult situation with it {because it is
good, we can support it is not so good *?*}

b) now our end is that the mean will be achieved, because... I forget

c) our end is the port: we say to the customer "you have to choose VMS
*because* it will be ported to x86" {at that point the customer thinks
we propose him a tool which is good *only* because it can do later...
what all the others tools can already do}

d) because the hypothesis places us in a contradiction, it is a false
hypothesis, so: we cannot say the port is everything.

From 2014 to today and from today to 2022, the port has not, cannot be,
will not be everything.

And the marvel is that althought we think the contrary, we know that the
port is not everything. The real good things are the second lives of
Alpha environments, the rebuild of a real support, the entousiasm of the
old guys... and the *way* of quality the port is made. It is a complete
revival of a computer ecosystem, with a myriad of topics involved. And
just at its beginning. The current possible trap is confusing the mean
and the end, observing only the -in-two-years- mean as a end, and
stumbling on a gap our obsession prevents seing.

Thanks for the opportunity :)

Gérard Calliet
Arne Vajhøj
2020-08-10 18:19:56 UTC
Permalink
Post by gérard Calliet
Post by Arne Vajhøj
Post by gérard Calliet
Post by Simon Clubley
Post by Arne Vajhøj
And open source could be used for some of he truly critical
stuff. Linux is becoming very common for SCADA today. And
they could use GNAT for software development.
That reminded me that VSI hasn't said anything recently about the
possibility of Ada support coming to x86-64 VMS.
Last meeting (UK users group by zoom). Bret Cameron: we have no plans
on Ada.
Since 2015 I had to rebuild Gnat Ada for Itanium OpenVMS, I didn't
get any collaboration from VSI (except from individuals).
VSI has limited resources. They have to prioritize.
Agreed. But.
It's now for more than five years I'm only saying "help us to help you".
Ada cannot be a priority. ok. Some invest in Ada for you. Take your
phone, perhaps for a very low effort something can be done and worth it
for all.
Maybe. But it is VSI's decision.
Post by gérard Calliet
It's my general opinion on interest of VSI being more fair in the Open
Source realm. Just do a little bit more to gain trust and help from a
large enthousiast (and new) community.
The times have changed - it's a pain for us thinking about the huge
success of internet compared to the Digital decline - and business
around Open Source paradigm proved it to be very good.
*If* you play the game as it is played by the majority. Is someone using
now MySql? No. MariaDB. Why? Oracle didn't play the game.
MySQL is still used many places.
Post by gérard Calliet
Post by Arne Vajhøj
People can disagree on how they prioritize, but everybody
should be able to agree that they have to prioritize.
And I understand why Ada is not a priority. I believe that
the Ada approach to safe programming is good. But the world
chose a different path many years before VSI was founded.
Have a look at how Adacore business is good and growing. And  the huge
role of community in their success. They play the game.
Even AdaCore has prioritized.

When I look at their CE I see: JVM version dropped in 2014, CLR version
dropped in 2015, 32 bit Linux dropped in 2015, Raspberry Pi dropped
in 2017, 32 bit Windows dropped in 2018.

Arne
gérard Calliet
2020-08-10 20:20:08 UTC
Permalink
Post by Arne Vajhøj
Post by gérard Calliet
Post by Arne Vajhøj
Post by gérard Calliet
Post by Simon Clubley
Post by Arne Vajhøj
And open source could be used for some of he truly critical
stuff. Linux is becoming very common for SCADA today. And
they could use GNAT for software development.
That reminded me that VSI hasn't said anything recently about the
possibility of Ada support coming to x86-64 VMS.
Last meeting (UK users group by zoom). Bret Cameron: we have no
plans on Ada.
Since 2015 I had to rebuild Gnat Ada for Itanium OpenVMS, I didn't
get any collaboration from VSI (except from individuals).
VSI has limited resources. They have to prioritize.
Agreed. But.
It's now for more than five years I'm only saying "help us to help you".
Ada cannot be a priority. ok. Some invest in Ada for you. Take your
phone, perhaps for a very low effort something can be done and worth
it for all.
Maybe. But it is VSI's decision.
Post by gérard Calliet
It's my general opinion on interest of VSI being more fair in the Open
Source realm. Just do a little bit more to gain trust and help from a
large enthousiast (and new) community.
The times have changed - it's a pain for us thinking about the huge
success of internet compared to the Digital decline - and business
around Open Source paradigm proved it to be very good.
*If* you play the game as it is played by the majority. Is someone
using now MySql? No. MariaDB. Why? Oracle didn't play the game.
MySQL is still used many places.
Post by gérard Calliet
Post by Arne Vajhøj
People can disagree on how they prioritize, but everybody
should be able to agree that they have to prioritize.
And I understand why Ada is not a priority. I believe that
the Ada approach to safe programming is good. But the world
chose a different path many years before VSI was founded.
Have a look at how Adacore business is good and growing. And  the huge
role of community in their success. They play the game.
Even AdaCore has prioritized.
When I look at their CE I see: JVM version dropped in 2014, CLR version
dropped in 2015, 32 bit Linux dropped in 2015, Raspberry Pi dropped
in 2017, 32 bit Windows dropped in 2018.
Arne
Everyone have priorities. And everyone is sometimes right, sometimes
wrong. Isn't it?

So it seems it is always possible to exprim critics?

My critic however is not about priorities, but about what I understand
as wrong practics.

VSI uses Open Sources a way which seems purely usefully. This way is in
contradiction with the major way Open Source is used, and it is not a
good point for VSI and us, and in general in contradiction with what can
be the motivations of computer scientists.

Internet succeeded because a lot of reasons. One of them is it joined
with essential motivations of thousands of computer scientists, the
scientists who created the Open Source standards.

I'm sure the motivation of an IBM computer scientist or a Linux one, or
a Apple one or a Digital one are very different. But all of them go on
with their job when they feel they are doing "the right thing". It is
very important to respect these motivations, and with the success of
Internet, Linux proves it is not a naïve thinking to say that.

It will be a very difficult thing, in the long term, to rebuild the VMS
culture. Because the motivation is a lot more complex than that of the
others: our blue cousins have a religion of the "service to the
enterprise", our Unix cousins are idealists, our Aple cousins are
worshiper of toys. Who are we? Just the gurus of the gurus, the best of
the bests? The way we'll rebuild our ecosystem, the way we'll interface
it with the others will determine our new identity. My opinion is our
value is something like "making things work". They said Digital is an
ingineer world. So, for everything, understanding how it works.

We have to understand how the open source ecosystem works.

Gérard Calliet
Arne Vajhøj
2020-08-12 20:03:29 UTC
Permalink
Post by gérard Calliet
My critic however is not about priorities, but about what I understand
as wrong practics.
VSI uses Open Sources a way which seems purely usefully. This way is in
contradiction with the major way Open Source is used, and it is not a
good point for VSI and us, and in general in contradiction with what can
be the motivations of computer scientists.
Internet succeeded because a lot of reasons. One of them is it joined
with essential motivations of thousands of computer scientists, the
scientists who created the Open Source standards.
I'm sure the motivation of an IBM computer scientist or a Linux one, or
a Apple one or a Digital one are very different. But all of them go on
with their job when they feel they are doing "the right thing". It is
very important to respect these motivations, and with the success of
Internet, Linux proves it is not a naïve thinking to say that.
It will be a very difficult thing, in the long term, to rebuild the VMS
culture. Because the motivation is a lot more complex than that of the
others: our blue cousins have a religion of the "service to the
enterprise", our Unix cousins are idealists, our Aple cousins are
worshiper of toys. Who are we? Just the gurus of the gurus, the best of
the bests? The way we'll rebuild our ecosystem, the way we'll interface
it with the others will determine our new identity. My opinion is our
value is something like "making things work". They said Digital is an
ingineer world. So, for everything, understanding how it works.
We have to understand how the open source ecosystem works.
I am not sure what is your point.

VSI use open source in their new offerings.

VSI's active contribution to open source is probably limited.

But VSI is not a company like IBM, HPE, Intel, MS, Apple, Google etc..
Or like Digital 30 years ago.

They are a relative small company with some very big tasks
for their core commercial offerings.

I don't think they have the resources to become a contributor like
the other companies mentioned.

So I can't blame them.

To me the biggest problem with VMS and open source is not VSI
but the community.

There are way too few that are willing to spend time
on VMS open source.

Arne
David Goodwin
2020-08-12 22:47:24 UTC
Permalink
Post by Arne Vajhøj
To me the biggest problem with VMS and open source is not VSI
but the community.
There are way too few that are willing to spend time
on VMS open source.
If open source projects on OpenVMS are important then VSI probably needs to actively encourage participation. Perhaps if some of their own things were open source and easy to contribute to people in the OpenVMS community would get involved.

As far as the wider open-source community goes, unless big changes are made that's probably a lost cause. OpenVMS is too obscure and too proprietary for most to bother with even if they have heard of it and are aware its still maintained.
gérard Calliet
2020-08-13 09:34:06 UTC
Permalink
Post by David Goodwin
Post by Arne Vajhøj
To me the biggest problem with VMS and open source is not VSI
but the community.
It's a big problem, not the biggest. The two problems are mixed.
Post by David Goodwin
Post by Arne Vajhøj
There are way too few that are willing to spend time
on VMS open source.
If open source projects on OpenVMS are important then VSI probably needs to actively encourage participation. Perhaps if some of their own things were open source and easy to contribute to people in the OpenVMS community would get involved.
It is my point. I just hope VSI could do the minimum so community could
take the opportunity.
Post by David Goodwin
As far as the wider open-source community goes, unless big changes are made that's probably a lost cause. OpenVMS is too obscure and too proprietary for most to bother with even if they have heard of it and are aware its still maintained.
It is our responsibility to make OpenVMS known and liked. We can develop
a form of curiosity about OpenVMS. Young ingineers are often inquisitive
people. And for-long-time developments, reusability are becoming hype.

I think of this situation as something like a dead lock:

VSI doesn't help encouraging collaboration on Open Source, and thinks
there is not sufficient strength outside that can be usefull,

The community - little for now - doesn't engage with strength on
collaboration, and is discouraged by the lack of interest on
collaboration by VSI.

Something has to be done to unlock this. Community License is a very
good point. Making more standardfully available Open Source developments
will be the next good point.

More generaly VSI and the community have to quit the old paradigm of the
marvelous company and the passive users. We have all to rebuild trusted
collaboration, and adopt some ways from the Open Source paradigm. And we
have also to be more conscious of the specific qualities of OpenVMS
which can be "selled" to other people.

Gérard Calliet
John Dallman
2020-08-13 11:17:00 UTC
Permalink
Post by gérard Calliet
VSI doesn't help encouraging collaboration on Open Source, and
thinks there is not sufficient strength outside that can be usefull,
The most important thing, by far, in getting open source work to happen
on VMS is getting the x86-64 port out and working. With that, people can
run VMS on commonplace hardware.

Emulation is slow and unsatisfying to someone who is new to VMS. Alpha
machines are rare and old, and Itanium became a bad joke outside the VMS
community.

John
gérard Calliet
2020-08-13 12:24:17 UTC
Permalink
Post by John Dallman
Post by gérard Calliet
VSI doesn't help encouraging collaboration on Open Source, and
thinks there is not sufficient strength outside that can be usefull,
The most important thing, by far, in getting open source work to happen
on VMS is getting the x86-64 port out and working. With that, people can
run VMS on commonplace hardware.
Emulation is slow and unsatisfying to someone who is new to VMS. Alpha
machines are rare and old, and Itanium became a bad joke outside the VMS
community.
John
I understand that, but my opinion is that it is The Big mistake now.

VMS was back with VSI in 2014. VMS on x86, production release is for
2022, and you have a minimum 6 months effort to port to x86.

More then 8 years is about a century in our business. And the
underground message if you speak of x86 as the panacea is "the boat is
sinking, be patient, another boat will be here tomorow".

x86 is not The solution, it is part of the solution, and it is VMS
itself we have to "sell" as the solution. The Big message in 2014 has
been "you were with VMS last century, we are with you this century, and
you will be with VMS next century". But we forgot this century, and it's
very difficult not to sink, waiting for the next century.

Another mistake is to spoil the HW and emulator based supports of VMS
now. For sure x86 will be a lot better, and without it no future, but
now (between 2014 and 2022) we can do a lot of things with what we have.

A lot of customers on VMS have investment plans between 3 to 5 years
minimum, decided 1 or 2 years before.

THEY HAVE to buy now the last itanium, which are good machines, with an
up-to-date OS on it.

THEY CAN project some of their apps in Cloud via emulation, and it is
the only way for them to join the past to the future.

They have not any interest on the real date 2022? 2023? they will get x86.

ANYTHING than can ease them for the 2 next years in the priority of the
priority.



Open Source is not at the center of that, of course. But all the work we
have to be able to say to our customers that VMS specialists are not all
at 1 year of retirement can be eased by gaining interest from Open
Sources geeks on VMS.


n.b.: The itanic joke is just the meeting of the conservatism of the
old, the narrow-minded reasoning of the big investors for the compilers,
and the anti-trust and therefore anti-intel ideology of the younger
generations. Result: the microprocessor is back to the stone age (x86 is
VAX but not as good, and with a turbo).
Dave Froble
2020-08-13 12:47:32 UTC
Permalink
Post by John Dallman
Post by gérard Calliet
VSI doesn't help encouraging collaboration on Open Source, and
thinks there is not sufficient strength outside that can be usefull,
The most important thing, by far, in getting open source work to happen
on VMS is getting the x86-64 port out and working. With that, people can
run VMS on commonplace hardware.
Emulation is slow and unsatisfying to someone who is new to VMS. Alpha
machines are rare and old, and Itanium became a bad joke outside the VMS
community.
John
And an even worse joke inside the VMS community ....
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Scott Dorsey
2020-08-09 00:58:57 UTC
Permalink
Post by Arne Vajhøj
Post by Scott Dorsey
Post by Arne Vajhøj
Today most open source users have no intention of ever looking
at the source code.
And this, in short, is everything wrong with the open source community today.
That is the natural consequence of open source changing status from
"something for hard core developers" to "something everybody uses".
It's more fundamental than that. Computers have changed from "something that
I use to do something I program them for" to "something that I use to do
something that someone else programs them for."
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Dave Froble
2020-08-08 18:24:47 UTC
Permalink
Post by Scott Dorsey
Post by Arne Vajhøj
Today most open source users have no intention of ever looking
at the source code.
And this, in short, is everything wrong with the open source community today.
Scott, I've really got to question this statement.

Assume something is written in say, C. Not everyone uses C. Are you
saying only C programmers should use the app?

Some users are not programmers at all. Are you saying open source apps
are only for those programmers who can read the source code?

I'm not saying I don't agree a bit with your suggestion. I'm saying
that if your suggestion was the criteria for using open source apps, the
number of users of such apps would be a tiny subset of those using them
today.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Scott Dorsey
2020-08-08 16:30:26 UTC
Permalink
Post by Jan-Erik Söderholm
Maybe it is simply that the goal for VSI is not to contribute to the
open soure world as such, just to provide their customers access to
some open source tools that might be of value (to the customers).
The thing is that many open source licenses -require- that any changes
or additions to their code be made available in source form. Not all
of them do, but the gnu license definitely does.

So if VSI were to port, say, gcc to VMS, any changes they made to the gcc
code as part of that port need to be made generally available under the gpl
since gcc is licensed under the gpl.
Post by Jan-Erik Söderholm
I'm perfectly fine with that, *I* will never read any source code
for Python, or any other open source tool...
I feel somewhat guilty for this discussion since I asked about the
Python 3 ports... Sorry about that. :-)
Now, Python is licensed under a BSD-style license, which means that if VSI
makes changes to the code to built it under VMS, they do not need to release
those changes in source form, nor do they need to make their port available
to the general public. So if VSI doesn't want to release source for their
port, they are perfectly within their rights to do that.

But not all open source code is like that.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arne Vajhøj
2020-08-08 17:57:22 UTC
Permalink
Post by Scott Dorsey
Post by Jan-Erik Söderholm
Maybe it is simply that the goal for VSI is not to contribute to the
open soure world as such, just to provide their customers access to
some open source tools that might be of value (to the customers).
The thing is that many open source licenses -require- that any changes
or additions to their code be made available in source form. Not all
of them do, but the gnu license definitely does.
So if VSI were to port, say, gcc to VMS, any changes they made to the gcc
code as part of that port need to be made generally available under the gpl
since gcc is licensed under the gpl.
Post by Jan-Erik Söderholm
I'm perfectly fine with that, *I* will never read any source code
for Python, or any other open source tool...
I feel somewhat guilty for this discussion since I asked about the
Python 3 ports... Sorry about that. :-)
Now, Python is licensed under a BSD-style license, which means that if VSI
makes changes to the code to built it under VMS, they do not need to release
those changes in source form, nor do they need to make their port available
to the general public. So if VSI doesn't want to release source for their
port, they are perfectly within their rights to do that.
But not all open source code is like that.
Correct.

But there is a middle ground between strong copyleft and permissive
licenses: weak copyleft.

LGPL etc. ensure that modifications get released without creating
the mixing with closed source problems as GPL etc. does.

Also most projects under permissive license are pretty
good at keeping the source code available. If the master
source code repository is on Github, then everything
should be fine.

Arne
Jan-Erik Söderholm
2020-08-08 23:31:13 UTC
Permalink
Post by Scott Dorsey
Post by Jan-Erik Söderholm
Maybe it is simply that the goal for VSI is not to contribute to the
open soure world as such, just to provide their customers access to
some open source tools that might be of value (to the customers).
The thing is that many open source licenses -require- that any changes
or additions to their code be made available in source form...
Sure! But "made available" is not the same thing as "contributing to
the open source world".

VSI can do additions and share them with the (few) VMS users that are
interested. But they do not need to, what ever it is called, send it
upstreams to the main source code repository.

I think there is a difference there...
Arne Vajhøj
2020-08-09 01:00:55 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Scott Dorsey
Post by Jan-Erik Söderholm
Maybe it is simply that the goal for VSI is not to contribute to the
open soure world as such, just to provide their customers access to
some open source tools that might be of value (to the customers).
The thing is that many open source licenses -require- that any changes
or additions to their code be made available in source form...
Sure! But "made available" is not the same thing as "contributing to
the open source world".
VSI can do additions and share them with the (few) VMS users that are
interested. But they do not need to, what ever it is called, send it
upstreams to the main source code repository.
I think there is a difference there...
The copyleft licenses typical have two requirements for modifications:
* the source code of the modifications must be made available to
those getting the binary
* those receiving the source code of the modifications are allowed
to share it with everybody

Arne
Scott Dorsey
2020-08-09 15:54:27 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Scott Dorsey
Post by Jan-Erik Söderholm
Maybe it is simply that the goal for VSI is not to contribute to the
open soure world as such, just to provide their customers access to
some open source tools that might be of value (to the customers).
The thing is that many open source licenses -require- that any changes
or additions to their code be made available in source form...
Sure! But "made available" is not the same thing as "contributing to
the open source world".
VSI can do additions and share them with the (few) VMS users that are
interested. But they do not need to, what ever it is called, send it
upstreams to the main source code repository.
This is true. However, if you don't get your changes included in the
main distribution, you can give up any chance of being able to incorporate
updates from the main distribution in the future. It is a -lot- more work
to maintain software this way. You can do it, if you have to.

And really, it's not very difficult to get your updates incorporated in the
main distribution, if they don't affect non-VMS systems.
Post by Jan-Erik Söderholm
I think there is a difference there...
There is. It's the difference between creating your own software distribution
and using someone else's. There are some arguments in favor of both, but when
your labour is limited and you expect the software to have any longevity, it's
easier to get someone else to do the maintenance.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arne Vajhøj
2020-08-09 17:22:15 UTC
Permalink
Post by Scott Dorsey
Post by Jan-Erik Söderholm
Post by Scott Dorsey
Post by Jan-Erik Söderholm
Maybe it is simply that the goal for VSI is not to contribute to the
open soure world as such, just to provide their customers access to
some open source tools that might be of value (to the customers).
The thing is that many open source licenses -require- that any changes
or additions to their code be made available in source form...
Sure! But "made available" is not the same thing as "contributing to
the open source world".
VSI can do additions and share them with the (few) VMS users that are
interested. But they do not need to, what ever it is called, send it
upstreams to the main source code repository.
This is true. However, if you don't get your changes included in the
main distribution, you can give up any chance of being able to incorporate
updates from the main distribution in the future. It is a -lot- more work
to maintain software this way. You can do it, if you have to.
And really, it's not very difficult to get your updates incorporated in the
main distribution, if they don't affect non-VMS systems.
Post by Jan-Erik Söderholm
I think there is a difference there...
There is. It's the difference between creating your own software distribution
and using someone else's. There are some arguments in favor of both, but when
your labour is limited and you expect the software to have any longevity, it's
easier to get someone else to do the maintenance.
Yes. And that is important because open source will not be a tiny
exotic corner of VSI software - it will be a huge part.

It is difficult to predict about the future, but my crystal
ball says that in 2025 then the software VSI distribute will be
1/3 closed source (written by VSI or licensed from HPE) and 2/3
open source.

LLVM, OpenJDK, Python, Apache, PHP etc..

Arne
David Goodwin
2020-08-09 21:54:42 UTC
Permalink
Post by Arne Vajhøj
Post by Scott Dorsey
Post by Jan-Erik Söderholm
Post by Scott Dorsey
Post by Jan-Erik Söderholm
Maybe it is simply that the goal for VSI is not to contribute to the
open soure world as such, just to provide their customers access to
some open source tools that might be of value (to the customers).
The thing is that many open source licenses -require- that any changes
or additions to their code be made available in source form...
Sure! But "made available" is not the same thing as "contributing to
the open source world".
VSI can do additions and share them with the (few) VMS users that are
interested. But they do not need to, what ever it is called, send it
upstreams to the main source code repository.
This is true. However, if you don't get your changes included in the
main distribution, you can give up any chance of being able to incorporate
updates from the main distribution in the future. It is a -lot- more work
to maintain software this way. You can do it, if you have to.
And really, it's not very difficult to get your updates incorporated in the
main distribution, if they don't affect non-VMS systems.
Post by Jan-Erik Söderholm
I think there is a difference there...
There is. It's the difference between creating your own software distribution
and using someone else's. There are some arguments in favor of both, but when
your labour is limited and you expect the software to have any longevity, it's
easier to get someone else to do the maintenance.
Yes. And that is important because open source will not be a tiny
exotic corner of VSI software - it will be a huge part.
It is difficult to predict about the future, but my crystal
ball says that in 2025 then the software VSI distribute will be
1/3 closed source (written by VSI or licensed from HPE) and 2/3
open source.
LLVM, OpenJDK, Python, Apache, PHP etc..
I hope someday VSI can just acquire the copyrights from HPE and then they're free to license OpenVMS and its layered products however they like. It would be certainly nice to see the source for the various layered products that don't really see any maintenance or sales released if only to preserve them.
Arne Vajhøj
2020-08-06 14:51:12 UTC
Permalink
Post by Jean-François Piéronne
Post by Arne Vajhøj
Post by Jean-François Piéronne
                                                            There are
many libraries/tools with a license which required you to publish the
sources like GPL for examples, SAMBA is one of them as mentioned by Craig.
Strictly speaking it only requires you to provide the source to those
that got the binary and allows those getting the source to redistribute
it to everybody. But that is practically the same as publish public.
My complaint was about your statement "a port without release sources
updates is not a contribution, it is a license violation" without any
note about that it only applies for some licenses. That was misleading.
You're right, they don't violate license of all products, just for some.
If this makes you happy and you think that's VSI has a great
contribution to the open source world that's your choice.
But for me a port without release any sources is not contributing to the
open-source world, it is just a contribution to the VSI business.
You should not be surprised by the fact that a commercial entity like
VSI seek to make money.

They should of course comply with all license rules.

And it is likely in their best interest long term to
support the open source community.
Post by Jean-François Piéronne
Post by Arne Vajhøj
Post by Jean-François Piéronne
I suggest you list all the VSI ports and give us how many doesn't
violate the associated license, and how many violate their license...
I am not the one that claims that they are violating any license.
I am assuming VSI is complying with all licenses.
Those that think otherwise should raise the issue.
And what am I doing ?
no, sorry no time.
But, again, if you're happy with this, no problem, and in fact, I know
many customers who have no problems with this.
If you want other examples: stunnel ,openjdk
"""
Stunnel uses the OpenSSL library for encryption and is distributed
under the GNU GPL version 2 license or later with an OpenSSL exception.
"""
"""
OpenJDK is licensed under the GNU General Public License (GNU GPL)
Version 2 with a linking exception such that components linked to the
Java Class library are not subject to the terms of the GPL license.
"""
Just found this in a few minutes.
I think you are pretty vague in a claim that they are
violating licenses.

OpenJDK is indeed under GPL and GPL with CPE. And VSI has released
OpenJDK 8 for VMS. That is common knowledge.

VSI not having put up the source for their changes on public HTTPS or
SFTP server is not a license violation.

If someone that has received a binary version, make a formal request for
the source code and don't get it, then there is a problem.

But that is not very clear from what you write.

If someone said: I downloaded OpenJDK 8 for VMS from VSI June 1st,
I made a formal request to VSI June 15th for the source code, June 30th
I got a reply from them signed by XXX saying that they could not provide
the requested. Then that would be specific. And a problem for VSI.
Post by Jean-François Piéronne
But, I agree for those under, for example, the Apache 2.0 license, you
are allowed to distribute binaries without providing the source code
with it.
Anything under a permissive license would be fine. Apache httpd, Python
etc..
Post by Jean-François Piéronne
Maybe I should have said that the contribution of VSI to the open-source
world is so light that it is near null, I don't think that's change the
facts.
If you had said that you think VSI has a moral/ethical problem of
using a lot of open source and not giving enough back to the open
source community then that would have been a completely different
topic than claiming that they are violating licenses.

Arne
Jean-François Piéronne
2020-08-06 15:05:24 UTC
Permalink
[snip]
Post by Arne Vajhøj
If you had said that you think VSI has a moral/ethical problem of
using a lot of open source and not giving enough back to the open
source community then that would have been a completely different
topic than claiming that they are violating licenses.
What is not clear in:

"""
The fourth section for version 2 of the license and the seventh section
of version 3 require that programs distributed as pre-compiled binaries
be accompanied by a copy of the source code, a written offer to
distribute the source code via the same mechanism as the pre-compiled
binary, or the written offer to obtain the source code that the user got
when they received the pre-compiled binary under the GPL.
"""
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Arne Vajhøj
2020-08-06 15:20:25 UTC
Permalink
Post by Jean-François Piéronne
[snip]
Post by Arne Vajhøj
If you had said that you think VSI has a moral/ethical problem of
using a lot of open source and not giving enough back to the open
source community then that would have been a completely different
topic than claiming that they are violating licenses.
"""
The fourth section for version 2 of the license and the seventh section
of version 3 require that programs distributed as pre-compiled binaries
be accompanied by a copy of the source code, a written offer to
distribute the source code via the same mechanism as the pre-compiled
binary, or the written offer to obtain the source code that the user got
when they received the pre-compiled binary under the GPL.
"""
Nobody is denying what GPL means.

But that is not what I am discussing above.

I am trying to make a clear distinction between moral/ethical
concerns and legal concerns.

Moral/ethical concerns give one significant freedom to
state subjective opinions.

Legal concerns are a bit different.

I would not accuse a company of license violation
which is a form of copyright infringement without
a very solid case.

Analogy: one can relative freely state that a named
politician economic policy is insane, but accusing
the same politician of accepting bribes requires
some documentation. And quoting the law that makes
bribery illegal is not relevant.

Arne
Jean-François Piéronne
2020-08-06 15:34:19 UTC
Permalink
Post by Arne Vajhøj
Post by Jean-François Piéronne
[snip]
Post by Arne Vajhøj
If you had said that you think VSI has a moral/ethical problem of
using a lot of open source and not giving enough back to the open
source community then that would have been a completely different
topic than claiming that they are violating licenses.
"""
The fourth section for version 2 of the license and the seventh section
of version 3 require that programs distributed as pre-compiled binaries
be accompanied by a copy of the source code, a written offer to
distribute the source code via the same mechanism as the pre-compiled
binary, or the written offer to obtain the source code that the user got
when they received the pre-compiled binary under the GPL.
"""
Nobody is denying what GPL means.
But that is not what I am discussing above.
I am trying to make a clear distinction between moral/ethical
concerns and legal concerns.
Moral/ethical concerns give one significant freedom to
state subjective opinions.
Legal concerns are a bit different.
[snip]

It's seems that we do not have the same reading of
https://gpl-violations.org/faq/sourcecode-faq/

So I will subscribe to the associated mailing list and ask them, so we
will see what is right, my understanding of the GPL license or yours.

Maybe it's you, maybe not...
JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Arne Vajhøj
2020-08-06 16:22:29 UTC
Permalink
Post by Jean-François Piéronne
Post by Arne Vajhøj
Post by Jean-François Piéronne
[snip]
Post by Arne Vajhøj
If you had said that you think VSI has a moral/ethical problem of
using a lot of open source and not giving enough back to the open
source community then that would have been a completely different
topic than claiming that they are violating licenses.
"""
The fourth section for version 2 of the license and the seventh section
of version 3 require that programs distributed as pre-compiled binaries
be accompanied by a copy of the source code, a written offer to
distribute the source code via the same mechanism as the pre-compiled
binary, or the written offer to obtain the source code that the user got
when they received the pre-compiled binary under the GPL.
"""
Nobody is denying what GPL means.
But that is not what I am discussing above.
I am trying to make a clear distinction between moral/ethical
concerns and legal concerns.
Moral/ethical concerns give one significant freedom to
state subjective opinions.
Legal concerns are a bit different.
[snip]
It's seems that we do not have the same reading of
https://gpl-violations.org/faq/sourcecode-faq/
So I will subscribe to the associated mailing list and ask them, so we
will see what is right, my understanding of the GPL license or yours.
Maybe it's you, maybe not...
I think we are pretty much in agreement on what GPL means.

We seem to have a very different opinion about level
of details necessary to publicly accuse a named
company of copyright infringement.

Arne
Jean-François Piéronne
2020-08-06 16:52:20 UTC
Permalink
Post by Arne Vajhøj
I think we are pretty much in agreement on what GPL means.
No, my reading of GPL is that source code should be provided in the same
way you provided the compiled version. And not doing that is a license
violation.

And you say that provided source code under request is enough, so it's
not a GPL violation.

That's the difference.

JF
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Arne Vajhøj
2020-08-06 17:02:34 UTC
Permalink
Post by Jean-François Piéronne
Post by Arne Vajhøj
I think we are pretty much in agreement on what GPL means.
No, my reading of GPL is that source code should be provided in the same
way you provided the compiled version. And not doing that is a license
violation.
And you say that provided source code under request is enough, so it's
not a GPL violation.
That's the difference.
OK. That is a difference.

https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

<quote>
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections 1 and
2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your cost of
physically performing source distribution, a complete machine-readable
copy of the corresponding source code, to be distributed under the terms
of Sections 1 and 2 above on a medium customarily used for software
interchange; or,
</quote>

One can either distribute the source with the binary (point a)
or supply the source at request (point b).

Arne
Phillip Helbig (undress to reply)
2020-08-06 19:12:54 UTC
Permalink
In article <rghd3b$15mc$***@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<***@vajhoej.dk> writes:
vvv
Post by Arne Vajhøj
https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
^^^
Arne Vajhøj
2020-08-06 19:21:46 UTC
Permalink
vvv
Post by Arne Vajhøj
https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
^^^
Yes. GPL 2 is "old".

But it is still widely used.

OpenJDK was mentioned in this thread.

But also Linux, MySQL etc..

Arne
Arne Vajhøj
2020-08-06 19:29:08 UTC
Permalink
Post by Arne Vajhøj
                                vvv
Post by Arne Vajhøj
https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
Yes. GPL 2 is "old".
But it is still widely used.
OpenJDK was mentioned in this thread.
But also Linux, MySQL etc..
And if you wonder why the old is used, then let us say getting
10 GPL people to agree on whether GPL 2 or GPL 3 are best is
just like getting 10 VMS people to agree on whether EDT or
EVE are best.

:-)

Arne
Loading...