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

Yaron Minsky yminsky at janestreet.com
Mon Oct 3 10:52:14 BST 2016

As to the substance, I also have some concerns about the AGPL-variant being
used here. It combines the requirement of the AGPL to make all source code
of modifications available, along with an OCamlPro/INRIA/IRILL advertising
requirement on all web pages published. The problems I see are:

   - It's incompatible with opam and other OCaml infrastructure in terms of
   license, which makes sharing more arduous.
   - The advertising and source code obligations seem painful to manage.
   I'd personally rather just not host such a thing, rather than be exposed to
   breaking the rules by so much as trying out a patch before making it public.

OCamlPro of course has the right to license its source code however it
wants. But it's also reasonable for other contributors to refrain from
contributing and using infrastructure whose licenses they find problematic.

Personally, I believe that we should avoid having to talk about licenses by
sticking to liberal licenses for the core infrastructure, which has
informed both how Jane Street has released its own code, and the licenses
it has required for infrastructure it funds.


On Mon, Oct 3, 2016 at 9:57 AM, Anil Madhavapeddy <anil at recoil.org> wrote:

> I'll second this. All of us in this conversation have done a huge amount
> of work towards advancing the state of OCaml, and care deeply about the
> future of OPAM and its ecosystem. It is my hope that there is room for
> everyone to grow and flourish their particular visions of OPAM tooling, and
> discourse such as this licensing thread is important to establish a common
> understanding for everyone to work together under an open-source umbrella.
> However, there is absolutely no room for disrespectful discourse in this
> community. Let's lay our arguments out rationally, and attempt to reach a
> consensus.  It's normal for complex issues such as CLAs and licenses to
> take some time to work through, and also for there to be stepping stones
> where we do not all agree on the right solutions.
> I would like to curate this list as a place where such matters can be
> discussed and understood, so we are all aware of each other's efforts
> towards our ultimate goal of an awesome OCaml developer experience.
> regards,
> Anil
> > On 2 Oct 2016, at 22:00, Yaron Minsky <yminsky at janestreet.com> wrote:
> >
> > Perhaps at this point a pointer to Simon Peyton Jones' recent post on
> respectful discourse is in order.
> >
> > https://mail.haskell.org/pipermail/haskell/2016-September/024995.html
> >
> > I understand that people care deeply about these issues, but that
> doesn't mean we shouldn't address them in a calm and respectful way.
> Discussing these issues is hard enough without mixing harsh language into
> the debate.
> >
> > y
> >
> > On Sat, Oct 1, 2016 at 9:16 AM, Daniel Bünzli <
> daniel.buenzli at erratique.ch> wrote:
> > On Saturday 1 October 2016 at 14:11, Fabrice Le Fessant wrote:
> > > On Sat, Oct 1, 2016 at 4:05 AM Daniel Bünzli <
> daniel.buenzli at erratique.ch (mailto:daniel.buenzli at erratique.ch)> wrote:
> > > > While not granting the same rights to the contributor if you don't
> have a liberal (in the sense non GPL) license... What you say is a gross
> misrepresentation of the actual implications of the terms.
> > >
> > > Yes, the rights are not equal, but often, the contributions are not
> equal either. I have written 100% of the code of opam-builder, so why shall
> I give you the same rights on my code, just because you might eventually
> contribute 10 lines ? Are you the one who will maintain the full code over
> time, fix bugs in the lines you added, make them evolve, and so on ? You
> want the same rights, but without the same duties.
> >
> >
> > Frankly I don't give a shit about what you do with your code or how you
> license it. Just notice that the system you setup will precisely *not*
> entice people to make large contributions or take over these duties.
> >
> > > We changed the license in your sense instead of introducing a CLA
> because you convinced everybody it was needed to increase the number of
> contributions.
> >
> > 1) The OPAM license wasn't changed in my sense, the bug of the license
> was fixed.
> > 2) I never said it would increase the number of contributions. I said
> that CLAs were barriers to contribution [1].
> >
> > > Looking at the git logs in github.com/ocaml/opam (
> http://github.com/ocaml/opam), the number of contributions have actually
> decreased since the license went more liberal...
> >
> > The license didn't go more liberal, the license had a bug which was
> fixed so that it would correspond to the original intent.
> >
> > And about that decrease in contributions, my sincere apologies to the
> community, that is certainly because we didn't introduce a CLA, I'll take
> the blame for this.
> >
> > Daniel
> >
> > [1] http://lists.ocaml.org/pipermail/opam-devel/2016-January/001291.html
> > _______________________________________________
> > Platform mailing list
> > Platform at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/platform
> >
> > _______________________________________________
> > Platform mailing list
> > Platform at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/platform
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20161003/96288001/attachment-0001.html>

More information about the Platform mailing list