Hi Ross,
I'm still a little but confused about what "license incompatible code"
means here.
In its exact wording MPL code *is* incompatible, as only the binaries
are allowed to be in an Apache release. Does that mean that we must not
have MPL source code in our svn?
The link
http://www.apache.org/legal/resolved.html
does not answer this question:
"Software under the following licenses may be included in binary form
within an Apache product if the inclusion is appropriately labeled:"
As binary releases contain binaries anyway, I assume that "Software"
means the source code. The cited statement leaves it open if that means
released source tarballs or svn.
Maybe the following link helps:
http://www.apache.org/dev/release.html#release-typeso
"What Must Every ASF Release Contain?
Every ASF release must contain a source package, which must be
sufficient for a user to build and test the release provided they have
access to the appropriate platform and tools."
This rule can be followed by providing a source tarball as part of the
binary release that contains the same MPL binaries as the product, but
not the source code. It does not explicitly forbid MPL source code (that
is used to build the binaries we deliver in source tarball and product)
in our svn repo. But I failed to find a quote that explicitly *allows* it.
Can you shed some light on this?
Regards,
Mathias
On 05.11.2011 12:27, 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.
Sent from my mobile device (so please excuse typos)
On 4 Nov 2011, at 15:38, Oliver-Rainer
Wittmann<[email protected]> 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.
