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]
