Re: License issue, and a possible solution

On Mon, Apr 26, 2004 at 03:43:55PM -0600, Kurt Fitzner wrote:
>
> 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.

That is also how I would interpret it.  However, as I mentioned
before, intentions can change and projects can change hands.  So we
still cannot afford to stake our business on good intentions that the
contracts and licenses do not back up.

> >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.

It would probably be an improvement and lessen the legal risk in the
short term, but I don't think it would solve the problem.  I explain
below.

> >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.
> 
> 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.

I get the impression they are planning to gradually change the license
on every file they can.  As of the first release under the new license
there were 206 files changed.  Here is a list of the ones that were
not under the server tree.

config/util/cleanlinks.sh
config/util/revpath.c
include/Xdefs.h
include/extensions/xf86misc.h
include/extensions/xf86mscstr.h
include/fonts/fontproto.h
lib/GLw/Imakefile
lib/GLw/GLwXm/PrimitiveP.h
lib/GLw/GLwXm/Xm.h
lib/GLw/GLwXm/XmP.h
lib/GLw/GLwXm/XmStrDefs.h
lib/XRes/XRes.man
lib/Xfontcache/Xfontcache.man
lib/Xp/XpExtUtil.h
lib/Xss/Xss.man
lib/Xxf86misc/XF86Misc.c
lib/font/FreeType/module/ftmodule.c
lib/font/Speedo/module/speedomod.c
lib/font/Type1/module/type1mod.c
lib/font/X-TrueType/module/xttmodule.c
lib/font/bitmap/module/bitmapmod.c
programs/fstobdf/fstobdf.h
programs/twm/session.h
programs/xfs/include/difs.h
programs/xmag/CutPaste.h
programs/xmessage/readfile.h
programs/xmessage/xmessage.h


Even assuming good intentions, and that they were willing to change
the license back on the headers, the fact that this issue was not
addressed in the beginning is a sign of legal irresponsibility on the
side of the XFree86 project.  With hundreds of the files under the new
license you still cannot trust them not to allow the new license to
slip into headers and code that gets used in applications.  Even
having any files at all in the X tree under the 1.1 license creates a
risk for distributors.  We would have to parse every source file in
every X application we distributed to identify X headers or other X
code and cross reference it to the X code verifying the license.

Assuming good intentions, I really don't see what they are trying to
accomplish.  X is a big package.  If the intentions are good, is it
really worth all this effort just to have better author attribution
where it comes to applications that past code from the core server?
I doubt it.  That is why I have a hard time believing it will be
limited to the core sever code.  And judging by the list if files
above, it appears that it isn't.

So, changing the license back on the headers and other non-server
specific code would lessen our risk in the short run, but having this
new license on any part of the project puts us at too much risk in the
long run.  We cannot stake our business on their responsibility to not
apply the new license in files that get over looked by us and authors
of third party applications.  

Basicly, I do not see any complete solution other than switching the
top level license back to the original and not allowing any of the
files to fall under a license that is incompatible with the GPL or
similar licenses.

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
Read how Network Solutions (NSI) was involved in stealing our domain name.
http://www.InetAddresses.net