<div dir="ltr"><div><br></div><div> The AGPL license cannot harm OPAM, as, as an owner of opam-builder's code, OCamlPro is allowed to redistribute opam-builder's code under whatever licence, including inserting parts of it in OPAM under the current OPAM license (LGPLv2+EXN). Note also that the patch on OPAM used by opam-builder is not under AGPL, but already under OPAM's license.<div><br></div><div>Anyway, I think we should not diverge from the original topics, which is how we could improve the current opam-builder hosted at OCamlPro to be more useful for maintainers. I will rebuild an archive of result files (including lint files this time), so that contributors can easily change the display without actually running the whole system.<br class="inbox-inbox-Apple-interchange-newline"></div><div><br></div><div>A related topics is the large number of opened issues being discussed on opam-repository, maybe we could also use references to opam-builder (and OWS) to close issues that are duplicates of problems already shown on these websites ? (this together with FAQ items could make it easier to triage issues as for git-on-windows)</div><div>--Fabrice</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 28, 2016 at 9:06 PM Gabriel Scherer <<a href="mailto:gabriel.scherer@gmail.com">gabriel.scherer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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.</div><div dir="ltr"><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 href="mailto:anil@recoil.org" target="_blank">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 href="mailto:gabriel.scherer@gmail.com" target="_blank">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 rel="noreferrer" href="https://github.com/OCamlPro/opam-builder/tree/master/libs/copam" target="_blank">https://github.com/OCamlPro/opam-builder/tree/master/libs/copam</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></blockquote></div>