Yes
unixODBC and DB2
It's easy enough for that.
Bill
> -----Original Message-----
> From: Ricardo [mailto:r00tzz@yahoo.co.uk]
> Sent: Thursday, February 07, 2002 9:19 AM
> To: wine-devel(a)winehq.com
> Subject: Example of ODBC and wine
>
>
> has anyone used wine with a program that conects to an ODBC
> database? How
> have you set this? I was thinking about FreeTDS but i
> configured it and
> doesn't know what to do nexe. Any help?
> Thanks
> …
[View More]Ricardo
>
>
>
>
>
[View Less]
[Oh, no here we go again]
> Some recent events have occurred that have made me change my opinion
> about a Wine license change.
I see.
> During my involvement in the Wine project, I have always striven to
> make sure that I, and my company, did what was best for the Wine
> project.
Before I critize you to much. I would like to point out for the record
that I do believe that you and Codeweavers as far reasonable possible
have done what you claim and that you have my gratitude …
[View More]and respect for
that.
However remember that: "The road the hell is paved with good intentions."
> I believe Wine's success will help to make the world a
> better place.
Partly agreed. I believe that people moving from Windows to Unix is
a good thing and that Wine (or Wine like projects) are among the nessary
tools to acceive this. It is not the only tools though.
> To that end, often through difficult personal
> negotiations, I have always insured that all of my contracts require
> that all code changes be returned to Wine. This, in effect, treats
> Wine as an LGPL product.
You have my respect for that as explain above. However I'm not
entirely convince that this always is a good thing. It is a probably
a good strategy by average but do not believe it is always the
right thing.
In military terms:
A strategic retreat is often good,
eventhough retreat as a strategy is not.
> You can argue that the flexibility granted by the Wine license has
> meant that I received some business I would not otherwise have had.
> Gav, for example, has pointed out that Corel would never have worked
> on Wine if not for its license. There are two ironies there - first,
> Corel has always been a great Wine citizen, IMO, never 'abusing' the
> license. Second, while we did work with Corel to help them with Wine,
> we never signed a contract with them. Their lawyers and I were never
> able to agree on a contract that we thought would sufficiently protect
> Wine. Fortunately for me, we were able to work with Corel without a
> contract, but this issue to this day creates unnecessary friction
> between my company and Corel.
Read that Gavriel have written again. Surely you must realize that
there is a difference between:
1. Specificing a goal in the beginning and be legally forced to stick to it
until the end no matter what.
2. Specificing a goal in the beginning and be legally able to retarget when
reallity didn't turn out as you expect.
There is a difference between striving to do good and being forced to do
good because of an earlier promise despite the fact that reality has
changed.
> However, with some recent events I cannot disclose, it is clear to me
> that the opportunity for Wine to be used in a proprietary product is
> too tempting and has caused some harm to the Wine project. Based on
> experience, I feel strongly that the potential for harm is great
> enough that CodeWeavers needs to take two actions. First, we would
> like to release all new code we develop under an LGPL style license.
> Second, I would like to open another call for a license change and
> thereby strongly add my voice to Alexandre's.
Luckily for you your credibillity is pretty high. Normally I immediately
raise the red flag of warning then I heard claims made referring to
undisclosed information.
I understand that you are worried about the future but don't let your
fears drive you onto the wrong path.
> Thus, I would like to call for a change in the Wine license. I think
> we all agreed that the LGPL formed the basis for a good 'alternate'
> license strategy. Eben Moglen, the counsel for the FSF, has kindly
> offered to help review licensing strategies for Wine. The goal is to
> attempt to secure some form of Copyleft protection for Wine while
> still permitting proprietary software to link and bind with Wine. I
> think it it is great that we have, in Eben, not only the leading legal
> scholar on free software licensing, but a great hacker to boot. I
> think he will clarify exactly what is possible and what is not
> possible with GPL style licenses and insure that the license we choose
> will meet our goals.
Talking to Eben can only help. However we need to very careful to specify
not only what we want to acceive but also and MUCH more importantly
what we want to _avoid_ the license from accidently preventing.
So what do you want this new license to acceive?
And the much more important question what do you want to avoid the
license from accidently preventing?
> When Alexandre last brought up this issue, he was very disappointed.
> He felt that there was not enough support from the 'silent majority'
> of Wine developers for a license change. His overriding lament to me
> was 'No one cares'.
I care.
> He further felt that since a small number of
> major Wine contributors objected, that it was not appropriate to
> change the license.
>
> I would like to ask for a more formal process. I would like each and
> every contributor to Wine to send Alexandre a private email with an
> 'Agree' or 'Disagree' opinion, so that he can more truly assess what
> the contributors to Wine really want. The specific question I wish to
> pose is as follows:
>
> Should the Wine project switch to a license which has as
> its goal to attempt to secure some form of Copyleft
> protection for Wine while still permitting proprietary
> software to link and bind with Wine?
>
> Please privately let Alexandre (julliard(a)winehq.com) know what you
> think, and then publicly respond to this thread as you feel
> appropriate.
Done.
> Finally, in closing, I wanted to summarize our position. We plan to
> release our future work under an xGPL style license, and we would like
> the rest of the Wine community to join us. If the bulk of the
> community wants to stick with the current license, then we will
> probably end up making a separate CVS development tree. Anyone would
> be free to use our work from that tree, under the xGPL-style license
> terms the FSF's lawyers recommend.
Is that a threat or what?
Hmm. I think I will intrepret is as symptom of your fears and advise
you to try and avoid acting in a hastely manner.
By all means start a dialog the FSF lawyers, but don't do anything
you might later regret.
[View Less]
Speaking of conferences, is anyone planning on going to FOSDEM (16th
& 17th Feb, Brussels) ?
--
Keith Matthews
Frequentous Consultants - Linux Services,
Oracle development & database administration
has anyone used wine with a program that conects to an ODBC database? How
have you set this? I was thinking about FreeTDS but i configured it and
doesn't know what to do nexe. Any help?
Thanks
Ricardo
I like the LGPL and all, but I think converting to this license will hurt
greatly the current projects such as Lindows and Transgaming and, in
proxy, hurt wine. Mindshare is important, and to see Wine in succesful
projects helps people to realize it as a viable product.
I don't think anybody is turned off from developing wine with its current
license, but the change would turn away many I'm sure. Some people get
thier paychecks working on Wine (Transgaming). I think TG has done great
things …
[View More]for Wine, and I wouldn't have supported them had they not promised
to release thier changes back to the main wine tree.
Lindows, however, can eat it. By not intending release thier changes and
to sieze the Wine code to make it thiers for profit, I cannot, and will
not support them.
What I would like to see is a new licence that sees that all forks move
back into the main wine tree at regular intervals, say, after 6 months or
a year while still allowing companies to do what they will with the code.
We aren't looking to stifle innovation here, I like the TG subscription
model, and I would probably contribute in that kind of fashion to many
projects, but there must be an incentive to do so (like TG's DirectX work)
I am against a change to LGPL, but I realize the current license is
allowing lindows to stand on the shoulders of giants and wearing a long
overcoat to cover it up, and that is just wrong.
Dave Jones - dajones(a)purdue.edu
[View Less]
Just a quick question that I haven't seen addressed:
If the license is changed to LGPL, who will own the copywrite? The
contributors, or the Wine Project?
-Rob
Folks,
Some recent events have occurred that have made me change my opinion
about a Wine license change.
During my involvement in the Wine project, I have always striven to
make sure that I, and my company, did what was best for the Wine
project. I believe Wine's success will help to make the world a
better place. To that end, often through difficult personal
negotiations, I have always insured that all of my contracts require
that all code changes be returned to Wine. This, in effect, …
[View More]treats
Wine as an LGPL product.
You can argue that the flexibility granted by the Wine license has
meant that I received some business I would not otherwise have had.
Gav, for example, has pointed out that Corel would never have worked
on Wine if not for its license. There are two ironies there - first,
Corel has always been a great Wine citizen, IMO, never 'abusing' the
license. Second, while we did work with Corel to help them with Wine,
we never signed a contract with them. Their lawyers and I were never
able to agree on a contract that we thought would sufficiently protect
Wine. Fortunately for me, we were able to work with Corel without a
contract, but this issue to this day creates unnecessary friction
between my company and Corel.
However, with some recent events I cannot disclose, it is clear to me
that the opportunity for Wine to be used in a proprietary product is
too tempting and has caused some harm to the Wine project. Based on
experience, I feel strongly that the potential for harm is great
enough that CodeWeavers needs to take two actions. First, we would
like to release all new code we develop under an LGPL style license.
Second, I would like to open another call for a license change and
thereby strongly add my voice to Alexandre's.
Thus, I would like to call for a change in the Wine license. I think
we all agreed that the LGPL formed the basis for a good 'alternate'
license strategy. Eben Moglen, the counsel for the FSF, has kindly
offered to help review licensing strategies for Wine. The goal is to
attempt to secure some form of Copyleft protection for Wine while
still permitting proprietary software to link and bind with Wine. I
think it it is great that we have, in Eben, not only the leading legal
scholar on free software licensing, but a great hacker to boot. I
think he will clarify exactly what is possible and what is not
possible with GPL style licenses and insure that the license we choose
will meet our goals.
When Alexandre last brought up this issue, he was very disappointed.
He felt that there was not enough support from the 'silent majority'
of Wine developers for a license change. His overriding lament to me
was 'No one cares'. He further felt that since a small number of
major Wine contributors objected, that it was not appropriate to
change the license.
I would like to ask for a more formal process. I would like each and
every contributor to Wine to send Alexandre a private email with an
'Agree' or 'Disagree' opinion, so that he can more truly assess what
the contributors to Wine really want. The specific question I wish to
pose is as follows:
Should the Wine project switch to a license which has as
its goal to attempt to secure some form of Copyleft
protection for Wine while still permitting proprietary
software to link and bind with Wine?
Please privately let Alexandre (julliard(a)winehq.com) know what you
think, and then publicly respond to this thread as you feel
appropriate.
Finally, in closing, I wanted to summarize our position. We plan to
release our future work under an xGPL style license, and we would like
the rest of the Wine community to join us. If the bulk of the
community wants to stick with the current license, then we will
probably end up making a separate CVS development tree. Anyone would
be free to use our work from that tree, under the xGPL-style license
terms the FSF's lawyers recommend.
Thanks,
Jeremy
[View Less]
> Is this correct that tests are made to compile Wine on MSVC?
Only on a small scale, nothing really serious yet.
> What good
> is this for? I thought Wine should be an emulation of windows
> code on a
> Unix platform, what good is it to run Windows on Windows?
>
> Just being curious. :)
Well. I qoute myself:
"It would be quite nice to have all non core DLL compiling and
working and with winetest ported. Then you could just run winetest
through the debugger and be …
[View More]able to set breakpoint and step through
the code in Visual Studio in order to get all to tests to run properly. :-)"
Also note that this would make it possible to debug each dll in an
enviroment where all other DLLs except the DLL tested were real
Windows DLLs.
[View Less]
Is this correct that tests are made to compile Wine on MSVC? What good
is this for? I thought Wine should be an emulation of windows code on a
Unix platform, what good is it to run Windows on Windows?
Just being curious. :)
> >Eventually I guess that the non-core DLL:s never should call any
> >non Windows functions at all and the core DLL:s are not really useful
> >to compile and run under Windows anyway.
>
> Well I have only played with the shell32.dll and in any file
> in there except
> "shelllink.c" removing "unistd.h" entirely had no negative
> effect whatsoever.
> This means to me that it is not needed at all. The use of
> fork(), execvp(), and
> waitpid() in "…
[View More]shelllink.c" however seems to require the
> "unistd.h" header.
>
> I'm not sure if shell32 should be considered a core DLL. It
> seems to me
> rather not.
shell32 is not really a core DLL eventhough it is
a borderline case since some functionallity might
want to intergrate with the desktop.
However, it definitly should compile under Windows at least
with limited functionallity.
> The desired operation could be possibly achieved
> with the use
> of Windows kernel functions as well.
Possibly, but it looks a little Wine specific to me.
I'm not 100% sure what the code does.
Anyway, we could always choose to exclude that code
on Windows. It would be useful to run test on the
rest of the functionallity in any case.
[View Less]