Re: licensing issues and jars in Avalon
What I find strange in all this discussion about tools that are licensed under LGPL is, why does it matter if you do not use the tool in the actual code of the project. It does not matter in that case. It only matters when use of the code restricts the license under which our own code is distributed beyond the Apache license. Take for example Checkstyle, you use this tool to check that your code conforms to a coding standard. Checkstyle does NOT: - modify project source code in anyway; - need to be imported/linked/referenced in project source code; or - need to be shipped in project deliverables. So if all of this is accepted, why does it matter that Checkstyle is licensed under LGPL? It is not being viral. It doesn't matter. However, it also doesn't need to be distributed from the ASF servers. There is no reason that developers couldn't use it -- we use dozens of such tools for httpd development. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Roy T. Fielding wrote, On 11/02/2003 3.44: ... So if all of this is accepted, why does it matter that Checkstyle is licensed under LGPL? It is not being viral. It doesn't matter. However, it also doesn't need to be distributed from the ASF servers. There is no reason that developers couldn't use it -- we use dozens of such tools for httpd development. Please excuse me if I ask it once more, just to be clear. In this case, that is using LGPL such as checkstyle for the build, is it possible that the build system downloads it automatically for the developer? And /GPL/ buildtools, is it different? Would it have to ask permission of the developer to download given that it's GPL (ie making it clear)? I'm asking it again because we are talking about buildtools here, not jars used in the compilation, runtime, or linked in any way. Thanks. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Nicola Ken Barozzi wrote: Roy T. Fielding wrote, On 11/02/2003 3.44: ... So if all of this is accepted, why does it matter that Checkstyle is licensed under LGPL? It is not being viral. It doesn't matter. However, it also doesn't need to be distributed from the ASF servers. There is no reason that developers couldn't use it -- we use dozens of such tools for httpd development. Please excuse me if I ask it once more, just to be clear. In this case, that is using LGPL such as checkstyle for the build, is it possible that the build system downloads it automatically for the developer? And /GPL/ buildtools, is it different? Would it have to ask permission of the developer to download given that it's GPL (ie making it clear)? I'm asking it again because we are talking about buildtools here, not jars used in the compilation, runtime, or linked in any way. Possible? Yes. Recommended? IMHO, and not as an official statement of Apache policy... no. Specifically for checkstyle, my recommendation would be to make this package optional yet easy to obtain. In Ant terms, this would translate to a separate target which does the get for you, and to make the target which actually runs checkstyle optional based on the availability of this package. I do most of my development on Linux, and use a wide variety of GPL tools to do it. I also have been known to use fully licensed versions of Microsoft tools on Windows. None of them limit in any way the license to which the code I produce is distributed. Being *able* to use these tools myself and *requiring* others to do so is two different things. For some people, it would be impractical or against some personal or corporate policy for them to do so. That's why I would seek to verify that there is a compelling compensating benefit before I would consider making such things a requirement. By necessity, such decisions need to be made on a case by case basis. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Hi all, I've just updated the setup mentioned below to do handle the licensing issue just a tiny bit better, up to the point where I think (IANAL!) it is no longer in violation of any license. http://cvs.apache.org/viewcvs.cgi/avalon/check-targets.ent http://cvs.apache.org/viewcvs.cgi/avalon/check-targets.properties It might make sense for other projects that are also not moving to maven or centipede just yet to put in place a similar setup. cheers, - Leo What is more or less clear at this point is that the current setup I just put in place for avalon-framework where some Sun BCL code is downloaded from ibiblio is in breach of license (it won't work anymore either, as the problematic jars have been removed, so I guess it is already no longer in breach), whereas the setup we use in logkit (where the user must actively agree to the BCL license and download the code themselves) /seems/ to be acceptable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Sam Ruby wrote: Leo Simons wrote: recent board decree (saw it first on the infrastructure list) (paraphrasing): the ASF must not distribute software packages (in any form) licensed under LGPL, GPL or Sun Binary Code License in any way. Sun's Binary Code license permits bundling as part of your Programs. The short form of this: you can include such things in tars and zips for your release, but for individually download. In other words, users need not feel the pain, but developers do. First, I understand it as *not* for individually download, just bundled in a single archive. Second, in jetspeed, David removed activation.jar some time ago (I think because of those issues). But I have reviewed our repo just now, and we still have mail.jar, which, I think, we should remove also. (Sun Binary Code License). If you confirm, I will take care that it is removed from the repository (being careful to make sure we don't break build procedures, updating docs, etc.) Regards, Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Santiago Gala wrote: Second, in jetspeed, David removed activation.jar some time ago (I think because of those issues). But I have reviewed our repo just now, and we still have mail.jar, which, I think, we should remove also. (Sun Binary Code License). If you confirm, I will take care that it is removed from the repository (being careful to make sure we don't break build procedures, updating docs, etc.) Confirmed. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
What I find strange in all this discussion about tools that are licensed under LGPL is, why does it matter if you do not use the tool in the actual code of the project. Take for example Checkstyle, you use this tool to check that your code conforms to a coding standard. Checkstyle does NOT: - modify project source code in anyway; - need to be imported/linked/referenced in project source code; or - need to be shipped in project deliverables. So if all of this is accepted, why does it matter that Checkstyle is licensed under LGPL? It is not being viral. I am worried that a knee jerk reaction to LGPL will prevent tools being used on Jakarta projects. Being the original author of Checkstyle - I would see this as a real shame. Regards, Oliver -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED] Sent: Thursday, 6 February 2003 09:59 To: community@apache.org Subject: Re: licensing issues and jars in Avalon Leo Simons wrote: recent board decree (saw it first on the infrastructure list) (paraphrasing): the ASF must not distribute software packages (in any form) licensed under LGPL, GPL or Sun Binary Code License in any way. Sun's Binary Code license permits bundling as part of your Programs. The short form of this: you can include such things in tars and zips for your release, but for individually download. In other words, users need not feel the pain, but developers do. Personally, if there are open source alternatives, my recommendation is that they should be supported instead. I've identified the following jars in avalon CVS repositories which seem like they should be removed based on the information above: - checkstyle (jakarta-avalon-apps/tools/checkstyle-all.jar and other places) (LGPL) If available, then checkstyle can be used during a build - this should not be any different than using EMACs. Preferably, the build should skip this step if checkstyle is not available. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Leo Simons wrote: recent board decree (saw it first on the infrastructure list) (paraphrasing): the ASF must not distribute software packages (in any form) licensed under LGPL, GPL or Sun Binary Code License in any way. Sun's Binary Code license permits bundling as part of your Programs. The short form of this: you can include such things in tars and zips for your release, but for individually download. In other words, users need not feel the pain, but developers do. Personally, if there are open source alternatives, my recommendation is that they should be supported instead. I've identified the following jars in avalon CVS repositories which seem like they should be removed based on the information above: - checkstyle (jakarta-avalon-apps/tools/checkstyle-all.jar and other places) (LGPL) If available, then checkstyle can be used during a build - this should not be any different than using EMACs. Preferably, the build should skip this step if checkstyle is not available. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Sam Ruby wrote: Leo Simons wrote: recent board decree (saw it first on the infrastructure list) (paraphrasing): the ASF must not distribute software packages (in any form) licensed under LGPL, GPL or Sun Binary Code License in any way. Sun's Binary Code license permits bundling as part of your Programs. The short form of this: you can include such things in tars and zips for your release, but for individually download. In other words, users need not feel the pain, but developers do. So, in other words, it is okay if I as a developer download a BCL-licensed package, compile an ASF module against it, then build a distribution consisting of the compiled code and the BCL-licensed package? For example, is a JAMES distribution allowed to be compiled against the BCL-licensed package (after the developer making the distribution has agreed to the license) and ship with the BCL-licensed package? Is it also okay if my distribution instead contains the source code and the BCL-licensed package, and a build script for compiling the ASF module against the BCL-licensed package? Or is that not okay, but can I distribute the source code with my binary distribution? What about providing everything but the build script? I'm sorry, it's not too clear to me just yet. Personally, if there are open source alternatives, my recommendation is that they should be supported instead. +1. cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
