谁拥有您定制业务系统的源代码？

委托开发定制系统的企业主——无论是预约平台、库存看板，还是把几个工具串联起来的应用——很少会在一开始就问源代码归谁所有，直到出了问题：开发商不再回复，第二家供应商被请来做修改，或者企业想把系统迁移到新的主机。到那时，您是否真正拥有自己花钱买来的东西，完全取决于几个月或几年前合同里写了什么，而不是发票金额有多大。这篇指南会讲清楚马来西亚法律到底是怎么规定的、为什么光有版权往往还不够，以及能在问题演变成纠纷之前把它解决掉的具体问题和文件。

简短回答：马来西亚法律默认对您有利，但仅限于默认情况下

根据马来西亚《1987年版权法》第26条，当受版权保护的作品——包括软件——是作为委托作品而非在雇佣合同下创作时，除非双方合同另有约定，版权将被视为转移给委托该作品的一方。简单来说：如果您付费请开发商为企业开发定制系统，马来西亚法律的默认立场是版权归您所有，而不是开发商——前提是协议中没有任何条款推翻这一点。

为什么许多企业其实并不真正拥有自己的代码

问题就出在"除非合同另有约定"这句话上。许多标准的开发商或代理合同都包含一项条款，将知识产权保留给供应商，仅授予客户使用成品软件的权利，甚至完全不提及归属问题，留待日后争论。没有书面合同的非正式合作更麻烦：法定默认规则或许在技术上仍然适用，但由于没有任何书面记录，一旦真的产生争议，要证明当初实际约定了什么会困难得多。

拥有版权不等于拥有可用的所有权

即使企业对其定制系统拥有明确的版权，实际上仍可能被排除在系统之外，无法真正使用。拥有版权是一项法律权利；而运行、维护和修改系统需要实际可用的部分，这些并不会因为拥有版权就自动到手：

• 源代码本身——不仅仅是访问一个已部署、已编译的版本，而是开发商用来阅读、修改和重新构建系统所需的底层文件。
• 技术文档——系统的结构、每个部分的作用，以及必要时如何将其部署到另一台服务器上。
• 管理员、服务器和数据库凭证——真正能让人操作和修改系统的登录信息，而不只是使用系统。
• 第三方及开源组件的说明——大多数定制开发都会在各自独立许可下使用现成的库和框架，即使企业拥有在此之上原创构建的一切，也应该了解这些组件的情况。

拥有版权却从未拿到这些东西的企业，仍然完全依赖原开发商才能对自己的系统做任何事情。

法律所说的"委托作品"到底是什么意思

有必要说清楚这里法律实际在判定什么。如果软件是企业自己的员工作为工作一部分编写的，雇主依照雇佣合同的一般规则拥有它——这种情况下很少出现争议。定制业务系统几乎总是属于另一种情况：服务合同，即委托外部开发商或代理、付费让其完成一款特定软件。正是这第二类情况适用"视为转移给委托方"的默认规则，也正是在这类情况下，合同的具体措辞才真正起作用，因为法律明确允许双方朝任一方向推翻这一默认规则。

同样值得说清楚的是，这里判定的到底是什么：是版权，不是商标、专利，也不是企业的数据。版权保护的是具体的代码和文档，作为一项创作性与技术性的成果。它本身并不说明系统运行后产生的数据归谁所有，也不涉及系统销售或推广所用的品牌名称——这些属于不同的法律领域，如果对项目有重要意义，值得单独谈清楚。

合同条款如何真正改变结果

同一个定制系统，由同一个开发商来做，最终可能落入三种完全不同的所有权结果，而这完全取决于合同里的三四句话：

只有第一行的结果真正值得依赖。其余三种或多或少都让企业暴露在风险之中，即使第二行和第四行在技术上有法定默认规则撑腰——一条从未在您具体案例中真正被论证过的默认规则，和一项已经确定的权利，并不是一回事。

供应商标准合同里要留意的警示条款

大多数代理商和自由开发者都会反复使用同一份模板合同应付不同客户，而这些模板在处理归属问题上差异很大。签约前有几类条款值得多读一遍：

• "客户获得使用该软件的许可"而不是"所有权转移给客户"——许可只是获准使用别人拥有的东西，本身并不等于拥有。
• 知识产权转移以"全部且最终付款"为条件却没有更多细节——表面上合情合理，但值得确认它是否真的自动触发，而不是需要另一份单独签署、却从没人去跟进的交接文件。
• 完全没有提到交付源代码，只写"该软件"——这种措辞模糊到日后可以往任何一个方向解读，而这正是纠纷的温床。
• 所有权或访问权与持续有效的维护合同挂钩——意味着哪怕是已经全额付清的代码，退订维护合同的那个月，访问权限也可能一并失效。
• 没有关于第三方或开源组件的披露条款——让企业根本不知道自己对系统的某些部分到底能做什么、不能做什么。

签约前该问的问题，而不是签约后

确定归属问题最划算的时机，是在接受报价之前——那时它还只是合同里的一行条款，而不是一场纠纷。签约前，请确认：

• 合同是否明确规定源代码和知识产权将转移给我，具体在什么时点——最好是在最终付款或项目验收时？
• 我是否会拿到完整的源代码库，而不仅仅是一个已部署或已编译的版本？将以什么方式交付？
• 项目交付后，系统所运行的主机、域名、API 和管理员账号归谁所有？
• 是否使用了任何开源或第三方组件？采用什么许可协议？
• 如果我停止支付持续的支持或维护费用，所有权或访问权限会不会发生变化？
• 如果日后需要，我能否把代码交给其他开发商？

如果当初从未以书面形式约定过，怎么办？

许多企业目前使用的定制系统，是多年前靠一次握手或几封简短邮件谈成的，完全没有任何知识产权条款。第26条下的法定默认规则很可能仍然对企业有利，因为企业是委托并支付这项工作费用的一方，但真正发生纠纷时，依赖这一默认规则远不如白纸黑字来得可靠。实际的解决办法不需要重新翻旧账，通常也比想象中简单：

• 找出现存的任何合同或邮件往来，看看里面是否有任何关于知识产权或归属的文字，哪怕是非正式的。
• 发一封简短、客气的书面请求，要求开发商以书面形式确认所有权归属企业，并提供源代码仓库、文档和管理员凭证。
• 专门询问开发中用到的第三方和开源组件，以免日后系统需要转交给新开发商时冒出意外。
• 把这份确认书保存归档，和当初的合作记录放在一起——它会成为将来纠纷、审计或新开发商真正需要看到的文件。
• 如果开发商不回应或拒绝，这本身就是一个有用的信号，也是咨询律师开始变得值得，而不只是可选项的时刻。

无论是网页应用、业务系统还是移动应用，规则都一样

源代码归属问题并非只针对某一种开发类型。同样的版权法条款，以及同样的实用检查清单——代码、文档、凭证和许可说明——无论定制项目是网页应用或看板、带有集成功能的多角色业务系统，还是移动应用，都同样适用。平台不同，代码的样子会不同；但谁有权拥有它，不会因此改变。

以上是关于马来西亚版权法如何看待委托开发软件的一般性说明，并非针对具体合同的法律意见。如遇实际纠纷或正在磋商的协议，请咨询专业律师。

常见错误

• 以为法定默认规则能解决一切。 第26条只在"合同没有另行约定"时才适用——它是一个起点，不是保证，而许多标准合同早就另有约定。
• 把版权和交付源代码当成一回事。 企业可能在纸面上拥有版权，却从未拿到过一个真正能打开、能编辑的文件。
• 因为关系显得非正式或彼此信任，就签了一份完全没有知识产权条款的合同。 今天良好的合作关系，并不能解决两年后联系不上开发商时该怎么办的问题。
• 没有询问第三方和开源许可。 拥有自己原创代码的所有权，并不能说明您对它所依赖的那些库到底能做什么、不能做什么。
• 让所有权依赖于持续的维护合同，却没有仔细读那条条款——有些合同会悄悄把访问权限和一份持续生效的支持订阅捆绑在一起。
• 等到纠纷发生才去要源代码。 要求交付源代码最有谈判筹码的时机是在最终付款之前，而不是关系已经变僵之后。
• 认为一套老旧、缺乏文档的系统已经没救了。 哪怕事隔多年，向原开发商发一份书面请求，通常仍然值得一试，而不是直接认定这个局面无法挽回。

Gotka Technologies 能提供什么帮助

Gotka 的应用与系统开发服务承接网页应用、业务系统和移动应用的开发，报价以书面形式确认，而非采用固定价目表，因此项目条款——包括最终交付哪些内容——会在开工前就谈妥，而不是靠假设。以这种方式开发的系统仍需要可靠的运行环境；Gotka 基于 LiteSpeed 服务器的云主机方案，可与成长型企业的网站和邮箱一并覆盖。如果您还在考虑一开始是否真的该走定制开发这条路，可以参考我们关于现成软件 vs 定制系统：如何选择的指南。

本指南使用的关键术语

• 1987年版权法：马来西亚规管创意与软件作品归属的法律，其中第26条专门针对委托作品。
• 委托作品：由外部一方收费完成的软件，而非由雇主自己的员工编写。
• 服务合同 vs 雇佣合同：聘用独立承包商（服务合同）与聘请员工（雇佣合同）之间的法律区别，决定了适用哪一种默认归属规则。
• 知识产权条款：合同中说明在其下创作的知识产权归谁所有、何时转移的部分。
• 源代码：开发商编写的、人类可读的实际文件，区别于客户只能使用、无法编辑的已编译或已部署版本。
• 法定默认规则：合同未作约定时，法律自动适用的归属结果，可由书面条款朝任一方向推翻。
• 开源组件：在定制开发中使用的、依其自身许可授权的现成代码，即便对企业完全拥有的代码而言，也应该了解这些组件的情况。
• 书面报价：一份明码标价、已梳理清楚的方案，做得到位的话，能在开发开始前就把费用、工期和归属条款一并确定下来。