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. First, I want to be clear that this is me seeking your input - we haven''t decided on anything, and I''m starting this thread so we have the necessary data to make a decision. We have to be conscious that Reductive Labs is a commercial company, though. My development of Puppet and the money I make around it feeds my family and keeps us housed, allowing me to focus on it full time. I think our focus on building community stands on its own, but the contributor list is an equally clear indication that being paid to work on Puppet results in a lot more work being done on Puppet - of the top ten Puppet contributors (http://www.ohloh.net/p/puppet/contributors ), 5 have been paid by their companies to do the work, and 4 have been paid specifically by Reductive Labs (me, Andrew, Rick, and Ben/ajax). One of my goals in this discussion is to figure out the best way to pay more people to work on Puppet, by having enough money to hire them. (Incidentally, I should be posting a job description for a full- time programmer at Reductive Labs this week.) Finally, if you have concerns about this topic that you don''t feel comfortable voicing publicly, feel free to contact me directly. So: We''ve never done a very good job of having much of a licensing or copyright strategy for Puppet and the tools around it. While all of the projects have a license, there''s no documentation on how to maintain the license (e.g., whether every file should have a license header), and there''s a bit of confusion around the license itself since Puppet''s current license file says ''GPL2 or later''. As to copyright, we''re *pretty* good at maintaining that, especially since we switched to Git, since everyone who commits has their email address recorded with the commit, but we don''t have an official project policy published anywhere one way or another, and we just haven''t been tracking copyright. For both the project and my company, I think we need to develop complete policies around these two topics, and then spend time actually maintaining them. Given that we have a license but no policies or history around it, I think it''s worth revisiting the basics, and assessing what''s best for the project. I expect that Reductive Labs would fund any work that needs to be done to enact these policies, but as always, I''ll do what I can to encourage community involvement. I think there are essentially two decisions to make, with some details around them: 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 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 expect this point to be the biggest source of contention, so all I can really say is, Reductive Labs isn''t suddenly morphing into an anti- community commercial vendor who uses open source for marketing but doesn''t actually believe in it. I''m asking *you*, right now, how we can tune our licensing and copyright policy to best meet your needs. If that doesn''t satisfy you, I''ll be glad to fly out and discuss it with you for $5,000 USD per day. :) Really, though, one of my other goals here is to be more transparent about how Reductive Labs hopes to make money and continue funding development. Many people in the community are curious on this front for many reasons, and I think it''s important it be clear. Here is some reading on this subject, to kind of set the context: http://madstop.com/2009/02/28/the-most-freetm-way-to-make-money-from-open-source/ (This article came out much more in favor than Open Core than it was supposed to; the article was supposed to be a question, rather than an answer.) http://blogs.the451group.com/opensource/2009/03/24/transparency-the-first-step-towards-open-source-participation-for-proprietary-vendors/ http://blogs.the451group.com/opensource/2009/04/06/on-the-importance-of-copyright-assignment/ http://www.knowledgetree.com/blog/company-driven-open-source-communities-copyright-assignment 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. 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? -- It is said that power corrupts, but actually it''s more true that power attracts the corruptible. The sane are usually attracted by other things than power. -- David Brin --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, Apr 6, 2009 at 1:15 PM, Luke Kanies <luke@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.)> 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.). -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, 6 Apr 2009, Luke Kanies wrote:> 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.I think a lot of it depends on your goals. Clearly long term #1 does not work. It provides a big mess for you and puts in you a boat of only ever really being able to sell support. I feel option number 2 will further limit the number of people willing to contribute code. Especially if you plan to sell it commercially later. For instance, at my employer here I could contribute some code (and as I bone up on Ruby I may even attempt to, even if it''s only some types and stuff at first). However, it gets a lot stickier contributing back if the I''m contributing code that you may be selling. Conflict and all. I must admit I''m a fan of the Apache license or a BSD license of some sort. It gives you the right to sell it while also remaining open. It also means that I don''t have to have a copyright laywer on staff to modify your code and use it locally :) Jason -- Jason Slagle - RHCE /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Luke Kanies wrote:> 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 licenseI think this kind of license is eminently fair: the sponsoring organization, which pays for most of the development, gets the (essentially exclusive) right to productize it, while others can use the open product at no cost (or buy something from the company, of course), but can''t productize it. However, while fair, I think this ends to lead to business models that are relatively unappealing to both customers and potential contributors. Contributing to projects licensed thusly feels like offering free labor to a commercial enterprise, rather than to a community. I don''t have any better idea to propose, though. We all need to make a living. -- Kyle Cordes http://kylecordes.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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Luke Kanies <luke@madstop.com> writes:> 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.AGPL is a little controversial, to warn. So far, I think it''s likely that organizations such as Debian will continue to consider it sufficiently free, but it''s a bit odd in its requirements and depending on how one reads it, some people think that it''s onerous for a developer who wanted to make private modifications. I''m not sure it''s a big enough problem to warrant not using it, but it''s something to be aware of. It makes people more nervous than the GPL does. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, Apr 06, 2009 at 02:15:44PM -0500, Luke Kanies wrote:> I think there are essentially two decisions to make, with some > details around them: > > 1) Should we use a completely open Apache-style license, or a > reciprocal/viral GPL-style license?I''m not a big fan of viral-style in most cases; it seems like giving with one hand and slapping with the other. (Depends on the software, though; I don''t mind it for compilers, for example. I also don''t really want to get into it.) Having said that, I think either choice is extremely generous; I''d still contribute (not that I''ve contributed code yet) if it was "free to distribute but not modify", OSLT. This is your baby, I can''t imagine being bothered by what you choose to do with it as long as it''s still free for me with my 3 machines over here.> 2) Should we require copyright assignment of any kind?My limited understanding of the legal ramifications says that yes, you probably should. [snip]> 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.I agree that #2 seems best. I''m really shocked by the Chef project; it seems really offensive to me, and I''d like to see you guys go in a direction that stops someone from just rebundling Puppet and calling it theirs. -Robin -- They say: "The first AIs will be built by the military as weapons." And I''m thinking: "Does it even occur to you to try for something other than the default outcome?" -- http://shorl.com/tydruhedufogre http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, 2009-04-06 at 14:15 -0500, Luke Kanies wrote:> I fear this discussion will quickly devolve into a recursive flame- > festHere 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 developmentLaudable 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 requireI 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, 2009-04-06 at 16:03 -0400, Jason Slagle wrote:> I must admit I''m a fan of the Apache license or a BSD license of some > sort. It gives you the right to sell it while also remaining open. It > also means that I don''t have to have a copyright laywer on staff to modify > your code and use it locally :)You don''t need one with the (L)GPL either: as long as you don''t distribute your modifications, you can keep everything you do to yourself. And when you distribute, your obligations are only to those that receive a modified version of the software, not the public at large. For example, it''s perfectly legal for Luke to modify the GPL''d puppet source for a client and give that only to that client - all he is obliged to do is to give the sources to whatever he changed to them and allow _them_ to pass that on. If that client chooses not to redistribute, that''s the end of the story - it has to be a choice though, Luke can''t require ''no further distribution'' from his clients. Having to distribute the sources of your modifications is kinda moot with Ruby anyway - it would be much harder not to. 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, Apr 6, 2009 at 12:15 PM, Luke Kanies <luke@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. > > First, I want to be clear that this is me seeking your input - we > haven''t decided on anything, and I''m starting this thread so we have > the necessary data to make a decision. We have to be conscious that > Reductive Labs is a commercial company, though. My development of > Puppet and the money I make around it feeds my family and keeps us > housed, allowing me to focus on it full time. > > I think our focus on building community stands on its own, but the > contributor list is an equally clear indication that being paid to > work on Puppet results in a lot more work being done on Puppet - of > the top ten Puppet contributors (http://www.ohloh.net/p/puppet/contributors > ), 5 have been paid by their companies to do the work, and 4 have been > paid specifically by Reductive Labs (me, Andrew, Rick, and Ben/ajax). > One of my goals in this discussion is to figure out the best way to > pay more people to work on Puppet, by having enough money to hire > them. (Incidentally, I should be posting a job description for a full- > time programmer at Reductive Labs this week.) > > Finally, if you have concerns about this topic that you don''t feel > comfortable voicing publicly, feel free to contact me directly. > > So: > > We''ve never done a very good job of having much of a licensing or > copyright strategy for Puppet and the tools around it. While all of > the projects have a license, there''s no documentation on how to > maintain the license (e.g., whether every file should have a license > header), and there''s a bit of confusion around the license itself > since Puppet''s current license file says ''GPL2 or later''. > > As to copyright, we''re *pretty* good at maintaining that, especially > since we switched to Git, since everyone who commits has their email > address recorded with the commit, but we don''t have an official > project policy published anywhere one way or another, and we just > haven''t been tracking copyright. > > For both the project and my company, I think we need to develop > complete policies around these two topics, and then spend time > actually maintaining them. > > Given that we have a license but no policies or history around it, I > think it''s worth revisiting the basics, and assessing what''s best for > the project. I expect that Reductive Labs would fund any work that > needs to be done to enact these policies, but as always, I''ll do what > I can to encourage community involvement. > > I think there are essentially two decisions to make, with some details > around them: > > 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 > > 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 expect this point to be the biggest source of contention, so all I > can really say is, Reductive Labs isn''t suddenly morphing into an anti- > community commercial vendor who uses open source for marketing but > doesn''t actually believe in it. I''m asking *you*, right now, how we > can tune our licensing and copyright policy to best meet your needs. > If that doesn''t satisfy you, I''ll be glad to fly out and discuss it > with you for $5,000 USD per day. :) > > Really, though, one of my other goals here is to be more transparent > about how Reductive Labs hopes to make money and continue funding > development. Many people in the community are curious on this front > for many reasons, and I think it''s important it be clear. > > Here is some reading on this subject, to kind of set the context: > > http://madstop.com/2009/02/28/the-most-freetm-way-to-make-money-from-open-source/ > (This article came out much more in favor than Open Core than it was > supposed to; the article was supposed to be a question, rather than an > answer.) > > http://blogs.the451group.com/opensource/2009/03/24/transparency-the-first-step-towards-open-source-participation-for-proprietary-vendors/ > > http://blogs.the451group.com/opensource/2009/04/06/on-the-importance-of-copyright-assignment/ > > http://www.knowledgetree.com/blog/company-driven-open-source-communities-copyright-assignment > > 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. > > 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?I wish I knew more about the issues at hand. I know that my existing knowledge as well as my intuition leads me to agree that option #2 is best for Reductive Labs and the Puppet community as a whole. On the other hand, I also know that the copyright assignment thing is going to make it more difficult for me to make contributions. Although I''m not a big contributor, I do have permission to spend time writing code for Puppet -- as long as that process only impacts my department, I''m likely to keep getting permission. Unfortunately, copyright assignment involves the legal branch of our company, who are typically clueless corporate-whore lawyers. Once they have to get involved, it is going to get ugly. I think other people at startups might face similar barriers to contribution. Thanks for keeping this process open, Luke, I hope people give you the credit you deserve for your efforts to make Reductive Labs be a community member rather than a corporate dictator. --Paul --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Paul Lathrop wrote:> best for Reductive Labs and the Puppet community as a whole. On the > other hand, I also know that the copyright assignment thing is going > to make it more difficult for me to make contributions. Although I''mMy impression is that the bulk of projects that use a commercial-open-source model, regardless of the licensing, generally end up with very few outside contributors anyway. I wish it weren''t so, but I suspect it is. -- Kyle Cordes http://kylecordes.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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, Apr 06, 2009 at 05:15:38PM -0500, Kyle Cordes wrote:> > Paul Lathrop wrote: > > best for Reductive Labs and the Puppet community as a whole. On > > the other hand, I also know that the copyright assignment thing > > is going to make it more difficult for me to make contributions. > > Although I''m > > My impression is that the bulk of projects that use a > commercial-open-source model, regardless of the licensing, > generally end up with very few outside contributors anyway. I > wish it weren''t so, but I suspect it is.I''ll take it a few steps further: the bulk of projects end up with very few contributors. You can talk about the bazaar all you want, but the truth is that almost all software is written almost entirely by a small oligarchy at most. Hence my being happy with pretty much anything Luke chooses on this front. -Robin -- They say: "The first AIs will be built by the military as weapons." And I''m thinking: "Does it even occur to you to try for something other than the default outcome?" -- http://shorl.com/tydruhedufogre http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
I''ve been using Puppet for a month or two, and plan to keep on using it. I would imagine that as long as there is a not-stagnant community, bugs are being fixed regularly, it is included as part of the distributions I use, and nothing comes along that is a lot better, I''ll keep using it. But the chances are relatively slim that I''ll ever contribute any code back. I''ll always try to file a good bug report or answer questions when they come up. But if I''m paying for support, then all bets are off. If I were paying for support (and with 10 linux machines and relatively simple needs, its unlikely that I would pay for support) all bets are off - I''m not filing any bug reports or helping anybody else. I don''t know how many people would stop contributing if they had to assign their copyrights to Reductive Labs. But that requirement wouldn''t stop me. Like Robin mentioned, I would guess over time the number of contributors stays relatively small. If you think about the Mythical Man Month, the number of contributors is always going to be small - just like the percentage of people in an operating room who are surgeons is relatively small. There are lots of non-code tasks that are part of software development. And just for the record, if there was a version of Puppet that worked on Windows clients, I probably would want some sort of support contract for about 100 machines. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 6, 2009, at 2:38 PM, Stephen John Smoogen wrote:> > On Mon, Apr 6, 2009 at 1:15 PM, Luke Kanies <luke@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 6, 2009, at 3:03 PM, Jason Slagle wrote:> > On Mon, 6 Apr 2009, Luke Kanies wrote: > >> 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. > > I think a lot of it depends on your goals. > > Clearly long term #1 does not work. It provides a big mess for you > and > puts in you a boat of only ever really being able to sell support. > > I feel option number 2 will further limit the number of people > willing to > contribute code. Especially if you plan to sell it commercially > later. > For instance, at my employer here I could contribute some code (and > as I > bone up on Ruby I may even attempt to, even if it''s only some types > and > stuff at first). However, it gets a lot stickier contributing back > if the > I''m contributing code that you may be selling. Conflict and all.Can you elaborate on what you think the problems will be? I don''t see how a conflict could develop.> > I must admit I''m a fan of the Apache license or a BSD license of some > sort. It gives you the right to sell it while also remaining open. > It > also means that I don''t have to have a copyright laywer on staff to > modify > your code and use it locally :)Well, you wouldn''t need a copyright lawyer if you bought a license from us. I think that''s part of the reason for supporting dual licensing - if this is something that concerns your company, then you can solve it by paying a bit. If you stay all open source, no problems. I''m not saying this is what I would do, but that it is the natural consequence of choosing a GPL-like license. -- I love deadlines. I like the whooshing sound they make as they fly by. --Douglas Adams --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 6, 2009, at 3:08 PM, Kyle Cordes wrote:> > Luke Kanies wrote: > >> 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 > > I think this kind of license is eminently fair: the sponsoring > organization, which pays for most of the development, gets the > (essentially exclusive) right to productize it, while others can use > the > open product at no cost (or buy something from the company, of > course), > but can''t productize it. > > However, while fair, I think this ends to lead to business models that > are relatively unappealing to both customers and potential > contributors. > Contributing to projects licensed thusly feels like offering free > labor > to a commercial enterprise, rather than to a community. > > I don''t have any better idea to propose, though. We all need to make a > living.I have the same kind of mixed feelings, and I''ve traditionally fallen on the side of "give it all away with no strings attached". Except, of course, the GPL attaches its own strings. I realized when looking into it that I almost definitely couldn''t release commercial add-ons to my own project if I wanted to, because I don''t own all of the copyright and it''s released under a reciprocal license. At some point, everything''s a compromise: Either you compromise the amount of free, or you compromise the ability to build a company around the produt. There aren''t a lot of open source projects out there in the infrastructure space that succeed without companies paying for the majority of development, so it seems pretty important to have a healthy company behind Puppet''s development. -- The most dangerous strategy is to jump a chasm in two leaps. -- Benjamin Disraeli --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 6, 2009, at 3:47 PM, Russ Allbery wrote:> > Luke Kanies <luke@madstop.com> writes: > >> 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. > > AGPL is a little controversial, to warn. So far, I think it''s > likely that > organizations such as Debian will continue to consider it sufficiently > free, but it''s a bit odd in its requirements and depending on how one > reads it, some people think that it''s onerous for a developer who > wanted > to make private modifications. > > I''m not sure it''s a big enough problem to warrant not using it, but > it''s > something to be aware of. It makes people more nervous than the GPL > does.I''ll keep that in mind. I don''t know license specifics; I was planning on leaving that up to the lawyerly discussions, given a general plan. -- Fallacies do not cease to be fallacies because they become fashions. --G. K. Chesterton --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 6, 2009, at 4:09 PM, Robin Lee Powell wrote:> > On Mon, Apr 06, 2009 at 02:15:44PM -0500, Luke Kanies wrote: >> I think there are essentially two decisions to make, with some >> details around them: >> >> 1) Should we use a completely open Apache-style license, or a >> reciprocal/viral GPL-style license? > > I''m not a big fan of viral-style in most cases; it seems like giving > with one hand and slapping with the other. (Depends on the > software, though; I don''t mind it for compilers, for example. I > also don''t really want to get into it.) > > Having said that, I think either choice is extremely generous; I''d > still contribute (not that I''ve contributed code yet) if it was > "free to distribute but not modify", OSLT. This is your baby, I > can''t imagine being bothered by what you choose to do with it as > long as it''s still free for me with my 3 machines over here.It''s true that this was my baby initially, and I''ve still got the vast majority of the commits (and probably an even larger share of the lines), but it''s becoming less true all the time, and I hope it becomes even less true over time. At the same time, I hope to have more room to do the long-term cool stuff I actually built Puppet to do, and that''s where I will hopefully be able to exert my influence beyond basic ability to churn out code.> >> 2) Should we require copyright assignment of any kind? > > My limited understanding of the legal ramifications says that yes, > you probably should.Yeah, the legal side seems to say yes, we''ll see if the community side will allow it.> > [snip] >> 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. > > I agree that #2 seems best. I''m really shocked by the Chef project; > it seems really offensive to me, and I''d like to see you guys go in > a direction that stops someone from just rebundling Puppet and > calling it theirs.To be clear here, Chef isn''t Puppet rebundled or anything; it takes a lot of Puppet''s obvious advancements, but it doesn''t share any code (and can''t, because we use the GPL2). Fortunately it doesn''t seem to include any of Puppet''s less obvious advancements, so... :) -- A conservative is a man who believes that nothing should be done for the first time. --Alfred E. Wiggam --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, 6 Apr 2009, Luke Kanies wrote:>> I feel option number 2 will further limit the number of people >> willing to >> contribute code. Especially if you plan to sell it commercially >> later. >> For instance, at my employer here I could contribute some code (and >> as I >> bone up on Ruby I may even attempt to, even if it''s only some types >> and >> stuff at first). However, it gets a lot stickier contributing back >> if the >> I''m contributing code that you may be selling. Conflict and all. > > Can you elaborate on what you think the problems will be? > > I don''t see how a conflict could develop.Sure.. While $employer doesn''t necessarily mind me contributing code to open source projects (As well as making donations which is something I''ll certainly look at once I finish my rollout), it becomes a lot more harry if I''m working on code on $company''s dime that your selling directly as a commercial product. You almost are forced to make a pretty hard split like some of the other projects where you have seperate sites and everything for the "community edition" and the commercial one. It can be done - I think mysql for instance does it fairly successfully. It''s just considerably trickier from a contribution standpoint.>> I must admit I''m a fan of the Apache license or a BSD license of some >> sort. It gives you the right to sell it while also remaining open. >> It >> also means that I don''t have to have a copyright laywer on staff to >> modify >> your code and use it locally :) > > Well, you wouldn''t need a copyright lawyer if you bought a license > from us. I think that''s part of the reason for supporting dual > licensing - if this is something that concerns your company, then you > can solve it by paying a bit. If you stay all open source, no problems. > > I''m not saying this is what I would do, but that it is the natural > consequence of choosing a GPL-like license.The AGPL is really scary with it''s section 13. It''s be even scarier to me if I was a company doing hosting and trying to use your product, because it''s a REALLY slipper scope when you deal with things like modules. LGPL is a little better. However, I think AGPL on a project like this that is very "programming" based is really a huge problem. Jason -- Jason Slagle - RHCE /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 6, 2009, at 4:59 PM, Paul Lathrop wrote:> I wish I knew more about the issues at hand. I know that my existing > knowledge as well as my intuition leads me to agree that option #2 is > best for Reductive Labs and the Puppet community as a whole. On the > other hand, I also know that the copyright assignment thing is going > to make it more difficult for me to make contributions. Although I''m > not a big contributor, I do have permission to spend time writing code > for Puppet -- as long as that process only impacts my department, I''m > likely to keep getting permission. Unfortunately, copyright assignment > involves the legal branch of our company, who are typically clueless > corporate-whore lawyers. Once they have to get involved, it is going > to get ugly. I think other people at startups might face similar > barriers to contribution.I expect you''re right, but I would hope to be able to invest time in helping to convince these lawyers. If I have to pay for a couple of hours'' time to convince a company''s lawyers to allow contribution here or there, it''s probably worth it. And after a few such conversations, I think our side could be carried on without lawyers, or we''ll have some on staff and won''t pay the hourly rates. Either way the lawyerly stuff comes up a lot more often than I''d like.> > Thanks for keeping this process open, Luke, I hope people give you the > credit you deserve for your efforts to make Reductive Labs be a > community member rather than a corporate dictator.Thanks, we try. :) -- Charm is a way of getting the answer yes without asking a clear question. -- Albert Camus --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 6, 2009, at 6:29 PM, Robin Lee Powell wrote:> > On Mon, Apr 06, 2009 at 05:15:38PM -0500, Kyle Cordes wrote: >> >> Paul Lathrop wrote: >>> best for Reductive Labs and the Puppet community as a whole. On >>> the other hand, I also know that the copyright assignment thing >>> is going to make it more difficult for me to make contributions. >>> Although I''m >> >> My impression is that the bulk of projects that use a >> commercial-open-source model, regardless of the licensing, >> generally end up with very few outside contributors anyway. I >> wish it weren''t so, but I suspect it is. > > I''ll take it a few steps further: the bulk of projects end up with > very few contributors. > > You can talk about the bazaar all you want, but the truth is that > almost all software is written almost entirely by a small oligarchy > at most. Hence my being happy with pretty much anything Luke > chooses on this front.This is a good point. The vast, vast majority of open source projects have a core set of people who do nearly all of the work, and the majority of projects also have most of their work done by people being paid to work on those projects. Just looking at the ohloh contribtors[1] makes it clear that it''s true for us, and once I have a couple more programmers on staff we''ll be contributing an even larger share of the commits. Of course, I''ll continue to be commited to an open development community, and I''ve already started pushing internal development conversations to the list, which has been a strange and difficult adjustment, for some reason. 1 - http://www.ohloh.net/projects/puppet/contributors -- To define recursion, we must first define recursion. --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 6, 2009, at 9:19 PM, Jason Slagle wrote:> > On Mon, 6 Apr 2009, Luke Kanies wrote: > >>> I feel option number 2 will further limit the number of people >>> willing to >>> contribute code. Especially if you plan to sell it commercially >>> later. >>> For instance, at my employer here I could contribute some code (and >>> as I >>> bone up on Ruby I may even attempt to, even if it''s only some types >>> and >>> stuff at first). However, it gets a lot stickier contributing back >>> if the >>> I''m contributing code that you may be selling. Conflict and all. >> >> Can you elaborate on what you think the problems will be? >> >> I don''t see how a conflict could develop. > > Sure.. > > While $employer doesn''t necessarily mind me contributing code to open > source projects (As well as making donations which is something I''ll > certainly look at once I finish my rollout), it becomes a lot more > harry > if I''m working on code on $company''s dime that your selling directly > as a > commercial product. > > You almost are forced to make a pretty hard split like some of the > other > projects where you have seperate sites and everything for the > "community > edition" and the commercial one.I wouldn''t have a community edition and a commercial edition. First, all contributions would be guaranteed to be open source, so I could never take someone''s open contribution and only include it in a commercial product. Second, I might have commercial add-ons, but one of my main reasons for thinking about this is that I adamantly don''t want to get into a situation where there''s anything like a commercial edition. That being said, I don''t want to rule out the possibility of some commercial add-ons that would only be useful in large or peculiar environments. Not opening up these could never be said to cripple the main project since most people would never use them anyway.> > It can be done - I think mysql for instance does it fairly > successfully. > It''s just considerably trickier from a contribution standpoint.They''ve basically set the standard, and I''d largely follow them. I had a conversation with their former CEO about exactly this, and his arguments were a big part of what got me thinking this way.>>> I must admit I''m a fan of the Apache license or a BSD license of >>> some >>> sort. It gives you the right to sell it while also remaining open. >>> It >>> also means that I don''t have to have a copyright laywer on staff to >>> modify >>> your code and use it locally :) >> >> Well, you wouldn''t need a copyright lawyer if you bought a license >> from us. I think that''s part of the reason for supporting dual >> licensing - if this is something that concerns your company, then you >> can solve it by paying a bit. If you stay all open source, no >> problems. >> >> I''m not saying this is what I would do, but that it is the natural >> consequence of choosing a GPL-like license. > > The AGPL is really scary with it''s section 13. > > It''s be even scarier to me if I was a company doing hosting and > trying to > use your product, because it''s a REALLY slipper scope when you deal > with > things like modules. > > LGPL is a little better. However, I think AGPL on a project like this > that is very "programming" based is really a huge problem.I see. I''ll make sure the final license choice is vetted thoroughly, and I''ll do my best to pick something relatively non-controversial. Or something. It''s all a pit of snakes, of course. -- Don''t hit at all if it is honorably possible to avoid hitting; but never hit soft! -- Theodore Roosevelt --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Luke Kanies wrote:> I think our focus on building community stands on its own, but the > contributor list is an equally clear indication that being paid to > work on Puppet results in a lot more work being done on Puppet - of > the top ten Puppet contributors (http://www.ohloh.net/p/puppet/contributors > ), 5 have been paid by their companies to do the work, and 4 have been > paid specifically by Reductive Labs (me, Andrew, Rick, and Ben/ajax). > One of my goals in this discussion is to figure out the best way to > pay more people to work on Puppet, by having enough money to hire > them. (Incidentally, I should be posting a job description for a full- > time programmer at Reductive Labs this week.)So I''ll put my ten cents in as the remaining member of the ten. To be clear I am completely unpaid for my work on the project by my employer or Reductive Labs. Though Luke does buy drinks sometimes. Excuse any rambling I am typing this whilst on holidays in Thailand on the end of some shaky connections. *big snips*> 1) Should we use a completely open Apache-style license, or a > reciprocal/viral GPL-style license?I have concerns over the use of the word ''viral'' as a value judgement but okay...> 2) Should we require copyright assignment of any kind?Fundamentally think that''s a good summary.> 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 developmentIt should be clear here that under certain models these could be mutually exclusive.> I expect this point to be the biggest source of contention, so all I > can really say is, Reductive Labs isn''t suddenly morphing into an anti- > community commercial vendor who uses open source for marketing but > doesn''t actually believe in it. I''m asking *you*, right now, how we > can tune our licensing and copyright policy to best meet your needs. > If that doesn''t satisfy you, I''ll be glad to fly out and discuss it > with you for $5,000 USD per day. :)I have no issues with you needing to eat and to be honest I''ve always thought you were way too generous with your time on "non-core" activities and especially to people who a) lack manners and b) treat the community as if they were paying support.> 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.I have no issues with a GPLv2/3 style license but I appreciate the reasons why it might not work.> 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.I have no issues with an AGPLv3 license but obviously see issues with 1. I personally probably wouldn''t be able to contribute to the community in this instance. It would be quite difficult for me professionally to sign a Sun-style SCA/copyright contribution license.> 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.This is my preference but again understand the challenges. I do wonder how many people would be potentially building commercial products from Puppet currently - though I can understand the potential future threat.> What do you think?I find myself in broad agreement with David Lutterkort on most of the issues in this discussion. Though, personally, I don''t much care which license is used - LGPL seems to be attractive, (A)GPLv3, even BSDv2 - all of which suit me fine to varying degrees of "fine". Dual licenses also seem a reasonable approach to me (though all these models all require copyright assignment of some kind - see below). The copyright assignment I find myself conflicted about. I think there would need to be a compelling commercial reason to do this. I obviously want to see Reductive and Puppet flourish - and if this requires that an SCA/copyright assignment of some kind takes place then so be it. I think it''d limit the potential contributions to the community - including mine. I also think a lot of casual bug/patch submitters won''t bother if they have to sign an agreement - especially if, like me, it requires dealing with corporate legal people. I suspect that some of the "paid" corporate contributors are also going to have issues with this. Regards James Turnbull - -- Author of: * Pro Linux Systems Administration (http://www.amazon.com/gp/product/1430219122/) * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ2sIj9hTGvAxC30ARAnfiAJ9sPzevOWO6L4uJL+fya46JYWLI2wCeLv8P AKnvxtnqVeTDrFt8kPDcsdw=Jlmd -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Luke Kanies wrote:> 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 stillThere is dangerous territory nearby: Paying customers have a higher expectation of a smooth out-of-box-experience, than open source users; to make this happen it is necessary to debug vigorously. However, open source users tend to chafe at the thought of a "community" version intentionally left buggy while a "pay" version is fixed. I think the only clean way out of this is a lot of debugging. Related to this, I can tell you from personal experience in commercial software: support costs can be an enormously drain. The most effective way to keep them down is with relentless quality improvement: kill bugs, make features more comprehensible, document, make failure modes gentle, make errors clear, etc. -- Kyle Cordes http://kylecordes.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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, Apr 06, 2009 at 09:14:07PM -0500, Luke Kanies wrote:> > I agree that #2 seems best. I''m really shocked by the Chef > > project; it seems really offensive to me, and I''d like to see > > you guys go in a direction that stops someone from just > > rebundling Puppet and calling it theirs. > > To be clear here, Chef isn''t Puppet rebundled or anything; it > takes a lot of Puppet''s obvious advancements, but it doesn''t > share any code (and can''t, because we use the GPL2).Yeah, I know; it just got my dander up. -Robin -- They say: "The first AIs will be built by the military as weapons." And I''m thinking: "Does it even occur to you to try for something other than the default outcome?" -- http://shorl.com/tydruhedufogre http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 6, 2009, at 10:07 PM, Kyle Cordes wrote:> > Luke Kanies wrote: >> 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 > > There is dangerous territory nearby: Paying customers have a higher > expectation of a smooth out-of-box-experience, than open source users; > to make this happen it is necessary to debug vigorously. However, open > source users tend to chafe at the thought of a "community" version > intentionally left buggy while a "pay" version is fixed. I think the > only clean way out of this is a lot of debugging.Yep, it''s essentially a ridiculous balance to try to find, especially since the third leg of the balance (after revenue and community) is my own life. I seem to sacrificing it rather than the other two, and I''m trying to find a better balance between them all. I don''t think I''m doing great at any of them, and my wife would certainly agree, but I''m constantly tuning it. I''ve been spending more effort on the lists recently (albeit in chunks). And, of course, I remain committed to keeping Puppet itself as stable as possible, but the definition of "stable" is always open to definition, unfortunately.> > Related to this, I can tell you from personal experience in commercial > software: support costs can be an enormously drain. The most effective > way to keep them down is with relentless quality improvement: kill > bugs, > make features more comprehensible, document, make failure modes > gentle, > make errors clear, etc.Considering how many people have told me they don''t buy support because they find Puppet so easy that they just don''t need help, I''m not too concerned about this yet. -- The chief lesson I have learned in a long life is that the only way to make a man trustworthy is to trust him; and the surest way to make him untrustworthy is to distrust him and show your distrust. -- Henry L. Stimson --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
>> >> Related to this, I can tell you from personal experience in >> commercial >> software: support costs can be an enormously drain. The most >> effective >> way to keep them down is with relentless quality improvement: kill >> bugs, >> make features more comprehensible, document, make failure modes >> gentle, >> make errors clear, etc. >(said somewhat tongue and cheek) Hey, isn''t that the purpose of commercial software? You need support because while it works in some way, yet does not completely work and must pay for support to get it working? :-) Support most certainly can be a profit center. In a serious note, for an OSS project I would say Puppet has a pretty good development/testing process. Hell I''ve known commercial products that went through less testing. Can Puppet''s development process be improved? Definately yes and is something that will be constantly revisited. -L -- Larry Ludwig Reductive Labs --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, Apr 6, 2009 at 6:30 PM, Mike <mhsemcheski@gmail.com> wrote:> > I''ve been using Puppet for a month or two, and plan to keep on using > it. I would imagine that as long as there is a not-stagnant > community, bugs are being fixed regularly, it is included as part of > the distributions I use, and nothing comes along that is a lot better, > I''ll keep using it. But the chances are relatively slim that I''ll > ever contribute any code back. I''ll always try to file a good bug > report or answer questions when they come up. But if I''m paying for > support, then all bets are off. If I were paying for support (and > with 10 linux machines and relatively simple needs, its unlikely that > I would pay for support) all bets are off - I''m not filing any bug > reports or helping anybody else. >Mike, Why would support change your behavior so much? Clearly, the way my perspective has changed since I started working for an Open Source company cannot be overstated The way I saw it before your email (and this isn''t just in regard to Puppet) was a classification of support customers handful of overlapping categories. For example ''bought support as a company policy'', ''recognized the value of the project and bought support to support the project'' and ''really needed help with the software''. I''ve used many open source projects and many commercial products. Ironically, particularly when considering your statement, I believe I have opened more bugs against commercial products. I also usually helped whomever with any software that I clearly could help with, regardless of the licensing. Your statement here stuck out and struck me as far removed from my own perspective. I''m hoping you will elaborate so I can better understand your position. Regards, Andrew> I don''t know how many people would stop contributing if they had to > assign their copyrights to Reductive Labs. But that requirement > wouldn''t stop me. Like Robin mentioned, I would guess over time the > number of contributors stays relatively small. If you think about the > Mythical Man Month, the number of contributors is always going to be > small - just like the percentage of people in an operating room who > are surgeons is relatively small. There are lots of non-code tasks > that are part of software development. > > And just for the record, if there was a version of Puppet that worked > on Windows clients, I probably would want some sort of support > contract for about 100 machines. > > > >--~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Luke Kanies wrote:> On Apr 6, 2009, at 4:37 PM, David Lutterkort wrote: > >>> 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. >Is this that big of a deal? I scanned several of the projects I have contributed too (Apache, Fedora, JBoss) and they all require copyright assignment. It does not seem to be way off base. The issue will be, I believe, how Reductive reacts to having the copyright. Some people will be offended by dual licensing, others will be offended by open-core licensing. I dont know that you can please everyone. As long as the actions which Reductive takes are supportive of the community, I think it would be fine. I personally would prefer the LGPL license, but I could see where RL would prefer GPL + copyright assignment. That would protect them the most from a revenue point of view. Anyone know an editor at the Harvard Business Review? It would be great to get the process/thinking pros and cons documented. -- bk --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Kyle Cordes wrote:> Luke Kanies wrote: >> 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 > > There is dangerous territory nearby: Paying customers have a higher > expectation of a smooth out-of-box-experience, than open source users; > to make this happen it is necessary to debug vigorously. However, open > source users tend to chafe at the thought of a "community" version > intentionally left buggy while a "pay" version is fixed. I think the > only clean way out of this is a lot of debugging. > > Related to this, I can tell you from personal experience in commercial > software: support costs can be an enormously drain. The most effective > way to keep them down is with relentless quality improvement: kill bugs, > make features more comprehensible, document, make failure modes gentle, > make errors clear, etc. >But this is the value of a community. Too often the focus is on the developers. But users are even more valuable. If RL were to release a full featured community version, and then a supported version based on that.. the community is doing the hardening. This does not mean that the community version is bad.. just new. The proof would be that bugs get fixed in both. -- bk --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, 7 Apr 2009, Bryan Kearney wrote:> Kyle Cordes wrote: >> >> There is dangerous territory nearby: Paying customers have a higher >> expectation of a smooth out-of-box-experience, than open source users; >> to make this happen it is necessary to debug vigorously. However, open >> source users tend to chafe at the thought of a "community" version >> intentionally left buggy while a "pay" version is fixed. I think the >> only clean way out of this is a lot of debugging. >> >> Related to this, I can tell you from personal experience in commercial >> software: support costs can be an enormously drain. The most effective >> way to keep them down is with relentless quality improvement: kill bugs, >> make features more comprehensible, document, make failure modes gentle, >> make errors clear, etc. >> > But this is the value of a community. Too often the focus is on the > developers. But users are even more valuable. If RL were to release a > full featured community version, and then a supported version based on > that.. the community is doing the hardening. This does not mean that the > community version is bad.. just new. The proof would be that bugs get > fixed in both.That''s not how the model tends to work though. Usually the paid community gets the product first with the community version lagging behind by a release. Jason -- Jason Slagle - RHCE /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Jason Slagle wrote:> On Tue, 7 Apr 2009, Bryan Kearney wrote: > >> Kyle Cordes wrote: >>> There is dangerous territory nearby: Paying customers have a higher >>> expectation of a smooth out-of-box-experience, than open source users; >>> to make this happen it is necessary to debug vigorously. However, open >>> source users tend to chafe at the thought of a "community" version >>> intentionally left buggy while a "pay" version is fixed. I think the >>> only clean way out of this is a lot of debugging. >>> >>> Related to this, I can tell you from personal experience in commercial >>> software: support costs can be an enormously drain. The most effective >>> way to keep them down is with relentless quality improvement: kill bugs, >>> make features more comprehensible, document, make failure modes gentle, >>> make errors clear, etc. >>> >> But this is the value of a community. Too often the focus is on the >> developers. But users are even more valuable. If RL were to release a >> full featured community version, and then a supported version based on >> that.. the community is doing the hardening. This does not mean that the >> community version is bad.. just new. The proof would be that bugs get >> fixed in both. > > That''s not how the model tends to work though. Usually the paid community > gets the product first with the community version lagging behind by a > release. > > Jason > >Depends on the community I guess. The ones I have been with are not that way. As typical, your mileage may vary. -- bk --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Luke Kanies wrote:> Considering how many people have told me they don''t buy support > because they find Puppet so easy that they just don''t need help, I''m > not too concerned about this yet.I think you''re getting a false signal from this. I am confident that tools in/around Puppet to make a gentle learning curve would make it accessible to many times more users. For every 1 person that tells you this, there could be 10 (100?) who struggle for a few hours to get started, hit some of the many caveats, and wander away. I really like Puppet. I''ve been working with Linux for over a decade. I have a highly automation-centric mindset. I know Ruby and can read its stack traces. Yet I had to struggle quite a long while to get Puppet up and going correctly on a set of machines. The sky is the limit, in terms of using the fruits of monetization to create a positive feedback loop in which more success (users / money / polish) yields more success. -- Kyle Cordes http://kylecordes.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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Andrew Shafer wrote:> The way I saw it before your email (and this isn''t just in regard to > Puppet) was a classification of support customers handful of overlapping > categories. For example> ''bought support as a company policy'',> ''recognized the value of the project and bought support to support the > project'' and> ''really needed help with the software''. Now that is very interesting. For a company looking for a good open source business model, it could be very informative to somehow eke information out of existing commercial open source firms, about the typical customer breakdown (and price point tolerance) among those categories. -- Kyle Cordes http://kylecordes.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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Apr 7, 2009 at 1:27 AM, Andrew Shafer <andrew@reductivelabs.com> wrote:> The way I saw it before your email (and this isn''t just in regard to Puppet) > was a classification of support customers handful of overlapping > categories. For example ''bought support as a company policy'', ''recognized > the value of the project and bought support to support the project'' and > ''really needed help with the software''.Very recently, I looked at Zmanda as a backup solution. Zmanda is a commercial entity that sells the Amanda open source backup system. They''re offering a web-based front-end for Amanda, as well as packaging and most importantly, support. For something that is "critical infrastructure", its not hard to justify paying for support... if you have enough infrastructure that you''re going to need support frequently. (How frequent is frequently enough depends on what you''ll tolerate in terms of outages.) I don''t use Amanda, but if I did, I would be using the work someone else did and all I could give in return is my contribution to the community. If I used Zmanda, then the relationship is very different. They have a clearly defined support channel that their customers go through and their may be a little friction there. I don''t want to hear that I have to file a bug report - I''d rather open a trouble ticket, upload my log files, and let a level 1 technician write the bug report and give me the solution. What it comes down to is my employer can''t / won''t pay to "support a project" or fit a policy. We will pay for support to put an upper bound on the amount of time our staff has to spend working with something. In the end, Zmanda had a promising product, but there were too many bugs and their package was just too immature. It was a lot cheaper than the alternatives we were looking at, maybe when our current contract is up we''ll look at them again. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> That''s not how the model tends to work though. Usually the > paid community gets the product first with the community > version lagging behind by a release.Huh? Not in Red Hat''s model: Fedora -> RHEL JOPR -> JON Spacewalk -> Satellite. The community version leads, not lags. -Peter --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, 7 Apr 2009, Burkholder, Peter wrote:>> That''s not how the model tends to work though. Usually the >> paid community gets the product first with the community >> version lagging behind by a release. > > Huh? Not in Red Hat''s model: > > Fedora -> RHEL > JOPR -> JON > Spacewalk -> Satellite. > > The community version leads, not lags.Different operating model than the ones I''m thinking of. Things like zmanda as pointed out where the commercial version will get features or other items not yet present in the community edition. Groundwork monitor seems to follow a similiar model. It''s more appropriate to new features, but thats where your bugs tend to come from. And you''re not exactly right. Spacewalk was just born from satellite. The open source version lagged by years. Similiar story with GFS, directory server, etc. The features went in the commercial product first. Only later were they opened up. If you consider them as addons to redhat, it makes the story similiar there. The "Core" would lag, but the add ons bolted on would lead. Those addons will be the things with bugs. Luke has expressed a disinterest in this model though so it''s largely irrelevant. -- Jason Slagle - RHCE /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 7, 2009, at 6:14 AM, Kyle Cordes wrote:> Luke Kanies wrote: >> Considering how many people have told me they don''t buy support >> because they find Puppet so easy that they just don''t need help, I''m >> not too concerned about this yet. > > I think you''re getting a false signal from this. I am confident that > tools in/around Puppet to make a gentle learning curve would make it > accessible to many times more users. For every 1 person that tells > you > this, there could be 10 (100?) who struggle for a few hours to get > started, hit some of the many caveats, and wander away.Count me one of the 10 (100?). I for one would try to get my $employer to buy support. And I''d probably cost you money at first in supporting me since I''m not a programmer and completely Ruby illiterate. I''m intrigued by puppet, got a proof of concept instance running, looked at what I really wanted to do with it and decided I didn''t have the time/bandwidth to figure out ERB and everything else now. Things to gentle the learning curve would be awesome. Until they exist and/or I have a nice chunk of time to try to force new knowledge into my poor brain, I will probably not be moving much past my proof of concept. --Susan --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 7, 2009, at 11:05 AM, Jason Slagle wrote:> > > > On Tue, 7 Apr 2009, Burkholder, Peter wrote: > >>> That''s not how the model tends to work though. Usually the >>> paid community gets the product first with the community >>> version lagging behind by a release. >> >> Huh? Not in Red Hat''s model: >> >> Fedora -> RHEL >> JOPR -> JON >> Spacewalk -> Satellite. >> >> The community version leads, not lags. > > Different operating model than the ones I''m thinking of. Things like > zmanda as pointed out where the commercial version will get features > or > other items not yet present in the community edition. > > Groundwork monitor seems to follow a similiar model.I can''t speak for zmanda, but IMO Groundwork is more of a horrible warning than a good example. AFAICT they basically founded the company as a way to make money from open source without going through the minor bother of actually writing any. My understanding is that they''ve gotten better in recent years, and I don''t know enough about them to be really mean, but if Puppet ever did have an "enterprise" edition (which is pretty unlikely) it would always look a lot more like RHEL than, um, the other stuff. Enterprises like it slow and stable. :)> > It''s more appropriate to new features, but thats where your bugs > tend to > come from. > > And you''re not exactly right. > > Spacewalk was just born from satellite. The open source version > lagged by > years.It''s more appropriate to say that Satellite was only recently open- sourced.> > Similiar story with GFS, directory server, etc. The features went > in the > commercial product first. Only later were they opened up. If you > consider them as addons to redhat, it makes the story similiar there. > > The "Core" would lag, but the add ons bolted on would lead. Those > addons > will be the things with bugs. > > Luke has expressed a disinterest in this model though so it''s largely > irrelevant.I will say, I''m a lot less sure about the future revenue models than I was when I started. At this point, I''m mostly interested in clarity, with a much smaller focus on our long term revenue. I just don''t want to make stupid decisions here that hurt our ability to grow Puppet in the long term. -- I''m worried about Bart. Today, he''s sucking people''s blood, tommorrow he might be smoking. -Marge Simpson --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Apr 7, 2009 at 8:45 AM, Michael Semcheski <mhsemcheski@gmail.com>wrote:> I don''t want to > hear that I have to file a bug report - I''d rather open a trouble > ticket, upload my log files, and let a level 1 technician write the > bug report and give me the solution. What it comes down to is my > employer can''t / won''t pay to "support a project" or fit a policy. We > will pay for support to put an upper bound on the amount of time our > staff has to spend working with something. > >Interesting... I''ve been on both sides of this equation many times and my experience has always been that every intermediary in the communication loses/distorts information, so if I really want something to be fixed the best strategy always seemed to be provide the best possible report with clear steps to reproduce the issue. This is probably a topic for a different thread, but I think it is directly related to why this thread started. What are your expectations for support? Have you ever had support from Oracle(replace with enterprise software company of your choice)? Did that put an upper bound on the amount of time your staff had to spend working on anything? I want to explore this topic so Reductive Labs can provide the most valuable support possible by understanding everyone''s expectations and motivations. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, 2009-04-07 at 12:05 -0400, Jason Slagle wrote:> Different operating model than the ones I''m thinking of. Things like > zmanda as pointed out where the commercial version will get features or > other items not yet present in the community edition.What Red Hat sells, and customers see value in, is stability: stability from extensive testing, stability from being very deliberate about updating etc.> Spacewalk was just born from satellite. The open source version lagged by > years.Huh ? When Satellite was open-sourced, Spacewalk _was_ the Satellite code base. Satellite should also serve as a warning to anybody thinking about doing something partially closed-source - for example, yum was a direct response to the fact that the server bits of up2date were closed source. up2date withered, yum is still around. 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
luke@madstop.com (Luke Kanies) writes:> I fear this discussion will quickly devolve into a recursive flame- > fest, but it needs to be broached, so here we go.... I''m a little surprised by the problem. One way to perhaps make things easier is to break puppet into independent chunks of code that do more clearly defined tasks, but work together. Publish an interface which states how the components talk together. Then you can add on extra comercial "functions" modules which are paid for, or substitute existing "community modules" with "non-free paid for ''better'' versions. As the interface is defined there''s no need to worry about some of the issues you are discussing. We''ve seen issues with the standard puppet master''s performance. - A "plug-in" enterprise replacement would be great. There was talk earlier about push-scheduling of changes (for example deployment of new software on certain servers during certain maintenance windows). - A plugin enterprise module would be great. You mentioned support contracts - I guess most of the people who are going to want support are for initial setup and configuration consultancy, and perhaps solving new problems as the "puppet installation" grows. If the support people are good word will spread. Puppet is currently very ruby centred. - That''s fine but I often wonder if a more generic interface might be better. If you defined the interface in a language independent manner then it might allow solutions in other languages to be offered. So perhaps a different way of looking at the problem is looking at puppet slightly differently and making it easy to add or replace components. Also to make sure that the interface to these various components is able to be expanded reasonably transparently. Looking at the problem this way doesn''t change the licensing concerns you are expressing but does make them much easier to manage than now. That might require a lot of initial work, and redesigning in the short term but potentially would make your life easier in the end. Simon --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 15, 2009, at 9:12 AM, Simon J Mudd wrote:> > luke@madstop.com (Luke Kanies) writes: > >> I fear this discussion will quickly devolve into a recursive flame- >> fest, but it needs to be broached, so here we go. > > ... > > I''m a little surprised by the problem.It''s really only a problem because no policy has ever been set or maintained, and people have questions that aren''t always clearly answered by the current situation. I just wanted to view this lack of policy, and the work we''re going to have to do to rectify it, as an opportunity to pick the best route forward rather than just picking the easiest one.> > One way to perhaps make things easier is to break puppet into > independent chunks of code that do more clearly defined tasks, but > work together. Publish an interface which states how the components > talk together. Then you can add on extra comercial "functions" > modules which are paid for, or substitute existing "community modules" > with "non-free paid for ''better'' versions. As the interface is defined > there''s no need to worry about some of the issues you are discussing. > [snipped example external modules] > So perhaps a different way of looking at the problem is looking at > puppet slightly differently and making it easy to add or replace > components. Also to make sure that the interface to these various > components is able to be expanded reasonably transparently.That''s hopefully something we''re much closer to accomplishing with 0.25, but I fear we''re still a ways out from transparent module replacement. And, actually, this module replacement exacerbates licensing concerns, rather than obviating them - I can''t actually currently publish commercial modules that interface with Puppet.> > Looking at the problem this way doesn''t change the licensing concerns > you are expressing but does make them much easier to manage than now. > > That might require a lot of initial work, and redesigning in the > short term > but potentially would make your life easier in the end.I think this is something we can realistically start looking at in 2010, probably - we''ve got bigger fish to fry right now, but I think we''re going to get more and more interest in replacing subsystems with external modules, either commercial or just different. -- The remarkable thing about Shakespeare is that he really is very good, in spite of all the people who say he is very good. -- Robert Graves --------------------------------------------------------------------- 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---