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

Working under the assumption that the Mozilla folks know what their license means:
<p><i>
The licensing schemes used for Mozilla code have always had two major features: They have required that people make source code available for modifications to Mozilla code, and they have allowed combining Mozilla code with proprietary code to create and distribute proprietary products. Anyone contributing code to the Mozilla project under the "standard" licenses (i.e., licenses using the NPL or MPL in some form) has in effect consented to their code being distributed under these general terms.
</i>
<p>
This is from a FAQ describing the adoption of the GPL by the Mozilla project (actually they're adopting a triple-option licensing scheme but let's not get into that!).  The ability to combine Mozilla code with proprietary code to build a proprietary (and closed source) product's a big difference, and was done due to the relationship with Netscape, i.e. the fact that Netscape was releasing its code as Open Source but already had contractual agreements which made adoption of the GPL impractical at the time.
<p>aD doesn't have this excuse :)
<p>
Hope this helps ...

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

What we're being cautious about is the UI stuff and wireframes, cause we're not sure how THAT is covered under copyright law. However, it's more than just begin over-cautious when it comes to code.

The aDPL has a clause regarding "giving credit to ArsDigita" which is extremely similar to the clause that the old BSD license had. This was *known* to be a sticking point with the Free Software Foundation and known to be incompatible with the GPL. Thus, it is fairly *certain* that the aDPL and the GPL are incompatible. The caution has to do with the scope of what's covered under this license, but where the discussion pertains to code, I'm fairly certain it's incompatible.

You may be wondering why aD would produce code that could be adopted as part of a 'closed' product.

I may have my own personal opinions about GPL vs ADPL but there are some good legal and commercial reasons for aDs approach. In fact we are currently in a similar position regarding some code of our own (not related to ACS) that presents the same difficulty.

Basically, according to our solicitors, the ADPL makes ArsDigita's code more attractive to certain commercial organisations who may be interested in working with (and thus paying) arsDigita but need to create a closed source product.

In our case the opportunity exists to enter into a commercial arrangement with an organisation whereby they might use our code (and thus our services) as part of an overall offering. However adoption of the GPL would make this impractical, given that we'd also like to make the source publicly available.

It is therefore worth pointing out that the ADPL in some senses is a more generous, and commercially attractive license. What remains unfortunate is that they could not have created a license more clearly specified, that would not have been entirely incompatible.

Its one of those bottom line situations. Do you turn down potentially lucrative opportunities in favour of retaining the GPL? Such are the agonies of operating in a commercial environment.

I'd be surprised if it were not possible to create a license that allowed inclusion in 'closed' products of source code, only with contractual agreement of the author. In this way it would surely be possible to protect the code under the GPL and at the same time, as the author, retain certain commercial prospects?

Mind you all this legal stuff makes my head spin :o). I look forward to the day when the industry accepts that it is the individual and their creative potential that is the real asset, more so than the code. In this way we could all stop selling code, and begin selling ourselves......

As an aside, the real danger of the aDPL is that were all source to be published under it, you'd create an environment where the marketeers and salespeople would govern the success or a company, given that its technical assets would be so easily stripped.... And I'm sure that would suit them just fine...

Sure... but the GPL does prevent them wrapping it up into a closed product, and hence reselling.. right? I think I'm also right in saying that if they combined thier code with GPL'ed code into one offering then their code would also implicity fall under the GPL??

So if we developed an OpenACS package that could be installed via the package installer, we would not have to release it as open source if we used the GPL?

Don,

I think you're right, but somewhat regardless of what Richard Stallman might say, I think it would be important for the community, or for you and Ben to issue a finding in this regard.  Is this something the OpenACS community wants?  That is, does the community feel that it is all right for OpenACS developers to develop closed source OpenACS packages that can be mounted and interoperate with GPL'd OpenACS packages?

Me?  Yes, I think it would be a good thing for OpenACS development for OpenACS to be open, but to allow developers to develop proprietary packages.  Of course, using the package system, I would strongly encourage such developers to separate out functionality that might be GPL'd from functionality they wish/need to keep closed.

My personal answer is that it wouldn't bother me if I learned of a proprietary package were developed that dropped into OpenACS 4 as a package.  I would strongly encourage folks to GPL their work as a first preference, of course.

How do other people feel?  My personal answer's based partly on my belief that it wouldn't be a license violation as long as no modifications to the GPL'd core and/or other packages were included.  In other words, by being pragmatic I can avoid having to think about philosophical issues.

Even if one were to argue that somehow using the APM is equivalent to linking against a library there's nothing to prevent someone from giving instructions on how to insert the proper data into the database  by other means...

I agree with Jerry and Don (I have the feeling that we all do). If someone writes a package that can be installed using APM it can use any licensing, I would of course suggest to use GPL, but that is up to the client.

If we all agree on this, why don't we write something in the FAQ, explaining this copyright criteria? It is certainly a :Frequently asked question"