On Fri, Jul 06, 2007 at 07:39:45PM -0500, Karl Berry wrote: > I hope Brett will comment.
I'll admit up-front that I'm still not entirely sure I understand the situation at hand, which is why I was holding off. But perhaps if I describe the issues as I see them, hopefully that will be helpful. Speaking generally, there are two main ways that the FSF, GNU, and associated projects can really mess up licensing: 1. We can release something under more permissive terms than we intended -- e.g., LGPLing something we wanted to GPL. 2. We can fail to communicate to the user what the license is and what their rights and obligations are. I think everything else is a pretty easy bug to fix -- it might be embarrassing, but it would all work out in the end. The main goal here, as I understand it, is to make gnulib files readily available under both the GPL and LGPL, with the appropriate headers. I haven't heard anybody say that that's the wrong goal, and on my first review, it seems pretty clear that the files in question should be LGPLed. So I don't think we're facing problem number 1. So it seems to me that we're having a discussion about whether or not we're facing problem number 2. I'll lay all my cards on the table and say up front that I'm personally a big fan of having license notices be as visible, clear, and consistent as possible. They can help make sure that everybody understands what's going on even after code has passed through many different hands, and they can help enforce the license (something I think about a lot ;) ). I don't think this needs to be a matter of what's legal, or what's not legal, or what a court case said or anything like that. A court's not going to punish us if our license notices are confusing. Instead, a user is going to decide they can't make heads or tails of it, and will just refuse to use the code. So we should make sure it's as clear as possible to that user. This is more about reasonable policy than law. I understand Karl's concern about the current situation. Given documentation that says the code has one license, and header comments that say the code has another license, it can be difficult for a user to discern which one is true. Even if there's documentation that says "The documentation is authoritative," how can you be sure that's trustworthy? Perhaps you have your own ideas about how much documentation of a license should be good enough, but I would ask that you please respect that other users may have different thresholds to reach before they're comfortable. I think we should do what we can to make sure everyone's as comfortable as possible. With all that said, I also understand that gnulib is in a pretty unique licensing situation, and so it may be difficult to get this to fit the standard licensing policies that suffice for most other projects. But I think it'd be worthwhile to spend a little time to see how close we can get. In that vein, Bruno, let me ask you a couple of questions. First: why does gnulib want to make these files readily available under *both* licenses, rather than just the LGPL? There are plenty of good answers to this question -- heck, even just plain old developer convenience will suffice for me -- I just want to know which ones are actually at play here. Second: is there a particular reason why the automatic conversion goes from GPL to LGPL, rather than the other way around? I ask because, under the LGPL, *everybody* has permission to relicense the work under the GPL. So if the headers that shipped with gnulib advertised the LGPL, and then gnulib-tool offered to convert them to the GPL, it would be cleaner for a couple of reasons. First, it would make the code headers consistent with the documentation. Second, it would very obviously be legally unquestionable, because the user running gnulib-tool would merely be exercising this right that the LGPL grants them. So I'd like to know if there's a particular reason not to do it that way. Of course, if I'm misunderstanding anything more fundamental, or if there's anything else you think that would be helpful to add, please don't hesitate to let me know. And if anybody has any of their own questions about this, I'd be happy to answer those. Thanks everyone, -- Brett Smith Licensing Compliance Engineer, Free Software Foundation
