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.
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. 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) --Fabrice On Wed, Sep 28, 2016 at 9:06 PM Gabriel Scherer <[email protected]> wrote: > 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/opam-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
