www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Vesse <rve...@dotnetrdf.org>
Subject Re: Include build tool source?
Date Mon, 03 Feb 2014 10:09:56 GMT
I think Mark is making an interesting point here about what we can
reasonably expect from downstream consumers of code.  Apache releases are
source releases though projects may provide convenience binaries so
generally speaking we are expecting people to build the code themselves in
many cases.

However if this were a Java project and we were talking about Maven/Ant
we'd be saying it would be silly to put Maven/Ant binaries in the
distribution because as Java developers we assume any serious developer
will have Maven/Ant installed already or known how to obtain and install
it.  Similarly make and autoconf for *nix development, MSBuild for .Net
development etc. the list could go on.

If Rebar is the widely used de-facto standard build tool for Erlang code
then I think it's reasonable to expect developers to have it or to be able
to install it themselves.  On the other hand if it is relatively uncommon
then making it available to users somehow seems sensible.

As Mark points out there are ways to do this that don't require putting
the binaries in SVN/distributions directly but rather using scripting to
check for the installation of the tool and provide the option to download
& install it where necessary.


On 03/02/2014 01:29, "Robert Samuel Newson" <rnewson@apache.org> wrote:

>Rebar is a single file of 306K. It¹s not something a developer is
>expected to have installed locally (as Paul notes, it¹s always bundled
>with the projects that use it). It¹s not hard to build but it would be an
>extra step. I honestly can¹t gauge how off-putting an "install rebar
>yourself" step would be since it¹s not a step I¹ve seen in a rebar-ified
>project to date.
>On 3 Feb 2014, at 08:03, Mark Thomas <markt@apache.org> wrote:
>> On 03/02/2014 04:36, Kevan Miller wrote:
>>> In past discussions on this general subject, the answer has been -- no,
>>> that's not ok. It's not really a "legal" question, but a question of
>>> policy of an "open source" foundation.
>>> There are discussions in the archives for this mailing list. As I
>>> recall, infra was against maintaining binaries in svn, also.
>> Putting on my infrastructure hat...
>> The starting point for infrastructure is that binaries do not belong in
>> svn. In the past we have found projects with gigabytes of Maven repos in
>> svn. Infrastructure were, how shall I put this, not happy when they
>> found this.
>> That said, there is some room for flexibility providing that the project
>> is sensible about it. The trade-offs that need to be considered:
>> - how big is the binary?
>> - how hard is it to build/download as part of the project build?
>> - is it something that developers are expected to have installed
>>  locally?
>> Taking some concrete examples from Tomcat:
>> - You need to have Java and Ant installed before you can build.
>>  Developers are expected to install these themselves.
>> - You need NSIS to create the Windows installer as part of a release
>>  build. This is downloaded as part of the build.
>> - You need the Commons Daemon binaries. These are also downloaded as
>>  part of the build.
>> - The examples web application uses JSTL. The JARs are in svn. To be
>>  honest, I can't see a good reason for this. It looks to be historical.
>>  I need to look into switching that to downloading.
>> From what I have read on this thread so far I don't yet see an
>> justification for why this needs to be in svn. Some explicit questions:
>> 1. Why is it unreasonable to expect folks that want to build CouchDb to
>> be required to download and install the rebar binary?
>> 2. How big is the binary?
>> 3. How hard is it to include downloading/creating the binary as part of
>> the build script?
>> Mark
>>> --kevan
>>> On Sat, Feb 1, 2014 at 4:54 AM, Robert Samuel Newson
>>> <mailto:rnewson@apache.org>> wrote:
>>>    Given that the rebar project is ASLv2, I¹m going to proceed with
>>>    just including the rebar binary, with notes on the exact tree it was
>>>    built from. The rebar binary will not be included in our release
>>>    artifacts.
>>>    B.
>>>    On 28 Jan 2014, at 14:27, Robert Samuel Newson <rnewson@apache.org
>>>    <mailto:rnewson@apache.org>> wrote:
>>>> Hi,
>>>> The Apache CouchDB team is working to incorporate two sizeable
>>>    code contributions which add many new features. CouchDB currently
>>>    builds using autotools but we have, as a team, decided to  switch to
>>>    Rebar (https://github.com/opscode/rebar), an erlang build tool
>>>    licensed under the ASLv2. Both contributions already use Rebar.
>>>> Expecting users and developers to have rebar available, or easily
>>>    available, is not reasonable and so we intend to include the built,
>>>    cross-platform rebar binary in the root of our source repository
>>>    (this is a common practice among Erlang projects using Rebar).
>>>> My question to legal is: Do we need to include the source from
>>>    which our build tool is built?
>>>> Thanks,
>>>> Robert Newson
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>For additional commands, e-mail: legal-discuss-help@apache.org

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message