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

>>> The contract is described here: http://rfc.zeromq.org/spec:22
>>
>> 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.

The first thing I see in the above link is the License which directly 
refers to the GPL.

>>> 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
> mis-behaviours.
>
> In particular wrt value judgments.
>
> would it help if i created a more detailed blog post about my 
> findings?

The point about value judgments might be right. But just merging every 
pull request without review just creates more work. Personally in my 
projects, I look at test outcomes and do a quick review of what is being 
done. Based on that I decide whether I merge and just fix any problems 
myself, or whether I ask for a followup.

Regards,
Florian Schulze