Interesting. I had not read that passage with a critical eye until just now ...
-- replying below to -- From: John D. Ament [mailto:johndam...@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 <aha...@adobe.com> wrote: > Hi, anybody willing to try to answer this? > > Thanks, > -Alex > > On 12/22/14, 8:11 AM, "Alex Harui" <aha...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
