On Tue, 03 Jan 2006 16:36:31 -0800, Michel Sanner wrote: > Hello, > > One of the greatest feature of Python in my opinion is the way the > interpreter can be used to integrate a wide variety of > software packages by dynamically linking them. This approach has been > extremely successful for us so far but now I run > into a license nightmare.
Various other people on the newsgroup have given varying advice. I can only say: Why are you asking us? If you want legal advice, speak to a lawyer. At the very least, the best (if not only) canonical source of the GPL's intention is gnu.org, not random googling for random thoughts by random people, many of whom have bees in their bonnet about what they (mis)understand the GPL to say. In particular: http://www.gnu.org/licenses/gpl-faq.html [quote] Q: If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL? A: Yes, because the program as it is actually run includes the library. ... Q: Can I release a non-free program that's designed to load a GPL-covered plug-in? A: 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 of the plug-in makes no requirements about the main program. 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, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins. 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. [end quote] If you work must _link_ to the libraries in question (as opposed to merely executing them), then it seems to me that your best bet would be to ask the copyright holder(s) of the libraries you want to use for a licence compatible with your needs. You may consider explaining why you can't use the GPL, and if need be you might consider paying them for a non-GPL licence. After all, if you can't use their libraries, you would have to either licence somebody else's work, or pay somebody to develop something for you. (Just because programmers release work under the GPL doesn't mean they won't do work for pay.) > The second question I would like to get an answer for is whether doing > an "os.system('GPLapp')" violates GPL if I ship my Python code that does > the os.system call and the GPLapp program ? Again, see the FAQs: [quote] Q: What is the difference between "mere aggregation" and "combining two modules into one program"? A: 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. [end quote] -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
