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 12:52:14 GMT
Ok…

I’ll remove the rebar source and make it something that developers/users need to install
themselves. We’ll see what the drop-off looks like.

B.

On 3 Feb 2014, at 10:09, Rob Vesse <rvesse@dotnetrdf.org> wrote:

> 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.
> 
> Rob
> 
> 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
>>>> <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
>> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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