Well that has definately cleared up the issue in my mind. Thanks for that Sean, wading through licencing is murky at best.
Sounds like MG *must* go ASL then? MD On 8/23/06, Sean Corfield <[EMAIL PROTECTED]> wrote:
On 8/22/06, Tom Chiverton <[EMAIL PROTECTED]> wrote: > On Tuesday 22 August 2006 15:44, Matthew Lesko wrote: > > agree with Sean Corfield's comments that generated code, which you can > > subsequently customize (and probably want to keep in source control), > > will be problematic under the LGPL 2.1 license for using Reactor with a > Please explain to a non-lawyer why the current one isn't as good as the new > one :-) It's hard for non-lawyers to understand but I'll try... In the beginning there was GPL. GPL is actually very restrictive for *users* of the software because it essentially requires that you open source *anything* you build with a GPL product. So LGPL was born - Lesser GPL - to cover "libraries" that can be including with other products. The idea behind LGPL is that you can build closed-source products with an LGPL "library" but you must provide the LGPL "library" as open source as part of your distribution. Moreover, if you modify the LGPL "library" to make it work for your product, your modifications must also be open sourced (my understanding, although that is somewhat irrelevant to the real issue here). With GPL and LGPL, you cannot relicense anything built with code under those licenses so commercial companies have to be *extremely* careful about how they use and package anything that even touches a (L)GPL product. (L)GPL are "package" licenses - they tend to apply to groups of files, usually in groups of directories. The Apache Software License (ASL1.0 and now ASL2.0) allows bundling, relicensing etc etc without forcing you to open source anything, as long as you appropriately credit the ASL code and don't promote the "derivative" work as some variant of the original (i.e., don't use the name of the original package). The ASL are "file" licenses - they apply to the files in which the license appears. Overall, those considerations make ASL a lot more friendly for companies trying to use open source products. Example: So a company builds a web application using third party open source and that company needs to runa legal audit on software copyright (maybe per SOX, maybe for other reasons - but it is *common* in medium-to-large commercial organizations). They need to identify the copyright and license that applies to every piece of code in the application. (L)GPL is somewhat of an implicit license so they mark entire directory trees as "third party, (L)GPL" in their audit (and remember the open source implications of (L)GPL noted above). ASL is per file and allows rebundling and relicensing - modified files can be copyrighted by the company and made closed source. Then their is the company's own code. Mixing ASL and company-owned code is not a problem due to the ASL wording. Mixing (L)GPL and company-owned code is very problematic. Now let's take a look at the three frameworks involved in MG:U: - ColdSpring - ASL - generates code into its own directory tree based on "your" code, i.e., your company-owned and copyrighted code. ASL makes this acceptable. - Reactor - LGPL - generates code into its own directory tree based on "your" intellectual property (IP), i.e., your database schema and your Reactor.xml file (copyrighted to the company). Furthermore, the generated code is a combination of LGPL XSL and your own IP - a "derivative" work. This is *very* problematic for a legal audit! - Model-Glue - LGPL - generates code into several of "your" directories based on "your" intellectual property, i.e., your ModelGlue.xml file and your database schema. This is also problematic since the generated code can be clearly traced to the (LGPL) XSL files and is therefore a "mixture" of your intellectual property and LGPL code - a "derivative" work - even tho' the generated files are now in "your" directories. For some companies, this will be a showstopper: it can make the difference between being allowed to use these frameworks or not. If Reactor and Model-Glue were both ASL, this would be a non-issue. This really isn't something that is particularly open to a "vote". If Reactor and Model-Glue stay LGPL, it's likely that a substantial number of commercial organizations simply won't be able to use them from a legal standpoint. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Mark Drew Blog: http://www.markdrew.co.uk/blog/ LinkedIn: http://www.linkedin.com/in/mdrew -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
