<div dir="ltr"><div><div>If one of your point is that it would be nice to move some of the opam-builder logic to become independent pieces of the ecosystem (or benefit opam directly), then I would agree -- and of course anything moved into OPAM would need to be made available under OPAM's license, and more generally stuff distributed as libraries would better not use AGPL. There was some discussion during the workshop on how much of opam-builder's cool incremental stuff could be done with opam (in particular opam 2.0), or could be made available to opam users directly.<br><br></div>That said, this goes well beyond the form of small improvements I had in mind when starting this thread, which are purely about making opam-builder, as a service, more useful to the open-source opam community.<br><br><div>(I now understand the other point, which is that companies with 
internal opam repositories would want to run internal opam-builder 
instances, and that the AGPL license may prevent these internal 
deployments because of internal company policies.)<br><br></div></div>Note that I'm also in general interested in the ability to deploy separate opam-builder instances; for instance, I wonder how much work it would be for the Coq community, which is starting to use opam, to deploy their own opam-builder for their repositories.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 2:53 PM, Anil Madhavapeddy <span dir="ltr"><<a target="_blank" href="mailto:anil@recoil.org">anil@recoil.org</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span>On 28 Sep 2016, at 19:35, Gabriel Scherer <<a target="_blank" href="mailto:gabriel.scherer@gmail.com">gabriel.scherer@gmail.com</a>> wrote:<br>
><br>
> And, in any case, any AGPL-related restriction might arguably prevent you from running opam-builder on your own server<br>
<br>
</span>...and OPAM was explicitly designed to support installation behind firewalls, which is what we do at work at Docker.<br>
<span><br>
> but I see even less how they could prevent you from contributing patches to the software itself, intended to take effect on Fabrice's instances -- that's the way I've been considering contribution to opam-builder so far, although others are of course warmly welcome to run their own instances if they want.<br>
<br>
</span>This isn't very useful for our purposes without access to our internal remotes and code.<br>
<br>
There is quite a comprehensive library driving opam-builder that could contribute to the OPAM tooling ecosystem, but cannot currently be extricated from the server software itself: <a target="_blank" rel="noreferrer" href="https://github.com/OCamlPro/opam-builder/tree/master/libs/copam">https://github.com/OCamlPro/op<wbr>am-builder/tree/master/libs/co<wbr>pam</a><br>
<br>
Like Thomas, I'm also unfortunately unable to contribute to software that is restrictively licensed enough that it is not compatible with the mainline OPAM license of LGPLv2. This is not to say that I do not appreciate the efforts that go into it, and I hope it continues to be hosted and maintained by OCamlPro.  I hope a clear separation continues to be maintained between OPAM and OPAM-builder, since code really shouldn't get mixed up as long as the licenses diverge...<br>
<br>
regards,<br>
Anil</blockquote></div><br></div></div>