They can not retroactively change the license and Apache License V2 seems to be compatible with the CPL and the licenses associated with the other components, so I think you are OK.

On a related note, I think you need to include a copy of the Apache License with the binary distributions if they include any Lucene.NET code, along with a note specifying which assemblies are covered by that license.  Since you are integrating several components with different licenses, I recommend creating a LICENSE.txt file that says something like what you have on the License/Credits page.  However, for each component or license I would explicitly say "Assemblies A1, A2, ... and An (and their associated source files) are covered by license L which is included in file F."  Also, I'd include the license files instead of just providing links to them, since many licenses (eg Apache License V2) require that.

Hope that helps.
--Dean

Thanks Dean!
I appreciate your advice and will do on the LICENSE.txt file. Another thing I've been pondering is whether I should change the license of mojoPortal to the LGPL since most of the related code is in that license. Is that feasible? My motive is to reduce the complexity of the licensing if possible to minimize confusion. Or should I keep things as they are and just add the LICENSE.txt?

Also if you have time to give an opinion on the compatibility with MS License if I want to use the Enterprise Application Blocks they provide free. Are there any license issues if I use that? I read the EULA here http://msdn.microsoft.com/practices/AppBlocks/default.aspx?pull=/library/en-us/dnpag2/html/pageula.asp and it sounds like I can use it but I'm a developer not a lawyer so input from folk who know more than me is helpful.

Any general advice on a licensing scheme that both allows me to use a wide variety of free open source code and keeps things simple for anyone who wants to use mojoPortal.  Those are my 2 main goals in choosing the licensing.

Just use DotLucene (http://www.dotlucene.net/). It's open source and it's more up to date with Jakarta Lucene.
How do you manage to handle access on pages and documents according to user roles. With intranet and extranet, not every user can search in all files.

Thanks Michel,

DotLucene is what I planned to use all along, just went to the wrong link and got confused.

My plan is to store the role information with the index and if permissions are changed for a page I will have to re-index the page to keep it in sync with permissions in the db.

Regarding the license questions, IANAL, but I believe:

1. You need to get permission from any other contributors to change the license you use on mojoPortal proper (ie the bits currently under the CPL).  I don't think you have many contributors at this point so that probably isn't too difficult, and FWIW, you have my permission for the miniscule amount of code I've contributed. :-)  The new license would apply to whatever you distribute in the future.  You can't retroactively change the license on the versions you've already released.

2. Choosing the LGPL won't eliminate the need for a LICENSE.txt file.  It will just simplify that file.  You will still need to point out which components are not under the LGPL.  Specifically, I think those would be skmMenu, SlickUpload, SeekDotNet, and DotLucene.  I don't think you need to single out RSS.NET and MasterPages as long as you don't alter/remove any copyright notices they contain.

3.  The main difference between the LGPL and the CPL is that the LGPL is GPL-compatible, while the CPL is not.  That means that anyone (including you) can use the LGPLed code in a GPLed program.

4. The "Excluded Licenses" clause in the EULA for the Enterprise Application Blocks forbids certain uses of the code.  It's a bit unclear exactly what is and isn't allowed.  You definitely can't copy any of that code into a lib or exe that is covered by the CPL, LGPL, or GPL.  It's not clear whether you can link libraries covered by the EULA with code covered by the CPL, LGPL, or GPL.  You can mix it with code covered by more liberal licenses (eg the RSS.NET code) however you want.  On a related note, it's not clear to me whether the EULA meets the Open Source Definition.  Technically, I can't find a clause it violates, but it is obviously biased against that part of the open source world known as "copyleft".

5. As for a recommended license scheme, there is no silver bullet.  Switching from CPL to LGPL (or a weaker license) would allow you to integrate GPLed code if you are ever in a situation where all of the other components are GPL-compatible.  And it is easier to make the switch now while the number of contributors is small.  No matter what license you choose though, the hard part will continue to be finding packages to integrate with licenses that are compatible with each other.

Again, IANAL, and you should not take any of this as legal advice.

Hope that helps,

--Dean

Thanks Dean,

I'm not really a big fan of copyleft myself. I didn't think CPL or LGPL were considered a copyleft license. Am I wrong on that?
What makes you say that I could not paste the Enterprise block code into a library that is covered by the CPL? Should I change my license to be more like the RSS.NET code? Would that make it easier to include things like the Enterprise blocks in my code?

What I'm after is a license strategy that allows me to include the widest range of things and is not so complex as to scare people from using or distributing it without feeling they need to consult a lawyer.

What is Copyleft? says, "Copyleft is a general method for making a program or other work free, and requiring all modified and extended versions of the program to be free as well."  The term free here means "open source" (ie source available, modifiable, and redistributable).  That page specifically mentions LGPL as a copyleft license.  I say CPL is copyleft as well because it says "A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that...its license agreement...states that source code for the Program is available from such Contributor... [and] When the Program is made available in source code form...it must be made available under this Agreement..."

I say you can't paste the Enterprise block code into a library covered by the CPL, because doing so would make the resulting library a derivative work of both the CPLed library and the Enterprise block code.  As a derivative work of the CPLed library, the library would need to be released under a license which ensured that all the source code (including the copied source code) was available to anyone who used the library.  This would be a violation of the Enterprise block EULA which says, "your license...does not include any right to (a) create derivative works of the Solution in an manner that would cause the Solution (or derivative work thereof) in whole or in part to be subject to any of the terms of an Excluded License.... "Excluded License" means any license that requires...that...software...be (x) disclosed or distributed in source code form, (y) licensed for the purpose of making derivative works..."

Changing your license to non-copyleft (eg like the RSS.NET license) would allow you to avoid the license conflict between your library and the Enterprise block code.  You could combine them however you want and distribute them, but it's not clear whether the result would be considered open source (see below).  Regardless, even if you switch to a non-copyleft license I'm not sure whether you could link the Enterprise block code (or code derived from it) with copylefted code (like all the LGPL components you are using).  It depends on whether the resulting program would be considered a derivative work of the Enterprise block code.  If it is considered a derivative work, then the EULA could be interpreted to say that such linking is not permitted because it causes the a derivative work to be, in part, copylefted.  I'm not sure whether it matters that those parts were already copylefted.  FWIW, the GNU lawyers take the position that linking (even dynamic linking) usually does create a derivative work.  I don't know what MS' position is.

As I mentioned above and in my previous post, I'm not sure whether the Enterprise block EULA counts as an open source license.  After another read of the license, I think I've found the reason it wouldn't be considered open source.  Criteria number 3 of the Open Source Definition says, "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."  The EULA allows you to distribute derived works, but it doesn't say you can license them under the terms of the EULA.  To the contrary it says that they must "include the following copyright statement: Contains software or other content adapted from Microsoft Enterprise Library.  Original Enterprise Library © 2005 Microsoft Corporation. All rights reserved."  That might mean that you have permission to modify and redistribute, but your users and other developers don't.

Regardless, IMO, by using the Enterprise block code you would be putting mojoPortal on questionable licensing grounds.  I would personally have to think hard about whether I'd continue using it and whether I'd contribute to it in the future.  I tend to be a bit paranoid about these sorts of things, so take that with a grain of salt.  On the other hand, major redistributors (eg Novell) have deep enough pockets to be similarly paranoid -- though I don't know whether they actually are.

I hope that helps, but remember, IANAL...

--Dean