[ocaml-platform] Maintainer notifications for opam-builder -- and other opam-builder enhancements

[Gabriel Scherer]

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 <anil at recoil.org> wrote:

> On 28 Sep 2016, at 19:35, Gabriel Scherer <gabriel.scherer at gmail.com>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20160928/3b35f8dc/attachment-0001.html>