Hi Stéphane, I share the comments already expressed by Roger. But would like to add the following:
- If you represent company 2 you will not have to purchase the client licenses. - It seems to me it is the sole responsibility of company 1 to secure the legality and the compliance to the GPL licence of their product or alternatively include a non-GPL license in their product. You might want to ask them about this if you feel unsure or have doubts. Jan > -----Original Message----- > From: Stéphane Bischoff [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 04, 2003 15:31 > To: 'Ron Albright' > Cc: MySQL (E-mail) > Subject: RE: Licence question > > > Thank you for all your response, but my question is very simple : > > Example : > > We have company 1 that make's a product that communicate with MySQL server > using TCP/IP. > This product (company 1) does not use the MySQL client to connect to MySQL > server. (Don't ask me how, I don't know) > (By the way, this product really exist, that is why I am asking this > question). > > Therefore, if Company 2 has a MySQL server (commercial license) and > purchases 100 product from company 1, > does company 2 need a 100 MySQL client or driver licenses ??? > > I believe not (2 reasons) > > 1 - I paid company 1 for its product. > 2 - the product does not use MySQL client to connect to MySQL server. > > This is what is bugging me, can you help ? > > thank you, > > -----Original Message----- > From: Ron Albright [mailto:[EMAIL PROTECTED] > Sent: 3 décembre, 2003 18:27 > To: [EMAIL PROTECTED] > Subject: Re: Licence question > > > At 01:26 PM 12/3/2003, Chuck Gadd <[EMAIL PROTECTED]> wrote: > > >This is your standard "I am not a lawyer" type answer, because reading > >the text of the GPL can be overwhelming, but the way I understand it, > >if you are shipping MySql with your app, then you've either got to > >release your app under the GPL, or you've got to buy a commercial > >Mysql license for each copy of your app that you ship. > > > >If you were to simply download and install MySQL at your company > >office, then write apps for in-house use at your company, then > >you have no license issues. Your apps would not need to be > >GPL, and you do not need a Mysql commercial license. > > > >This was discussed by a Mysql AB employee during the MySQL > >training class I took a few weeks ago. > > This is somewhat ambiguous. From the statements below it would > appear to me > that you can ship MySQL with an application as long as the your > application > does not directly link to the MySQL libraries as would be the case if > embedded. But "mere aggregation" seems to apply even if your application > starts the database as a separate executable. The last paragraph of the > first question seems to allow shipping it along with your application but > the last sentence leaves it somewhat open to question. > > From the GPL FAQ (http://www.gnu.org/licenses/gpl-faq.html): > > > What is the difference between "mere aggregation" and "combining two > modules into one program"? > > Mere aggregation of two programs means putting them side by side on the > same CD-ROM or hard disk. We use this term in the case where they are > separate programs, not parts of a single program. In this case, if one of > the programs is covered by the GPL, it has no effect on the other program. > > Combining two modules means connecting them together so that they form a > single larger program. If either part is covered by the GPL, the whole > combination must also be released under the GPL--if you can't, or > won't, do > that, you may not combine them. > > What constitutes combining two parts into one program? This is a legal > question, which ultimately judges will decide. We believe that a proper > criterion depends both on the mechanism of communication (exec, > pipes, rpc, > function calls within a shared address space, etc.) and the semantics of > the communication (what kinds of information are interchanged). > > If the modules are included in the same executable file, they are > definitely combined in one program. If modules are designed to run linked > together in a shared address space, that almost surely means > combining them > into one program. > > By contrast, pipes, sockets and command-line arguments are communication > mechanisms normally used between two separate programs. So when they are > used for communication, the modules normally are separate > programs. But if > the semantics of the communication are intimate enough, > exchanging complex > internal data structures, that too could be a basis to consider the two > parts as combined into a larger program. > > > > If a program released under the GPL uses plug-ins, what are the > requirements for the licenses of a plug-in. > > It depends on how the program invokes its plug-ins. If the program uses > fork and exec to invoke plug-ins, then the plug-ins are separate > programs, > so the license for the main program makes no requirements for them. > > If the program dynamically links plug-ins, and they make function > calls to > each other and share data structures, we believe they form a single > program, so plug-ins must be treated as extensions to the main program. > This means they must be released under the GPL or a GPL-compatible free > software license, and that the terms of the GPL must be followed > when those > plug-ins are distributed. > > If the program dynamically links plug-ins, but the communication between > them is limited to invoking the `main' function of the plug-in with some > options and waiting for it to return, that is a borderline case. > > > > Can I use the GPL for a plug-in for a non-free program? > > If the program uses fork and exec to invoke plug-ins, then the > plug-ins are > separate programs, so the license for the main program makes no > requirements for them. So you can use the GPL for a plug-in, and > there are > no special requirements. > > If the program dynamically links plug-ins, and they make function > calls to > each other and share data structures, we believe they form a single > program, so plug-ins must be treated as extensions to the main program. > This means that linking the GPL-covered plug-in with the main > program would > violate the GPL. However, you can resolve that legal problem by adding an > exception to your program's license which gives permission to > link it with > the non-free main program. > > For more details, see the question above that starts with, "I am writing > free software that uses a non-free library." > > > > If a programming language interpreter is released under the GPL, > does that > mean programs written to be interpreted by it must be under > GPL-compatible > licenses? > > When the interpreter just interprets a language, the answer is no. The > interpreted program, to the interpreter, is just data; a free software > license like the GPL, based on copyright law, cannot limit what data you > use the interpreter on. You can run it on any data (interpreted program), > any way you like, and there are no requirements about licensing that data > to anyone. > > However, when the interpreter is extended to provide "bindings" to other > facilities (often, but not necessarily, libraries), the > interpreted program > is effectively linked to the facilities it uses through these > bindings. So > if these facilities are released under the GPL, the interpreted program > that uses them must be released in a GPL-compatible way. The JNI or Java > Native Interface is an example of such a facility; libraries that are > accessed in this way are linked dynamically with the Java programs that > call them. > > Another similar and very common case is to provide libraries with the > interpreter which are themselves interpreted. For instance, Perl > comes with > many Perl modules, and a Java implementation comes with many Java > classes. > These libraries and the programs that call them are always dynamically > linked together. > > A consequence is that if you choose to use GPL'd Perl modules or Java > classes in your program, you must release the program in a GPL-compatible > way, regardless of the license used in the Perl or Java interpreter that > the combined Perl or Java program will run on. > > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
