On Sun, Oct 30, 2011 at 2:49 PM, Mathias Bauer <mathias_ba...@gmx.net> wrote: > Moin, > > thinking a bit about what would be the best to do I would like to sort > all tarballs into several categories: > > (1) external source tarballs with an AL compatible license > (2) external source tarballs with weak copyleft license > (3) external source tarballs with strong copleft license > > The topics we need to consider are differnt in these three sections. > > Everybody should know how external modules are built now: > Currently we build all external modules as part of the "main" directory: > a script in the folder of the module unpacks the tarball from the local > ext_src folder into the build sub folder of the module, applies patches > if necessary and then builds the module from its build folder (not from > its source folder as with all "internal" modules). > > (1) AL compatible license > > We don't have problems to add them to our repository, but we should > think a little bit about how we do it. > As we are now thinking about moving external tarballs into svn, I don't > see a reason to keep their build directories inside of "main" - at least > not for those components that will always be built as external module > and so will never be used from the system. It looks strange to me to > have the tarballs in one part of the svn repo, copy it into another part > and then build from there. > So IMHO it would make sense to move these tarballs into the folder of > the module that builds it and then decise whether the whole module > should be moved from "main" to "external". > > (2) Weak Copyleft license > > It seems as if we want to keep at least HunSpell, maybe more, and > according to the Apache rules we must deliver them as binaries in our > source tree. As we don't take these binaries from the original projects > as they are (for several reasons), we must build them from the sources > ourselves and that must happen somewhere outside of the "regular" OOo > build. We already do that with the "mozilla" module if the
I don't believe that there is any requirement to place these modules outside of the Apache SVN. The requirement is around *releases*, not *builds*. We cannot include the source of weak copyleft components in our releases. But we can host them in SVN. In general, I don't think that there is any real advantage, in terms of Apache license and release policy, of moving code to Apache Extras. It doesn't enable anything that would not already be permitted. Where you host the code does not really change anything. It is what you put in the release that really counts. However, there are advantages to having the code in SVN rather than Apache Extras: 1) Backups and support provided by Apache Infra 2) Access controlled automatically maintained per our committer list 3) All committer changes automatically covered by iCLA 4) Ability to have a coherent project history in a single repository 5) Ability to branch across the entire project, including the external dependencies. This might be very important when we start integrating code from Symphony, for example. So I don't see any great advantage to hosting the 3rd party components outside of our AOOo SVN, even non-Apache licensed ones. > "--disable-build-mozilla" option in configure is used. In that case > precompiled binaries are expected to be in the "moz" module. > It don't know how this will look in the future, but it seems clear to me > that we will need the sources for these components. So I will cpüy these > source tarballs into our "external" sub repo as planned. > > (3) Strong Copyleft license > > In the end we don't want to keep them, so sooner or later we will remove > them from our repository. The question I have now is: shall we move them > to our repository first and remove them later (as we do with the > lgpl/mpl stuff that currently is inside the source code tree) or can be > leave out at least some of them now? Different to the weak copyleft > components, the strong copyleft ones are of no use for us, neither in > source nor in binary form. > To keep things simple for now: if nobody asks for the opposite, I will > copy them into our "external" sub repo, but that's open for discussion. > I think we just keep them in our SVN, but remove them as we work toward our first release. There might even be areas where we keep LGPL header files in our tree in order to resolve dependencies that will be resolved at runtime based on platform available modules. -Rob > Regards, > Mathias >
