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.
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. (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.) 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. On Wed, Sep 28, 2016 at 2:53 PM, Anil Madhavapeddy <[email protected]> wrote: > On 28 Sep 2016, at 19:35, Gabriel Scherer <[email protected]> > wrote: > > > > And, in any case, any AGPL-related restriction might arguably prevent > you from running opam-builder on your own server > > ...and OPAM was explicitly designed to support installation behind > firewalls, which is what we do at work at Docker. > > > 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. > > This isn't very useful for our purposes without access to our internal > remotes and code. > > 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: https://github.com/OCamlPro/op > am-builder/tree/master/libs/copam > > 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... > > regards, > Anil
_______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
