|[ IWETHEY ]|
[ Licensing Philosophy ]
(1/25/00 9:53:38 pm)
|Interesting summary of the various licenses|
Discusses why the Enhydra team is planning on changing from a BSD (Enhydra core) / GPL (XMLC) license to one very similar to the NPL - and makes sense to me. One thing I would add - they think if a commercial Enhydra add-on becomes popular, an open source equivalent will get made - and then the commercial company will have to move on.
I think a good commercial s/w company could also stay in business by improving their code, and most importantly, basically providing service for the cost (possibly releasing it under an open source license). Service could include good documentation, good tech support, and thorough testing. In a way, I think this is Lutris' strategy - Enhydra is used as the basis for a lot of their work, and it's also free advertising for their services, since they're the experts in it.
(1/26/00 3:01:29 am)
|MozPL v. NPL|
There are some very important and non-trivial differences between the Netscape Public License, and the Mozilla Public License, which is what Enhydra are basing their own license off of. Though commonly abbreviated NPL and MPL, I prefer MozPL to exaggerate the distinction between the two.
Most importantly, the NPL allows changes from third-party contributors to be relicensed under proprietary terms, by the original license issuer (e.g.: one named party). MozPL does not -- developers essentially share more-or-less equally in their power under the license. MozPL is a pretty good commercial license. I think.
(1/26/00 4:21:08 am)
|Re: Interesting summary of the various licenses|
Haven't read their link yet, but here's my read on their license:
Enhydra is releasing their Enhydra Server under the EPL, which is apparently based off of the MozPL 1.0. http://www.enhydra.org/software/license/index.html http://www.enhydra.org/software/license/epl.html Obvious changes from MozPL 1.0: - 3.2 Requirement for original developer notification: >>>>>>>> add You are responsible for notifying the Initial Developer of the Modification and the location of the Source Code if a contact means is provided. Lutris will be acting as maintainer of the Source Code and may provide an Electronic Distribution mechanism for the Modification to be made available. You can contact Lutris to make the Modification available and to notify the Initial Developer. ( http://www.lutris.com/ ) ======== You are responsible for ensuring that the Source Code version remains available even if the Electronic Distribution Mechanism is maintained by a third party. <<<<<<<< delete - 3.6 (Distribution of Executable Versions) added language to end: If you distribute executable versions containing Covered Code, you must reproduce the notice in Exhibit B in the documentation and/or other materials provided with the product. - 6 (Versions of the License) Several reference changes from Netscape, etc. to Lutris, etc. - 11 (Miscellaneous) -- Jusrisdiction same, venue moved to San Francisco county from Santa Clara County. Same arbitration authority is retained, FWIW -- JAMS/EndDispute. - Exhibit B -- new section noting that derived product contains the original work. Looks like a trademarks and liabilities rider from their legal team. ------------------------------------------------------------------------ Commentary: First, the choice of MozPL 1.0 rather than 1.1 denies Lutris of a number of useful changes to the MozPL, in particular the termination language of MozPL 1.1 which provides significant power to individual developers, and the dual licensing provisions. The 3.2 change is a gratuitous addition which potentially creates downstream obligations to Lutris for diverse projects licensed under EPL. Specifically, if the EPL becomes widely adopted, a large body of work emerges which is obliged to notify Lutris of updates and modifications. This is unlikely, but annoying. The clause is a change above and beyond the venue and license version data which must be changed in any adaptation of the MozPL 1.0 or 1.1. The 3.3 language and associated Exhibit B are somewhat similar in nature to the BSD advertising clause. I'm not sure they're inherently bad, but there is little additional information (and potentially little relevance) to the Exhibit B notice. It strikes me as extraneous. The section 6 language is an obligitory change. I'd say the same for section 11, except to note that the distinction between San Francisco and Santa Clara counties seems almost sufficiently small to have allowed the latter to stand. Still, a likely dimension of variance. EXHIBIT B appears to me to be entirely redundant and an unnecessary deviation from the MozPL: - Trademarks can be dealt with externally to the software license, and there is no need to reference the external document. A notice that no right to trademarks of the original or contributing developers is granted should be sufficient. See MozPL v1.1 2.1(a) and 2.2(a), and AMENDMENTS. - The copyright notice is already included in Exhibit A, which is required for binary distribution under 3.5. - The disclaimer of warranty duplicates what is already in the license. It is also not multilateral, and provides uneven protection to Lutris vis-a-vis third party contributors to the codebase.
(1/26/00 10:34:45 am)
|Why don't you pass this on to them?|
IIRC, the web page said they're still considering the details and are open to suggestions.
(1/26/00 2:40:20 pm)
|Submission address bounces|
I did. Actually, what I pasted in was something I wrote for YALG (yet another licensing group), but felt might be of interest here.
The email address for feedback listed at the website appears to be broken.
| Email this to a friend|
Topic Commands (Moderator only)
CREATE A FREE POLL NOW
ezboard Ver. 5.072
© Copyright 1998, 1999