Re: License issue, and a possible solution

Vincent wrote:

> Please show me a quote from the actual license that says this.
> Also, even if the client libraries are not affected, in order to use
> them, you must include the related headers which are being changed
> over to the new license, which would create a derived work where your
> application includes code with the new copyright.  Again, I see no
> provisions in the licenses to accommodate this.

Well, there is nothing in the actual license itself that says the old 
license applies to the client libraries.  Just that the client libraries 
are released with the old license, and the server is released with the 
new license.

As far as headers go, I would think (and this is "Doctrine According to 
Kurt" (tm) here) that any header you need to compile X client software - 
that is software that uses the X client libraries - would be included 
under the old 1.0 license, as per their commitment to release the 
libraries themselves under the old license.  I would think that any 
instance of the new license in headers that are needed for client 
libraries is a mistake.  This is my own interpretation of their 
intentions, though.

Anyone else - can we get some clarification on this please?  Whereas the 
license FAQ states:

     "To avoid issues with application programs such as KDE and GNOME
     and other X-based applications, that are licensed under the GPL,
     the 1.1 license is not being applied to client side libraries."

Does this mean that the headers required for compiling against the 
client libraries are also supposed to have the old 1.0 license?

>>Sorry, this is too clever for me to grok.  "It would not be widely known 
>>if it stated it in the license" ??? It is what it states in the license 
>>that counts, as far as I know.
> 
> 
> You misread my statement.  Please re-groke the word "unknown" :-).

Ya, I think my language parser signal 11'ed sometime reading.  My bad.

  8< Bunch of stuff snipped to get to the heart >8

> First, if binaries only are distributed then, again, these binaries
> are linked with code and headers that have the new licenses.  I looked
> at the diff of files that have already been updated with the new
> license and a lot of the headers are included.

 From what I'm reading, then, a lot of the issue resides around the 
status of the headers.

If there were no ambiguity with the headers, then it would seem to me to 
solve the issue of there potentially being a lot of non-compliant software.

>>From one of my previous postings:
> 
> We believe the entire problem lies in the two statements,
> 
> "in the same place and form as other copyright, license and disclaimer
> information"
> 
> and
> 
> "in the same form and location as other such third-party
> acknowledgments"
> 
> It is "the same form and location" that makes the new license very
> different from all other open source licenses that we know of.  As a
> distributer, you cannot guarantee this kind of compliance for every
> application you include.

True.  But, if the client development headers were all unambiguously 
under the 1.0 license, would this address your concerns?  To my 
thinking, if this were the case then the only area for concern would be 
people who take server code and use it in their software.  They would, 
then, need to add attribution of that code.

>>>I also find it interesting that when David Dawes was directly asked in
>>>one of the earlier postings for examples of where the X licenses has
>>>been abused or where anybody had tried to falsely claim credit for the
>>>code, I never saw any reply.  Please feel free to direct me to it if I
>>>overlooked it.  Since author accreditation was their whole excuse for
>>>the license change, I am in question of their true motives.
>>
>>The whole point is, they'd never know.  Who knows if Hummingbird ripped 
>>off Xfree code.  I dunno.  Do you?
> 
> 
> No, I don't, and that is why I questioned their motives.  If while
> looking at every commercial system out there that includes Xwindows,
> there are no known violations, then why the sudden concern now after
> all these years?  Xwindows and BSD have been going strong for all
> these years without having such a license restriction.  Since it is
> unlikely that vendors could fully comply with the new license as it is
> worded, it opens the door for a major legal attack, in the future,
> much worse the the SCO one.

True.  But (at risk of sounding very repetitive) this seems to all hinge 
on the status of the headers.


>>If you are questioning their motives, perhaps you can offer a suggestion 
>>as to what you think the "real" motives are.
> 
> 
> This new license is a perfect setup to have everybody violating the
> license so that a company such as SCO or Microsoft can step in in the
> future and slap down all commercial distributions of free software.
> We are already seeing the first attempt at this with the SCO/Caldera
> lawsuits.  This situation could turn into something far worse.
> Obviously we are not the only ones who see this going by the response
> of the other major Linux and BSD vendors.

Honestly, I don't think this is the motivation of XFree86 Project Inc. 
While I can't honestly say for a certainty what their intention is, I 
don't read anything malicious or underhanded in it.  There has, I think, 
been a lack of communication, and perhaps people getting their 
proverbial knickers in twists, and the change might even have been 
unwise.  But I honestly don't think it was done for any malicious 
intent.  This is, though, completely a matter of opinion - my 
interpretation of what I have read.

> It is possible they were contemplating the change already but I don't
> think that is the issue.  I see this license as a very big change
> compared to the original MIT license.  We had not even considered
> changing from XFree86 before this license issue.  And we are strong
> believers in giving credit where credit is due.

Well, let's try and get some official clarification on the headers, and 
then maybe this will allay some concerns - perhaps more than just yours.