incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@intertwingly.net>
Subject Re: Category B licenses
Date Tue, 28 Jun 2011 20:51:34 GMT
On Tue, Jun 28, 2011 at 4:10 PM, Michael Stahl <mst@openoffice.org> wrote:
>
[snip]
>
> now, some questions:

Things will go quicker if I back up first, and then answer your
specific questions.

The overall policy is that you can't ship anything that isn't Apache
Licensed without prior approval from Legal Affairs.  What you see on
the web site evolved over time; it simply intends to answer some of
the frequently asked questions.  Do *NOT* assume that it is static; if
you have a situation that it doesn't (yet) cover, simply go back to
the policy statement and ask.  Generally, it is best to be specific
about what you want to do instead of posing hypothetical questions.  I
don't think that will be problem here as there are plenty of specific
issues to work though.

Second, we worked hard to make the Apache License compatible with
GPLv3.  And with proprietary usages.  And soon with MPLv2.  We don't
want to approve anything that violates these expectations.

You may (or may not) find the following to be helpful:
http://www.apache.org/legal/ramblings.html

> the sentence on "including only the object/binary form" i don't understand
> at all.
> if we ship a binary installation set, then of course it doesn't include the
> source code for anything (except perhaps Python/BASIC code...).

We need to ship source code.

Not directly in answer to your question, but if we compile and build
that source using MSVC++ and produce an executable that only runs on
Windows platforms, that doesn't stop anybody from also building the
same source using gcc and running it on Linux.  Within reason, you can
even have #ifdef's around code that only make sense on Windows or
Linux.

Similar reasoning can apply to any dependency you can identify.  Of
course, the devil's in the details, and we can work together on
resolving those details.

> so i guess this refers to a source code release.
> but that doesn't make much sense either: what exactly is gained by putting
> binary libraries for a bunch of platforms into a source tarball?
> _which_ platforms? all of them? that's going to be huge...
> is this sentence perhaps intended specifically for Java libraries?

Shipping JAR files is common enough to have been a FAQ.  This answer
may not apply to ooo.

> secondly, "requiring an explicit action to get the reciprocally-licensed
> source", does our existing fetch_tarballs.sh script qualify?
>
> does an explicit configure flag that enables fetch_tarballs.sh to fetch the
> Category B source qualify?

If the default is false and the result is substantially usable with
the default, then approval will be easier to obtain.

> would we get any closer to compliance by uploading per-platform binary
> Category B tarballs, which fetch_tarballs.sh may then fetch and which are
> unpacked during the build?

Doubtful.  I would recommend that you focus more on what you need to
include and assess the impact on doing so on people who would like to
ship the results under various licenses than to try to figure out
workarounds to the current draft of the policy.

> basically, how can we build an ApacheOOo binary release that includes
> Category B licensed libraries?

Again, for the purpose of Legal Affairs, I'd recommend focusing first
on the requirement to provide source to various constituencies.  Once
those basic needs are met, follow up with requests for pre-packaged
binaries.  It may turn out that certain combinations we leave to
others.  That's OK too.

> confused,
>  michael

- Sam Ruby

Mime
View raw message