[licensing] On Apache Releases [WAS Re: Clarification on treatment of "weak copyleft" components]

[Robert Burrell Donkin <ro...@gmail.com>]

<snip>

On Tue, Oct 18, 2011 at 5:08 PM, Rob Weir <ro...@apache.org> wrote:
>
> I'm trying, with some difficulty, to interpret what we can do based on the description here:
>
> http://www.apache.org/legal/resolved.html#category-b
>
> How does this fit into a release strategy that has both source and
> binary releases.

Let me turn that around and start to answer "how can an appropriate
release strategy be formulated that abides by these rules?" :-)

IMHO understanding the way Apache uses these terms is key

At Apache, a "source release" is (just) what's in version control when
the release is cut, is canonical and mandatory. Other artifacts follow
the "binary release" rules, are optional and secondary.

"Source releases" are aimed at downstream developers. Amongst this
audience are downstream packagers. An important aim of the "source
release" rules is to allow downstream developers to confidently create
derivative works without excessive effort checking licenses.

"Binary releases" are everything else, including artifacts containing
source code in combination with other works.


More explanation? Questions? Opinions? Comments? Objections?

Robert

Re: [licensing] On Apache Releases [WAS Re: Clarification on treatment of "weak copyleft" components]

[Ross Gardler <rg...@opendirective.com>]

Sent from my mobile device, please forgive errors and brevity.
On Oct 20, 2011 9:40 PM, "Robert Burrell Donkin" <
robertburrelldonkin@gmail.com> wrote:
>
> On Thu, Oct 20, 2011 at 9:01 PM, Rob Weir <ro...@apache.org> wrote:
> > On Thu, Oct 20, 2011 at 9:06 AM, Robert Burrell Donkin
>
> <snip>
>
> >> At Apache, a "source release" is (just) what's in version control when
> >> the release is cut, is canonical and mandatory. Other artifacts follow
> >> the "binary release" rules, are optional and secondary.
> >>
> >
> > OK.  So obviously no "weak" copyleft source files in our source
> > release, i.e., in our source tarballs.
>
> +1
>
> <snip>
>
> > The approach we currently have for these components, in OpenOffice, is:
> >
> > 1) The 3rd party components are stored in a separate repository, not
> > with the core product's SVN.  So we reduce the opportunity for
> > contamination.
> >
> > 2) The build script downloads the source for these components and
> > compiles them.
> >
> > So we avoid the pre-req/provisioning issue.  And we don't need to
> > include the MPL code in the source distribution.  It comes down
> > automatically at build time,
> >
> > That may satisfy the letter of what I'm reading.  But I'd be
> > interested to hear what you think, whether something like that had
> > been done at Apache before.
>
> Most projects use this sort of approach (though there is a strong
> minority view that thinks that they are wrong to do so)

That is not my understanding. As far as I am aware automated downloading of
incompatible licensed coffee is not acceptable.

Providing a separate convenience script that prepares the tree might be
acceptable (need to check with legal-discuss). The difference is th at
there I'd an opportunity to inform the downstream.

Ross

>
> There has been historic resistance to hosting weak copyleft source at
> Apache but there's now a consensus that requirements to supply source
> in perpetuity mean that we'll have to host it sooner or later, most
> likely in a separate repository.
>
> > Maybe it would be better, for example, to allow two build modes, one
> > with and one without the copyleft components, and force the downstream
> > developer to explicitly enable the compilation with weak copyleft
> > components by changing a flag or something?
>
> Always a good idea to let developers know what's happening
>
> Some downstream consumers (in particular, packagers) want to compile
> against their own system dependencies so IMHO it'd be cleaner just to
> switch on or off dependency download, preferrably with fine control.
>
> Robert

Re: [licensing] On Apache Releases [WAS Re: Clarification on treatment of "weak copyleft" components]

[Robert Burrell Donkin <ro...@gmail.com>]

On Thu, Oct 20, 2011 at 9:01 PM, Rob Weir <ro...@apache.org> wrote:
> On Thu, Oct 20, 2011 at 9:06 AM, Robert Burrell Donkin

<snip>

>> At Apache, a "source release" is (just) what's in version control when
>> the release is cut, is canonical and mandatory. Other artifacts follow
>> the "binary release" rules, are optional and secondary.
>>
>
> OK.  So obviously no "weak" copyleft source files in our source
> release, i.e., in our source tarballs.

+1

<snip>

> The approach we currently have for these components, in OpenOffice, is:
>
> 1) The 3rd party components are stored in a separate repository, not
> with the core product's SVN.  So we reduce the opportunity for
> contamination.
>
> 2) The build script downloads the source for these components and
> compiles them.
>
> So we avoid the pre-req/provisioning issue.  And we don't need to
> include the MPL code in the source distribution.  It comes down
> automatically at build time,
>
> That may satisfy the letter of what I'm reading.  But I'd be
> interested to hear what you think, whether something like that had
> been done at Apache before.

Most projects use this sort of approach (though there is a strong
minority view that thinks that they are wrong to do so)

There has been historic resistance to hosting weak copyleft source at
Apache but there's now a consensus that requirements to supply source
in perpetuity mean that we'll have to host it sooner or later, most
likely in a separate repository.

> Maybe it would be better, for example, to allow two build modes, one
> with and one without the copyleft components, and force the downstream
> developer to explicitly enable the compilation with weak copyleft
> components by changing a flag or something?

Always a good idea to let developers know what's happening

Some downstream consumers (in particular, packagers) want to compile
against their own system dependencies so IMHO it'd be cleaner just to
switch on or off dependency download, preferrably with fine control.

Robert

Re: [licensing] On Apache Releases [WAS Re: Clarification on treatment of "weak copyleft" components]

[Rob Weir <ro...@apache.org>]

On Thu, Oct 20, 2011 at 9:06 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> <snip>
>
> On Tue, Oct 18, 2011 at 5:08 PM, Rob Weir <ro...@apache.org> wrote:
>>
>> I'm trying, with some difficulty, to interpret what we can do based on the description here:
>>
>> http://www.apache.org/legal/resolved.html#category-b
>>
>> How does this fit into a release strategy that has both source and
>> binary releases.
>
> Let me turn that around and start to answer "how can an appropriate
> release strategy be formulated that abides by these rules?" :-)
>

I can't really say yet, since some aspects of those rules are still
obscure to me.  But let's push ahead with the discussion, and
hopefully arrive at clarity.

> IMHO understanding the way Apache uses these terms is key
>
> At Apache, a "source release" is (just) what's in version control when
> the release is cut, is canonical and mandatory. Other artifacts follow
> the "binary release" rules, are optional and secondary.
>

OK.  So obviously no "weak" copyleft source files in our source
release, i.e., in our source tarballs.

What was not clear was what we meant, in regards to weak copyleft, by
"Software under the following licenses may be included in binary form
within an Apache product if the inclusion is appropriately labeled".

Does this mean:

A) We can include MPL binaries such as a JAR or a native code lib,
DLL. or object file in a source release?

or

B) We can include MPL binary code only in our binary releases?

When it says "In an Apache product" is that something different than a
release?  Is a source release a product?

> "Source releases" are aimed at downstream developers. Amongst this
> audience are downstream packagers. An important aim of the "source
> release" rules is to allow downstream developers to confidently create
> derivative works without excessive effort checking licenses.
>
> "Binary releases" are everything else, including artifacts containing
> source code in combination with other works.
>
>
> More explanation? Questions? Opinions? Comments? Objections?
>

I think it is important that downstream developers can take our source
releases and build them without:

1) "Excessive license checking" as you say,

2) But also without excessive downloading of scattered prerequisites
from all over the web

So there is some tension here, between what we include in the source
release, as a convenience to the developer, and what we specify as a
pre-req for them to download and provision on their own.

The approach we currently have for these components, in OpenOffice, is:

1) The 3rd party components are stored in a separate repository, not
with the core product's SVN.  So we reduce the opportunity for
contamination.

2) The build script downloads the source for these components and
compiles them.

So we avoid the pre-req/provisioning issue.  And we don't need to
include the MPL code in the source distribution.  It comes down
automatically at build time,

That may satisfy the letter of what I'm reading.  But I'd be
interested to hear what you think, whether something like that had
been done at Apache before.

Maybe it would be better, for example, to allow two build modes, one
with and one without the copyleft components, and force the downstream
developer to explicitly enable the compilation with weak copyleft
components by changing a flag or something?

-Rob

> Robert
>

Re: [licensing] On Apache Releases [WAS Re: Clarification on treatment of "weak copyleft" components]

[Rob Weir <ro...@apache.org>]

On Thu, Oct 20, 2011 at 9:06 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> <snip>
>
> On Tue, Oct 18, 2011 at 5:08 PM, Rob Weir <ro...@apache.org> wrote:
>>
>> I'm trying, with some difficulty, to interpret what we can do based on the description here:
>>
>> http://www.apache.org/legal/resolved.html#category-b
>>
>> How does this fit into a release strategy that has both source and
>> binary releases.
>
> Let me turn that around and start to answer "how can an appropriate
> release strategy be formulated that abides by these rules?" :-)
>
> IMHO understanding the way Apache uses these terms is key
>
> At Apache, a "source release" is (just) what's in version control when
> the release is cut, is canonical and mandatory. Other artifacts follow
> the "binary release" rules, are optional and secondary.
>
> "Source releases" are aimed at downstream developers. Amongst this
> audience are downstream packagers. An important aim of the "source
> release" rules is to allow downstream developers to confidently create
> derivative works without excessive effort checking licenses.
>
> "Binary releases" are everything else, including artifacts containing
> source code in combination with other works.
>
>
> More explanation? Questions? Opinions? Comments? Objections?
>

Drilling into the details now, but another question has come up
related to packaging of the weak copyleft (category b) dependencies in
releases, related to header files.

If we have a dependency on an MPL component, then we do not include
its source in our source release.  But what about the component's
C/C++ header file, which generally is defining the interface to the
module, to satisfy the compiler's, encourage strong type checking,
etc.  Should we remove the header files from the source release as
well?

-Rob

> Robert
>