CryptoAPI

[Patrik Stridvall]

> > Beside the GPL doesn't cover use, only distribution, so if the user
> > would install a Winelib that uses a GPL library that would be
> > completely legal as far as that user would be concern despite the
> > fact that he has a non-GPL:ed application that uses Winelib.
> 
> Hmm, if only distribution is covered, then can we still write 
> code for a GPL 
> library (use) as long as the library isn't shipped with wine 
> and test for it 
> on the user's system?

Well, actually since the Wine license is GPL compatible that is
not a problem either.

The problem is that some 3rd party might use Winelib for
an application that has non-GPL compatible license.

See below.

> > However Alexandre has clearly expressed that he doesn't want Wine
> > to be a legal test bed, if not primarily for the legal issues, so
> > because he doesn't want an unsuspecting company using Winelib be
> > "cruficed" on Slashdot or wherever for alleged GPL violation. :-)
> >
> > While I, in some meaning, agree, I do not believe that we should
> > refrain from doing so because of fear of what might never be.
> > Obviously we should turn off the use of any GPL:ed library 
> by default.
> 
> I tend to agree with Alexandre and suggest little or no work 
> in this area 
> proceed until the legal debate is over.  It seems only best 
> for the project 
> to avoid the possibility of legal action against us, 
> especially for something 
> we don't fully understand.

As far as the Wine source code is concerned the debate as over as it
can be without a real court case. The Wine license is GPL compatible
so saying that the Wine source code violates the GPL is ridiculous.
So what you have to claim is that the Wine source code facillitates
others to violate the GPL. This is ridicioulous too for other reasons,
foremost because none of requirements of contributary or vicarious (sp?)
is even remotely fullfilled.

As far as the binaries are concerned, well, the Wine project itself
doesn't distribute binaries so it doesn't matter as far as the
project is concerned. OK it links to others binaries but claiming
liabillity for that is ridiculos too.

So far the Wine project. As for other people, well no one really
knows since there are very few (if any) relevant court cases on
the subject.

However consider this, that is actually not a hypotetical
situation at all. Even if it is, it still illustrates an example.

IIRC when Corel ported Corel Office it used some sort of
font rendering library made by Bitstream IIRC. The library cost
money to use, but the use of library was optional. If you
had it was used if not you didn't get as good fonts as
otherwise.

So does Corel Office violate Bitstream's copyright?
Obviously not, no sane court would claim that and beside
Bitstream haven't and won't sue because they benefit from
the sitution since now consumers has one more reason to
buy their product. Beside that will make it a much harder
for them to show damages since their are none.

That covers pretty much the use of all normal commersial libraries.
In short they have no reason to sue and no chance of success
either.

Now enter the GPL. The problem is that GPL has an entirely
different goal than normal commersial licenses.

The commersial library developers wants as many users as possible
since each legal user pays money for their product and even
illegal users might help them to make the library more
widely spread and more of a defacto standard that will
likely generate more users (both legal and illegal) in the
long run. Note that they normaly don't care what license any
user of library distributes his code under either.
In short they don't make any difference between different
users as long as they are paid.

The copyright holder a GPL:ed library on the other hand have no 
intrest in that software under non-GPL compatible licenses uses
their library. This is a fundmental difference. On the other
hand the GPL is a distribution not a use license. Paradox? :-)

I could speak about this much longer but the point what is
legal or what is not is entirely dependent on:
1. Is the GPL is virus that can infect users of the code?
2. If it is a virus, to what extent does the infection spread.

Put is another way: GPL:ed libraries discriminates again
different kinds of users (developers and end user). The
commersial libraries does not normaly do that.

Whether and how far copyright law permits this is IMHO one
of the most fundamental unresolved questions for open source
software development.

Even worse. Note that a ruling a _either_ direction have
enormous implications for the future of open source
software so keep that in mind. 

"United we stand, divided we fall."

Another small note if you are less hostile to the GPL you
could say that the GPL is not a virus it is a contract.
However all copyright is a contract between the author
and society question what contract takes predence is
still revelant and unresolved.

However if you see the problem with Wine project use
of GPL:ed for a contract perspective you could in
addition argue that you never have accepted the
contract since you didn't have to since you didn't
redistribute or modify the library and claim Wine
and derived work of the library is rediculous.

> > Anyway, unless or until Alexandre changes his mind, I think that
> > you should submit all general code that needn't use a specific
> > library and distribute that rest as a patch. Preferable so
> > that Winelib could dynamically load it so it could be
> > distributed seperately in binary form as well.
> 
> Hmm, I never thought about libgcrypt, but if we can somehow 
> use it legally 
> then it could be a possible back-end as opposed to or 
> inconjunction with 
> OpenSSL.  Naturally, I would prefer not to re-invent the 
> wheel by having to 
> re-write every needed algorithm used in the M$ API, if we can 
> find a library 
> that is legal in all circumstances :-!

Use of all normal commersial libraries are "legal" as shown above,
at least if you only distribute your Winelib application.
Only the GPL and similar viral license can be a problem.
 
> But has anyone considered the following:
> -Writing code that interfaces with either OpenSSL or 
> libgcrypt depending on 
> what the USER (or any winelib developer) requires AND has 
> installed on their 
> system.  Providing this is legal.  From what I understand 
> this *should* be 
> legal long as we're not DISTRIBUTING whatever is illegal to do so.

Most probably yes. The only issue as I can see it is how far the
GPL extends.

> -Use OpenSSL by default if it is more compatible with our own license.
> -Disabling the cryptoAPI to winelib developers by default to 
> make them aware 
> of these issue and allow them to choose the interface that 
> matches their 
> requirements.
> -Provide adequate documentation that discusses these points 
> and touches the 
> legalities of this software.
> 
> One thing we should probably do no matter what is contact the 
> developers for 
> both OpenSSL and libgcrpyt and make them aware of out situation. (and 
> possibly see which one or both is willing to bend on their 
> license(s)).

That is probably a good idea.

> Oh and one other possibility may be to find a way to modify 
> our own license 
> such that it fits this problem.

Since only GPL libraries AFAICS can be a problem and our license
it already GPL compatible that not possible (or needed).

> However, I'm not sure how 
> willing Alexandre 
> or any of us are about doing this (...again?, I think it's 
> has been done 
> before).

Well I don't know. Ask him. However he is currently away
so that will have to wait I guess.

Anyway what you suggested above is fine by me.