On Tue, Nov 29, 2011 at 11:07 AM, Andre Fischer <[email protected]> wrote: > > > On 29.11.2011 13:08, Rob Weir wrote: >> >> On Tue, Nov 29, 2011 at 6:11 AM, Andre Fischer<[email protected]> wrote: >>> >>> Hi all, >>> >>> I need advice regarding license headers. >>> >>> The upgrade of rhino to version 1.7 will integrate a file >>> (OfficeScriptInfo.java) that previously existed only in a patch that was >>> applied to version 1.5 source code before building. This file still has >>> the >>> old license. The patch file itself is part of the SGA. >>> >> >> So the entire OfficeScriptInfo.java was included in a patch, and that >> patch was included in the SGA? If that is true, then I believe we may >> update the license header in the source file. >> >> Think of it this way: The SGA is what puts these files under ALv2. >> Updating the license header is how we document this fact, so it is >> clear to downstream consumers exactly what files are under ALv2. > > > Good, I was hoping for this answer. > > And I have another question. Can/should we download the source or even the > binaries (keep in mind that rhino is a Java library, so the binary is a JAR > file) directly from the mozilla servers or should we update the rhino tar > ball in ext_sources? >
I'm working on another Apache podling (ODF Toolkit) where we use Maven. So no third party components are stored in SVN. JAR's are downloaded at build time. That is the Maven model. So that is certainly permitted. IMHO, I'd look at the stability of the host. If we have a dependency on a long-established, well-known, widely-used open source component that is not tremendously large, then we could safely download it it build time. (Assuming the license is compatible, of course). But if it is a component that we worry might disappear tomorrow, or the host is not very attentive to preserving stability of URL references, or they commonly delete old binaries when updating their component, then having a copy in SVN could be a good idea. The idea should be (I believe) to support some sort of release policy where we have something like "Long term stable" releases as well as more frequent feature releases. For an LTS release we would want to be able to spin a new maintenance release 18 months from now. What do we need to do to be sure that everything we depend on is still there? That's my personal opinion. -Rob > Regards, > Andre > > >> >> -Rob >> >>> My question is how to handle this file? Change the license on my own? >>> Ask >>> Andrew Rist to do it? >>> >>> Regards, >>> Andre >>> >>> >>> On 25.11.2011 15:44, Tsutomu Uchino wrote: >>>> >>>> >>>> Hi Andre, >>>> >>>> 2011/11/25 Andre Fischer<[email protected]>: >>>>> >>>>> >>>>> Hi Tsutomu, >>>>> >>>>> On 25.11.2011 13:08, Tsutomu Uchino wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi Andre, >>>>>> >>>>>> Yesterday I got a suggestion about MPL license from Pedro. But it is >>>>>> clear >>>>>> now. >>>>>> I have already reopned the issue. >>>>> >>>>> >>>>> >>>>> Ah, very good :-) >>>>> >>>>>> >>>>>> Additionally, I noticed about license issue we need to add configure >>>>>> options to switch Rhino enabled or disabled. >>>>> >>>>> >>>>> >>>>> I can do that if you like. There are a number of libraries that have >>>>> to >>>>> get >>>>> a special treatment, not just rhino. I will start to work on that, as >>>>> soon >>>>> the category-x code is removed. >>>> >>>> >>>> Thank you for your work. I think I can do it in short time, my >>>> knowledge about the building process is not enough for the task. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Andre >>>> >>>> >>>> >>>> Regards, >>>> Tsutomu
