www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Include build tool source?
Date Mon, 03 Feb 2014 16:52:38 GMT
Bob, not so fast!

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

It is the de-facto standard, but the de-facto method of using it is to
bundle it with the source.

Given the size of the binary (~300K), and given the things already
highlighted by Paul, I don't think we need to frustrate our users by
asking them to install it.

This clearly isn't an infra issue (too small) and it doesn't appear to
be a legal issue (the fact that a "deps" folder is okay tells me that
this is more about making sure our end users have the right
expectations about the code -- something which should be true, as we're
following established packaging patterns in the Erlang community) so
what else is left?

As Capt. Picard pointed out to Q one time: rules are useless without
exceptions! I think this is an exception.

On 3 February 2014 13:52, Robert Samuel Newson <rnewson@apache.org> wrote:
> 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
>



-- 
Noah Slater
https://twitter.com/nslater

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


Mime
View raw message