You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Michael Stahl <ms...@openoffice.org> on 2011/06/28 22:10:12 UTC
Category B licenses
hi all,
one thing that is currently unclear to me is whether/how Apache OOo may
depend on code licensed under a Category B license.
the most prominent specimen of this category is the MPL.
first, about OOo:
how we currently build external libraries:
the external libraries are not checked into the HG repository; they
reside (as source tarballs) on some FTP server.
the repository contains things to build the external library:
* a fetch_tarballs.sh script, which is executed as part of "bootstrap"
and downloads all the tarballs
* for every external library, a module, containing:
- patches to fix bugs that affect OOo
- patches to backport security fixes (taken from upstream)
- patches to make it build in our environment (especially on windows)
- more bizarre patches :)
- a makefile.mk to drive the build: call configure with proper flags,
then make, ...
- dependency metadata (prj directory)
during the build, the downloaded external library tarball is unpacked,
built, and the binaries and headers copied to a global directory.
one thing should be perfectly clear: if there is an external C/C++
library that builds in our environment on all platforms without needing
to be patched, then i haven't seen it; i don't think such a creature exists.
of course for all the external modules it's possible to tell configure
to not build the module in OOo but instead use the library on the system
(which in many cases of course only works on GNU/Linux or *BSD).
i think for some libraries (cairo?) it could be an option to do our
release builds against system libraries; if i understood correctly it
should be possible to do this for both Category B and Category X libraries.
while ApacheOOo can never ship Category X libraries, for Category B
there is this:
http://www.apache.org/legal/resolved.html#category-b
"Software under the following licenses may be included in binary form
within an Apache product if the inclusion is appropriately labeled:
[...]
By including only the object/binary form, there is less exposed surface
area of the third-party work from which a work might be derived; this
addresses the second guiding principle of this policy. By attaching a
prominent label to the distribution and requiring an explicit action by
the user to get the reciprocally-licensed source, users are less likely
to be unaware of restrictions significantly different from those of the
Apache License. Please include the URL to the product's homepage in the
prominent label."
now, some questions:
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...).
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?
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?
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?
basically, how can we build an ApacheOOo binary release that includes
Category B licensed libraries?
confused,
michael
--
"And I don't need to waste my time with a computer just because I am
a computer scientist. [Medical researchers are not required to
suffer from the diseases they investigate.]" -- Edsger W. Dijkstra
Re: Category B licenses
Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Jun 28, 2011 at 4:10 PM, Michael Stahl <ms...@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
Re: Category B licenses
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Jun 28, 2011 at 11:42 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> For the magical case of binaries that are not built from the Apache code, what occurred to me first were shared libraries (.DLL or .SO, as well as CLASSPATH goodies and .JAR files) and also executables that could be operated silently from within the Apache-code built software (crude example: how TortoiseSVN installs SVN in some manner and which it is a form of shell for). Another example happens to be over font files, something which has had some folks exercised on LibreOffice lists recently.
IMHO this is an area of shared interest where we should definitely be
talking and working with those folks
IMO this is essential a tooling problem. For projects as large and
complex as office, comprehension of the code base, the build and
assembly starts to become a major issue. A finely grained, loosely
coupled component structure with a simple license for each component
goes some way towards solving this problem by allowing each component
to be small enough to be understood. But this still leaves tooling gap
for a comprehension and verification for the assembled artifact
shipped to end users.
> If the external material is statically linked or otherwise integrated into the Apache code in its build, I think there are concerns, of course
I tend to think in terms of build and assembly as different activities
requiring different tools and techniques. AIUI (from comments earlier
in this thread) OOo already uses a compositional scripting layer for
assembly which then choreographs the build. IMHO it's not such a long
journey from that towards a compositional assembly tool that automates
and reports the license and provenance wrangling.
> and with comingling in source compilations in some way even more-so.
Mixing licenses in source causes major difficulties for developers and
downstream consumers. Most successful FOSS projects tend to adopt a
homogeneous regime. So FOSS tends to factor along license lines. One
way to look at the Apache categories is that they specify which
licenses are sufficiently compatible with the Apache License to be
included within the source.
> My suggestion for here (ooo-dev) is that we focus on how to minimize the exposed surface to run-time access to non-Apache resources (that might be co-deployed) wherever we can, so that nothing is comingled into the build of Apache-source executable or library code itself.
AIUI to ship artifacts for end users, executables are going to need to
be assembled from a complex mixture of resources. Going forward, IMO
separating these concerns by isolating the assembly is likely to make
everything work more smoothly.
> And even then maybe we need to go to legal-discuss.
Apache policy is evolutionary. OOo brings some new challenges and this
means refinement is likely. It's best to start talking as early as
possible...
Robert
RE: Category B licenses
Posted by "Dennis E. Hamilton" <de...@acm.org>.
For the magical case of binaries that are not built from the Apache code, what occurred to me first were shared libraries (.DLL or .SO, as well as CLASSPATH goodies and .JAR files) and also executables that could be operated silently from within the Apache-code built software (crude example: how TortoiseSVN installs SVN in some manner and which it is a form of shell for). Another example happens to be over font files, something which has had some folks exercised on LibreOffice lists recently.
If the external material is statically linked or otherwise integrated into the Apache code in its build, I think there are concerns, of course and with comingling in source compilations in some way even more-so.
My suggestion for here (ooo-dev) is that we focus on how to minimize the exposed surface to run-time access to non-Apache resources (that might be co-deployed) wherever we can, so that nothing is comingled into the build of Apache-source executable or library code itself. And even then maybe we need to go to legal-discuss.
-----Original Message-----
From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com]
Sent: Tuesday, June 28, 2011 14:24
To: ooo-dev@incubator.apache.org
Subject: Re: Category B licenses
On Tue, Jun 28, 2011 at 9:10 PM, Michael Stahl <ms...@openoffice.org> wrote:
> one thing that is currently unclear to me is whether/how Apache OOo may
> depend on code licensed under a Category B license.
> the most prominent specimen of this category is the MPL.
(Apache is mailing-list centric and legal-discuss [1] is where good
answers to questions on this topic are to be found but I'll do my
best. It's also where discussions and decisions about refining policy
happen.)
[ ... ]
Conventionally at Apache, the "source release" is canonical and is
identical to the tagged source in version control. The downstream
ecosystem typically consumes this source and produces installations. A
"binary release" is a (typically compressed) aggregation derived from
the source by some build process and shipped as a convenience for end
users.
> 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?
Not specifically but dynamic and bytecode languages are more likely to
want to ship this sort of thing
> secondly, "requiring an explicit action to get the reciprocally-licensed
> source", does our existing fetch_tarballs.sh script qualify?
Running a script sounds like an explicit action to me but it's best to
open an issue so the documentation can be updated [2]. I'm running out
of my (limited) computer time for today, so hopefully someone will
beat me to it and jump in with the number
<snip>
> basically, how can we build an ApacheOOo binary release that includes
> Category B licensed libraries?
Am I right in assuming that we're talking about shipping something
that can be used to install ApacheOOo?
Robert
[1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/
[2] https://issues.apache.org/jira/browse/LEGAL
Re: Category B licenses
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Robert Burrell Donkin wrote on Wed, Jun 29, 2011 at 11:53:43 +0100:
> On Wed, Jun 29, 2011 at 12:26 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Robert Burrell Donkin wrote on Tue, Jun 28, 2011 at 22:24:07 +0100:
> >> Conventionally at Apache, the "source release" is canonical and is
> >> identical to the tagged source in version control.
> >
> > FWIW, at Subversion the tagged release and the tarball differ by some
> > autogenerated files. ('configure' and SWIG headers are present in the
> > tarball but need to be generated when building from the tag)
>
> Yep :-)
>
> > I've seen the same discrepancy in build procedure (from svn v. from
> > tarball) elsewhere.
>
> "source release" and "binary release" are just names which allow us to
> agree rules and conventions and to express distinctions and
> similarities.
>
> Including resources generated by some process from source means that
> the rules for "binary releases" apply, not "source release". This is
> useful but confusing and often needs explanation (patches for
> documentation gratefully accepted over at legal-discuss).
>
Don't call them "binary" releases then, call them "Releases that include
files that were machine-generated from other files"?
(doing some acrobatics to account for projects that, say, add their
generated 'configure' files to revision control)
> Using other words, including resources under some licenses in an
> aggregate "binary release" shipped is fine but these shouldn't be in
> version control when the "source release" is cut.
>
> Robert
Re: Category B licenses
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Jun 29, 2011 at 12:26 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Robert Burrell Donkin wrote on Tue, Jun 28, 2011 at 22:24:07 +0100:
>> Conventionally at Apache, the "source release" is canonical and is
>> identical to the tagged source in version control.
>
> FWIW, at Subversion the tagged release and the tarball differ by some
> autogenerated files. ('configure' and SWIG headers are present in the
> tarball but need to be generated when building from the tag)
Yep :-)
> I've seen the same discrepancy in build procedure (from svn v. from
> tarball) elsewhere.
"source release" and "binary release" are just names which allow us to
agree rules and conventions and to express distinctions and
similarities.
Including resources generated by some process from source means that
the rules for "binary releases" apply, not "source release". This is
useful but confusing and often needs explanation (patches for
documentation gratefully accepted over at legal-discuss).
Using other words, including resources under some licenses in an
aggregate "binary release" shipped is fine but these shouldn't be in
version control when the "source release" is cut.
Robert
Re: Category B licenses
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Robert Burrell Donkin wrote on Tue, Jun 28, 2011 at 22:24:07 +0100:
> Conventionally at Apache, the "source release" is canonical and is
> identical to the tagged source in version control.
FWIW, at Subversion the tagged release and the tarball differ by some
autogenerated files. ('configure' and SWIG headers are present in the
tarball but need to be generated when building from the tag)
I've seen the same discrepancy in build procedure (from svn v. from
tarball) elsewhere.
Re: Category B licenses
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Jun 28, 2011 at 9:10 PM, Michael Stahl <ms...@openoffice.org> wrote:
> one thing that is currently unclear to me is whether/how Apache OOo may
> depend on code licensed under a Category B license.
> the most prominent specimen of this category is the MPL.
(Apache is mailing-list centric and legal-discuss [1] is where good
answers to questions on this topic are to be found but I'll do my
best. It's also where discussions and decisions about refining policy
happen.)
<snip>
> while ApacheOOo can never ship Category X libraries, for Category B there is
> this: http://www.apache.org/legal/resolved.html#category-b
>
> "Software under the following licenses may be included in binary form within
> an Apache product if the inclusion is appropriately labeled:
> [...]
> By including only the object/binary form, there is less exposed surface area
> of the third-party work from which a work might be derived; this addresses
> the second guiding principle of this policy. By attaching a prominent label
> to the distribution and requiring an explicit action by the user to get the
> reciprocally-licensed source, users are less likely to be unaware of
> restrictions significantly different from those of the Apache License.
> Please include the URL to the product's homepage in the prominent label."
>
> now, some questions:
> 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...).
>
> so i guess this refers to a source code release.
Conventionally at Apache, the "source release" is canonical and is
identical to the tagged source in version control. The downstream
ecosystem typically consumes this source and produces installations. A
"binary release" is a (typically compressed) aggregation derived from
the source by some build process and shipped as a convenience for end
users.
> 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?
Not specifically but dynamic and bytecode languages are more likely to
want to ship this sort of thing
> secondly, "requiring an explicit action to get the reciprocally-licensed
> source", does our existing fetch_tarballs.sh script qualify?
Running a script sounds like an explicit action to me but it's best to
open an issue so the documentation can be updated [2]. I'm running out
of my (limited) computer time for today, so hopefully someone will
beat me to it and jump in with the number
<snip>
> basically, how can we build an ApacheOOo binary release that includes
> Category B licensed libraries?
Am I right in assuming that we're talking about shipping something
that can be used to install ApacheOOo?
Robert
[1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/
[2] https://issues.apache.org/jira/browse/LEGAL