Assuming that all open source licenses are equally good (they're not, but for sake of argument, let's say they are), and that you wanted to use source code from 100's of projects, all licensed differently. To do the right thing before using that code one would need to vet, and I mean legally vet, the license before adopting the code. That process is time consuming and expensive. And...
more...
- DeWitt Clinton
The net effect of that explosion of combinational complexity is that consumers of open source code may ignore the responsibility of compliance in the first place. Which is a bad thing. It puts the pain and burden on the user of open source code. How many open source licenses have you personally read and understood, and had your lawyers read and understand? The answer 2 or 3 is reasonable. 20 or 30 is not.
- DeWitt Clinton
A momentous occasion indeed: this marks my first actual comment on FriendFeed, I think. Still undecided on the tool That trivia aside, it's not the macro intent or direction I question, but rather the timing and the logistics. The why now question still stands, I think, if we assume that staving off license proliferation is the end goal. The MPL is no more or less viable as a license...
more...
- stephen o'grady
...which the FSF discourages use of). Which is, again, Google's right. I just don't happen to share that philosophy.
- stephen o'grady
Just an idea, but if existing code released under the MPL and the EPL (and other MPL derivatives) were relicensed under say, the CDDL, then there would be a single weak copyleft license that has something like 6-7% market share. That would facilitate interoperability between those projects (making one bigger island), and be a step in the right direction.
- DeWitt Clinton
Also, one private commenter argued that the MPL is dead, to which I'd respond by pointing here (http://labs.mozilla.com/2008...). Relevant bit: "We only ask that all concepts and related source materials be freely redistributable and remixable under either a Creative Commons license (for Ideas and Mockups) or the Mozilla Public License (for Prototypes) so that we can all effectively collaborate on the exploration."
- stephen o'grady
Stephen, how many of your clients primary concern is as a *consumer* of open source licensed code? Most of them are vendors trying to find the business advantage in releasing it, right? To properly stay in compliance one needs to compute the transitive closure of all applicable licenses before code is even compiled. The cost of this goes all the way down to how the internal code repositories and the internal build systems are architected. Increase that cost, and fewer consumers will be in compliance..
- DeWitt Clinton
Heh. That statement precisely makes my point. IMHO, it is not a good thing that a community would say "in order to contribute we need you to use our proprietary open source license." Isn't the goal getting the code out there and reusable without arbitrary restrictions?
- DeWitt Clinton
I'd be all all for a centralization of the MPL/EPL/CDDL/etc assets, but it's not likely to happen. The odds of the Eclipse EPL assets, for example, being rereleased under the CDDL are probably near zero. Realistically, I think we're stuck in a world that will have three rough styles of licenses and at least two options within each style (if only due to versioning). Illogical as this might seem, I think this is the reality for the foreseeable future.
- stephen o'grady
I agree with your assessment about the likelihood of relicensing. However, Google Code can put a tiny little bit of pressure on the community when it comes to new code by saying, if you want to host it here, please pick one of the major non-product-specific license choices. Is that sufficient to change major established projects, like Mozilla's codebase or Eclipse? Probably not. But those are a small fraction of all open source projects, and the goal is to change the future, not the past.
- DeWitt Clinton
I don't think we disagree at all on the advantages to a world with fewer licenses, whether it's from the vendor combinatorial or consumer comprehension perspectives. Where we break, I think, is in the achieveability of that goal. Specifically, I think the world that Google would like to see is a very much a perfect world scenario. Achievable within the confines of Google Code, certainly, but unrealistic on a wider scale. Unless massive changes of incentive occur.
- stephen o'grady
I don't know... We're all so new at this. A dozen years ago there were only a handful of open source licenses. Then it became trendy to write your own -- the Mozilla license even encouraged it by saying "copy this license for your project, just change the name and fork." A decade later, with the benefit of hindsight, we're seeing that this approach was probably a mistake.
- DeWitt Clinton
And 10 years from now we may have moved past that, and companies that are interested releasing open source software will use a standard license, rather than fragmenting the open source ecosystem with more one-off licenses. At the very least, Google Code can take the position of not being an enabler of that fragmentation. [Edited, because I think I accidentally came across as blaming you for what's going on -- I didn't mean that!]
- DeWitt Clinton
One last thought: the desired end state of easy recombination of assets is already sacrificed, even in the world of Google Code. The simplest way to guarantee free combination would be to reduce everything to one license: Apache. The allowance is made, however, for the GPL's philosophy and vision of freedom. Why? Because there's a lot of GPL code, presumably. In that context, the MPL deletion is more about volume than philosophy. Which is fine. Just important to note, I think.
- stephen o'grady
DeWitt, come on, give us _some_ credit. We would never, under any circumstances, recommend that a client use a one off license. Today, not in future. That's off the table. You and I agree on the implications of license proliferation, I'm pretty sure: we just differ in how aggressively it must be combated, and how strictly the licenses must be pared back.
- stephen o'grady
Sorry, Stephen. I had already went back and edited my comment on that. No offense meant!
- DeWitt Clinton
Google Code's license options are up to them. It's nice that they offer the service at all. I soured on it a bit when I discovered that they mingle the project hosting with closed source SDKs and network interfaces to closed source serverside stuff. I don't oppose closed source software on moral grounds, but I don't like that Android and AppEngine etc live on Google Code, because I feel like hosting a project there is a tacit endorsement of that stuff.
- Rob Sayre
Hey, Rob! Welcome to FriendFeed. Do you mean that code.google.com now has more than just open source project hosting on it? (The developer product apis, the Google Code University stuff, etc?) [Ahh, you updated your comment...]
- DeWitt Clinton
None taken: I just didn't want passers by to think we were out there recommending vanity licenses ;)
- stephen o'grady
Interesting point, Rob. I guess I like it because I think it is great that there can be an interplay and exchange between developer apis and open source code. And frankly, the more that open source philosophies can inform developer products, the better. But that's interesting about "endorsement". I never thought of it that way. Do you think mixed communities like sf.net or collabnet have the same problem?
- DeWitt Clinton
Rob: agreed. I've maintained pretty consistently that it's Google's right to choose whatever licenses they like for their service, since they are the ones hosting and maintaining it. My point in the piece and here was rather to debate their reasoning, since I don't happen to agree. Not to question their right to it.
- stephen o'grady
DeWitt: network APIs don't really bother me. I'm not sure network APIs conflict with open source much, though it does feel like sharecropping. I put a crash processing server on Google Code for work because I figured it would get more contributors. Later on, I found Google Code hosting Google products that are not open source, but it all looks very similar. When combined with videos of execs claiming Android is "open top to bottom" (not true for now), it started to smell for me.
- Rob Sayre