Forum OpenACS Q&A: Response to GNU Public License and Mozilla Public License

Collapse
4: Response to GNU Public License and Mozilla Public License (response to 1)
Posted by Talli Somekh on 10/16/01 07:04 PM
Michael Feldstein writes: "Al, another issue you should be aware of is that the MPL and the GPL are incompatible, which means that OpenACS can't share code or (perhaps more importantly) data models with ACS Java anymore. By switching licenses, ArsDigita has definitively forked the code bases. OpenACS can no longer even *try* to develop in parallel to ACS Java, because to do so would be to risk violating the license."

Michael, this isn't entirely true. As it says on the Various Licenses and Comments on Them at GNU.org (http://www.gnu.org/licenses/license-list.html):

The Mozilla Public License (MPL).
This is a free software license which is not a strong copyleft; unlike the X11 license, it has some complex restrictions that make it incompatible with the GNU GPL. That is, a module covered by the GPL and a module covered by the MPL cannot legally be linked together. We urge you not to use the MPL for this reason.

However, MPL 1.1 has a provision (section 13) that allows a program (or parts of it) to offer a choice of another license as well. If part of a program allows the GNU GPL as an alternate choice, or any other GPL-compatible license as an alternate choice, that part of the program has a GPL-compatible license.

The aDPL, which is what Java ACS is published, is derived from the MPL1.1. So, Al, the question you may be asking is whether the aDPL and the GPL are incompatible.

The answer to that is is aD let's it be so. The clause in the aDPL about derived and extended work is ambiguous. From the aDPL FAQ (http://www.arsdigita.com/doc/adplfaq):

I am trying to build a product (versus a Web application) based on ACS. What practical changes does this license change imply?

Under ADPL, you may choose to distribute the source code for packages you develop that use services provided by ACS Core under any license agreement you choose, open or closed. We invite you to distribute such products through ArsDigita. (Under GPL, you would have been obligated to distribute the source code for your product under GPL if it included any modifications to ACS.)

As part of your distribution, you must redistribute any ACS source code, and any modifications you make to it, under ADPL. If your product is an extension of an ACS package licensed under ADPL, it must be licensed under ADPL unless the extension limits itself to using unmodified the APIs provided by the ACS package. You must also credit ArsDigita and ACS as provided in the ADPL. This protects our interests and helps us earn an indirect return, through awareness and adoption, on the very sizable investment (well into the millions of dollars) we've made in this latest generation of ACS. We believe this attribution is in the interests of developers building products that extend ACS, as it will help fund ongoing investment in a platform that will in turn make their products more competitive.

The problem is that it's not clear what any of this means.

The gatekeepers have requested that rather than risk running into problems with aD. Whether or not aD might have done something objectionable to the OpenACS project is a matter of conjecture. The gatekeepers simply chose to err on the side of prudence.

So to be fair to all parties, the aDPL is not a horrible license because it doesn't guarantee the freedom that the GPL does. They made the decision to license their software in such a way that provides them with their own freedom to protect their investment. The gatekeepers didn't make their decision to insult aD either but simply to protect a project with no legal fund.

Of course, given aD's current crises and unstable future, it's not clear whether the aDPL or any future release of JACS is certain anyway...

talli