Re: TODO: GNU TLS - Mailing list pgsql-hackers
From | mark@mark.mielke.cc |
---|---|
Subject | Re: TODO: GNU TLS |
Date | |
Msg-id | 20061229064748.GA8091@mark.mielke.cc Whole thread Raw |
In response to | Re: TODO: GNU TLS (Stephen Frost <sfrost@snowman.net>) |
Responses |
Re: TODO: GNU TLS
Re: TODO: GNU TLS |
List | pgsql-hackers |
On Thu, Dec 28, 2006 at 09:34:05PM -0500, Stephen Frost wrote: > * mark@mark.mielke.cc (mark@mark.mielke.cc) wrote: > > By the words you describe above, the GPL doesn't require that you > > include a copy of the PostgreSQL license either. Are you saying that > > this makes GPL incompatible with PostgreSQL? > What in the world are you talking about...? I truely can't follow your > train of thought in the least. I will try again. It is a difficult subject for many. GPL software derived from PostgreSQL must honour the restrictions defined by the PostgreSQL (BSD) license. GPL software derived from OpenSSL must honour the restrictions defined by the OpenSSL license. What is the difference? Do you see it? You speak of "compatibility" as if it means that the above are different in some technical way. They are NOT different. Just because the GPL >= the PostgreSQL license, does not allow you to disobey the PostgreSQL license restrictions. You *cannot* release your entire derived GPL product as GPL, if it is distributed with PostgreSQL. The PostgreSQL component retains the PostgreSQL licensing restrictions, The GPL restrictions do not supercede or replace the PostgreSQL component and there is NOTHING the GPL can do to change this. > > It's silliness. If you redistribute OpenSSL, you honour the OpenSSL > > requirements. That's the *only* requirement by copyright law. It doesn't > > matter if it is GPL on top, or not. You always honour each license. > The GPL says you can't combine GPL code with code which has additional > requirements and then distribute the result. The GPL *cannot* say this. The GPL *cannot* define how OpenSSL can or cannot be used. Only the OpenSSL license can define how OpenSSL is allowed to be distributed or used once distributed. You are looking at it from the wrong direction. The GPL can prevent *GPL-derived* works from being non-GPL. The GPL CANNOT prevent one from deriving from non-GPL works. Take some time to read this a few times if you need to. The difference is HUGE. It would be ridiculous for it to be different. If it was different, it would require all software to have exactly equivalent licenses in order to be integrated. Insanity. Any lawyer who would claim this should lose their license to practice law. I'll state again - there is no such thing as *compatibility* in the sense you are using it. If they were fully compatible, they would have the exact same effect. The PostgreSQL license is *not* compatible with GPL in the sense that they can be interchanged. Read the following snip from the PostgreSQL license, which is incompatible with the GPL license: "Permission to use, copy, modiy, and distribute ... provided that the above copyright notice and this paragraph and thefollowing two paragraphs appear in all copies." A distribution that includes GPL software and PostgreSQL software *must* include both the GPL license, and the PostgreSQL license. This is an additional "incompatible" restriction with the GPL. The advertising clause of the OpenSSL license is a second such restriction. It is not the first such restriction as some people are trying to make it appear. > > 1) Adding GNUTLS support to PostgreSQL does not eliminate any PostgreSQL > > obligation to honour the OpenSSL distribution license. Any PostgreSQL > > distribution that includes OpenSSL must honour the OpenSSL distribution > > license, just as any PostgreSQL distribution that includes GNUTLS must > > honour either the GPL or LGPL license. Nothing changes. It's about > > distribution. If PostgreSQL includes OpenSSL support, it is a derived > > works when distributed with OpenSSL. It is a misunderstanding to believe > > that support for many interfaces allows you to avoid any licensing > > issues. It is a popular misunderstanding. > > As I tried to make clear previously, this hasn't got anything to do with > PostgreSQL distributing anything. Nor does it have anything to do with > PostgreSQL obligations. Here, I'll try again: > > Debian -- > \ Applications > - exim4 > \ Links against: > - libpq > \ Links against: > - libssl (OpenSSL) > > exim4 is under the GPL > libpq is under BSD (no advertising clause) > libssl is under BSD (advertising clause) > > So, Debian is distributing an application (exim4 w/ libpq & libssl) > which includes GPL code (exim4) combined with code under another license > (BSD w/ advertising clause) which *adds additional restrictions* (the > advertising clause) over those in the GPL, which is against the terms of > the GPL. It's *Debian's* problem, but *PostgreSQL* can solve it by > providing the option to link against GNUTLS instead. There is no problem above. Debian must honour all licenses for all software components. There is no need for an exemption, or an OpenSSL exception clause. If OpenSSL is included within Debian, than the Debian distribution should include an attribution to it in the Debian documentation, and the OpenSSL LICENSE file should be stored somewhere in the file system. If there is a problem, feel free to describe the actual points of conflict, using wording from the licenses itself. You are talking about a theoretical issue that I you have not shown to exist. Drawing ascii pictures doesn't substantiate your claim. The choice to use the GPL as the license for a product cannot stop the product from being derived from a non-free work. Richard Stallman's virus cannot prevent people from using non-GPL base software. He can *ONLY* prevent people from deriving from GPL software. Again, read this a few times. Legally, it can only go in one direction. If Richard Stallman wants to say that no part of his GNU system will make use of non-GPL software, that is his choice. He cannot tell the authors of other software what they can or cannot derive from. Only the license of the product being derived from can tell the author what they are allowed to do. Richard Stallman / GPL is not in the picture. The truth here, as I see it, is that Richard Stallman wants people who use the GPL, to believe in his political ideal, and choose to only use GPL software wherever possible, to allow his agenda to be achieved as quickly as possible. For GPL software to be legally derived from non-GPL software prevents his political ideal from ever being fully achieved. This is why people are trying to make open source hardware, and open source drivers for hardware. The dream is to have a complete software stack that is all guaranteed to be free to use, and free to derive from. It really is a dream. I don't share this dream. > > 2) Explicitly stating an OpenSSL "exception" is not a legal requirement. > > It is not possible for any derived product to "except" conditions > > for OpenSSL. OpenSSL defines its *own* license. You cannot modify it, > > which means that the GPL cannot reduce its significance, nor can an > > explicit exception claus increase its significance. OpenSSL > > distribution rights are defined by the OpenSSL license. Full stop. > In the case above, exim4 *can* provide an exception because it's the > *GPL* of *exim4* which is being violated by the advertising clause in > the *OpenSSL* license. Which exim4 upstream has *done*, and which can > be seen in their license (linked to previously in this thread). There > are a number of other GPL'd applications which have done this, mostly > (if not completely) at the prodding of Debian (bacula being another > which comes to mind). No. It's because of the FUD surrounding the issue. People would rather submit, and write an exception clause, than argue, or risk having to square off against a lawyer. Existence of the clause does not prove that the clause is necessary, or that it has any legal weight. It only proves that one or more people were convinced that it wouldn't hurt. I think it hurts everyone to submit to FUD, no matter if the FUD is from Microsoft, or from the FSF. I believe that people should be making choices based on knowledge, and understanding, than because of fear or uncertainty. > > If you wish to explicitly point out that you don't mind if your > > product is linked against OpenSSL (which should be obvious by the > > fact that you included support for it in your program), you are > > free to do so. Maybe it'll keep the lawyers a little hungrier. > > It's not necessary, and it *cannot* have legal effect. > Programs may not directly link against OpenSSL and so may not directly > include support for it (uhm, exactly the case when something links > against libpq which then links against OpenSSL), but which ends up still > being part of the distributed application. It doesn't matter how it happens. If it's possible that OpenSSL might be linked, than the distribution should include a copy of the OpenSSL license, and documentation for the distribution should show that OpenSSL is a part of the distribution. On my Fedora Core 6 system, I see a copy of the license in: /usr/share/doc/openssl-0.9.8b/LICENSE As well as in the header of most files such as: /usr/include/openssl/ssl.h I assume if I look hard enough, I would find something that qualifies as an attribution to Fedora Core containing OpenSSL within the Fedora Core documentation. If Fedora Core wishes to be legal, and respect all licenses of included software components, it should. > > Exception clause or not, every author of a derived works that makes > > use of it, should understand their *obligation* to honour any and > > all licenses for any derived software. GPL, LGPL, OpenSSL, Apache, > > whatever. The exception clause is making this obvious. It has no > > legal weight. > Given that I think your premise above is wrong I won't bother argueing > against conclusions you draw from it. Where are the words in the GPL that you think make your case? I haven't seen them in this thread. I've seen references to the thinking of other people, mostly people who have an FSF agenda to maintain. Where are the words? Is it all hearsay? > > No. The GPL is allowed to do whatever it wants. What it wants, is to > > achieve Richard Stallman's vision of software communism. What the GPL > > cannot do is say whether you can, or cannot use OpenSSL. Only OpenSSL > > can say whether you can or cannot use OpenSSL. > This isn't about whether you can use or cannot use OpenSSL. It's about > if you're allowed to distribute GPL applications which are linked to > OpenSSL without violating the terms of the GPL. *This is not about > distributing OpenSSL*. It is ONLY about distributing OpenSSL. GPL applications can CERTAINLY link against a legally distributed and used OpenSSL without violating the GPL. I think you are confusing the intent of Richard Stallman in authoring the GPL, with any legal weight the GPL actually has. One is about the dream. The other is about what the countries we live in, allow to be written on paper. Find words in the GPL that prevent one from choosing to use the GPL as the license for your software, even if your software legally links against a non-GPL product. I assume you are aware that GPL software is often compiled using proprietary compilers and linkers, and linked with proprietary system libraries, and executed on proprietary operating systems, running on proprietary hardware. Will you claim that this violates the GPL as well? > > They're entirely different discussions. One is about politics. One is > > about practical application. > > > > With regard to practical application, I agree with you. > > > > With regard to giving in to legal FUD, I feel it is my duty to stand up > > to it as best as I can, to prevent it from becoming widely accepted. > > Nothing personal, and we're both entitled to our own opinions on the matter. > > You expressed yours. I've expressed mine. Hopefully truth is found from > > the reading of both. > The problem is that you're not standing up to FUD, you seem to be > arguing about something completely seperate from the issue that I've I am *only* standing up to the FUD. Your points a), and b) below are practical issues. The FUD is about people repeating fear and uncertainty to open source project mailing lists all over the world. On practical issues, my opinion might be quite different. I'll offer them below, although after how you've responded to my other opinions, I'll assume you might not care to read them... :-) > brought up. I can understand Tom's point, or Andrew's point, that this > might not be an issue because of any number of reasons which might > include: > a) technically the program isn't linked till it's own the user's > computer (personally I don't feel that removes the GPL > requirements though I've heard it claimed) My opinion: If distributed in binary form, than the distribution itself must obey the OpenSSL restrictions. This includes ensuring that documentation for the distribution includes an attribution to the OpenSSL project, and ensuring that the OpenSSL license is included in the distribution. If the user downloads PostgreSQL and OpenSSL separately, and then uses both legally, linking them together, no distribution has occurred. As copyright law is about distribution, copyright law cannot prevent one from linking the pieces together at compile time or run time. If the user distributes the binary image, then this goes back to the previous paragraph. Some lawyer might be able to convince a judge that PostgreSQL requires OpenSSL to operate, and therefore, PostgreSQL is a fully derived work, and not including OpenSSL does not free the PostgreSQL owners of responsibility. The case seems pretty shaky, though, and OpenSSL is not a required component of PostgreSQL. > b) The GPL application doesn't link *directly* to OpenSSL and the level > of indirection means the GPL application doesn't *depend* on OpenSSL, > which means it's not a derivative (imv, this isn't very far removed > from 'a', but I can see some distinction) My opinion: Not different from 'a' at all. GPL applications can be legally derived from non-GPL applications. The license restriction of the product that is being derived from determine whether the derivation is legal or not. Richard Stallman doesn't want people to do this, because it hurts his cause, but legally, he can't stop them, as it is a necessary part of life with software. The product is always derived from at least one non-GPL product, even if only the hardware that it sits on. That is, until the FSF achieves its agenda of having a 100% GPL system.... > c) Authors of GPL code are very unlikely to prosecute such a claim > since OpenSSL *is* OSS and does abide by the DFSG (I wonder if the > FSF might find someone some day willing to, though they might not be > insterested due to possible bad press, who knows...) My opinion: This usually takes the form of 1) somebody forgetting to honour a part of the license, 2) somebody pointing it out, 3) somebody grudingly obeying. This might be a GPL-derived product that was released from the authors as binary only, where the software is grudingly released upon request (perhaps request by the FSF). This might be an OpenSSL-derived product that was released from the authors without attributing OpenSSL in the documentation, in which case they add a note in the documentation. This could be a BSD-derived product that forgets to include a copy of the BSD license in the distribution, in which case the license is grudingly added back. It doesn't matter what the license is. People know they should honour the license. Ignorance is not an excuse. Choosing to ignore the license is not honourable. > d) PostgreSQL can be configured to not use SSL when it ships and > therefore as shipped there isn't a problem (again, kind of a stretch) This goes back to a). If the distribution includes OpenSSL, it must honour the OpenSSL license. If PostgreSQL is not shipped with OpenSSL, but allows it to be linked with OpenSSL, than the responsibility is moved to the person who links the application and redistributes the linked application. If the end user does it, then it is not a redistribution, so copyright law cannot apply. > e) The GPL doesn't apply to shared library linking My opinion: I don't think this is true. LGPL doesn't apply to shared library linking. GPL does. > f) The OpenSSL falls under the 'distributed with the OS' clause of the > GPL and therefore it isn't a problem that there are additional > restrictions in its license (probably the most practical argument, > but not sure it'd hold up when that'd basically make all of Debian > exempt since it can all be considered 'part of the OS'...) My opinion: Same as a). The responsibility is moved to the distributor. The OS distribution must honour the license. > Your comments above about a PostgreSQL obligation just don't make sense > and so I have to conclude that you don't understand the issue, which may > be my fault for not explaining it clearly enough but there's only so > much I can do.. Hopefully this will help... I think we've both concluded that the other person doesn't understand the issue. Although it may be clear to you or I that the other is wrong, I think the strength of the arguments will stand on their own as to whether other people choose to believe you, I, or some third interpretation. I've tried not to be presuming. I ask of you the same. Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bindthem... http://mark.mielke.cc/
pgsql-hackers by date: