Tom Lane wrote: > Kevin Brown <[EMAIL PROTECTED]> writes: > > But if both of these paragraphs are simultaneously true, then why put > > *anything* in contrib? > > Don't say that too loudly, or Marc may take it upon himself to make it > happen ;-).
Well, I hope he's not so eager to do so that he does it before this licensing thing is hammered out. :-) I think having contrib is a very good idea, but that's only *because* it currently allows non-BSD licenses. Take that away, and I think you've taken away the entire purpose for contrib (versus simply including something in the main source tree with a configure switch to enable/disable it). > There are a number of reasons to keep things in contrib. One is that > the code may be too tightly tied to backend innards to be appropriate to > maintain separately (the GIST extension modules are a good example, and > most of the modules that include server-side code are easier to maintain > with the server than not). Shouldn't this stuff (if we decide to make contrib BSD-only) become part of the main source tree, then, with a configure option to enable/disable it at compile time? > Another is that small modules may not have > enough critical mass to get maintained at all, if they're kicked out to > live or die on their own. That's certainly a problem, but only if the modules are also tightly tied to the backend. But then, does that mean that anything which is strongly tied to the backend must be included in contrib, no matter how unpopular? Aside from that and licensing, what other criteria would you use to decide on such inclusion? > > Otherwise, perhaps you're more concerned about the licensing issues in > > contrib than you need to be? > > The way I see it, the "only BSD stuff in contrib" rule is designed > precisely to save us from having to think too hard about licensing > issues. I'm not interested in getting into lawyeristic arguments > about how it's okay to distribute something with a different license > if only we don't do XYZ with it. Yeah, but what I'm saying is that *we* don't have to think about this lawyeristic stuff regardless. All we have to care about is whether or not the contrib item in question has a license that allows source distribution. The rest of it is a problem for whoever wants to build binary distributions, and such people *already* know what the issues are and know that they have to think about them. The only case where that might not be true is the case of the individual who is building a binary distribution for use within his own group. But such a person is easily covered by simply disabling compilation of contrib by default. If he has to go to the trouble of enabling that explicitly, then he can be warned that the stuff in contrib might be covered by a different license. But such a person is likely to be in a role where he's had to deal with licensing issues elsewhere, so it's more likely than not that he'll be aware of such things. The only thing he needs to be made aware of is that contrib contains items that fall under different licenses. That alone isn't, IMO, justification for removing non-BSD items from contrib. So in the end, keeping contrib BSD-only doesn't help *us*, it only helps the people who build binary distributions. But because they're already used to dealing with the problem, they don't need our help on this. And that means that kicking non-BSD stuff out of contrib doesn't really help anyone very much, if any...but it does hurt us in that some potentially very valuable things will no longer be considered for inclusion in the distribution. So from here it looks like there's more (perhaps much more) to be lost by making contrib BSD-only than there is to be gained. It would be one thing if we had a lot of people clamoring for removal of non-BSD stuff from contrib because they'd actually been burned by licensing issues. But I haven't seen anything to that effect on this list, at least, and we've had at least one GPL item in there (pgcrypto) since late 2000. -- Kevin Brown [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])