One of the surprising findings from the recent survey was that so many responders (more than 30%) reported that they needed to "modify" the LIVE555 source code for their purposes. Looking at the specific details of their reported "modifications", however, it became clear that many people were confused about what it means to "modify" the supplied "LIVE555 Streaming Media" code.
In particular, many people described their "modifications" by explaining that they needed to create their own subclasses of existing LIVE555 classes. Subclassing an object-oriented library is *not* modifying it. On the contrary, it's the appropriate and proper way to extend its functionality. You can subclass an existing LIVE555 class without changing *any* of the LIVE555 files (either the ".hh" or ".cpp" files). Because the existing LIVE555 files remain unchanged, it's trivial to upgrade to a new version of the code, whenever it comes out. More importantly, if you subclass the LIVE555 classes - without modifying any of the LIVE555 header files or ".cpp" files - then, under the terms of the LGPL, you are *not* required to release your subclass code (nor the rest of your application code). Your application can be 'closed source'. If, however, you truly modify (i.e., change) the supplied LIVE555 library code - either the ".hh" or the ".cpp" files - and distribute a product (e.g., a network camera, media server, media player, or proxy server) that's built from this modified code, then, under the terms of the LGPL license (and the GPL license on which it is based), you MUST ALSO distribute your modifications to the LIVE555 code. ONCE AGAIN, TO MAKE THIS CLEAR: If you distribute a product (even a free product) that's based on a modified version of the LIVE555 code, then I MUST INSIST that you also distribute your modifications. The easiest way to do this is by putting your modifications on your product's web site. Note that merely sending your code modifications to the "live-devel" mailing list (even in the form of a 'patch' file) is NOT sufficient - unless your patch happens to get included in a future release of the LIVE555 code, and you then upgrade to this new version of the code (without modifying it again). But there's no guarantee that we will accept your patch (and we are certainly under no obligation to do so). We are unlikely to accept very large patches, nor patches that add functionality that's not likely to be of general interest. (Of course, patches that fix genuine bugs are always welcome.) As always, we will continue to try to design the LIVE555 library code in a way that makes it easy for developers to extend its functionality - if necessary - via subclassing. If you believe that a particular member function or variable should be "protected:" or even "public:" instead of "private:" (or "public:" instead of "protected:") then let us know. (Be aware, however, that not every such request will be accepted, because by design, some member functions and variables were truly not intended to be accessible to subclasses, or accessible from outside the class hierarchy.) A FINAL NOTE: If you have any further questions about your compliance with the LGPL and its conditions, please consult your company's copyright attorney. (This mailing list is filled with engineers, not lawyers, so it's not an appropriate forum for legal discussion.) If, after consulting your company's copyright attorney, you feel that you have problems complying with the LGPL, then please get in touch with me by private email (i.e., not via this mailing list), and we'll see what we can work out. Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
