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

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

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

Regards,
Florian Schulze