incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [EXT][DISCUSS] Including Groovy as a scripting language
Date Tue, 27 Sep 2011 16:53:01 GMT
On Tue, Sep 27, 2011 at 12:24 PM, Pedro F. Giffuni <giffunip@tutopia.com> wrote:
> Hello;
>
> --- On Tue, 9/27/11, Shane Curcuru wrote:
> ..
>>
>> I.e. there are cases where Apache projects may want to
>> include Category-B (EPL, CPL, MPL, etc.) tools within a
>> distribution.  This is permitted in binary form, but
>> not source form.
>>
>
> Someone correct me if I am wrong, but dmake as we have it
> today clearly lies in this category.
>

Would it be part of the released distribution?  That is the key question.

Some components are statically inked with our binaries.  So when we
distribute the binaries, we are copying the code, and that has license
implications.

Some components might be dynamically linked and are part of the user's
desktop platform.  In that case we don't need to distribute the
binaries.

Some components might be dynamically linked, but we cannot assume they
are pre-installed on the platforms.  In that case we do need to
distribute the binaries, and that has license implications.

And then some tools might not be used by the binaries at all.  These
are build tools, like make, dmake, perl and shell scripts, etc.  They
help us build, but they do not become part of the binaries.

So look at this from the perspective of someone using our releases,
source and binaries.  If we used copyleft components linked into the
binaries, then we would be restricting the rights of anyone who
modified the code.  For example, the GPL would require that they make
all of their modifications available under GPL as well.

But for build tools, like dmake, I think that is in another category.
Dmake provides functionality for building. It doesn't provide
functionality for the actual product.  Using it does not add any
obligations to the users of our code distributions.  Even if they
modified Dmake, they don't need to distribute dmake with their own
binary distributions.  And if they wanted to release their own source
distributions then all they would need to do is distribute their dmake
changes.  Since the dmake code every bound with the OOo binaries, it
doesn't have wider implications.

The "weak" part of MPL, etc., is that it is not viral.  The copyleft
provision applies only to the actual code modified, not all the code
that it is linked to.  IMHO, a build tool has the effect of "weak
copyleft" even if it was GPL.   If the license is scoped to only the
build tool itself and the tool is not required for the binary
distributions, then I think the effect is similar.

But we should watch out  and take this case-by-case.

-Rob

>
>> With these tools in binary form in the Apache release, a
>> user is unlikely to attempt to modify that non-Apache
>> licensed source code (which they'd have to go find
>> themselves) without clearly realizing that that portion of
>> the Apache release is not under our Apache license.
>>
>
> Concerning the external sources that we still carry: would
> source tarballs of MPL/LGPL stuff be considered binary form?
> This is mostly what we do today so it would solve
> most of our issues (gettext still has to go), but that
> workaround would remove the motivation to further cleanup
> of the source (glibc could stay!)
>
> Pedro.
>

Mime
View raw message