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

[Gabriel Scherer]

Hi platform,

During Fabrice's opam-builder presentation at the OCaml workshop there were
some ideas of minor or major improvements floating around. I just sent a
pull request for improving the colors of the HTML report -- including for
example Yaron Minsky's suggestion to remove the distinction between the
shades of green -- see

https://github.com/OCamlPro/opam-builder/issues/26
https://github.com/OCamlPro/opam-builder/pull/27

(in the issue, Fabrice gives instruction on how to test the HTML report
generation without first doing a full build of the opam repository, which
were very helpful to me and could help others wishing to make other changes
to the reporting logic of opam-builder.)

I started a discussion on what would be a good way to notify package
maintainers, on which feedback could be useful -- I'm also interested in
the opinion of the current opam-repository maintainers for example, which
have more experience than I have working with upstream packagers.

https://github.com/OCamlPro/opam-builder/issues/28

In general I would encourage anyone to help improve opam-builder. We
already have a few suggested features in the issue tracket (for example
Alain Frisch gave feedback tracked in
https://github.com/OCamlPro/opam-builder/issues/17 ), but ideas for
improvements can easily be very open-ended while the resources to implement
those changes seem fairly scarce, so I think focusing on small things first
and actually implementing them could be very productive.

[Thomas Gazagnaire]

In general I would encourage anyone to help improve opam-builder. We already have a few suggested features in the issue tracket (for example Alain Frisch gave feedback tracked in https://github.com/OCamlPro/opam-builder/issues/17 ), but ideas for improvements can easily be very open-ended while the resources to implement those changes seem fairly scarce, so I think focusing on small things first and actually implementing them could be very productive.

Is there any hope to change the license? As a repository maintainer, I use/maintain/publish a lots of CI scripts and I also work on related topics, so AGPL make it impossible for me to contribute.

Best,
Thomas

[Gabriel Scherer]

I don't follow, why would AGPL be a danger for your CI scripts or other
works on related topics? I'm not a lawyer, but the AGPL text (
https://www.gnu.org/licenses/agpl.html ) does not seem to imply that CI
scripts or "related topic" works would be affected by opam-builder's use of
the AGPL:

The "Corresponding Source" for a work in object code form means all the

source code needed to generate, install, and (for an executable work) run
the object code and to modify the work, including scripts to control those
activities. However, it does not include the work's System Libraries, or
general-purpose tools or generally available free programs which are used
unmodified in performing those activities but which are not part of the
work. For example, Corresponding Source includes interface definition files
associated with source files for the work, and the source code for shared
libraries and dynamically linked subprograms that the work is specifically
designed to require, such as by intimate data communication or control flow
between those subprograms and other parts of the work.

This description of "Source code" (to be distributed when you deploy
opam-builder on a service) includes "script to control those activities",
so you may argue that for example Docker files used to administrate an
opam-builder instance would have to be included -- which seems a reasonable
degree of invasiveness to me. I see nothing that could affect CI scripts
related to opam-repository in general, or your other works in the area:
they are not "specifically designed to require" interaction with
opam-builder, or are they?

And, in any case, any AGPL-related restriction might arguably prevent you
from running opam-builder on your own server, 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.

Post by Gabriel Scherer
In general I would encourage anyone to help improve opam-builder. We

already have a few suggested features in the issue tracket (for example
Alain Frisch gave feedback tracked in https://github.com/OCamlPro/
opam-builder/issues/17 ), but ideas for improvements can easily be very
open-ended while the resources to implement those changes seem fairly
scarce, so I think focusing on small things first and actually implementing
them could be very productive.
Is there any hope to change the license? As a repository maintainer, I
use/maintain/publish a lots of CI scripts and I also work on related
topics, so AGPL make it impossible for me to contribute.
Best,
Thomas

[Anil Madhavapeddy]

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

[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.

Post by Gabriel Scherer
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.

Post by Gabriel Scherer
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

[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

Post by 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.

Post by Gabriel Scherer
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.

Post by Gabriel Scherer
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
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

[Anil Madhavapeddy]

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).

That is correct, but how does this fit in with the request for contributions that Gabriel issued? External contributors presumably need to sign a CLA with OCamlPro to give them copyright retention over the source code so that you can dual license it. Has Gabriel signed such a CLA for https://github.com/OCamlPro/opam-builder/pull/27, and are other contributors expected to do the same?

Note also that the patch on OPAM used by opam-builder is not under AGPL, but already under OPAM's license.

I was referring to the copam library here: https://github.com/OCamlPro/opam-builder/tree/master/libs/copam
which appears to be a standalone library and not a patch under OPAM. I haven't looked closely or built the opam-builder sources myself due to the licensing concerns, however.

regards,
Anil

[Fabrice Le Fessant]

Post by Anil Madhavapeddy
That is correct, but how does this fit in with the request for
contributions that Gabriel issued? External contributors presumably need
to sign a CLA with OCamlPro to give them copyright retention over the
source code so that you can dual license it. Has Gabriel signed such a CLA
for https://github.com/OCamlPro/opam-builder/pull/27, and are other
contributors expected to do the same?

I don't understand the relationship between AGPL and the need for a CLA.
Many free-software or open-source projects make their contributors sign a
CLA (even Docker asks PRs to contain a sign-off), this is completely
unrelated to using AGPL, BSD, or whatever. By the way, I didn't need to ask
Gabriel to sign the CLA because his contribution, although significative by
its impact, is not significative by the number of lines.

--Fabrice

[Daniel Bünzli]

I don't understand the relationship between AGPL and the need for a CLA. Many free-software or open-source projects make their contributors sign a CLA (even Docker asks PRs to contain a sign-off),

I don't know what docker uses, but a linux sign-off (http://developercertificate.org/) is very very very different from the CLA companies usually try to make you sign (which tend to be quite unfair toward contributors)...

Daniel

[Fabrice Le Fessant]

Post by Daniel Bünzli
I don't know what docker uses, but a linux sign-off (
http://developercertificate.org/) is very very very different from the
CLA companies usually try to make you sign

Because they use BSD-like licenses, that allows them to redistribute your
code as their own under a proprietary license, so yes, they don't need to
ask for more (well, the Linux kernel is a different case as they use GPL
and keeps everything GPL).

Post by Daniel Bünzli
(which tend to be quite unfair toward contributors)...

Most of the CLAs I have seen recently (probably copied from the same
original one) are actually not so unfair, as they don't ask for the
ownership of the code, but just a license to use and relicense the code.
The only CLA I know that is different is the one used by the FSF, that is
done to allow them to sue for license enfringements on your code.

--Fabrice

[Daniel Bünzli]

Post by Daniel Bünzli
(which tend to be quite unfair toward contributors)...

Most of the CLAs I have seen recently (probably copied from the same original one) are actually not so unfair, as they don't ask for the ownership of the code, but just a license to use and relicense the code.

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. Please stop thinking we are idiots. We already had this discussion when you tried to introduce a CLA on OPAM, so I won't discuss this further.

Daniel

[Fabrice Le Fessant]

Post by Daniel Bünzli
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.

Post by Daniel Bünzli
Please stop thinking we are idiots.

These are your own thoughts, not mine.

Post by Daniel Bünzli
We already had this discussion when you tried to introduce a CLA on OPAM,
so I won't discuss this further.

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. Looking at the git logs in github.com/ocaml/opam, the number
of contributions have actually decreased since the license went more
liberal...

--Fabrice

[Daniel Bünzli]

Post by Daniel Bünzli
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

[Yaron Minsky]

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

Post by Daniel Bünzli

On Sat, Oct 1, 2016 at 4:05 AM Daniel BÃŒnzli <

Post by Daniel Bünzli
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
http://lists.ocaml.org/listinfo/platform

[Anil Madhavapeddy]

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

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

Post by Daniel Bünzli
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
http://lists.ocaml.org/listinfo/platform
_______________________________________________
Platform mailing list
http://lists.ocaml.org/listinfo/platform

[Yaron Minsky]

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.

y

Post by Anil Madhavapeddy
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

Post by Yaron Minsky
Perhaps at this point a pointer to Simon Peyton Jones' recent post on

respectful discourse is in order.

Post by Yaron Minsky
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.

Post by Yaron Minsky
y
On Sat, Oct 1, 2016 at 9:16 AM, Daniel BÃŒnzli <

On Sat, Oct 1, 2016 at 4:05 AM Daniel BÃŒnzli <

Post by Daniel Bünzli
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.

Post by Yaron Minsky

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.

Post by Yaron Minsky
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.

Post by Yaron Minsky

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.

Post by Yaron Minsky
1) The OPAM license wasn't changed in my sense, the bug of the license

was fixed.

Post by Yaron Minsky
2) I never said it would increase the number of contributions. I said

that CLAs were barriers to contribution [1].

Post by Yaron Minsky

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...

Post by Yaron Minsky
The license didn't go more liberal, the license had a bug which was

fixed so that it would correspond to the original intent.

Post by Yaron Minsky
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.

Post by Yaron Minsky
Daniel
[1] http://lists.ocaml.org/pipermail/opam-devel/2016-January/001291.html
_______________________________________________
Platform mailing list
http://lists.ocaml.org/listinfo/platform
_______________________________________________
Platform mailing list
http://lists.ocaml.org/listinfo/platform

[Anil Madhavapeddy]

Post by Anil Madhavapeddy
That is correct, but how does this fit in with the request for contributions that Gabriel issued? External contributors presumably need to sign a CLA with OCamlPro to give them copyright retention over the source code so that you can dual license it. Has Gabriel signed such a CLA for https://github.com/OCamlPro/opam-builder/pull/27, and are other contributors expected to do the same?
I don't understand the relationship between AGPL and the need for a CLA. Many free-software or open-source projects make their contributors sign a CLA (even Docker asks PRs to contain a sign-off), this is completely unrelated to using AGPL, BSD, or whatever.
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,

but this dual-licensing only holds as long as only OCamlPro employees (who presumably license their IPR to the company) are the sole contributors. Otherwise patches will come in under the license that the original source code was published under (AGPLv3) and cannot be relicensed without agreement of all the contributors. This is a similar process to the one we embarked on for opam-repository ages ago (CC0) and opam itself recently (LGPLv2+exception).

Post by Anil Madhavapeddy
By the way, I didn't need to ask Gabriel to sign the CLA because his contribution, although significative by its impact, is not significative by the number of lines.

I'm afraid I don't understand the legal subtleties here. I'd be grateful if someone could point me to a guide that explains who judges the threshold of the lines of code required before the patch becomes significant. And what happens if the patch contributor disagrees. Dual licensing seems complex enough that the contributors should be aware of it...

regards,
Anil