You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Robert Samuel Newson <rn...@apache.org> on 2014/01/28 15:27:45 UTC
Include build tool source?
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
Re: Include build tool source?
Posted by Alex Harui <ah...@adobe.com>.
I am not a lawyer, but my understanding is that you are doing the right
thing by asking on this mailing list. Hopefully someone who can give a
ruling will do so. I think you can also enter a legal JIRA to try to draw
attention as well.
But until approved officially, I wouldn't put it in a distribution.
My understanding is that putting it in SVN/Git can be ok if you use a
"deps folder". My mental model is that the repos can only hold source
code for stuff officially donated to Apache, with the exception that a
folder called "deps" has become a popular pattern, as folks seem to
understand that such folder indicates that the contents may not be owned
by Apache.
HTH,
-Alex
On 2/2/14 10:18 PM, "Paul Davis" <pa...@gmail.com> wrote:
>Kevan,
>
>Do you have any specific keywords to search for. The Googling and
>reading I've done have pointed me very much to the opposite
>conclusion. Specifically [1] seems to suggest that this is acceptable.
>The questions posed in the FAQ:
>
>1. Is it customarily part of distributions of running code?
>
>No. Rebar is a standard build tool and is not tied to the running
>program by any means. Rebar is only required during the compilation
>phase.
>
>2. Has it been around for years and a de facto standard in its
>respective community?
>
>Yes. Its ~4 years old [2] and is the de facto standard for building Erlang
>projects. Its even customarily checked into Erlang project source
>repositories and has no real distribution beyond being included in
>VCS.
>
>3. Is it made available under "library" or "lesser" licenses or
>otherwise containing an exception which ensures that usage of this
>tool does not affect the license of the code against which it is run?
>
>Yes. Its ASL 2.0.
>
>
>There's no question of source level compatibility here. Its just a
>procedural question. Do we really need to include the source and have
>a build step to build the build tool to build the project? Given the
>tool's license and the cited FAQ I would've thought this would be
>acceptable for inclusion. I haven't been able to find anything to the
>contrary but that is quite possibly just because I don't know what I
>should be looking for.
>
>
>[1] http://www.apache.org/legal/resolved.html#build-tools
>[2]
>https://github.com/rebar/rebar/commit/b7e2088c273708bd5ce46b3c135c20f2229c
>7ccf
>
>
>On Sun, Feb 2, 2014 at 10:36 PM, Kevan Miller <ke...@gmail.com>
>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.
>>
>> --kevan
>>
>>
>>
>> On Sat, Feb 1, 2014 at 4:54 AM, Robert Samuel Newson
>><rn...@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 <rn...@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
Re: Include build tool source?
Posted by Robert Samuel Newson <rn...@apache.org>.
Not.
I think the simplest thing here is for rebar to be a system requirement. Every current CouchDB developer is capable of doing that, and we’ll help new folks as needed. If it becomes an issue, we can trivially automate the fetching/building/whatever of rebar in a ./configure or ./bootstrap file. We might end up having to anyway to ensure we’re all using the same version (built against the right erlang release, if that turns out to matter).
B.
On 3 Feb 2014, at 18:33, Kevan Miller <ke...@gmail.com> wrote:
>
>
> On Mon Feb 03 2014 at 10:29:17 AM, Kevan Miller <ke...@gmail.com> wrote:
> For the record, you can try something like: 'asf legal-discuss binaries in svn'. Latest discussions I recall were back in April/May there were discussions about open source fonts in svn:
>
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201304.mbox/browser
>
> "What constitutes a source release?"
>
> As Mark mentions, there have been cases where projects maintained private Maven repos in svn. Causing issues for infra.
>
> There has also been the issue of the ASF releasing source code, not binaries. Putting binaries in your svn for release, is counter to this practice. IIRC, you only want this as an aid to y
>
> Oops. Finger check...
>
> IIRC, you only want this as an aid to your developers and not released. It does beg the question of what your source code "release" looks like. Would it include or not include Rebar?
>
> --kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Include build tool source?
Posted by Kevan Miller <ke...@gmail.com>.
On Mon Feb 03 2014 at 10:29:17 AM, Kevan Miller <ke...@gmail.com>
wrote:
> For the record, you can try something like: 'asf legal-discuss binaries in
> svn'. Latest discussions I recall were back in April/May there were
> discussions about open source fonts in svn:
>
>
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201304.mbox/browser
>
> "What constitutes a source release?"
>
> As Mark mentions, there have been cases where projects maintained private
> Maven repos in svn. Causing issues for infra.
>
> There has also been the issue of the ASF releasing source code, not
> binaries. Putting binaries in your svn for release, is counter to this
> practice. IIRC, you only want this as an aid to y
>
Oops. Finger check...
IIRC, you only want this as an aid to your developers and not released. It
does beg the question of what your source code "release" looks like. Would
it include or not include Rebar?
--kevan
Re: Include build tool source?
Posted by Kevan Miller <ke...@gmail.com>.
For the record, you can try something like: 'asf legal-discuss binaries in
svn'. Latest discussions I recall were back in April/May there were
discussions about open source fonts in svn:
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201304.mbox/browser
"What constitutes a source release?"
As Mark mentions, there have been cases where projects maintained private
Maven repos in svn. Causing issues for infra.
There has also been the issue of the ASF releasing source code, not
binaries. Putting binaries in your svn for release, is counter to this
practice. IIRC, you only want this as an aid to y
--kevan
On Sun Feb 02 2014 at 10:20:03 PM, Paul Davis <pa...@gmail.com>
wrote:
> Kevan,
>
> Do you have any specific keywords to search for. The Googling and
> reading I've done have pointed me very much to the opposite
> conclusion. Specifically [1] seems to suggest that this is acceptable.
> The questions posed in the FAQ:
>
> 1. Is it customarily part of distributions of running code?
>
> No. Rebar is a standard build tool and is not tied to the running
> program by any means. Rebar is only required during the compilation
> phase.
>
> 2. Has it been around for years and a de facto standard in its
> respective community?
>
> Yes. Its ~4 years old [2] and is the de facto standard for building Erlang
> projects. Its even customarily checked into Erlang project source
> repositories and has no real distribution beyond being included in
> VCS.
>
> 3. Is it made available under "library" or "lesser" licenses or
> otherwise containing an exception which ensures that usage of this
> tool does not affect the license of the code against which it is run?
>
> Yes. Its ASL 2.0.
>
>
> There's no question of source level compatibility here. Its just a
> procedural question. Do we really need to include the source and have
> a build step to build the build tool to build the project? Given the
> tool's license and the cited FAQ I would've thought this would be
> acceptable for inclusion. I haven't been able to find anything to the
> contrary but that is quite possibly just because I don't know what I
> should be looking for.
>
>
> [1] http://www.apache.org/legal/resolved.html#build-tools
> [2] https://github.com/rebar/rebar/commit/b7e2088c273708bd5ce46b3c135c20
> f2229c7ccf
>
>
> On Sun, Feb 2, 2014 at 10:36 PM, Kevan Miller <ke...@gmail.com>
> 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.
> >
> > --kevan
> >
> >
> >
> > On Sat, Feb 1, 2014 at 4:54 AM, Robert Samuel Newson <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 <rn...@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
>
>
Re: Include build tool source?
Posted by Paul Davis <pa...@gmail.com>.
Kevan,
Do you have any specific keywords to search for. The Googling and
reading I've done have pointed me very much to the opposite
conclusion. Specifically [1] seems to suggest that this is acceptable.
The questions posed in the FAQ:
1. Is it customarily part of distributions of running code?
No. Rebar is a standard build tool and is not tied to the running
program by any means. Rebar is only required during the compilation
phase.
2. Has it been around for years and a de facto standard in its
respective community?
Yes. Its ~4 years old [2] and is the de facto standard for building Erlang
projects. Its even customarily checked into Erlang project source
repositories and has no real distribution beyond being included in
VCS.
3. Is it made available under "library" or "lesser" licenses or
otherwise containing an exception which ensures that usage of this
tool does not affect the license of the code against which it is run?
Yes. Its ASL 2.0.
There's no question of source level compatibility here. Its just a
procedural question. Do we really need to include the source and have
a build step to build the build tool to build the project? Given the
tool's license and the cited FAQ I would've thought this would be
acceptable for inclusion. I haven't been able to find anything to the
contrary but that is quite possibly just because I don't know what I
should be looking for.
[1] http://www.apache.org/legal/resolved.html#build-tools
[2] https://github.com/rebar/rebar/commit/b7e2088c273708bd5ce46b3c135c20f2229c7ccf
On Sun, Feb 2, 2014 at 10:36 PM, Kevan Miller <ke...@gmail.com> 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.
>
> --kevan
>
>
>
> On Sat, Feb 1, 2014 at 4:54 AM, Robert Samuel Newson <rn...@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 <rn...@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
Re: Include build tool source?
Posted by Noah Slater <ns...@apache.org>.
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 <rn...@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 <rv...@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" <rn...@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 <ma...@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
>>>>> <ma...@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
>>>>> <ma...@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
Re: Include build tool source?
Posted by Robert Samuel Newson <rn...@apache.org>.
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 <rv...@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" <rn...@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 <ma...@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
>>>> <ma...@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
>>>> <ma...@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
Re: Include build tool source?
Posted by Rob Vesse <rv...@dotnetrdf.org>.
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" <rn...@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 <ma...@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
>>> <ma...@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
>>> <ma...@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
Re: Include build tool source?
Posted by Robert Samuel Newson <rn...@apache.org>.
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 <ma...@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
>> <ma...@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
>> <ma...@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
Re: Include build tool source?
Posted by Mark Thomas <ma...@apache.org>.
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
> <ma...@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
> <ma...@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
Re: Include build tool source?
Posted by Kevan Miller <ke...@gmail.com>.
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.
--kevan
On Sat, Feb 1, 2014 at 4:54 AM, Robert Samuel Newson <rn...@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 <rn...@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
> >
>
>
Re: Include build tool source?
Posted by Robert Samuel Newson <rn...@apache.org>.
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 <rn...@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
>