[pytest-dev] [Proposal] adapting the Collective Code Construction Contract (which includes a switch to a weak share-alike license and limits branching models)

Ronny Pfannschmidt opensource at ronnypfannschmidt.de
Mon Feb 15 08:30:25 EST 2016


please see below

Am 15.02.2016 um 09:38 schrieb Florian Schulze:
>> in the last few weeks i researched the topic of Code of Conducts,
>> i found many of them lacking, however the zeromq model strikes me as
>> something designed much better
>> The contract is described here: http://rfc.zeromq.org/spec:22
>> A first point in that contract does look like a problem,
>> which is the insistence on a share-alike license.
>> After a reading i am under the strong impression that the MPL is
>> perfectly fine for the purposes and usage of py.test,
>> the main question is if our direct users (and/or their managers/law
>> experts)
>> can be helped to arrive at that conclusion as well.
> I just recently learned that viral licenses like GPL can be a huge
> pain. They also did a lot of good though, allowing us to still have
> free choice of software on most routers for example. But especially
> for things like py.test, companies tend to avoid contributing or
> extending for understandable reasons. A very permissive license is
> much better for that imo.

my understanding is, MPL is non-viral, it does not infect other code, it
only applies to the code itself and vendor-ed copies.
in Fact its per design even weaker than LGPL, since it allows inclusion
without viral extension.
>> A second point that does look problematic is the limitation in branching
>> models,
>> however after poking Pieter Hintjens on the reason he promptly
>> pointed me to
>> http://zguide.zeromq.org/page:all#Git-Branches-Considered-Harmful
> This is the only thing I agree with, feature branches belong to forks.
> The main repository should only contain released and agreed on
> upcoming stuff.
>> http://hintjens.com/blog:106
>> I found myself agreeing with those 2 items, as well as a lot of the
>> followup of the zguide.
> I don't like this approach at all.
can you pinpoint what about the approach strikes you?
i find it practical, since upon reflection i realized it pretty
much works effectively against various of my own biases/mistakes and

In particular wrt value judgments.

would it help if i created a more detailed blog post about my findings?

Regards, Ronny

> Regards,
> Florian Schulze

More information about the pytest-dev mailing list