<div dir="ltr">I don't follow, why would AGPL be a danger for your CI scripts or other works on related topics? I'm not a lawyer, but the AGPL text ( <a href="https://www.gnu.org/licenses/agpl.html">https://www.gnu.org/licenses/agpl.html</a> ) does not seem to imply that CI scripts or "related topic" works would be affected by opam-builder's use of the AGPL:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities.  However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work.  For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.<br></blockquote><div><br></div><div>This description of "Source code" (to be distributed when you deploy opam-builder on a service) includes "script to control those activities", so you may argue that for example Docker files used to administrate an opam-builder instance would have to be included -- which seems a reasonable degree of invasiveness to me. I see nothing that could affect CI scripts related to opam-repository in general, or your other works in the area: they are not "specifically designed to require" interaction with opam-builder, or are they?<br><br></div><div>And, in any case, any AGPL-related restriction might arguably prevent you from running opam-builder on your own server, 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></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 2:18 PM, Thomas Gazagnaire <span dir="ltr"><<a href="mailto:thomas@gazagnaire.org" target="_blank">thomas@gazagnaire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> In general I would encourage anyone to help improve opam-builder. We already have a few suggested features in the issue tracket (for example Alain Frisch gave feedback tracked in <a href="https://github.com/OCamlPro/opam-builder/issues/17" rel="noreferrer" target="_blank">https://github.com/OCamlPro/<wbr>opam-builder/issues/17</a> ), but ideas for improvements can easily be very open-ended while the resources to implement those changes seem fairly scarce, so I think focusing on small things first and actually implementing them could be very productive.<br>
<br>
</span>Is there any hope to change the license? As a repository maintainer, I use/maintain/publish a lots of CI scripts and I also work on related topics, so AGPL make it impossible for me to contribute.<br>
<br>
Best,<br>
Thomas<br>
<br>
</blockquote></div><br></div>