For the record, uPortal is distributed under the terms of the BSD License <http://www.opensource.org/licenses/bsd-license.php>. (the "new/modified" version, not the original one that had a lame advertising clause). This fact appears to have been lost in the tribal knowledge of JA-SIG. While the uPortal license does not explicitly state that this is the BSD license (which is normal), a word-for-word comparison of the uPortal License <http://www.uportal.org/license.html> and the BSD License shows that this is clearly the case. So, we need to clear up a long standing misconception: uPortal is in fact distributed under a license that is approved both by the OSI as an "open" license <http://www.opensource.org/docs/osd> and by the FSF as a "free" license <http://www.gnu.org/licenses/license-list.html> (and is entitled to all the rights and privileges thereof!) We need to dispel this long-standing myth -- I'm only sorry it took me so long to research this fact. At a minimum, someone should updated the license page on the uPortal web site to indicate that this is in fact the New BSD license and provide a link to the appropriate OSI page.
Since the FSF considers the BSD License to be a "free software license", this makes it completely GPL compatible. This means that uPortal can be combined with GPL software and then redistributed under the terms of the GPL (but not under the terms of the original license). However, as Andrew points out, if GPL software is made available with a "FLOSS Exception" then it can be combined with software licensed under an acceptably "Free" license (like the new BSD license) and still be distributed under its original license. This is the case with things like MySQL <http://www.mysql.com/company/legal/licensing/opensource-license.html>, Alfresco <http://www.alfresco.com/legal/licensing/>, and (most recently) Unicon's Toro projects for uPortal <http://www.unicon.net/toro/>. So, it would be fine to take something like the Toro projects and include them in uPortal and continue to distribute uPortal under its current license. It is also important to realize the critical difference between LGPL <http://www.opensource.org/licenses/lgpl-license.php> and GPL <http://www.opensource.org/licenses/gpl-license.php>, also as Andrew mentions. A project is free to utilize LGPL licensed code (usually in the form of libraries) all it wants without causing any licensing restrictions on the project itself. This is true so long as the LGPL code itself is unmodified -- any modifications should be made part of the original LGPL project (or a fork of that project) in order to preserve the licensing status of the main project. There are also projects that distribute under GPL with a "Classpath Exception <http://www.gnu.org/software/classpath/license.html>" which, from what I can tell, is pretty much the same as LGPL. Bear in mind that changing the license under which a project is distributed can be difficult. If the new license is not compatible with the old license then you must have the permission of all copyright holders to change the licensing. For example, it took Mozilla over two years <http://www.mozillazine.org/articles/article4155.html> to relicense their code <http://www.mozilla.org/MPL/relicensing-faq.html> when they realized that the MPL was going to create some barriers to adoption and decided to triple-license the code under the GPL and the LGPL as well. If you want to see some real fun, take a look at the Licensing FAQ <http://www.sun.com/software/opensource/java/faq.jsp#g> of the OpenJDK project <http://openjdk.java.net/> (the new GPL version of the Sun JDK) -- this is the current state of over a year of legal negotiations with copyright holders of "encumbered code". (I have new sympathy for Jonathan Schwarz after reading all that!) FYI: The FSF considers <http://www.gnu.org/licenses/license-list.html> the Apache license <http://www.opensource.org/licenses/apache2.0.php> to be incompatible with GPL (which the Apache Foundation disagrees with), so Apache license projects do need to avoid any GPL mingling. The Educational Community License <http://www.opensource.org/licenses/ecl1.php> (which is used by Sakai) is also considered GPL incompatible because it has several provisions and limitations that are not in the GPL (the FSF has not yet issued any public opinion about this license). Disclaimer: I'm not a lawyer either and this should not be construed as legal advice. These are just my interpretations from reading lots of riveting material about open-source licensing! John Andrew Petro wrote: > Jason, > > !L [1] > > > > whether it's legit to bundle GPL jars (Apache doesn't -- our license > looks a lot like theirs). > > Not legit to bundle GPL .jars that are "part of the software". See > this article <http://www.itmanagersjournal.com/feature/12878> for > discussion of over-broadness of popular understanding of viral nature > of GPL. > > uPortal 2.6 does not bundle any GPL software. It does bundle LGPL > software, which is unambiguously permitted so long as it is not modified. > > The "FLOSS exception > <http://www.mysql.com/company/legal/licensing/foss-exception.html>" > where applied to otherwise GPL code by the copyright holder allows the > code to be included *unmodified* with any FSF or OSI approved > license. This would allow uPortal to use but not to modify the Toro > portlets, e.g. > > It's not totally clear that uPortal's license falls under the FLOSS > exception because, for no good reason, it's not actually OSI > <http://www.opensource.org/> approved. Lack of OSI approved license > is an ongoing drag on uPortal, excepting us from Google Summer of Code > opportunities, scaring would-be adopters, etc. Would be a nice thing > to fix, either by migrating to a better license or by getting our > license formally OSI approved. (In principle it meets the > requirements; someone's just gotta do the work of getting it run > through their process). > > > Does Maven get us around this (since we're not redistributing the > artifacts?) > > Yes. If the project used Maven, then uPortal would be shipping > instructions on where to get the .jars, not the .jars themselves. > > For lots of other good reasons, I'd like to see uPortal 2 use Maven > for uPortal 2.7. CAS3 and uP3 seem to have worked through a lot of > the difficulties of adoption; SVN allows moving files around to be > more Maven-friendly. > > Andrew > > [1]: I'm not a lawyer. Nothing in this email should be construed as > legal advice. > -- Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in Denver, CO USA. Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity Management, and Open Source For more information & registration visit: http://www.ja-sig.org/conferences/07summer/index.html --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
