Over the past week there have been a few common questions about the IronPython Shared Source license that need to be addressed. Here are the answers but a critical disclaimer first. I am not a lawyer and thus, this blog entry does not constitute legal advice. You should be working with your legal counsel to understand the implications of any source code license as it applies to your project.
Q: Why didn’t you submit the IronPython license to the OSI for approval?
A: The OSI has provided a much needed aggregation point for open source licenses but there are elements to the OSI website that are strongly anti-Microsoft. They have every right to hold their own opinions and to post what they will on their website. For the time being, Microsoft has chosen not to work with the OSI. As we continue to expand our collaborative development efforts we welcome any and all constructive conversations with the OSI and others about how the various elements of the software industry can work together more effectively. For example, we think that establishing some consistency among source licenses is a worthwhile objective. With >55 “open” licenses and counting, it is clear that property holders have strong opinions about how they would like to share their property. All individuals and organizations must be able to reserve the right to choose the source license (or write a new one) that will work best for them. Yet, there would be significant benefit from some consensus on a few archetypical licenses that were well understood by all parties.
Q: Can I use software licensed under the IronPython license with other OSI-licensed projects?
A: That depends on the governing license of the other OSS project. Like many OSI-licensed projects, the governing license of the project will be compatible with some OSS projects and incompatible with others as many OSI-approved licenses are incompatible with each other. For example, there are license conflicts if you mingle GPL code and either CPL or MPL code. All three licenses claim exclusivity of licensing for directly related modifications and then there are differences as to how far the reach of each license is (whole project vs. module vs. file-by-file). Furthermore, there are some individual terms (such as regarding patents) that cause conflicts as well. There are numerous examples of this within the OSI-approved license world. Software licensed under the PSF, BSD, PHP or Apache licenses for example can be used in conjunction with the IronPython license. Software licensed under the IronPython license may not be combined with GPL code (in this regard both IronPython .6 and .7 are the same). On the other hand a project that incorporates MPL code is ok as long as there is file separation between the MPL and the IronPython licensed code.
Q: How can Microsoft refer to the IronPython license as “BSD-like” when there are some obvious differences between the two?
A: In an attempt to simplify the broad array of licenses available in the OSI-approved arena, there are permissive (BSD-like) licenses and reciprocal (GPL-like) licenses. It was under this premise that we referred to the IronPython license as BSD-like. You may want to check out my other blog entry on this topic.
Q: Can you please clarify clause 6, the patent clause, of the license?
A: The patent clause in the IronPython license is 100% in line with many OSI-approved licenses. Look at the MPL 1.1 – clause 2.2.(d) and the CPL 1.0 – clause 2(b). The license is granting you rights to any patents that read (are directly applicable) to the IronPython software. Also, if you create a modified version of IronPython, you retain the patent license to both use and distribute the original work in your modified version. In other words, the patent rights are not taken away from you when making a derivative – in fact, they expressly travel with the original code thus allowing you to use it in derived works. The license does not add patent rights as modifications are made which is standard for this type of licensing (see MPL/CPL examples above). It is important to note that this is the same between the CPL-covered IronPython .6 and the new license that covers .7.
In all of this discussion of licensing, it is important not to lose site of what is behind the licensing of the IronPython .7 source code was in the first place.
a) encourage community use of IronPython
b) facilitate the creation of extensions and add-ons to IronPython
c) provide other dynamic language developers an example as to how they could work well with the CLR.
This posting is provided “AS IS” with no warranties, and confers no rights.