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

[Fabrice Le Fessant]

 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 <gabriel.scherer at gmail.com>
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 <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/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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20160928/82e35cae/attachment.html>