On Oct 19, 2012, at 1:02 PM, Miguel Di Ciurcio Filho <[email protected]> wrote:
> On Thu, Oct 18, 2012 at 11:53 PM, Luke Kanies <[email protected]> wrote: >> >> Note that we don't require copyright assignment and never have. We have a >> nearly-standard Apache CLA, which just confirms that we have the right to >> distribute the code you're contributing. >> > > There, right there, that is the problem with the CLA. You see how it > is pointless? I'm already giving you code under the Apache License. > PuppetLabs and any other entity or person on this planet have all the > rights and obligations stated in the Apache License. There is no need > for a second document, PuppetLabs have the right to distribute my > contributions as everybody else does under the Apache License. That's actually not necessarily true. Without a clear document somewhere, the legal standing of your contributions is technically unclear. Or rather, it is clear, and what's clear is that we don't automatically have a right to them, and they do not automatically acquire an Apache license. One could certainly argue that if you contribute to an Apache-licensed project you are submitting that contribution under an Apache license, but unless every patch you send includes an Apache license with it, you're in questionable territory, and I'm confident you could find a lawyer willing to take the oppositing position. It's annoying, but that's the way the law works. >> We're actually in the process of figuring out whether we can remove these. >> Every lawyer we're talking to is saying no, but every one of us wants to get >> rid of them, so I expect us all to end up ignoring the lawyers. The only >> reason we instituted them in the first place is because we were GPL'd, and >> we expected to either make commercial forks (which we didn't do) or switch >> licenses (which we did). >> > > There, right there too. The reason why you instituted the CLA is the > same reason that it fundamentally keeps people away from seriously > contributing to the project: PuppetLabs gets an extra privilege other > then the licensing of code being contributed. > > The license of the project is a pact of how a community whats to share > its production and every single member of the community _must_ not > have any extra privilege. Meh. I'd have a lot more sympathy for this position if every single member of the community put the same effort into the project. Long before I was able to hire developers to work on Puppet full time, I was the single largest contributor by a country mile, and after doing almost no work on it for at least 3 years, I'm *still* the largest contributor, and the next 10 or so are almost all paid to work on it by me. Yes, a big part of that is because we've failed to build as much of a developer community as we could and should have, but I worked really hard at this in the early days and still didn't make a lot of progress. We're taking another crack at it now, and that's specifically one of Dawn's mandates, but I haven't run into a lot of people who think it's unreasonable that we try to find a way to make a living doing what we're doing. And, of course, it's all moot, because that only mattered when the project was GPL'd. Now that it's Apache-licensed, Puppet Labs is not special in any way when it comes to licensing. We're only special because we employ tons of people who are paid to work on and care about Puppet. :) >> I know that I personally never was able to extract patches from a mailing >> list, because I use IMAP, not mboxes. Yes, I know I could do filtering, set >> up mutt explicitly for this, and relearn how to use it just for patches, >> but… I could also just go to github and see a clean, clear list with support >> for comments, email, and everything else I want. >> > > About the git send-email maybe it is just me. I've contributed to > other projects where there is no need to open tickets, just send the > patch to the mailing list and take the heat of the feedback, plain > simple. We used to do that for code review, but it got too overwhelming on the lists. I know some lists can survive with this, but we got a lot of feedback that ours wasn't working well. If that's not the case, I'm sure people would be willing to revisit, and, of course, you're always welcome to send your patches to the list if you prefer. >> We do a lot of this, but we're mixed in how consistent we are. Part of the >> reason is just the mixed bag of lots of us sitting in the same room - it's >> more expensive to communicate with people outside the building, so we tend >> to suck at it more than we should. >> > > That is definitely understandable. When there is a mix like this, it > is hard to keep the outside community on the loop. > >> I will say that I'm still a bit gun-shy of posting all of our ideas >> publicly, at least anything other than stuff we're basically ready to work >> on now. I'm a bit gun-shy for 2 reasons: First, I do have some legitimate >> competitive concerns, but most importantly, it's a lot of work to get it all >> out there and there's questionable value. >> >> That being said, we should obviously be more open about what we know we're >> going to work on and what we think we're going to build. We just recently >> split dev teams so that our OSS developers are much more independent of the >> commercial teams, which means that they'll naturally start looking outward >> more. >> > > That is a very nice change. > >> >> I don't actually know the difference between an open source project and an >> open source product. It's all just free code on the internet, right? >> > > It is more than just free code on the internet, IMHO. Quoting Peter, > from the message that started all this: > > "Or is it really the idea that in the future everybody runs their very > own patched version of facter and each time there is a new (minor) > release everybody has to check whether this does not break their whole > infrastructure? > > We all have his code, it is free and on the internet. As he points > out, do we have to maintain our on branches with fixes that doesn't > get merged? And they might not get being merged or there is a lack of > man power thanks to reasons that I'm trying explain, especially the > CLA. > > Your reasons you said about being gun-shy of posting ideas, IMHO, show > that you are more concerned about the product than the project. > > Open Source/Free Software projects must not be afraid of competition > and must not be afraid of failing. I'm not convinced. Everyone attaches ego and pride to work they do, and they don't want that work to fail regardless of whether their jobs are on the line. I could say a lot about this topic, but I'd prefer to do it over beers rather than publicly. Suffice it to say that I believe openness and transparency are the best behaviors, but there are some reasons for not being completely open about everything. Yes, those reasons reduce if I don't have to worry about what my company looks like in 3 years, but realistically, not by much. > I don't what to be picky, but it is the example that comes to mind > because I was concerned. On Puppet 3.0 `puppet kick` now shows a > deprecation warning. On other projects, changes like that are > presented to the project and discussed. PuppetLabs' developers opened > the ticket, committed the code, and it is done. I notice the thing > after the fact and by accident. > > This is a product behavior, not project behavior. My expectation as a > project is that: > > 1) Someone wants to deprecate/change/remove/create something, for any reason. > 2) Sends an RFC do the mailing list and gets feedback > 3) Work on the feedback received > 4) Go to 2 until it there is a consensus. > > I don't know if I'm the only one that have all this concerns or most > people are OK with how things are, but now I got it out of my chest > :-) You're definitely not the only one. I actually thought we did do an RFC on that. I know we've done it on a bunch of other ones. If we missed it on that, I think it's basically an oversight. You're right, though, that getting this wrong looks bad. To be clear, though, this wasn't done for business reasons, it was done because the team thought that few, if any, people were actually using it, and it made the whole system much simpler. And, of course, lots and lots of projects do a lot of their work essentially behind closed doors, even if they aren't backed by a company. I don't want to work that way unless we can't avoid it, but I think it's more the rule than the exception, counter to the myth of how open source works. -- Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
