ansa软件许可证转让流程及条件详解

公司重组、业务分拆、集团内部把CAE团队划到新主体——这种事一落到ANSA头上就特别难受。你以为把license.dat从老服务器拷到新服务器、改个主机名就完事了,结果beta_lm服务根本起不来,或者能起来但日志里一堆签名报错,工程师在工位上等着开工,IT这边只能干瞪眼。更糟的是过了半年原厂来函做合规核查,发现主体名对不上,那就不是技术问题了,是钱的问题。

先说清楚这事的本质:不是拷文件,是重新签发

ANSA这一套用的是BETA家自己的license manager,叫 beta_lm(不是FlexLM那套,别习惯性敲lmstat,ANSA自带的是beta_lm_stat)。许可证文件license.dat里几行是关键,转让能不能办、办完能不能用,全看这几行:

• OPTIONS=​ 这一行写的是签约公司名。主体一变,这行就不对了
  
• HOSTID=​ 锁的是license server的主机标识。换机器,这行就不对了
  
• SN=​ 每段的序列号,加短期许可的时候原厂是递增着发的
  
• CREDIT / WEIGHT​ ——ANSA不是按"几个license"算的,是按点数(credits)算的。一个GUI占100 credits,像ANSA_CATIA这种转接口是WEIGHT 25,CREDIT 200,那最多就8个实例。PACKAGE还能把几个feature打包成组,比如PRE_POST给3000 credits
  
• MAINTENANCE=​ 维保到期日,过保的feature日志里会报EXCEEDED MAINTANANCE PERIOD
• TZOFFSETMIN / TZOFFSETMAX​ 时区锁,有的license带这个,异地团队用了会报EXCEEDED TIMEZONE RANGE
• 所以"转让"这个动作,本质上就是让原厂按新的主体名和新的HOSTID,重新出一份license文件。文件里的东西是加密签名的,你自己改一行都改不动。
• 补一句现实情况:现在license文件是由Cadence Design Systems签发的(2026年2月起的license需要BETA LM 7.3),账号体系也并到CadenceID和ASK门户了。好消息是BETA LM Tools 7.x不需要换新的host key,老的license文件和新管理器是兼容的,这点省了不少事。

转让到底要满足什么条件

• 原厂(或中国区代理)的书面同意。绝大多数企业软件EULA里都有anti-assignment和change of control条款,控制权变更视同转让,没书面同意就是无效转让。这条各地判法还不一样,美国那边有过判决认定集团内部重组合并也算"禁止转让",别想当然
  
• 维保在有效期内。过保的license,原厂没有义务给你重签,而且这时候你谈判筹码基本为零
  
• 新的HOSTID。得在目标服务器上跑BETA_LM工具采集服务器标识信息,发给客户经理,他才能生成新文件
  
• 老服务器必须下线。新文件装好之后,原服务器上的license文件要删掉、服务停掉,合同里一般都写这条
  
• 提前量。别卡在交割前两周才提申请,那时候人家要什么条件你都得认
  

真要办,流程大概是这样

1. 把现有license.dat从头扒一遍,上面那几个字段抄成清单,跟采购合同对账
   
2. 翻合同里的assignment / change of control条款,确认到底要不要书面同意、找谁签字
   
3. 提前两三个月跟客户经理/代理提主体变更申请,给新实体名、新HOSTID、新签约主体信息
   
4. 维保断了的先补缴,不然第5步走不下去
   
5. 拿到新的license.dat:停beta_lm服务 → 备份旧文件 → 替换 → 重启。旧文件一定要备份,路径记清楚,改错了服务起不来全公司都干不了活
   
6. 客户端那头别忘了。ANSA找服务器的顺序是 -h → -f → BETA_LIC_FILE → ANSA_HOME → 当前目录 → BETA_LIC_SRV → ANSA_SRV → ansa_srv(DNS别名)→ localhost。你服务器换了,客户端的环境变量不改,他们还往老地址发请求
   
7. 老服务器清干净
   

四个坑,我见过的基本都在这

坑一:把转让当拷文件。​ 最常见。SERVER行看着就是个主机名+端口嘛,改改不就行了。不行,HOSTID和签名都对不上,服务起不来,或者起来也是个半死状态。后果是整个前处理环节全线停摆,少则一天多则一周,项目节点卡在这上面,研发那边能把你电话打爆。

坑二:只数"几个ANSA",不数credits和feature权重。​ 商务那边谈的时候说的是"多少个license",IT这边到手才发现同样数量的GUI点数,CATIA转接口、某些deck的权重不一样,或者干脆没转过来。原因就是采购只看总量不看结构。后果是交接完了工程师开不了某个模块,回头再找原厂加,那又是新一轮报价。

坑三:维保断了。​ 这个是最花钱的。过保意味着原厂没义务给你重签,这时候你不是"转让",你是在"重新购买"。常见的处理是补缴maintenance、顺带被要求迁到当前版本、原来谈下来的折扣清零。一笔本来几万块能办的事,最后变成几十万。

坑四:母子公司、分公司之间划转,觉得是"自己家的事"不用走流程。​ 母公司和子公司是两个法人实体,license是签给母公司的,子公司用就是超用。分拆的时候尤其容易出问题,过渡期搞个TSA让剥离出去的业务先接着用,大部分license根本不允许你这么干。而且并购重组是厂商盯得最紧的审计触发点,同意函和合规审查经常一起来,true-up直接被塞进同意的条件里。你越晚提,越被动。

怎么办,分四层,从上往下做

第一层,先摸底,别急着找原厂谈。​ 用beta_lm_stat把占用情况拉一段时间的数据,至少跨三五个月,发版季和平时完全两个样。重点看三个数:占用小时数(总消耗)、排队失败率(供需矛盾有多狠)、空闲检出率(多少点数是被白白占着的)。顺手把beta_lm.log里的total clients和waiting time也捞出来。注意beta_lm_stat只能告诉你"现在谁占着",历史趋势它没有,要么自己把日志落库,要么上工具。

第二层,零成本的配置优化,转让前后都能做。​ 这块不需要花钱,全是beta_lm自带的能力:

• shared选项:同一用户同一台机器多开只占一份点数。但虚拟机和网卡teaming的情况下不共享,v7.0的说明里写得很明确,别指望靠VM省点数
  
• Idle User Timeout + Kill User:先设保守点,90分钟起步。前处理一开就是一天,上来设15分钟,工程师能把你工位掀了
  
• options文件里按user/group/host做feature的allow/deny/limit,把稀缺的deck点数保给关键项目组,v7.0之后支持这个
  
• 时区锁务必提前确认。有TZOFFSETMIN/MAX的license,转让前不问清楚,接过来才发现外地分公司用不了,那时候再改来不及
  
• 第三层,采购策略得改。​ 别再按峰值并发买了,按P95并发加一个可接受的排队率买,峰值那部分用短期许可顶一下——原厂可以加一段更高SN的临时许可,到期自动失效,专门对付集中发版那两个月。续保千万别断,把MAINTENANCE到期日做成日历提醒,提前90天动。签约主体在第一次签合同的时候就谈清楚,转让条款、控制权变更条款,那时候你有筹码,等到交割时谈就是被宰。还有,rehost的次数有的厂商一年是有限制的(比如Ansys是每年3次),这种限制提前问明白,别一年里把额度用光了。
• 第四层,才轮到工具。​ beta_lm_stat解决不了的是"历史"和"真闲置"——它看不出一个人是开着界面去吃饭了还是在等求解。第三方的许可管理方案(Open iT、LMT LicManager这类)是靠客户端agent采CPU、IO、键鼠事件来判断真闲置,再自动回收。上之前先想清楚一件事:这套数据你打算拿来干嘛。如果只为了砍明年的预算,研发那边一定会想办法让你的数据失真;如果拿去保关键项目、把排队率降下来,这事才推得动。

说个我经手的

一家做零部件的,集团把CAE团队从老主体划到新成立的合资公司。原来池子是3000 credits,GUI 100 credits一个,相当于30个并发。我先按上面第一层跑了一个季度的数据:峰值并发只有16个,排队失败率12%,空闲检出率31%——也就是说买的时候是按"30个人同时要"报的,实际一半都不到,还有三分之一的时间点数是被人占着不干活。

转让那一步,因为中间断过9个月维保,原厂要求先补齐再重签,补缴加版本迁移,一笔七位数人民币差点就出去了,最后按现值谈下来也得几十万。真正省回来的是后面:把idle timeout设成90分钟、按项目组给CFD deck做limit、集中发版那两个月用短期许可顶,credits从3000砍到1800照样够用,排队失败率从12%掉到2%,利用率从38%拉到71%。省下来的钱覆盖了差不多一半的转让成本,剩下的就当买了个教训——维保这个东西,平时看着是纯支出,到转让那天它是你唯一的门票。