[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 at gmx.net
Mon Feb 15 11:45:05 EST 2016
>>> 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,
> only applies to the code itself and vendor-ed copies.
> in Fact its per design even weaker than LGPL, since it allows
> without viral extension.
The first thing I see in the above link is the License which directly
refers to the GPL.
>>> 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
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.
More information about the pytest-dev