在GAMP监管行业中应用开放源代码软件（OSS）的指导（一）

ISPE

介绍
开放源代码软件（OSS）和商业软件（COTS）的区别比许多业主想象的少得多。本文章重点描述了免费的开放源代码软件相对于商业软件的好处，以及其在GxP合规领域中的确认和操作方法。

商业软件一般是由公司按照传统方式开发和市场化，通常需要支付版权费用，软件代码是不能开放的并且用户没有权利修改软件。

免费的OSS是那种用户拥有某些权限或自由度的软件。权限大小取决于选择的软件许可，通常有修改源代码的路径并能自由的重新发布。
由于这种软件的开放特性，开放源代码软件应用的一个主要动机在于可以减少商业风险；系统的所有细节能够被详细地确认和审核。从另一方面讲，现今的验证方法需要强调以下几个方面：
§ 团队不再是传统的商业伙伴。沟通方式和工作方法可以是不同的，例如，服务等级的协议不再适用或者团队可能由于某种原因不愿和你一起工作
§ 传统的供应商审计对OSS团队无法实施，必须使用其它的供应商评估方法。

免费的OSS已是现今软件行业的一个重要组成部分，已经存在许多重要的商业应用，并呈持续上升的势头。因而，多数安装包含OSS软件的系统，在一定程度上成为“基础软件”的一部分（按照GAMP 5）。他们通常部分或全部使用LINUX和MYSQL数据库组成OSS(OSS的应用)，尤其对于这些基础软件，他们节约了大量的经济成本。

国际监管机构通常没有区分商业软件和OSS，因此，公司可以自由地从二者选择其一。所有GxP监管的计算机系统在使用前必须验证，以确保系统适合于特定的用途。对于数据完整性的控制措施和验证范围的决策，必须是基于文件化和可评价的风险评估。对患者安全和产品质量的影响以及数据的完整性和适用性，必须在过程中进行评估。清晰的接受标准应基于风险评估设定并且记录在验证方案中。

开放源代码软件的特性
对于OSS，一个通常的错误概念是其由一些无私的个人专门开发的，因而，它应该总是免费的。其实，无论OSS的开发还是规划都包括了许多重要的投资企图，我们有理由不能忽略这点。了解OSS的商业和许可模型、开发过程、和支持结构，是其能否适合成为商业的决策基础，相关方包括OSS团队、商业软件公司、系统集成商、咨询顾问、用户/健康行业和监管单位。

商业模型

“这些支持的开发者是如何赚钱的？”就像其它的软件开发项目，一个OSS项目所需的成本与特定产品的规模和复杂性直接相关。在商业软件的开发中，工作由开发者带薪完成的，由用户通过直接的开发合同或其它的许可模式支付财务资源。

在OSS项目中，开发的付出主要来自于：
§ 个体免费使用部分的个人时间为项目工作。

公司或其它组织直接或间接承担为项目工作的编程人员或其它专业人员的费用。在第一种情况中，个体的动机是非常广泛的，从具有利他动力（例如，OSS有助于战胜贫困和不平等）的技术挑战，到试图通过在有影响力项目中提供有价值的贡献建立他们个人的声望。从另一方面讲，公司和一些自由的专业人员，对于围绕他们的OSS开发新的商业机会有相当的兴趣。许多的商业模型可能是：
§ 推广或提升OSS，以低费用或外购替代者贡献到相应的项目。
§ 为OSS产品提供有偿服务，可能包括以合同形式为用户提高或修订产品的功能。
§ 调整商业产品成为OSS。这可以提高产品的接受度，为公司创造新的商业机会。
§ 在双重许可下提供一个产品。在这样的OSS的情况下应用。OSS的许可通常受限于某些方面（例如不允许集成到商业产品中），而商业许可以克服这些障碍。通过这样的方式，公司可以开拓团队的利益（例如外部的贡献者、大的用户群），并且仍然可以提供额外的有偿服务。

总之，许多OSS项目至少在一定程度上是由商业考虑驱动的。这种趋势在随后几年会延续下去，并支撑着OSS利润的增长。

法律层面
OSS是成本（许可）免费的，但不是任何责任免除的。因此，当采用OSS开发时需考虑到法律层面。当讨论法律层面时，我们需要严格地区分合同方面（例如质保期）与知识产权（专利）方面的内容。
让我们首先看一下典型软件用户的看法：在目标OSS可以获取、安装和运行的情况下（通常基于Linux、MySQL或Apache），并且不改变软件，法律层面和外购的商业软件就没有多少区别了。即使软件的源代码因为功能的需要做了改变，但只要没有分发给其它用户，通常没有法律层面的影响。但是，用户应该意识到一旦使用OSS，就可能产生合同关系，包含了合同和版权两个方面。作为商业软件，购买者应确保供应商获得了第三方的免费使用权。

软件供应商或集成商的看法是：相对于正常的OSS用户，更复杂的情况是：当OSS用于开发新的将来发布的软件基础时，需要考虑OSS的许可条件和另外的特定国家的法律条款。取决于OSS许可模式，分销商承担一些OSS的特殊义务。例如，BSD类型的许可（例如 Apache服务器）允许OSS软件的修改和商业销售，但不能披露源代码。从另一方面讲，GNU通用共用软件要求（修改的）源代码公开，嵌入到OSS的软件源代码也需要发布。如果仍然有疑问，那么就需要考虑专业的建议了。

开发过程
典型的OSS开发过程包括一组松散合作的开发者，他们同时在新的功能或改进方面工作。在许多案例中，需要使用版本化的系统（如CVS或其子版本）管理产品的源代码。通常，仅仅有少数可信任的开发者（叫做维护者）可以访问源代码库进行编辑，他们能够修改主要的开发程序。然而，其他开发者可以得到源代码的拷贝（例如，通过公开的、只读的路径进入代码库）并基于这些拷贝开发他们自己的应用。他们将包含修改的文件（文件补丁）递交给维护者，维护者审核，如果程序是正确的，就可以集成到主代码分支中。

分支代码可以导致独立的开发流程。在随后的过程中集成到主开发程序或分支形成一个新的项目（分叉）。

成熟的OSS项目通常同时存在许多流程来支持不同的活动，例如需求管理、放行管理、发布报告和跟踪、软件分发、软件测试，以及前面提到的版本和组态管理。这些过程通常由软件工具和团队队活动结合起来强化，团队的开放度和透明度是其中的关键因素。

支持和维护
一个OSS产品的积极团队也可以增加产品获得免费支持的机会。在许多案例中，OSS产品的用户在开放的邮件清单或网络论坛中提出产品的相关问题；也有许多项目提供了一个问题跟踪系统。在这个系统中，每个人都可以报告问题或提出改进建议。无论如何，都必须考虑到不能保证这些免费的支持渠道一直工作。送到邮件清单的问题可能得不到回答，或者报告的问题也可能相当长的时间没有得到解决。原因包括技术工程师没有回答，团队中没有人知道答案，或者甚至认为需求或问题是不相关的。即使在一个大的项目中，一个积极的团队也会发生这样的事情。

对于需要支持保证的组织，仍然有一些办法，例如跟公司或者一些自由开发者签署合同，或者雇佣有经验的开发者或系统管理员在线提供支持。（未完待续）

文章来自 ISPE《制药工程》

ISPE《制药工程》杂志精选文章志愿者招募啦！只要你是ISPE的会员，具备良好的制药行业专业知识和从业背景，有一定的翻译水平，即可加入。赶快加入我们的大家庭，为制药行业献出你的一份力吧！

联系方式：021-23123521 china@ispe.org

lyzqshsci

顶一下