前段时间，我在一家咨询服务公司，使用开源许可的软件作为构建模块组装为他们的客户解决方案。客户需要的教育，然而，当它来到的时间来了解谁拥有最终的工作。从历史上看，在从无到有的世界，所有新编写的软件由客户端作为一个拥有“职务作品”。如果溶液周围构建的专有产品，需要有相应的许可证。这并不完全工作在一个开源这种方式使世界。
我们开始在主服务协议列明，有些工作可能来自开放源代码许可的软件开发，因此拥有了和每个OSS项目自身目标的许可。这通常是一个简单的讨论，因为客户意识到他们正在接受不必一定要购买许可证或让我们实现一切从零开始储蓄的艰巨性。会有他们的长期维护会如何工作的更多灵活性和选择。
更有趣的讨论发生在我们对开源许可软件包本身所做的必要更改上。虽然大部分工作都是在许可条件下许可的开放源码软件上完成的，因此仍然属于客户的雇佣工作，但如果这些改变回到开放源码软件项目的主流开发中，这仍然符合客户的长期利益。
生活在一个叉的费用会从几个角度艰巨的一段时间。有需要再进行更改，如果OSS项目的新版本需要新的特性和关键的可能漏洞修复的成本。如果不同的开发者都参与这一需要拿出一个学习曲线，这个成本可能并不简单。有没有新的可用功能的长期失去的机会成本。一切从经济学的角度更好地工作，如果所做的更改可以回并对谈判进入主开发树。
2006年左右这样的一个事件涉及我们的开发人员增加主要特点为ActiveMQ的OSS许可的项目，然后通过LogicBlaze公司管理。我们需要让客户端释放合同，我们为他们做了我们指定的版权，LogicBlaze公司为参与该项目的条件作品的版权。LogicBlaze公司坚持的版权分配在那些日子里贡献的工作ActiveMQ的。我们也很幸运，LogicBlaze的开发者对我们的变化。虽然合作开发的经济性是令人信服的，但一般的公司律师会介入并坚持对作品的所有权进行跟踪和适当的许可。这很有趣，看看这个已经改变了ActiveMQ的项目是一个Apache软件基金会的项目，LogicBlaze公司被收购IONA。
I didn’t encounter this level of legal due diligence from consultant and client to OSS-licensed project again until last summer when a contractor well known for his expertise in the MySQL and Drizzle communities shared his stories of needing similar clauses in his contracts with corporate clients and needing to spend similar time educating clients' legal departments to ensure all work flowed back to the projects and the engineering economics didn’t fall apart through legal interference.
由于采用开源的许可软件的持续增长和世界的IT部门茁壮成长，我很好奇，如果这是一个新的领域，人们将需要教育，了解经济和合法性危在旦夕。我很想从咨询顾问，IT经理和律师一样他们在这方面看到的（和做）的来信。