On 29.11.2011 17:17, Rob Weir wrote:
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,
check
well-known,
check
widely-used open source component
check
that is not tremendously large, then we could safely download it it
build time. (Assuming the license is compatible, of course).
The size should not be a problem in general as you have to download it
anyway, either from our SVN server or from its home server.
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?
In this case, with the source code hosted at mozilla.org I see no
problem. But in general we probably have to keep a copy in SVN, just to
be sure.
If there are no objections then I will give the download a try.
Adapting the fetch_tarballs.sh script should not be too hard. If that
does not work out, we can still put a copy of the rhino library into
ext_sources.
-Andre
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
