On Tue, May 28, 2013 at 6:50 AM, Laurens Van Houtven <_...@lvh.io> wrote:
> > On May 28, 2013 12:39 PM, "Richard Hipp" <d...@sqlite.org> wrote: > > There is a "pending review" branch ( > http://www.fossil-scm.org/fossil/timeline?c=pending-review&y=ci) on the > Fossil self-hosting repository now! > > I'm not sure I understand the workflow here. It seems the branch name > itself is "pending-review". Where do I start writing code? How do I submit > it for review? How does code get reviewed? > Fossil follows a BSD-style of code development, rather than a GPL-style. Have you ever considered the difference between these two licenses? One way to think of the difference is that BSD is easier on readers and that GPL is easier on writers. With the GPL, you must agree to contribute back in change you make as a precondition for reading the code. This make GPL a great license for software that is built up incrementally by anonymous passers-by on the internet. There are no pesky and burdensome licenses to deal with. Anybody can submit a patch, without unnecessary paperwork, because by the act of reading the code they have implicitly licensed their changes to the world. The BSD-style licenses (and I use BSD in this discussion only as an archetype - most open-sources licenses work like BSD - GPL is the only real outliers) do not place any restrictions on readers. You can download and use BSD-licensed code with no preconditions and no restrictions. You do not have to contribute any changes you make back to the public. That makes BSD easier for readers to deal with. But it means that before you can contribute back changes to a BSD-licensed project, you need to execute some paperwork to certify that you are releasing those changes under the same BSD-style license. This makes BSD more of a hassle for writers. Note that no paperwork is required to contribute to a GPL-licensed project because the contributor has implicitly consented to the license by the act of reading the code. In the case of Fossil we require all potential contributors to print and sign a Contributor License Agreement (CLA). The CLA is just an affidavit from the contributor saying that the contributions are covered by the same BSD license as the rest of the code. The CLA is needed to help ensure that nobody contributes changes to the project, then later comes back and tries to claim royalty rights on the code. Fossil's CLA can be seen at http://www.fossil-scm.org/fossil/doc/trunk/www/copyright-release.pdf I have signed copies of CLAs from all Fossil contributor in a file folder in the fire safe at my office. As it happens, I also use the CLA process to vet developers. I only turn on the ability to push changes to the canonical Fossil repository for people who have proven their ability to write good code. Typically, this "proof" consists of submitting some patches either directly to me, or by posting on this mailing list. Another way of looking at it: I place more emphasis on reviewing coders than on reviewing code. D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
