On Mon, Jun 11, 2012 at 7:57 AM, Chad Perrin <per...@apotheon.com> wrote:
> These are generally exceptional cases that require either copyright > assignment or carefully controlled maintenance of contribution records > and continued contact with contributors. In cases where contributions to > the downstream copyleft project are accepted from all comers (within > reason) without a lot of bookkeeping -- as is the case with many open > source projects -- the ability to contribute substantial code from the > downstream copyleft project to the upstream copyfree project starts > evaporating, not only because it may be difficult to get people to > consent to their code being contributed to a copyfree licensed project > when they intended it for a copyleft project, but also because the > project maintainers may not have any easy way to identify and contact all > the contributors with affected contributions in the first place. > > In many cases, it may even be difficult to track contributions > themselves, regardless of the contributors. > > Meanwhile, in proprietary downstream projects, there is a single > copyright holder, almost by definition. This entire problem of trying to > figure out whether you have the legal "right" to contribute to upstream > pretty much doesn't exist. I think this is an important point. When we look at a project like PostgreSQL for example, you have proprietary vendors like Green Plum and EnterpriseDB who contribute a *lot* of code back to the common project. This is pretty typical with BSD-licensed projects as a whole. Once you start having a GPL'd off-shoot then you have problems getting the same level of contribution back to the BSD-licensed original. This is an important concern and it's something a lot of people just kind of glide over but as someone who has worked with projects under both licenses I will say clearly that it's easier to get a proprietary project to make contributions back to a BSD-licensed project than it is to get a GPL'd project to do the same. True there are always cases where a vendor starts with a BSD codebase and runs their own direction with it without contirbuting back. In the PostgreSQL world, I guess the primary examples that come to mind are Informix and Vertica. However these are usually only successful when either the approach is so different that code sharing is not helpful or the project is sufficiently immature to make it helpful to just run one's own direction. In general though the cost to the developer is that they bear the fll cost of integrating new features from the BSD version, and almost always this creates a heavy incentive to contribute back. Best Wishes, Chris Travers > > >> >> Permissive licensing implies right to create derivatives under licences >> you don't like and reuse in ways you don't approve of, because that's >> somebody else's property (derivative of yours, but needing to satisfy >> only your minimal conditions), and some guy actually read your licence, >> correctly understood its permissive nature, and acted accordingly. > > Ben Tilly appeared to be addressing more than this simple legal status of > copyfree licenses and other "permissive" licenses. > > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] > _______________________________________________ > License-discuss mailing list > License-discuss@opensource.org > http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss _______________________________________________ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss