现实中，我们的很多项目都是建立在开源框架上的，但是你有问过么：利用这些开源项目来赚取利润之前真的有得到过授权许可吗？或许下面的这些问题能帮助你找到答案。
不管你是不是已经开始了一个开源项目，还是决定参与到一个开源项目里，但是我想，你绝对不想将时间和精力浪费在一个以后有可能因为强制收费而*停掉的一个项目上吧！
我是 Open Source Initiative 的主席，我们已经成功的将版权许可升华到了一个对软件*的具体表达。OSI 并不会提供一种具体的形式来形容开源软件的定义，但是，对于*开源用使用版权许可的时候需要经过 OSI 的认可。
下面就是我在咨询会上使用的模型，来帮助客户来完成新的开源社区的活动。评估一个项目的许可、专利和社区管理策略应该从这些问题开始：
1 . 我有授权吗？
有 OSI 授权吗？他授权提供所有源码吗？如果有部分是私有代码，那么，我们很有可能无法*使用。开发者想要在没有许可之前优化、开发这部分代码，所以，那时候，他们并不一定会将授权提供出来。
2 . 商业化可以免费使用吗？
版权许可可能制约商业使用者，但是，问题并不一定是由授权条款引起的。由于处于公平竞争环境，社区使用 GPL 非常有效——Linux 内核和 GNOME 社区就是典型例子。更多的问题是使用其授权从事商业活动，而该项目并不授权商用。
3 . 我可能会陷入专利纠纷吗？
专利战争从未停止过，而专利在开源项目中也是一个深坑——公司承诺或者互不侵犯联盟 OIN 对团体对专利问题有帮助。不要不重视专利，他是一把锋利的武器，既可以保护自己，也可以伤害自己。
4 . 我是公平地和其他使用者竞争吗？
社区中明确或默认禁止的规则——与赞助商竞争有失公平性。这包括任何领域的使用限制。
5 . 我可以*修改升级吗？
版权转让也是一道坎，任何强制性的协议一样需要法律审查。我需要减少重构和维护成本，所以对于自己修改升级项目这样的需求是很正常的。
6 . 我是被作为一个开发同行对代吗？
对于社区合作者之外的人，修改更新总是没有被公开的。如果，想要确定自己是否是被作为一个客户或合作者，还是社区同仁，那就应该有一个双边协议。
7 . 我可以接触所有的人和技术吗？
我有授权文档吗？我可以奉献出自己的文档吗？技术论坛如何？我可以提交文档并得到技术帮助吗？论可以过滤垃圾信息吗？如果需要技术支持，需要提前申请吗？这一切都是我们需要考虑的问题。
所以，不要认为某某开源就一劳永逸，这上面的7点只是你应该考虑的问题中的一小部分。