www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Include build tool source?
Date Mon, 03 Feb 2014 09:29:13 GMT

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 <rnewson@apache.org
>> <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


Mime
View raw message