We've been required to encrypt h/ds, and so have been rolling that out over the last year or so. Thing is, you need to put in a password, of course, to boot the system. My manager found a way to allow us to reboot without being at the system's keyboard, a package called clevis. Works fine... except in a couple of very special cases.
Those systems, the problem is that, due to older software, and *very* expensive licenses that are tied to a MAC address, I have to spoof the MAC address since my users got new(er) machines.
Clevis is trying to contact its password server, using the *real* MAC address, but our DHCP has to serve the *spoofed* MAC address. I know, from trying, that I can't have two entries for the same system. Can anyone suggest a solution?
mark
On Fri, 8 Jun 2018, m.roth@5-cent.us wrote:
We've been required to encrypt h/ds, and so have been rolling that out over the last year or so. Thing is, you need to put in a password, of course, to boot the system. My manager found a way to allow us to reboot without being at the system's keyboard, a package called clevis. Works fine... except in a couple of very special cases.
Those systems, the problem is that, due to older software, and *very* expensive licenses that are tied to a MAC address, I have to spoof the MAC address since my users got new(er) machines.
Clevis is trying to contact its password server, using the *real* MAC address, but our DHCP has to serve the *spoofed* MAC address. I know, from trying, that I can't have two entries for the same system. Can anyone suggest a solution?
Nothing wrong with having two MAC addresses listed for one IP. With ISC DHCP the label for a host has to be unique, but the hostname doesn't.
jh
John Hodrien wrote:
On Fri, 8 Jun 2018, m.roth@5-cent.us wrote:
We've been required to encrypt h/ds, and so have been rolling that out over the last year or so. Thing is, you need to put in a password, of course, to boot the system. My manager found a way to allow us to reboot without being at the system's keyboard, a package called clevis. Works fine... except in a couple of very special cases.
Those systems, the problem is that, due to older software, and *very* expensive licenses that are tied to a MAC address, I have to spoof the MAC address since my users got new(er) machines.
Clevis is trying to contact its password server, using the *real* MAC address, but our DHCP has to serve the *spoofed* MAC address. I know, from trying, that I can't have two entries for the same system. Can anyone suggest a solution?
Nothing wrong with having two MAC addresses listed for one IP. With ISC DHCP the label for a host has to be unique, but the hostname doesn't.
The IP's not the problem, it's dhcpd gagging on two entries, two MAC addresses, for the same server name - think dhcpd.conf.local
mark
On Jun 8, 2018, at 11:27 AM, m.roth@5-cent.us wrote:
John Hodrien wrote:
On Fri, 8 Jun 2018, m.roth@5-cent.us wrote:
We've been required to encrypt h/ds, and so have been rolling that out over the last year or so. Thing is, you need to put in a password, of course, to boot the system. My manager found a way to allow us to reboot without being at the system's keyboard, a package called clevis. Works fine... except in a couple of very special cases.
Those systems, the problem is that, due to older software, and *very* expensive licenses that are tied to a MAC address, I have to spoof the MAC address since my users got new(er) machines.
Clevis is trying to contact its password server, using the *real* MAC address, but our DHCP has to serve the *spoofed* MAC address. I know, from trying, that I can't have two entries for the same system. Can anyone suggest a solution?
Nothing wrong with having two MAC addresses listed for one IP. With ISC DHCP the label for a host has to be unique, but the hostname doesn't.
The IP's not the problem, it's dhcpd gagging on two entries, two MAC addresses, for the same server name - think dhcpd.conf.local
From the dhcpd.conf man page:
If it is desirable to be able to boot a DHCP or BOOTP client on more than one subnet with fixed v4 addresses, more than one address may be specified in the fixed-address declaration, or more than one host statement may be specified matching the same client. The fixed-address6 delcaration is used for v6 addresses. At this time it only works with a single address. For multiple addresses specify multiple host statements. If client-specific boot parameters must change based on the network to which the client is attached, then multiple host declarations should be used. The host declarations will only match a client if one of their fixed-address statements is viable on the subnet (or shared network) where the client is attached. Conversely, for a host declaration to match a client being allocated a dynamic address, it must not have any fixed-address statements. You may therefore need a mixture of host declarations for any given client...some having fixed-address statements, others without. hostname should be a name identifying the host. If a hostname option is not specified for the host, hostname is used.
You need multiple host entries, with different labels on the “host” line, different MAC address, same IP, same hostname.
On 06/08/18 10:27, m.roth@5-cent.us wrote:
John Hodrien wrote:
On Fri, 8 Jun 2018, m.roth@5-cent.us wrote:
We've been required to encrypt h/ds, and so have been rolling that out over the last year or so. Thing is, you need to put in a password, of course, to boot the system. My manager found a way to allow us to reboot without being at the system's keyboard, a package called clevis. Works fine... except in a couple of very special cases.
Those systems, the problem is that, due to older software, and *very* expensive licenses that are tied to a MAC address, I have to spoof the MAC address since my users got new(er) machines.
Clevis is trying to contact its password server, using the *real* MAC address, but our DHCP has to serve the *spoofed* MAC address. I know, from trying, that I can't have two entries for the same system. Can anyone suggest a solution?
Nothing wrong with having two MAC addresses listed for one IP. With ISC DHCP the label for a host has to be unique, but the hostname doesn't.
The IP's not the problem, it's dhcpd gagging on two entries, two MAC addresses, for the same server name - think dhcpd.conf.local
When I have a machine that can comes with different MAC addresses, and I have to give it the same IP, here is what I have in DHCP server configuration (Mac addresses and IP address are obfuscated below):
# tricky machine host tricky { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address A.B.C.D; }
# tricky machine again host tricky1 { hardware ethernet yy:yy:yy:yy:yy:yy; fixed-address A.B.C.D; }
# and a bunch of other configs for the same machine
The only trouble here will be if both MAC addresses request IP and and are both present, in that case DHCP server will offer that same static IP to the second request from different MAC address as well, but DHCP client (if smart) will check the presence of the IP address on the network already, and will not use that IP if it is already used and will send new request, and this will go on till first hardware stops using that IP address.
Those are "tricky", "tricky1", ... labels that John mentioned should be unique, and they are only known to DHCP server.
<rant> There are a bunch of Out Of Band management creeps that sit on the first network interface and come up when AC is connected no matter whether the system is up or not. And they come with different MAC address. And these are the ones that you can not assign the same IP as that the machine itself is supposed to have. Sorry about little rant, these creepy things are sysadmin's disaster, - UNIX sysadmin's disaster I meant. Or Windows sysadmin's best friend, I figure. Like in the phrase I'm stealing from one Windows sysadmin whom I respect a lot: "Did you try to power cycle the machine and see if it solves that?" </rant>
I hope, this helps.
Valeri
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Valeri Galtsev wrote:
On 06/08/18 10:27, m.roth@5-cent.us wrote:
John Hodrien wrote:
On Fri, 8 Jun 2018, m.roth@5-cent.us wrote:
We've been required to encrypt h/ds, and so have been rolling that out over the last year or so. Thing is, you need to put in a password, of course, to boot the system. My manager found a way to allow us to reboot without being at the system's keyboard, a package called clevis. Works fine... except in a couple of very special cases.
Those systems, the problem is that, due to older software, and *very* expensive licenses that are tied to a MAC address, I have to spoof the MAC address since my users got new(er) machines.
Clevis is trying to contact its password server, using the *real* MAC address, but our DHCP has to serve the *spoofed* MAC address. I know, from trying, that I can't have two entries for the same system. Can anyone suggest a solution?
Nothing wrong with having two MAC addresses listed for one IP. With ISC DHCP the label for a host has to be unique, but the hostname doesn't.
The IP's not the problem, it's dhcpd gagging on two entries, two MAC addresses, for the same server name - think dhcpd.conf.local
When I have a machine that can comes with different MAC addresses, and I have to give it the same IP, here is what I have in DHCP server configuration (Mac addresses and IP address are obfuscated below):
# tricky machine host tricky { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address A.B.C.D; }
# tricky machine again host tricky1 { hardware ethernet yy:yy:yy:yy:yy:yy; fixed-address A.B.C.D; }
Hmmm... wonder if it will gag - we don't put the IP in that, that comes from DNS. The format we use is host <host <shortname> P hardware ethernet <MAC address>; fixed-address <fqdn>;}
so if it would work, replace shortname with short and short1?
mark
On 06/08/18 12:01, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On 06/08/18 10:27, m.roth@5-cent.us wrote:
John Hodrien wrote:
On Fri, 8 Jun 2018, m.roth@5-cent.us wrote:
We've been required to encrypt h/ds, and so have been rolling that out over the last year or so. Thing is, you need to put in a password, of course, to boot the system. My manager found a way to allow us to reboot without being at the system's keyboard, a package called clevis. Works fine... except in a couple of very special cases.
Those systems, the problem is that, due to older software, and *very* expensive licenses that are tied to a MAC address, I have to spoof the MAC address since my users got new(er) machines.
Clevis is trying to contact its password server, using the *real* MAC address, but our DHCP has to serve the *spoofed* MAC address. I know, from trying, that I can't have two entries for the same system. Can anyone suggest a solution?
Nothing wrong with having two MAC addresses listed for one IP. With ISC DHCP the label for a host has to be unique, but the hostname doesn't.
The IP's not the problem, it's dhcpd gagging on two entries, two MAC addresses, for the same server name - think dhcpd.conf.local
When I have a machine that can comes with different MAC addresses, and I have to give it the same IP, here is what I have in DHCP server configuration (Mac addresses and IP address are obfuscated below):
# tricky machine host tricky { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address A.B.C.D; }
# tricky machine again host tricky1 { hardware ethernet yy:yy:yy:yy:yy:yy; fixed-address A.B.C.D; }
Hmmm... wonder if it will gag - we don't put the IP in that, that comes from DNS. The format we use is host <host <shortname> P hardware ethernet <MAC address>; fixed-address <fqdn>;}
It will not care if you put hostname (FGDN) instead of IP address - either is acceptable in config file. FQDN just makes your DHCP server go for every request it receives where FQDN is involved to DNS server, whereas if you have static IPs (not rotating all the time Windows gang like to probably to make compromised machines change their IP all the time), then you will save unnecessary DNS requests and associated delays by using IPs.
so if it would work, replace shortname with short and short1?
Yes, that was exactly John's point, I just put my example to make it more transparent: we all are quicker comprehending actual config files, than the documentations they were created according to.
Valeri
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
so if it would work, replace shortname with short and short1?
With all of this hokey-pokey surrounding licensing and mac addresses, I wonder if this outfit is actually still in compliance with the terms of their license for this software, whatever it may be?
If the software licensed to run only on Machine X and Machine X has now been junked and replace by Machine Y, then isn't the solution to obtain a license for the software for Machine Y or be out-of compliance regardless of the technical ability to spoof whatever it's looking for?
Frank Cox wrote:
so if it would work, replace shortname with short and short1?
With all of this hokey-pokey surrounding licensing and mac addresses, I wonder if this outfit is actually still in compliance with the terms of their license for this software, whatever it may be?
If the software licensed to run only on Machine X and Machine X has now been junked and replace by Machine Y, then isn't the solution to obtain a license for the software for Machine Y or be out-of compliance regardless of the technical ability to spoof whatever it's looking for?
It's apparently a very good molecular modeling program, and to be real, my users tell me that the company that bought the original company wants, and I'm not making this up, $15k US to generate a license for a new workstation. And there's two? three? workstations that run it.
And this is a US gov't agency (civilian secrot). Budget? We don' need no steenkeen budgets, the Magic Hand of the Market will produce all the results we need.....
mark "not including building maintenance budgets"
On 06/08/18 13:48, m.roth@5-cent.us wrote:
Frank Cox wrote:
so if it would work, replace shortname with short and short1?
With all of this hokey-pokey surrounding licensing and mac addresses, I wonder if this outfit is actually still in compliance with the terms of their license for this software, whatever it may be?
If the software licensed to run only on Machine X and Machine X has now been junked and replace by Machine Y, then isn't the solution to obtain a license for the software for Machine Y or be out-of compliance regardless of the technical ability to spoof whatever it's looking for?
Frank, I 100% agree with you. The only case with spoofed MAC address and license that may have chance to stand in court will be if all below are true:
1. the company issued perpetual license. 2. the company does not exist 3. the original hardware died (be it motherboard whose embedded NIC license was locked to or network card) 4. single replacement machine (meeting requirements of license; sometimes it is number of CPUs/cores, memory, etc) is used to replace it [imminently needing to spoof MAC address] 5. fair effort was made to find and notify about the above whoever inherited rights of dissolved company
But I bet the lawyer can find flaws in what I tried to say.
On a similar note: one of the companies whose software scientists here were using a lot (IDL is a product) changed hand several times, and last owner changed licensing terms and stopped signing perpetual licenses. With perpetual license you were able to keep upgrading software during support period, usually 1 year, and keep using last version later forever only you are locked to that older version. They stopped signing perpetual licenses, and made it "software for rent" with 1 year rent term. When that happened I recommended all our people to avoid using IDL in new projects (python was my recommendation as fair replacement - just what I know, not that I consider it better than other alternatives). As a programmer (former I should say, as I don't put my dirty hands into code lately, almost not) I wouldn't invest my time into mastering something that I not necessarily will have access to at some point in a future...
Valeri
It's apparently a very good molecular modeling program, and to be real, my users tell me that the company that bought the original company wants, and I'm not making this up, $15k US to generate a license for a new workstation. And there's two? three? workstations that run it.
And this is a US gov't agency (civilian secrot). Budget? We don' need no steenkeen budgets, the Magic Hand of the Market will produce all the results we need.....
mark "not including building maintenance budgets"
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Valeri Galtsev wrote:
On 06/08/18 13:48, m.roth@5-cent.us wrote:
Frank Cox wrote:
so if it would work, replace shortname with short and short1?
With all of this hokey-pokey surrounding licensing and mac addresses, I wonder if this outfit is actually still in compliance with the terms of their license for this software, whatever it may be?
If the software licensed to run only on Machine X and Machine X has now been junked and replace by Machine Y, then isn't the solution to obtain a license for the software for Machine Y or be out-of compliance regardless of the technical ability to spoof whatever it's looking for?
Frank, I 100% agree with you. The only case with spoofed MAC address and license that may have chance to stand in court will be if all below are true:
- the company issued perpetual license.
- the company does not exist
- the original hardware died (be it motherboard whose embedded NIC
license was locked to or network card) 4. single replacement machine (meeting requirements of license; sometimes it is number of CPUs/cores, memory, etc) is used to replace it [imminently needing to spoof MAC address] 5. fair effort was made to find and notify about the above whoever inherited rights of dissolved company
But I bet the lawyer can find flaws in what I tried to say.
Both users' old workstations were at least 6 years old, maybe more. They got surplused (I'm the one who did that). So it's only on the two machines that the licenses were for. But.... I assume it was very expensive when they bought it.
On a similar note: one of the companies whose software scientists here were using a lot (IDL is a product) changed hand several times, and last owner changed licensing terms and stopped signing perpetual licenses. With perpetual license you were able to keep upgrading software during support period, usually 1 year, and keep using last version later forever only you are locked to that older version. They stopped signing perpetual licenses, and made it "software for rent" with 1 year rent term. When that happened I recommended all our people to avoid using IDL in new projects (python was my recommendation as fair replacement - just what I know, not that I consider it better than other alternatives). As a programmer (former I should say, as I don't put my dirty hands into code lately, almost not) I wouldn't invest my time into mastering something that I not necessarily will have access to at some point in a future...
Yeah. We have a number of folks here using R, and fewer still using Matlab.
mark
On 06/08/18 15:26, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On 06/08/18 13:48, m.roth@5-cent.us wrote:
Frank Cox wrote:
so if it would work, replace shortname with short and short1?
With all of this hokey-pokey surrounding licensing and mac addresses, I wonder if this outfit is actually still in compliance with the terms of their license for this software, whatever it may be?
If the software licensed to run only on Machine X and Machine X has now been junked and replace by Machine Y, then isn't the solution to obtain a license for the software for Machine Y or be out-of compliance regardless of the technical ability to spoof whatever it's looking for?
Frank, I 100% agree with you. The only case with spoofed MAC address and license that may have chance to stand in court will be if all below are true:
- the company issued perpetual license.
- the company does not exist
- the original hardware died (be it motherboard whose embedded NIC
license was locked to or network card) 4. single replacement machine (meeting requirements of license; sometimes it is number of CPUs/cores, memory, etc) is used to replace it [imminently needing to spoof MAC address] 5. fair effort was made to find and notify about the above whoever inherited rights of dissolved company
But I bet the lawyer can find flaws in what I tried to say.
Both users' old workstations were at least 6 years old, maybe more. They got surplused (I'm the one who did that). So it's only on the two machines that the licenses were for. But.... I assume it was very expensive when they bought it.
On a similar note: one of the companies whose software scientists here were using a lot (IDL is a product) changed hand several times, and last owner changed licensing terms and stopped signing perpetual licenses. With perpetual license you were able to keep upgrading software during support period, usually 1 year, and keep using last version later forever only you are locked to that older version. They stopped signing perpetual licenses, and made it "software for rent" with 1 year rent term. When that happened I recommended all our people to avoid using IDL in new projects (python was my recommendation as fair replacement - just what I know, not that I consider it better than other alternatives). As a programmer (former I should say, as I don't put my dirty hands into code lately, almost not) I wouldn't invest my time into mastering something that I not necessarily will have access to at some point in a future...
Yeah. We have a number of folks here using R, and fewer still using Matlab.
Sounds like your former matlab users are happy with R (bad name, BTW, try to search...). Thanks, I will know now what to mention as alternative if it will be about matlab!
Valeri
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Valeri Galtsev wrote:
On 06/08/18 15:26, m.roth@5-cent.us wrote:
<SNIP>
On a similar note: one of the companies whose software scientists here were using a lot (IDL is a product) changed hand several times, and last owner changed licensing terms and stopped signing perpetual
licenses.
With perpetual license you were able to keep upgrading software during support period, usually 1 year, and keep using last version later forever only you are locked to that older version. They stopped signing perpetual licenses, and made it "software for rent" with 1 year rent term. When that happened I recommended all our people to avoid using IDL in new projects (python was my recommendation as fair replacement - just what I know, not that I consider it better than other
alternatives). As
a programmer (former I should say, as I don't put my dirty hands into code lately, almost not) I wouldn't invest my time into mastering something that I not necessarily will have access to at some point in a future...
Yeah. We have a number of folks here using R, and fewer still using Matlab.
Sounds like your former matlab users are happy with R (bad name, BTW, try to search...). Thanks, I will know now what to mention as alternative if it will be about matlab!
And it has heavy hooks for python. And it's open source. Matlab may have more sophisticated tools, but....
mark "now, there is the guy who runs R jobs on a server with a ton of memory *and* to Tesla cards that run for, literally, 2-3 *weeks*. Lotta data...."
On 06/08/18 15:45, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On 06/08/18 15:26, m.roth@5-cent.us wrote:
<SNIP> >>> On a similar note: one of the companies whose software scientists here >>> were using a lot (IDL is a product) changed hand several times, and >>> last owner changed licensing terms and stopped signing perpetual licenses. >>> With perpetual license you were able to keep upgrading software during >>> support period, usually 1 year, and keep using last version later >>> forever only you are locked to that older version. They stopped signing >>> perpetual licenses, and made it "software for rent" with 1 year rent >>> term. When that happened I recommended all our people to avoid using >>> IDL in new projects (python was my recommendation as fair replacement - >>> just what I know, not that I consider it better than other alternatives). As >>> a programmer (former I should say, as I don't put my dirty hands into >>> code lately, almost not) I wouldn't invest my time into mastering >>> something that I not necessarily will have access to at some point in a >>> future... >> >> Yeah. We have a number of folks here using R, and fewer still using >> Matlab. > > Sounds like your former matlab users are happy with R (bad name, BTW, > try to search...). Thanks, I will know now what to mention as > alternative if it will be about matlab! > And it has heavy hooks for python. And it's open source. Matlab may have more sophisticated tools, but....
I know about R, I set it up for those who asks, have it on main number crunchers here. I just never played with it myself, and didn't have any idea that matlab users may be happy about it. But now I know, thanks again!
Valeri
mark "now, there is the guy who runs R jobs on a server with a ton of memory *and* to Tesla cards that run for, literally, 2-3 *weeks*. Lotta data...."
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Valeri Galtsev wrote:
On 06/08/18 15:45, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On 06/08/18 15:26, m.roth@5-cent.us wrote:
<SNIP> >>> On a similar note: one of the companies whose software scientists >>> here >>> were using a lot (IDL is a product) changed hand several times, and >>> last owner changed licensing terms and stopped signing perpetual licenses. >>> With perpetual license you were able to keep upgrading software >>> during >>> support period, usually 1 year, and keep using last version later >>> forever only you are locked to that older version. They stopped >>> signing >>> perpetual licenses, and made it "software for rent" with 1 year rent >>> term. When that happened I recommended all our people to avoid using >>> IDL in new projects (python was my recommendation as fair replacement >>> - >>> just what I know, not that I consider it better than other alternatives). As >>> a programmer (former I should say, as I don't put my dirty hands into >>> code lately, almost not) I wouldn't invest my time into mastering >>> something that I not necessarily will have access to at some point in >>> a >>> future... >> >> Yeah. We have a number of folks here using R, and fewer still using >> Matlab. > > Sounds like your former matlab users are happy with R (bad name, BTW, > try to search...). Thanks, I will know now what to mention as > alternative if it will be about matlab! > And it has heavy hooks for python. And it's open source. Matlab may have more sophisticated tools, but....
I know about R, I set it up for those who asks, have it on main number crunchers here. I just never played with it myself, and didn't have any idea that matlab users may be happy about it. But now I know, thanks again!
I've never played with it either - it's statistical software, I think. I just install and upgrade....
Have a good weekend.
mark
On Fri, 8 Jun 2018, Valeri Galtsev wrote:
Frank, I 100% agree with you. The only case with spoofed MAC address and license that may have chance to stand in court will be if all below are true:
- the company issued perpetual license.
- the company does not exist
- the original hardware died (be it motherboard whose embedded NIC license
was locked to or network card) 4. single replacement machine (meeting requirements of license; sometimes it is number of CPUs/cores, memory, etc) is used to replace it [imminently needing to spoof MAC address] 5. fair effort was made to find and notify about the above whoever inherited rights of dissolved company
I can think of a few more: 1: The company does not exist and for some reason no one inherited its rights. 2: The company does not exist, it had duty to inform its customers of such events and it failed to do so. 3. The company still has rights, but the DRM is enforcing rights it does not have.
Of course all of these might be blown away by the DMCA. When Sony installed malware on Windows machines, Jerry Pournelle was afraid to tell its victims how to get rid of it for just that reason. http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DD...
Perhaps the simplest solution might be to get the real MAC addresses right. If you cannot dig the old NIC out of the trash, perhaps you could use something with an adjustable MAC.
On 2018-06-08, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Frank, I 100% agree with you. The only case with spoofed MAC address and license that may have chance to stand in court will be if all below are true:
- the company issued perpetual license.
- the company does not exist
Based on what's written below, it seems like the company does in fact still exist, and that therefore the organization trying to spoof MACs may be violating their license. I hope the company which sells the program doesn't read this mailing list.
It's apparently a very good molecular modeling program, and to be real, my users tell me that the company that bought the original company wants, and I'm not making this up, $15k US to generate a license for a new workstation. And there's two? three? workstations that run it.
And this is a US gov't agency (civilian secrot). Budget? We don' need no steenkeen budgets, the Magic Hand of the Market will produce all the results we need.....
--keith
On Sun, June 10, 2018 6:19 pm, Keith Keller wrote:
On 2018-06-08, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Frank, I 100% agree with you. The only case with spoofed MAC address and license that may have chance to stand in court will be if all below are true:
- the company issued perpetual license.
- the company does not exist
Based on what's written below, it seems like the company does in fact still exist, and that therefore the organization trying to spoof MACs may be violating their license. I hope the company which sells the program doesn't read this mailing list.
Keith, you as well as Frank originally and following Frank I all agree that the case described in this thread may constitute violation of license agreement. So, for the OP it may be advantageous think everything over...
That is why I tried to draw hypothetical set of conditions I under which if all if all are met, it may not fall under violation. To show how narrow could be the case in which it may, just may not be a violation. You trimmed away several other conditions that are necessary as well. Anyway, as we all agree, we should comply license agreement, or not use software at all if we can not comply for one reason or another.
Valeri
It's apparently a very good molecular modeling program, and to be real, my users tell me that the company that bought the original company wants, and I'm not making this up, $15k US to generate a license for a new workstation. And there's two? three? workstations that run it.
And this is a US gov't agency (civilian secrot). Budget? We don' need no steenkeen budgets, the Magic Hand of the Market will produce all the results we need.....
--keith
-- kkeller@wombat.san-francisco.ca.us
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
-
Frank Cox -
John Hodrien -
Keith Keller -
m.roth＠5-cent.us -
Michael Hennebry -
Noam Bernstein -
Valeri Galtsev