Updated license - please comment

[Christophe Dupre]

Hello Mark,
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    dagon at dagon.net    <http://www.dagon.net/>  

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3