I've just re-read the OSD document, and I'm not sure we read the same one. You claim that 2a and 2d are unacceptable and violate OSD#3.
OSD#3 is not violated: you can change the code, you can distribute those modifications. #3 doesn't say that it needs to be completely unrestricted. In particular, anyone could decide to fork the code and maintain their own tree.
2(d) is important IMHO, and prevents modifications that would cause the library to become a hollow shell, a wrapper around a closed source library.
One library that would be released is a finite element mesh database. Suppose that someone has a nice but closed source library that provides attachable data capabilities. That someone might want to be able to attach data to mesh entities, but that would require hooks in the library which would call the closed source facilities. Even if the changes are released as opensource, they are useless without the closed source library, and as such would not be acceptable. The LGPL has the same limitation probably for the same reason.
OSD#6 refers to type of users (commercial, business, religious zealot) and fields of endeavour (biotech research, gaming, CAD, etc). Our license has no such limitation, and 2(a) seems to have nothing to do with OSD#6.
For OSD#8, as far as I know 'software library' is not a specific product. The license doesn't restrict the covered software to be part of a specific distribution (or prevent the software from being packaged in a distribution). The license would allow Red Hat to package the library in Red Hat Linux v11 if they so wish. The software distributed under this license would not be part of any specific distribution, or package, so OSD#8 doesn't seem to apply.
I think you're ready a bit too much in the open source definition.
Mark Rafn wrote:
On Wed, 18 Jun 2003, Rod Dixon wrote:
This version seems fine, given what we were told about the license last time. I read this license to have the same or similar purpose as the LGPL, and in that respect section 2(a) seems permissible. It is a slight restriction that could have a strategic purpose, but the author says the limitation is consistent with the LGPL and that sounds fine. It might be more acceptable if the provision did not impose a mandatory requirement, but, instead, used a permissive condition. Still, I do not see the issue as an OSD matter.
Am I the only one who thinks 2a and 2d are unacceptible? It violates OSD#3 by limiting the type of derived work, perhaps OSD#6 by limiting itself to creators of software libraries, and perhaps OSD#8 by being specific to the product "software library". As far as I can tell, it prevents anyone from distributing an application that statically links the library into it (if such an application is a derived work of the library, at least).
It doesn't even seem close to me. Let me know if I'm insane, or reading it wrong, but I can't see how such a restriction can be considered open source.
I know they're straight from the LGPL, but they are irrelevant there because the LGPL is a pure superset of the GPL (see LGPL section 3), unlike the license under discussion.
Yes, this indicates that I think the LGPL without section 3 would be non-open-source.
--
Mark Rafn [EMAIL PROTECTED] <http://www.dagon.net/>
-- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
