incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [code] main/dmake
Date Mon, 07 Nov 2011 12:31:23 GMT
On Sat, Nov 5, 2011 at 7:27 AM, Ross Gardler <> wrote:
> In order to graduate there can be no license incompatible code in SVN. The solution below
is ok only as an interim solution.

This statement conflicts with what I thought Robert had told us
previously.  My impression from that discussion was that the license
of what was in the *release* was what mattered.  But using GPL build
tools was itself not a problem, unless that triggered a dependency in
the release.

Remember, there are no pure Apache 2,0 licensed operating systems.  So
every application Apache releases, if it goes beyond the facilities of
the programming language, will have some platform dependencies.  For
C/C++ the programming language gives us memory allocation and file
I/O.  That's it.  Everything else we do will require the use of system
header files and libraries, system build tools, etc.  At that point it
is not a question so much of license but of developer notification, of
developer convenience and of build reproducibility:

1) We need to make sure that the developer is explicitly made aware of
any additional licenses that govern the use of their work

2) If we have a choice between requiring the developer to download 20
pieces of code manually from 20 different web sites, and giving them
an easier way to do this, while still requiring explicit notification
per above, then we should be convenient.  As far as I can tell, being
hard to use does not advance any Apache licensing or other goal.

3) Relying on code hosted externally from our SVN puts us at risk of
that code being lost, of it changing URL's the original author dying,
etc.  The web decays.  Our SVN does not.  Even for our own ability to
reproduce a year-old build in order to patch it for a security patch,
it is necessary that we can reassemble all the sources, including
build tools under GPL, in a coherent, consistent form.  So I think,
just form the engineering perspective, that this recommends storing
all non-platform build dependencies in SVN, regardless of license.

So I'd like to push back on Ross's assertion a little, and see what
principles are really at stake, and explore what else might be


> Sent from my mobile device (so please excuse typos)
> On 4 Nov 2011, at 15:38, Oliver-Rainer Wittmann <> wrote:
>> Hi,
>> our build tool dmake is licensed under GPL.
>> Thus, it can not be part of our source releases.
>> But, we can use it for building - as we are using the gcc compiler.
>> Thus, I will move the dmake source folder from .../ooo/trunk/main/ to new folder
.../ooo/buildtools/ in order to assure that everything under .../ooo/trunk/ can become part
of our source release.
>> In order to get our bootstrap process still working it needs some adaption:
>> I am planning to introduce a configure option in order to provide manually the path
to the source folder of the build tool dmake - something like with-dmake=<$PATH to dmake
folder>. If this option is not used, the default path ../../buildtools/dmake/ - relative
from folder main - will be taken. The configure will then check, if this folder exists - the
manual given one or the default. The bootstrap process will then work with this path to create
the build tool dmake.
>> Any objections?
>> Best regards, Oliver.

View raw message