Re: Questions about MPL license
Simon P. Lucy wrote: You can charge as you like for your application, but you won't be charging for the Mozilla component itself. What part of MPL says that you cannot charge for Mozilla?
Re: Delphi Components (SynEdit)
Frank Hecker wrote: You appear to want to make an analogous distinction between a work that subclasses a class and a work that uses a class. So maybe what you The entire idea of inheritance-scope is too easily circumvented. Suppose class A is covered by such a license. If I create class B which inherits from class A, then I have to release class B. I can avoid this by creating a new class A' which has an interface similar to class A, and which simply uses class A rather than inherits from it. Now I can let class B inherit from class A' without having to release anything. This is a simplified version of the Bridge design pattern (see Design Patterns by Gamma et al.)
Re: Delphi Components (SynEdit)
Per Abrahamsen wrote: MPL is not intended to protect derived code in the CopyLeft sense. It is not a copyleft license. I do not disagree with your explanation in general, but I think that you are using a very limited notion of 'copyleft'. According to http://www.gnu.org/copyleft/copyleft.html Copyleft is a general concept; there are many ways to fill in the details. [...] An alternate form of copyleft, the GNU Lesser General Public License (LGPL) [...] If you would like to copyleft your program with the GNU GPL or the GNU LGPL, [...] It seems to me that GPL, LGPL, and MPL all are copylefted licenses, but each have a different scope (executable, library, and file, respectively).
Re: Delphi Components (SynEdit)
Michael Beck (Team JEDI) wrote: Inheritance is an addition/deletion/change (i.e. modification) of the substance/structure of the existing class. If you don't want to modify the class, WHY would you subclass it in the first place? The MPL speaks of modifications to the code, not to the behaviour. If modified behaviour was included by MPL then we should also consider aggregation, reflection, proxy objects, and whatever clever mechanism are available in a given programming language. If you inherit a class in a new file, IMHO it does implicitly contain parts of the Original Code. Unless you want to claim that inheritance doesn't modify the original class in any shape and form. If the SynEdit component is released as a series of files, then MPL is quite clear that a modification is a change to the content of a file covered by MPL, or copying of code from a file covered by MPL to another file. Inheritance modifies behaviour, not the contents of a file.
Re: Delphi Components (SynEdit)
Michael Beck (Team JEDI) wrote: MPL is not about physical file, but about intellectual property, i.e. if From MPL 1.1, Section 1 (Definitions) 1.9. ''Modifications'' means any addition to or deletion from the substance or structure of either the Original Code or any previous Modifications. When Covered Code is released as a series of files, a Modification is: A. Any addition to or deletion from the contents of a file containing Original Code or previous Modifications. B. Any new file that contains any part of the Original Code or previous Modifications.
Re: LDAP C SDK 5.0 MPL/GPL
Ben Bucksch wrote: There is a clause in the MPL saying that AOL is allowed to update the license. Nowhere is specified how that update has to look like. That is not the clause I mentioned. From the clause that you are referring to, the only part that is of interest to me in this regard, is section 6.2 Effect of New Versions which allows me to choose to use such Covered Code under the terms of any subsequent version of the License. Ironically, Bjorn cannot use that clause, because the clause mentions AOL specifically, not the initial developer. Thus, what Bjorn described above is illegal, I believe. Here is the clause that I mentioned (from MPL 1.1). It explictly says the Initial Developer. quote 13. MULTIPLE-LICENSED CODE. Initial Developer may designate portions of the Covered Code as 'Multiple-Licensed'. 'Multiple-Licensed' means that the Initial Developer permits you to utilize portions of the Covered Code under Your choice of the NPL or the alternative licenses, if any, specified by the Initial Developer in the file described in Exhibit A. /quote
Re: LDAP C SDK 5.0 MPL/GPL
Stuart Ballard wrote: Hang on... if you are using MPL/BSD (so long as you mean modified-BSD, that is, without the advertising clause - which is the only verson GPL-compatible) then you can still create a GPL fork: 1) Use the program under the terms of the BSD license, 2) Link in some other code that is GPL'd 3) Release the combined software as GPL If MPL had been GPL-compatible, then you could have done the same with purely MPL covered code. There is a subtle difference between the GPL fork you are talking about and the one I am talking about. With an MPL/BSD dual-license my code will remain under either MPL or BSD, regardless of what the combined software is released as. With an MPL/GPL dual-license my code can become GPL-only, which would be against my wishes. Also, I don't quite understand the benefit of a MPL/BSD dual license. Surely everything that is permitted under the MPL is also permitted under BSD, so MPL/BSD is just equivalent to BSD by itself? There is no benefit per se, and none were intended -- it is all about legalism. The code was originally released under MPL. Years later the contact to many of the contributors had been lost, and it was thus impossible to ask their permission for a change of license to solve the GPL-incompatibility problem. Instead, section 13 Multiple-licensed Code in MPL 1.1 was used to create a dual-license.
Re: LDAP C SDK 5.0 MPL/GPL
Michael Hein wrote: Do you mind posting the dual MPL/BSD you used the more I learn about GPL this seems quite attractive You can find it at http://curl.haxx.se/docs/copyright.html Another example is (see question 1) http://xmlsoft.org/FAQ.html Daniel Veditz raises the question about a BSD-like license being too permissive, and indeed it is. I am also convinced that it will spark discussions as Daniel mentions. However, the experience from the two above-mentioned projects is that proprietary projects, which uses your BSD-like covered code, will usually contribute their modifications back voluntarily. One motivating factor is configuration management -- it is much easier to upgrade to a new version of the open project, if the modifications have become part of the Open project. It is also the experience that such contributions, as they are made by professional developers, are of a high quality. Then there is the pervasive fear in the Free/Open Source community that proprietary companies will steal the code (that is, extend the code without contributing anything back). This has certainly happened in the past, and will certainly happen again. However, this is not necessarily a bad thing. If they build upon your code, then you have less work to catch up, than if they made their own, and most likely, incompatible implementation.
