IronPython Q and A

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.

Comments (5)

  1. A plain reading of point 6 of the license directly contricts what you claim it says. This post says "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." Your last post, which actually quotes the license, says "hat the patent rights, if any, granted in this license only apply to the Software, not to any derivative works you make."

    I’d like to believe what you’re saying in this blog, but you explicitly disclaim it being promisory estoppel ("This posting is provided "AS IS" with no warranties, and confers no rights."), so I can’t base any decisions on what you say.

    Oh, and I missed an important difference between this license and others: this one claims that you accept it by dint of using the software; others only claim that if you do not accept it, then you have no rights to /copy/ the software. This license attempts to go beyond copyright.

  2. There have been a lot of questions about Microsoft’s Shared Source program and the Licenses that…

  3. Swaroop C H says:

    Will there be a list of what patents that IronPython will use?

    I’m basically asking this because of point (c) where it is to be an example for other languages to be used on top of CLR.

    Could Boo possibly use ideas from IronPython?

    Btw, it is very encouraging for Microsoft to take such an "open view" w.r.t. IronPython and encouraging openness. Kudos to you guys to take such a bold and pragmatic step (compared to the FUD days)!

  4. "Software licensed under the IronPython license may not be combined with GPL code (in this regard both IronPython .6 and .7 are the same)."

    I would like some clarification on what ‘combined’ means in the context of this license.

    If I write a GPL application in Python, and run it on FePy, is this considered ‘combination’?

    If my GPL application imports from the standard python library, part of which is reimplemented in FePy, is this considered ‘combination’?

    If my GPL application imports and uses part of the .Net framework that is *not* part of the standard Python library, is that considered ‘combination’?

    Assuming that at least one of the answers to the above is no, may I distribute FePy with my GPL application?

  5. Jason, thank you BTW for engaging in this dialog.

    I have a question regarding the patent grant. Although the FePy licence grants the use of Microsoft patents for any FePy implementation (including derivative implementations), it does not grant the use of those patents in any other Python implementations, including CPython, PyPy, and Jython. This concerns me. Could the patent grant be extended to cover other Python language implementations as well?