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...
As I mentioned earlier, much like the original NPL/MPL, this allows someone to take the ACS and bundle it into a closed-source, proprietary product.
Since I'm not interested in seeing OpenACS releases get bundled into closed-source, proprietary products released and sold by others I don't want my code licensed under these terms. This is a primary reason to avoid any possible "pollution" of the OpenACS project with code from aD under their license.
Certainly our approach is cautious, probably even overly-cautious. But at this point we really have no compelling reason to not be cautious, so we might as well be cautious...
Anyway, I think Al probably gets the point now. If dotLRN (for instance) were released under the NPL/MPL/aDPL any commercial entity could bundle it into a proprietary, closed-source product...
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.
I am planning to put together a course using openACS next year. I want to provide students with a hardcopy of the documentation plus documentation I plan to write. Of course everything would be in a CD together with the code and the GPL license.
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...
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.Then somebody has misread the GPL. The GPL doesn't say that once you write code under the GPL, you must post a tarball of it to freshmeat. What it says is that anyone you give an executable to must also have access to the source. In the case of these commercial organizations, do they intend to resell the product?
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.This is implicit by the very nature of software licences. If you don't accept the licence offered, you get in touch with the author and see about it being made available under a different licence.
One could argue quite strongly that a package once mounted is much like an executable, making use of an API but not actually containing any GPL'd code. This would be true for uncustomized versions of the core and other packages you might work with. In other words, if the consumer can download OpenACS 4, install it, then install your package without your package modifying any of the underlying OpenACS 4 code then I think you'd be OK.
However note that all this is pretty fuzzy stuff. Richard Stallman has his own private interpretations of various licenses and whether or not they're compatible with the GPL, as well as what activities are or are not legal under the GPL. However none of this has ever been tested in court in any serious way.
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.
Yes, this is what we would do.
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...
Given then, Close Source software will have problems with GPL'd code as it will be hard to _not_ make changes that break the close source software. Just look at the Linux Kernel, yea there are binary modules but Linus does not promise the next version of the kernel will keep the compatability. So you take a chance doing that.
There are plenty of "reason" people don't/won't release source code, legal, greed, etc. But if the choice is closed source or nothing it can help a project continue and gain acceptance.
Of course, I don't think I'll ever like it, but I can accept it with cause and caution.
Now, the Mozilla Public License was developed for a specific purpose, so Netscape could release the code of a closed source product. They were also going to produce/sell that product. This obviously had many many legal issues and in that I see the Mozilla Public License as an excellent piece of work for people that need to do the same thing. It is not good for a Open Source GPL'd project to go closed source (to any level). I would have much rather seen aD goto a BSD type licence instead.
Netscape/Mozilla was basically saying they wanted to be Open Sourced but we can't because of the obligations associated with a closed source product. aD has seem to say we want to move to closed source because we can't make money being GPL'd but we still want the benefits of being Open Source'd (this is my personal thoughts on the matter).
Obviously, mixing the two license is a recipe for disaster.
Being GPL'd allows somebody if they want to create an application (for example an ISO900X or CMM management system) that co-exists with OpenACS (or even ACS TCL) that requires NO MODIFICATION to that
base system, but run on it. I'm not sure of the legal specifics of how it could be done though. The MPL, as my bodyfeeder^H^H^H^H^H^H^H lawyer tells me, that would not be a clear cut possibility.
Just my thoughts.
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"