On Mon, 2009-04-06 at 14:15 -0500, Luke Kanies wrote: > I fear this discussion will quickly devolve into a recursive flame- > fest
Here we go ;) > 1) Should we use a completely open Apache-style license, or a > reciprocal/viral GPL-style license? I would prefer if you dropped the word 'viral' in there - feels like a strange (though popular) value judgment. > 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 Laudable and understandable goals. > This second point is important to be obvious about - like Pixar > (http://www.nytimes.com/2009/04/06/business/media/06pixar.html > ), we make money so we can write software, and Puppet clearly needs > more development time than we're spending on it right now. There are > further tools beyond Puppet that we also want to create, but we need > enough developer manpower to be able to do so. I am not sure if this is what you are getting at, but if you are thinking about some sort of proprietary/open split (ala ghostscript), you need to carefully weigh the increase in revenue against both turning off potential contributors and the lack of bug reports from the open version. I would only even consider this if you have solid data that you could increase your revenue this way. (And I don't want to put you on the spot here - don't feel like you have to respond to this paragraph) As with any open source project, the big issue here are the people who like the software enough to run it when it's free but not pay for the support contract. Make sure that you have solid data that you can get some of those to pay in whatever model you look at. Have you considered being more agressive about doing only development you are being paid for. I find the expectation that you help chase down and fix bugs from people who have deployed puppet but are not willing to buy support entirely unrealistic - you wouldn't dream asking for something similar from your car mechanic. > 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, Copyright assignment is an interesting point in this - being able to deal with license infringement would be an important aspect. I think it's only workable if the software is under an extremely open license (GPL). It also increases the burden to contribute quite a bit; while a lot of employers won't mind sending the occasional patch to a mailing list, getting copyright assignment papers signed is a serious headache. If you want to go with copyright assignment, you should explore if there's any way to turn puppet into an FSF project, since a lot of people trust them to do the right thing, and have umbrella agreements in place with them. > 2) Stick to a viral/reciprocal license (probably AGPLv3) but require I don't understand why the AGPL is of interest here - I was under the impression that it was meant fo online services a la Google Apps. Have you considered switching to the LGPL ? IANAL, but the idea that you can 'link' from proprietary software to the open software might leave enough room for you to write custom providers etc. for hire and keep them closed for a while. > provide patent indemnity (which I've already been asked about by > others but cannot currently offer), Strange - without knowing anything about your balance sheet, RL doesn't have the resources to fight a patent suit, and not really anything else that would make RL an attractive target for such a suit. By offering indemnity, you'd make yourself a proxy in a fight between the big boys (one being your client, and the other not) > 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? I am also much in favor of #2. I can see that relicensing as LGPL might make some sense. David --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
