You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Alex Harui <ah...@adobe.com> on 2014/12/22 17:11:06 UTC
Binary Convenience Package Dependencies
Hi,
I have some questions about Binary Convenience Packages:
1) In [1] it says: "the binary/bytecode package .. may only add
binary/bytecode files that are the result of compiling that version of the
source code release”. An Apache Flex SDK source package has a build
script that downloads jars such as Saxon and JavaCC. Does the text I
quoted mean that the binary package cannot bundle Saxon and JavaCC because
we did not compile those jars from their sources? Or does “compiling”
really mean “running the build script on”?
2) In [2] it says for Category B: "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.” Does “including” means
“bundling”? If so, the quoted text must be referencing binary packages
and not source packages since source packages can never include
object/binary forms. Or does “including” also refer to build scripts that
download an MPL jar like Saxon?
2A) If your build script downloads an MPL jar, must it provide an option
to download the source?
2B) If your build script downloads an MPL jar, is any other additional
warning or explicit action required?
2C) If your binary package bundles an MPL jar (assuming the answer to #1
allows it), must it provide an option to download the source?
Thanks,
-Alex
[1] http://www.apache.org/dev/release.html
[2] http://www.apache.org/legal/resolved.html
Re: Binary Convenience Package Dependencies
Posted by sebb <se...@gmail.com>.
On 6 January 2015 at 01:41, John D. Ament <jo...@apache.org> wrote:
> Hi,
>
> I would strongly recommend that you review with legal, in addition to the
> incubator on this type of question.
>
> If I look here: http://www.apache.org/legal/3party.html
Please *don't* use that page.
It says:
>>
This document represented a proposed ASF policy that was very helpful
in guiding the foundation for a number of years.
Please refer to the official version [1] that was derived from this
draft and associated feedback.
<<
[1] http://www.apache.org/legal/resolved.html
> MPL is listed under Category B, which has the following associated with it:
>
> Although the source must not be included in Apache products, the NOTICE
> file, which is required to be included in each ASF distribution, must point
> to the source form of the included binary (more on that in the forthcoming
> "Receiving and Releasing Contributions" document).
>
> This implies to me that you must include a link in your NOTICE to the
> source code. This doesn't mean you need to distribute the source, nor add
> a download option (from my perspective).
>
> John
>
> On Mon Jan 05 2015 at 12:53:41 PM Alex Harui <ah...@adobe.com> wrote:
>
>> Hi, anybody willing to try to answer this?
>>
>> Thanks,
>> -Alex
>>
>> On 12/22/14, 8:11 AM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>> >Hi,
>> >
>> >I have some questions about Binary Convenience Packages:
>> >
>> >1) In [1] it says: "the binary/bytecode package .. may only add
>> >binary/bytecode files that are the result of compiling that version of the
>> >source code release”. An Apache Flex SDK source package has a build
>> >script that downloads jars such as Saxon and JavaCC. Does the text I
>> >quoted mean that the binary package cannot bundle Saxon and JavaCC because
>> >we did not compile those jars from their sources? Or does “compiling”
>> >really mean “running the build script on”?
>> >
>> >2) In [2] it says for Category B: "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.” Does “including” means
>> >“bundling”? If so, the quoted text must be referencing binary packages
>> >and not source packages since source packages can never include
>> >object/binary forms. Or does “including” also refer to build scripts that
>> >download an MPL jar like Saxon?
>> >
>> >2A) If your build script downloads an MPL jar, must it provide an option
>> >to download the source?
>> >
>> >2B) If your build script downloads an MPL jar, is any other additional
>> >warning or explicit action required?
>> >
>> >2C) If your binary package bundles an MPL jar (assuming the answer to #1
>> >allows it), must it provide an option to download the source?
>> >
>> >Thanks,
>> >-Alex
>> >
>> >[1] http://www.apache.org/dev/release.html
>> >[2] http://www.apache.org/legal/resolved.html
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary Convenience Package Dependencies
Posted by "John D. Ament" <jo...@apache.org>.
On Mon Jan 05 2015 at 9:18:48 PM Dennis E. Hamilton <de...@acm.org>
wrote:
> Interesting. I had not read that passage with a critical eye until just
> now ...
>
> -- replying below to --
> From: John D. Ament [mailto:johndament@apache.org]
> Sent: Monday, January 5, 2015 17:41
> To: general@incubator.apache.org
> Subject: Re: Binary Convenience Package Dependencies
>
> Hi,
>
> I would strongly recommend that you review with legal, in addition to the
> incubator on this type of question.
>
> If I look here: http://www.apache.org/legal/3party.html
> MPL is listed under Category B, which has the following associated with it:
>
> Although the source must not be included in Apache products, the NOTICE
> file, which is required to be included in each ASF distribution, must point
> to the source form of the included binary (more on that in the forthcoming
> "Receiving and Releasing Contributions" document).
>
> <orcmid>
> I don't see how this is going to work in the case of redistributables
> for which source is not supplied and is not open.
>
> What come immediately to mind are the Microsoft Windows redistributables
> for native runtime libraries that are commonly installed with those
> convenience binaries that depend on their presence.
>
> Installing a JVM or a .NET Framework for internal use by a binary
> would probably raise the same issues.
>
> Of course, when the ASF project doesn't actually build the redistributed
> binary artifact, it's not easy to point to *the* source either.
> </orcmid>
>
> This implies to me that you must include a link in your NOTICE to the
> source code. This doesn't mean you need to distribute the source, nor add
> a download option (from my perspective).
>
> <orcmid>
> I think the minimum is to link to the source *of* the code. Whether
> that is
> direct to the source code might not even be the best choice, depending
> on
> circumstances, even if possible.
> </orcmid>
>
>
My interpretation of this (since I deal with this on internal stuff every 3
months or so) has always been that it's a link to the source code, not a
link to the source of the source code.
> John
>
> On Mon Jan 05 2015 at 12:53:41 PM Alex Harui <ah...@adobe.com> wrote:
>
> > Hi, anybody willing to try to answer this?
> >
> > Thanks,
> > -Alex
> >
> > On 12/22/14, 8:11 AM, "Alex Harui" <ah...@adobe.com> wrote:
> >
> > >Hi,
> > >
> > >I have some questions about Binary Convenience Packages:
> > >
> > >1) In [1] it says: "the binary/bytecode package .. may only add
> > >binary/bytecode files that are the result of compiling that version of
> the
> > >source code release”. An Apache Flex SDK source package has a build
> > >script that downloads jars such as Saxon and JavaCC. Does the text I
> > >quoted mean that the binary package cannot bundle Saxon and JavaCC
> because
> > >we did not compile those jars from their sources? Or does “compiling”
> > >really mean “running the build script on”?
> > >
> > >2) In [2] it says for Category B: "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.” Does “including” means
> > >“bundling”? If so, the quoted text must be referencing binary packages
> > >and not source packages since source packages can never include
> > >object/binary forms. Or does “including” also refer to build scripts
> that
> > >download an MPL jar like Saxon?
> > >
> > >2A) If your build script downloads an MPL jar, must it provide an option
> > >to download the source?
> > >
> > >2B) If your build script downloads an MPL jar, is any other additional
> > >warning or explicit action required?
> > >
> > >2C) If your binary package bundles an MPL jar (assuming the answer to #1
> > >allows it), must it provide an option to download the source?
> > >
> > >Thanks,
> > >-Alex
> > >
> > >[1] http://www.apache.org/dev/release.html
> > >[2] http://www.apache.org/legal/resolved.html
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
RE: Binary Convenience Package Dependencies
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Interesting. I had not read that passage with a critical eye until just now ...
-- replying below to --
From: John D. Ament [mailto:johndament@apache.org]
Sent: Monday, January 5, 2015 17:41
To: general@incubator.apache.org
Subject: Re: Binary Convenience Package Dependencies
Hi,
I would strongly recommend that you review with legal, in addition to the
incubator on this type of question.
If I look here: http://www.apache.org/legal/3party.html
MPL is listed under Category B, which has the following associated with it:
Although the source must not be included in Apache products, the NOTICE
file, which is required to be included in each ASF distribution, must point
to the source form of the included binary (more on that in the forthcoming
"Receiving and Releasing Contributions" document).
<orcmid>
I don't see how this is going to work in the case of redistributables
for which source is not supplied and is not open.
What come immediately to mind are the Microsoft Windows redistributables
for native runtime libraries that are commonly installed with those
convenience binaries that depend on their presence.
Installing a JVM or a .NET Framework for internal use by a binary
would probably raise the same issues.
Of course, when the ASF project doesn't actually build the redistributed
binary artifact, it's not easy to point to *the* source either.
</orcmid>
This implies to me that you must include a link in your NOTICE to the
source code. This doesn't mean you need to distribute the source, nor add
a download option (from my perspective).
<orcmid>
I think the minimum is to link to the source *of* the code. Whether that is
direct to the source code might not even be the best choice, depending on
circumstances, even if possible.
</orcmid>
John
On Mon Jan 05 2015 at 12:53:41 PM Alex Harui <ah...@adobe.com> wrote:
> Hi, anybody willing to try to answer this?
>
> Thanks,
> -Alex
>
> On 12/22/14, 8:11 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
> >Hi,
> >
> >I have some questions about Binary Convenience Packages:
> >
> >1) In [1] it says: "the binary/bytecode package .. may only add
> >binary/bytecode files that are the result of compiling that version of the
> >source code release”. An Apache Flex SDK source package has a build
> >script that downloads jars such as Saxon and JavaCC. Does the text I
> >quoted mean that the binary package cannot bundle Saxon and JavaCC because
> >we did not compile those jars from their sources? Or does “compiling”
> >really mean “running the build script on”?
> >
> >2) In [2] it says for Category B: "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.” Does “including” means
> >“bundling”? If so, the quoted text must be referencing binary packages
> >and not source packages since source packages can never include
> >object/binary forms. Or does “including” also refer to build scripts that
> >download an MPL jar like Saxon?
> >
> >2A) If your build script downloads an MPL jar, must it provide an option
> >to download the source?
> >
> >2B) If your build script downloads an MPL jar, is any other additional
> >warning or explicit action required?
> >
> >2C) If your binary package bundles an MPL jar (assuming the answer to #1
> >allows it), must it provide an option to download the source?
> >
> >Thanks,
> >-Alex
> >
> >[1] http://www.apache.org/dev/release.html
> >[2] http://www.apache.org/legal/resolved.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary Convenience Package Dependencies
Posted by "John D. Ament" <jo...@apache.org>.
Hi,
I would strongly recommend that you review with legal, in addition to the
incubator on this type of question.
If I look here: http://www.apache.org/legal/3party.html
MPL is listed under Category B, which has the following associated with it:
Although the source must not be included in Apache products, the NOTICE
file, which is required to be included in each ASF distribution, must point
to the source form of the included binary (more on that in the forthcoming
"Receiving and Releasing Contributions" document).
This implies to me that you must include a link in your NOTICE to the
source code. This doesn't mean you need to distribute the source, nor add
a download option (from my perspective).
John
On Mon Jan 05 2015 at 12:53:41 PM Alex Harui <ah...@adobe.com> wrote:
> Hi, anybody willing to try to answer this?
>
> Thanks,
> -Alex
>
> On 12/22/14, 8:11 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
> >Hi,
> >
> >I have some questions about Binary Convenience Packages:
> >
> >1) In [1] it says: "the binary/bytecode package .. may only add
> >binary/bytecode files that are the result of compiling that version of the
> >source code release”. An Apache Flex SDK source package has a build
> >script that downloads jars such as Saxon and JavaCC. Does the text I
> >quoted mean that the binary package cannot bundle Saxon and JavaCC because
> >we did not compile those jars from their sources? Or does “compiling”
> >really mean “running the build script on”?
> >
> >2) In [2] it says for Category B: "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.” Does “including” means
> >“bundling”? If so, the quoted text must be referencing binary packages
> >and not source packages since source packages can never include
> >object/binary forms. Or does “including” also refer to build scripts that
> >download an MPL jar like Saxon?
> >
> >2A) If your build script downloads an MPL jar, must it provide an option
> >to download the source?
> >
> >2B) If your build script downloads an MPL jar, is any other additional
> >warning or explicit action required?
> >
> >2C) If your binary package bundles an MPL jar (assuming the answer to #1
> >allows it), must it provide an option to download the source?
> >
> >Thanks,
> >-Alex
> >
> >[1] http://www.apache.org/dev/release.html
> >[2] http://www.apache.org/legal/resolved.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
RE: Binary Convenience Package Dependencies
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The "answers" below are not on behalf of the ASF, but based on what the
common sense appears to be, from my individual perspective.
In particular, your project is not relieved from learning what a license
requires of it and demonstrating satisfaction of such requirements.
-- replying below to --
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Monday, January 5, 2015 09:52
To: general@incubator.apache.org
Subject: Re: Binary Convenience Package Dependencies
[ ... ]
>2A) If your build script downloads an MPL jar, must it provide an option
>to download the source?
>
>2B) If your build script downloads an MPL jar, is any other additional
>warning or explicit action required?
<orcmid>
It depends on what the governing license requires with respect to
Whatever is being done with the download. If you are redistributing
the jar or anything in it, see (2C).
As a *practice* it can be valuable to download accompanying licenses
and to make it clear where the download is obtained. That's a matter
of being transparent with regard to the provenance of code being used
and what version it is, etc. That can matter in the event there is a
later concern about revelations of upstream defects, vulnerabilities,
and such.
Presumably the upstream source will provide any determination on the
availability of source code. (In (2B) there is no indication that the
ASF project is accessing such source code itself.)
</orcmid>
>
>2C) If your binary package bundles an MPL jar (assuming the answer to #1
>allows it), must it provide an option to download the source?
<orcmid>
This item has nothing to do with the ASF policy about category B software.
For (2C), the obligation is to comply with the MPL license with respect
to redistribution of a binary component that is provided under that
license.
In particular, what other ASF projects might or might not do is not a
reliable precedent for what your project does. What your project must
do is comply with the applicable license. There may be additional steps
required as part of the ASF policy and recommendations, but the minimum
is determined by the governing license.
For example, your project's LICENSE and NOTICE files included in your
binary package bundle will likely also address the presence of the
MPL-licensed dependency, as required in accordance with ASF policy.
</orcmid>
>
>Thanks,
>-Alex
>
>[1] http://www.apache.org/dev/release.html
>[2] http://www.apache.org/legal/resolved.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary Convenience Package Dependencies
Posted by Andrea Pescetti <pe...@apache.org>.
On 05/01/2015 jan i wrote:
> On 5 January 2015 at 18:52, Alex Harui wrote:
>>> 2) In [2] it says for Category B: "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.” Does “including” means
>>> “bundling”? If so, the quoted text must be referencing binary packages
>>> and not source packages since source packages can never include
>>> object/binary forms. Or does “including” also refer to build scripts that
>>> download an MPL jar like Saxon?
>
> AOO release notes, includes the list of external packages (binary) we use,
> but we do NOT provide the source for these libraries, nor do our installer
> give the user a possibility to download.
Let me just complete this. The OpenOffice SVN repository (but, Jan is
correct, not the source package we ship) does include some libraries
that are under Category A. OpenOffice can be fully built from that
source package, but our users need additional functionality.
So the convenience binaries are configured with --enable-category-b
(yes, we really have a configure option named that way) and include
binary forms of some extra libraries. These are listed and credited not
in the Release Notes, but in the LICENSE file. So credits and notices
are shipped with the binaries.
Again, for convenience of developers, we archive the Category A
materials in SVN, and we archive Category B materials on Apache Extras,
which seemed a wonderful idea to have them permanently archived until
Google decided to pull the plug and shut down Apache Extras...
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary Convenience Package Dependencies
Posted by jan i <ja...@apache.org>.
On 5 January 2015 at 18:52, Alex Harui <ah...@adobe.com> wrote:
> Hi, anybody willing to try to answer this?
>
Without being an expert on all the legal implications, I can tell you how
AOO deals with the problem set.
see inline.
rgds
jan i.
>
> Thanks,
> -Alex
>
> On 12/22/14, 8:11 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
> >Hi,
> >
> >I have some questions about Binary Convenience Packages:
> >
> >1) In [1] it says: "the binary/bytecode package .. may only add
> >binary/bytecode files that are the result of compiling that version of the
> >source code release”. An Apache Flex SDK source package has a build
> >script that downloads jars such as Saxon and JavaCC. Does the text I
> >quoted mean that the binary package cannot bundle Saxon and JavaCC because
> >we did not compile those jars from their sources? Or does “compiling”
> >really mean “running the build script on”?
>
AOO uses a "configure" script that downloads all the packages we needs,
then we run "build" and release the binary.
If you take [1] too strictly you would never be able to make a binary,
because you always depend on some system libraries at the very least.
> >
> >2) In [2] it says for Category B: "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.” Does “including” means
> >“bundling”? If so, the quoted text must be referencing binary packages
> >and not source packages since source packages can never include
> >object/binary forms. Or does “including” also refer to build scripts that
> >download an MPL jar like Saxon?
>
AOO release notes, includes the list of external packages (binary) we use,
but we do NOT provide the source for these libraries, nor do our installer
give the user a possibility to download.
I can only repeat my argument from above.
>
> >2A) If your build script downloads an MPL jar, must it provide an option
> >to download the source?
>
AOO does not.
> >
> >2B) If your build script downloads an MPL jar, is any other additional
> >warning or explicit action required?
>
AOO does not give any. The configure scripts informs the user what it
downloads as it happens not in advance.
> >
> >2C) If your binary package bundles an MPL jar (assuming the answer to #1
> >allows it), must it provide an option to download the source?
>
AOO does not.
I hope this helps you a bit, feel free to come back with questions.
rgds
jan i.
> >
> >Thanks,
> >-Alex
> >
> >[1] http://www.apache.org/dev/release.html
> >[2] http://www.apache.org/legal/resolved.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: Binary Convenience Package Dependencies
Posted by Alex Harui <ah...@adobe.com>.
Hi, anybody willing to try to answer this?
Thanks,
-Alex
On 12/22/14, 8:11 AM, "Alex Harui" <ah...@adobe.com> wrote:
>Hi,
>
>I have some questions about Binary Convenience Packages:
>
>1) In [1] it says: "the binary/bytecode package .. may only add
>binary/bytecode files that are the result of compiling that version of the
>source code release”. An Apache Flex SDK source package has a build
>script that downloads jars such as Saxon and JavaCC. Does the text I
>quoted mean that the binary package cannot bundle Saxon and JavaCC because
>we did not compile those jars from their sources? Or does “compiling”
>really mean “running the build script on”?
>
>2) In [2] it says for Category B: "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.” Does “including” means
>“bundling”? If so, the quoted text must be referencing binary packages
>and not source packages since source packages can never include
>object/binary forms. Or does “including” also refer to build scripts that
>download an MPL jar like Saxon?
>
>2A) If your build script downloads an MPL jar, must it provide an option
>to download the source?
>
>2B) If your build script downloads an MPL jar, is any other additional
>warning or explicit action required?
>
>2C) If your binary package bundles an MPL jar (assuming the answer to #1
>allows it), must it provide an option to download the source?
>
>Thanks,
>-Alex
>
>[1] http://www.apache.org/dev/release.html
>[2] http://www.apache.org/legal/resolved.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org