Re: License issues

On Wed, Mar 10, 2004 at 10:49:43AM -0500, David Dawes wrote:
> On Wed, Mar 10, 2004 at 12:18:49PM +0100, Sven Luther wrote:
> 
> >Now, what policy i would like to see, well, the previous one is fine,
> >but i guess that GPL compatibility would be a must, at least on those
> >parts who have vocation to be linked with GPLed code. The client side
> >libraries at least, and you have said you will not apply the licence
> >change to those. the SDK is also problematic, but to a lesser amount,
> >and well, if someone is willing to write a driver for xfree86, then he
> >is welcome to do it in a licence xfree86 can also use.
> >
> >So, all in all, a stronger and official commitment that the client side
> >libraries will not be GPL incompatible in the future would be a good
> >addition to the policy.
> 
> So you would not prevent so-called "probematic" licences, acceptable
> under the long-standing policy, from being used elsewhere.  These
> very same problematic licenses that you previously said would be
> "freed, replaced or riped (sic) out."  Now I'm not really sure where
> you stand.

Err, let's stay in context.

As you probably don't know, i have been arguing outside of here, that as
long as the client side libraries are not made GPL uncompatible, that no
major problem exist. I have even been almost convinced about the SDK
issue, you did notice that altough i first raised the point, i didn't
pursue it, but more to this below.

The "freed, replaced or riped out" comment, well, this is what i believe
will happen, as has always been the case, if there is a definitive
divorse between the XFree86 Project's code base, and the rest of the
free software/open source world.

> >But what you did is a change, a change that is problematic, and there is
> >really no reason why you should deny it.
> 
> You cannot have it both ways.  Either licences of this type are
> acceptable (outside the client libraries) under the licensing policy
> or they are not.  So either the change is within the policy, or it
> is not.  I don't believe the change to be problematic.

I believe they are acceptable, but problematic, maybe it is because i am
not a native english speaker, but i see a difference of degree between
something that is unacceptable and somewhat that is problematic.

That said, i believe that the latest move is contrary to the flow of
things currently, and as thus not advisable to take. I have said before,
and i believe that it was a reaction to some perceived threat or
power-grab attempt, or something such. I may be wrong, i have no idea
to what internal problems lead to it, and nobody is talking, so ...
But even if that is the case, i think the licence change is counter
productive, and will win you nothing in the long run. This is my honest
feeling of how this is resented in the free software/open source
community, and i can only offer you this for your reflexion.

> My basis for that belief and for my surprise at the reaction to
> the change, is
> 
>    1) The change clearly fits within long established policy,

Yeah, well, maybe with the policy, but not with the practice or the flow
of the time.

>    2) Similar licences were in use in XFree86 before the change,

Well, similar ones yes, but somewhat different. Still, they were also in
use elsewhere, and are slowly being phased out, as their problems are
too handicaping over their very limited benefits. 

I don't understand why a phrasology like the "Provided due
aknowledgement is given" would not have been enough to achieve your
goal, unless it was to clearly stop one or more entities who are using
your code without giving said aknowledgement. Still, if that was the
case, you could have gained more PR points in decrying this situation,
over this PR disaster move that was the licence issue.

>    3) Those licences were clearly published in our licence document
>       for all to see, and
> 
>    4) All of the above was widely accepted as evidenced by the
>       absence of complaints about it.

I guess like always, this comes from practice that was acceptable 10-20
years ago, and nobody really bothered to look at it. Times change
though, and reviving such licences is, i believe, a regression.

> The big surprise to me was just how widely the existing licensing
> was apparently being ignored.  Are you really arguing that this is
> a valid reason for claiming the changes to be "problematic."  What
> is "problematic" is that past licensing abuses and policy
> inconsistencies elsewhere have been exposed, and that it is harder
> for them to continue now that this is public knowledge.

Nope, i don't believe that there is a deliberate attempt to ignore
problematic licence, and you will see, these will be freed, replaced or
riped out, like i said, now that they have come to attention. I guess it
is just that nobody really wanted to look at those issues.

> [The SDK issue is, BTW, a red herring.  A plain GPL driver could
> not, under the strictest GPL interpretation, be linked/loaded into
> the XFree86 server before or after the recent licensing changes.
> It would be dishonest at worst, and misleading at best, to imply
> otherwise.  That makes GPL compatibility of the SDK irrelevant.]

Well, i mostly agree with you, but for different reasons. I think the
argument you are making is counter productive, since it would apply also
to binary-only kernel modules, like the nvidia or ati proprietary ones,
and i don't think that is a terrain you will want to engage in (altough
i would gladly, i am still waiting for that Radeon 9600 powerpc drivers
needed to get the most out of that nice and shiny new powerbook i have
been eying lately :).

I believe this is not a problem because, well, apart from nobody having
written pure GPL drivers upto now, well, if they really want to use the
SDK for this, then they should abide by the rule of this.

If i ever finish my 3dlabs wildcat VP driver, i will probably place it
under a dual GPL/XFree86 licence myself, and have the same code shared
by the linux kernel fbdev driver.

Friendly,

Sven Luther