On Apr 6, 2009, at 2:38 PM, Stephen John Smoogen wrote: > > On Mon, Apr 6, 2009 at 1:15 PM, Luke Kanies <l...@madstop.com> wrote: >> >> Hi all, >> >> I fear this discussion will quickly devolve into a recursive flame- >> fest, but it needs to be broached, so here we go. Note that I kind >> of >> think this is more of dev topic than users, but I want to make sure >> everyone knows the conversation is happening and can easily >> participate. This is also likely to be the first of a series of >> conversations I'll be starting to try to paper over the lack of >> organization and process we've had in the past. >> > > Hi I am cutting down a lot of stuff to try and put my comments into a > concise format: > >> 1) Should we use a completely open Apache-style license, or a >> reciprocal/viral GPL-style license? >> 2) Should we require copyright assignment of any kind? >> >> Going with those questions, we have two priorities: >> >> 1) Maximize ability to grow and sustain a community >> 2) Enable Reductive Labs to increase its funding of development >> >> Fundamentally, I see three basic choices: >> >> 1) Leave them like they are. No copyright assignment, no real >> copyright maintenance, GPL2 or later. This means that every >> contributor ever must give permission for things like license >> changes, >> we can't easily protect against license infringement >> (http://www.gnu.org/licenses/why-assign.html >> ), no one can ever dual license, and essentially no commercial >> software can ever be produced that integrates with Puppet. >> >> 2) Stick to a viral/reciprocal license (probably AGPLv3) but require >> Sun-style copyright contribution (which provides the project a non- >> exclusive license to the copyright). This provides a single >> organization with a license for all copyright, and allows that >> license >> holder (Reductive Labs) to protect against license infringement, >> provide patent indemnity (which I've already been asked about by >> others but cannot currently offer), relicense Puppet (and produce >> commercial software that integrates with that relicensed product), >> and probably more. >> >> 3) Switch to a non-reciprocal license (e.g., Apache) and don't >> require >> copyright coassignment. This allows anyone to do anything with the >> code, so there's no real concern about license infringement and >> anyone >> can make commercial add-ons. This is both good and bad, though, in >> that even those with no commitment to Puppet's community could build >> commercial products on it, which I think is not so great. > > OK with any licensing issue.. you need to have a lawyer's advice on > things :/. They will be able to give the best advice on whether a re > licensing can be done and what the best ways of doing so will be. The > method I have seen for anyone changing from 1 to 2/3 is that they > either required everyone to sign on the commit list or rewrite from > scratch and get FSF/Sun style copyright contributions going (or some > combination of the two.)
Yep, I'm already working with a lawyer, so I have a good idea of what any conversion will take (exactly as you say - every committer will need to sign off, or his/her work will need to be redone). This will be expensive time-wise, but I think all significant contributors are still around and have no problems signing off (I've asked around already). > >> After spending the last month thinking about it, and talking with >> many >> people (e.g., Tarus Balog, Matt Asay, Marten Mickos, Mark Radcliffe, >> and many more), I think #2 is the best option. It provides the best >> combination of openness for the community and opportunity for >> Reductive Labs. It hurts to say this, because I've always thought >> copyright assignment was evil, but I've been convinced otherwise, >> mostly by the links above and conversation with Tarus of OpenNMS. >> >> The problem I have with #1 is that is explicitly limits Puppet's >> ability to integrate with other commercial software, which I think is >> unfortunate and makes it hard to build Puppet into an ecosystem, >> rather than just being a stand-alone tool. The problem I have with >> #3 >> is that I have a hard time seeing how Reductive Labs can add more >> programmers to the project with it. >> >> What do you think? > > The one other issue you will need to do is craft what the license you > use to sell for people to incorporate puppet into a non-GPL product. I > believe a couple of companies have been screwed by selling a version > to some company under a 'closed' license and then seeing that the > other company uses that code to compete against the first company. > Again get a software lawyer well versed in contract law to draft an > appropriate one where A) they can't take improvements from the GPL > version and pull it into their license, and B) product improvements > that are made for them can be 'Freed' at some definite point in the > future (as in now to 6 months from the date they are made.). Yeah, this license would certainly be picked carefully, again with advice from a lawyer with significant experience in this space. Any improvements for them would be handled on a per-contract basis, but I'll certainly always push to have everything open-sourced right away. -- Life is too short for traffic. --Dan Bellack --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
