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
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)? You can't isolate questions. If no other condition exists that causes it to be a derived work, then a build system download won't either, assuming that the build system is an independent mechanism (i.e., it doesn't exist for the sole purpose of placing the GPL'd functionality within a non-GPL product). The GPL specifically excludes bundling for the purpose of distribution from its list of things that makes one work derived from another. That is what allows RPMs and Debian packages and FreeBSD ports to work. You can safely assume that any such system is okay, even if it is written in Java. However, note that we are not in the business of providing bundles (like RedHat), so the storage for such a system should make use of the origin sites rather than assuming an uber-repository. The fink system (Debian based) does that rather well. This is completely separate from the Sun binary license issue, which specifically forbids anyone from allowing such downloading. Placing the repository on someone else's machine doesn't remove culpability for the license infringement -- it only increases it. 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
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
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
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
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
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
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]
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]
licensing issues and jars in Avalon
Hi peeps, talks about this have been on the infrastructure, the community, the jakarta-general and the cocoon-dev list recently (and possibly other places as well I'm not tracking). first of: IANAL and I hate having to worry about licensing issues. I'll be contacting Sun to complain about the rediculous complexity of their licensing. --- 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. Licenses which have been specifically identified as okay include IBM Public License and MPL. I assume ASL-style and BSD-style are also okay (relevant for our inclusion and redistribution of qdox, mx4j). Two public domain packages, namely DougLea's threadutils and antlr have also been marked as acceptable. But all this has not been stated as strongly just yet. An attempt is now underway to get this sorted. --- 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. 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) - hsqldb (jakarta-avalon-apps/hsql/lib/hsqldb.jar) (custom license) - jsch (jakarta-avalon-excalibur/altrmi/jsch-0-0-11.jar) (LGPL) There are lots of jars all over the avalon CVS repositories for which the license is perfectly acceptable but not specified, for example of jars which are ASL-licensed, like xerces. I am not done checking yet, but I believe none of the avalon distributions provide any of these potentially problematic jars. I've found more than a few jars under "non-standard" BSD-style or ASL-style licenses, like jdom, mx4j, qdox, jing and isorelax which I am relatively sure are okay but IANAL. --- I think we should remove the checkstyle, hsqldb and jsch jars. We should also make sure all "autofetch" functionality is only provided after the user has agreed to the applicable license. For the Sun BCL, the user must download and install the files themselves. For the "non-standard" BSD-style and ASL-style licenses we must take part in the effort to get this thing sorted and receive a green light from the board. --- The board has asked that all apache contributors act proactively on this matter, performing an audit of ASF distributions, and taking part in clarifying and removing any licensing issues. I believe the goal is to get things clarified and settled within two weeks, in time for the next board meeting. Please follow-up on [EMAIL PROTECTED] --- cheers & g'night, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
