incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <mathias.ba...@numberfour.eu>
Subject Re: [code] main/dmake
Date Wed, 09 Nov 2011 14:06:32 GMT
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<orwittmann@googlemail.com>  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.
>


Mime
View raw message