Hi Arthur,
> Which comes to question: what license is BQ under?
The NuOnce CD contains a license text that indicates GPL v2 for the
distribution, which may or may not be entirely correct. After all, the ISO
contains both CentOS and BlueQuartz, plus custom additions made by Brian.
What is under which license can be checked by examining the source code or
the headers of the installed RPMs. As for CentOS: It's released under the
GPL, but that wasn't your question.
Now how about BlueQuartz itself? The CCE and UI code that goes back to the
initial RaQ550 OSS release from Sun Microsystems is under the "Sun BSD
license". There is enough "old" and "original" Sun code around to safely
assume that a lot of parts of BlueQuartz are still under their original Sun
BSD license.
The bandwith management kernel modules of the RaQ550 OSS release are under GPL
v2 as well - as indicated in the readme included in the original release from
Sun.
The BlueQuartz page itself doesn't clarify which license is used - at least
not in a prominent fashion. Which should be cleared up sometime down the
road. However: CentOS itself doesn't do that either, so we're in good
company. :o)
My own personal take is that it's either Sun BSD or GPL v2, but the best
person to answer that question would of course be Hisao.
> This one seems as appropriate for us, also it might give us a "marketing"
> push. What do you think?
I don't think so.
Sun BSD even grants a broader scope of rights than GPL v2, like the right to
distribute the code or code that derived from it in just binary form.
GPL v2 is the most commonly used license for open source projects and there is
a good reason for it. It gives both the project maintainers and the users of
the code about equal opportunities for what it can be used for and what not.
Most other licenses shift this balance in one direction or another and take
usage rights and permissions away from the end user or the developer of
derived works. The GPL sums this up quite nicely in its preface:
"The licenses for most software and other practical works are designed to take
away your freedom to share and change the works."
The "Creative Commons v2.5" license for example grants you rights to alter and
redistribute the code, but says: "You may not use this work for commercial
purposes."
"Open Xchange" for example uses a mix of GPL and Creative Commons for
different parts of the distribution. The "backend" is under GPL, but the
really interesting parts (the web based UI) are under Creative Commons. Some
modules (like the synchronization with PDA's and handhelds) are under a
pretty restrictive commercial license. Which throws a big wrench into using
it in any shape or form for commercial purposes. Unless you roll out the
money for it.
Expectedly the "Affero General Public License" (AGPL) takes some freedoms away
as well. Assume for a moment that BlueQuartz would be under the AGPL and
someone used the BlueQuartz framework to create something new. The AGPL would
force him to release all his modifications to the original code to the
general public. The GPL already does that as well, but the AGPL also covers
cases where the software is just provided as "a service" over the network and
where the end user doesn't actually "see" the code or installs the code
himself.
BlueQuartz is *very* modular, so you could simply use the GUI framework and
create new "modules" for it which do the work that BlueQuartz itself doesn't
cover. So these extra modules that someone created from scratch could still
be under any license he chooses and he wouldn't need to make the code for the
extra modules available. That would still be fine with both GPL and AGPL and
therefore choosing AGPL over Sun BSD or GPL v2 wouldn't help the project one
bit. To the contrary: Developers might think twice about using BlueQuartz for
derived work.
Speaking from personal experience: I've checked out a lot of "interesting"
software over the years to evaluate if I could provide it as extra service to
clients. But if the software in question is not outright under GPL I usually
stop looking further at it, because it may turn out as a bitter pill to
swallow once you finished thumbing through the legal fineprint in that
particular license.
On the other hand the AGPL also allows developers to have sub-contractors work
on the code and force them in a binding way to not use the derived works for
themselves other than for the assigned development task. Which can be useful
to a certain degree. But you can also do that without AGPL and in form of a
contract between developer and sub-contractor.
While there are certainly projects where the AGPL is appropriate, I don't
think it would be something that helps us.
All in all I'm not a big fan of all the different GPL lookalikes and GPL v2 is
good enough for most "true" open source projects. Even GPL v3 has been
subject of a lot of heated discussions, because it takes some rights and
permissions away and adds new obligations to certain parties.
--
With best regards,
Michael Stauber