On Apr 6, 2009, at 4:37 PM, David Lutterkort wrote: > > 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 ;)
Indeed. > >> 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. I sometimes feel like it's pretty viral, but I understand your point - the term is more hyperbolic than informative. I'll drop it. > >> 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. I don't actually know how we'll increase revenue based on these licensing changes; this discussion is driven by our lack of clarity rather than revenue goals, I just want to make sure that the company is out there as part of my input when discussing it. I think there are valid revenue models around all options I outlined, but I think they're most obvious and most common around a gpl that allows relicensing. That combines maximum freeness for the community while allowing the main company behind the product a bit more flexibility, along with a push for some usages of the product to encourage a relicensing. > > 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. I've tried this a bit, and I seem to have set completely unrealistic expectations by providing such good free support for a few years. :/ I believe, to be crude, that many have taken my attempts to get paid for development as a "fuck you pay me" attitude (yeah, that's a quote). As is probably obvious, I've scaled back my free online support and my attempts at fixing every bug ever, but a certain amount is still required all around to make sure the community has the information it needs and the product is stable. It's true that I could step back even further and really only do development I got paid for, but the truth is that I have *much* bigger goals for Puppet and the tools around it, and I'm not content to sit on the product as it is now. Dashboards and a module site are big priorities this year, but there's other really interesting stuff to do in the Puppet core, too. >> 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. Yep, that's already come up in off-list discussions, and I knew it would be a big deal. > > 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. I'm not sure I'm comfortable with that, but I don't have good reasons. I don't know much about the organization, and the majority of my impression of it comes from my own personal experience with Stallman, along with some other second-hand (by many parties) stories of behaviour I'm not a fan of. > >> 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. I will be quite surprised if there isn't some kind of hosted puppetmaster service at some point, and I'd like people who make those to contribute their code back. > > 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. Yep. That's an option, but it seems kind of not-quite-here-or-there. It might be the best option in the end, though. > >> 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) That's true, and my initial thought was "wtf? no way!". I've been talking to lawyers about this, and apparently a far larger group of people than you'd expect demand this. The most indemnity I could ever provide is the amount that a customer paid me, but yeah, this is a nasty situation all around. > >> 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. That seems to be the majority view so far, but there are still plenty of concerns about the copyright aspects. -- However beautiful the strategy, you should occasionally look at the results. -- Sir Winston Churchill --------------------------------------------------------------------- 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 -~----------~----~----~----~------~----~------~--~---
