wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > Sure it is true that what people (read: companies) believe > is true is > > more important than what really is true. > > So, in fact, you indirctly agree that arguing about the doctrine of > derived work as part of this discussion is irrelevant. No, its not irrelevant because it will effect the advise the company lawyers give their clients. You seem to wish to use ignorance (or uncertainty) as weapon to protect Wine, but know this: Ignorance (or uncertainty) cuts both ways. Gav has said that Transgaming or for that matter Corel would have use Wine if it had been LGPL:ed. Perhaps this was because of ignorance, perhaps not. Anyway even if you would be able to convince Gav that he was/is wrong, you must realize that Gav IIRC have researched legallity issues extensively so it is entirely likely that somebody else spending similar resources would come to the same, in your opinion wrong, conclusion. In short: Ignorance (or uncertainty) is a dangerous weapon. > All you seem to be saying is that you think that the _spirit_ > of the LGPL > would be detrimental to Wine since it will drive companies away. > > Right? No. I have been trying to explain just because to are for the spirit of something it is not nessarily so that you support all possible means to acheive something and sometimes any acceptable means to acheive something might not exists. Do you support the spirit of: "Peace on earth!" Does it nessararily follow that you wish to accept any means to achieve this? Including, say, to be really extreme: "Nuke the middle east, then it will be peace there" and after enough nukes it probably WILL be peace, so it would be entire in line with peace on earth. Right?

2 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > But why should I do that? > > I can for example write a script that download Wine for the > end user user > > and apply the patch automatically. > > The patch would be considered a derivative work, so distributing it > would also violate the LGPL. That again is dependent of the doctrine of derived work have any meaning since the patch is written by me and only contains my work. Just because you build upon somebody else work doesn't mean it is a derivation. Anyway since it denies my right to speech it must be constitional within the context of the first amendment which is IMHO very unlikely that a strong doctrine of derived work is. The copyright clause exception only reserves only gives congress the right to give exclusive rights to _their_ work not to the work of others (read: me). Note by patch I do not nessarily mean a patch like (diff -u) that contains the (LGPL:ed) context of the patch. An "ed-script" or whatever similar will do. Anyway the LGPL:ed context of a (diff -u) patch might very well be consider fair use so that might not be relevant.

4 4

Re: CryptoAPI (no, this has nothing to do with licensing! YAY!)
by David Elliott 21 Dec '01

21 Dec '01

On 2001.12.20 11:52 Travis Michielsen wrote: [BIG SNIP] > Actually I too, have been hacking away at the CryptoAPI (advapi32.dll) > and > was going to submit a full patch for it at the end of the week. My > patch, > however, has almost a completely different approach to the problem! > Attached is my version (not quite complete or clean). > > These are the main differences and issues I see between our patches: > > 1) I can successfully acquire/release a context (tested with MSDN sample > code). I have not experienced any problems with <loading> a CSP. Umm, yes, I can successfully acquire and release when testing with the MSDN sample as well, but not with RSAENH.DLL that IE wants. > 2) Currently the ms CSPs can perform but all launch pstores.exe - the > protected stores service. This is fine except that it eventually crashes > > with an unhandled exception c0000005 and then becomes unwilling to start > again. Pardon my ignorance, but I didn't realize that that was what pstores did. > 3) Dependancy functions of pstores and M$ providers not implemented: > (advapi:RevertToSelf, ntdll:NtOpenProcessToken, advapi:SetThreadToken, > mpr:WNetGetCachedPassword, etc.) Yup, if pstores is necessary, we'll need pstores working, so that's something to add to the task list. > 4) I do not create any list of providers. This should not be required as > the > registry is supposed to contain the list of available providers. Once a > handle is acquired then we can gain access to the provider by this > handle. > Note: Key and hash objects need to link to the provider handle, when they > are > created. As for the key and hash: Yes, I am well aware of this, there is a blatant FIXME in the code since I haven't gotten there yet. And I don't know where you get that I am making a list of all CSPs. What I am doing is making a list of any CSPs which are in use and storing the appropriate function pointers in that object. I could simply do a loadlibrary each time the CSP is loaded and store all of that information for every context. But I thought it would be better to do it the way I did so that if multiple contexts are acquired from the same provider we don't have duplicate information in memory. > 5) I have not yet considered thread or process safing/locking. Nor have I > > done any reference counting. Well, I am not so sure about my thread safety but I think theoretically it is okay. I wrote the thread safety in from the beginning. > 6) Seting and getting Key/Hash/Prov Params doesn't consider flags not > used by > the CSP and have meaning in advapi32.dll. Haven't even really gotten that far yet. > 7) I currently do not allow a CSP to drop any of the stardard functions. > > This only affects a few functions, however, as MSDN states these > functions > are *required* for the CSP to have. If they are not implemented they > must > set the last error as ERROR_CALL_NOT_IMPLEMENTED. Well, CSP.DLL from the CSPDK does not provide a couple things. Originally I required every function to be provided but when I found that CSP.DLL did not provide one of them I decided to err the other way and only require the bare essentiallys like Acquire/ReleaseContext. > 8) You seem to make not use > ?????????? > Anyway I think the correct thing to do right now is to co-ordinate our > work > to make a single patch and implementation. > YES, definitely. Sorry to be stepping on your toes here. Most of the CryptAcquireContext function, specifically the parts that look up which CSP we need to load, I implemented rather quickly months ago. I didn't have time to do anything until a few days ago when I wrote everything else and posted it on wine-devel. > I am currently testing this code against windows 98. > Well, I have Win95osr2 running under Win4Lin and I use that as my C: drive in Wine as well. It works a lot better having everything stored on an ext2 drive than on vfat. I have not yet taken a look at your code but will do so as soon as I finish reading the rest of today's wine-devel. -Dave

1 0

Re: timed-out non-overlapped ReadFile
by Mike McCormack 21 Dec '01

21 Dec '01

Hey Lawson, Cool. i just wanted to get apps like yours back to their working state. Ideally i need to add a bit more code for the case (ReadIntervalTimeout = -1) that waits until at least some data is received before returning.... more trouble :-) The timeouts for non overlapped ReadFile should help alot of the recent problems reported on wine-users... hopefully. Mike Original message from: lawson_whitney(a)juno.com .. >Sorry if that sounded like faint praise. The app works as well with >both patches as it did before with neither, and probably there is some >other app that needs non-overlapped ReadFile to time out. > >Thanks! > >Lawson ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: timed-out non-overlapped ReadFile
by lawson_whitney＠juno.com 21 Dec '01

21 Dec '01

On Fri, 21 Dec 2001, Mike McCormack wrote: > > This patch handles the special case where > ReadIntervalTimeout=MAXDWORD, ReadTotalTimeoutConstant=0 and > ReadTotalTimeoutMultiplier=0 a little better. We should just wait > until we get some data, then read it and return in that case. > > Mike > > ChangeLog: > * handle ReadIntervalTimeout=MAXDWORD special case a bit better > Sorry if that sounded like faint praise. The app works as well with both patches as it did before with neither, and probably there is some other app that needs non-overlapped ReadFile to time out. Thanks! Lawson Slowly but with considerable uncertainty.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 21 Dec '01

21 Dec '01

> > You forgot that the end user still need to legally get hold of > > the work somehow. For normal commercial stuff this involves > > paying for it and the author will get payed just like he did in > > the old non-digital world for _each_ copy. > > I did not forget that. Good because this is _very_ important. > But I still do not think a book author would > allow you to publish a patch that would modify the last chapter to > provide a different ending. Why, if people like the alternative ending and recomend it to other he might get increase sales because presumeable they want to read the begining. Anyway, we a talking about what is legal and what is not, so that doesn't matter. > The point is that whatever way you use to distribute your > modifications, they are specific to the original work, alter it and > combines with it to provide a single new work. And these are the > criteria I would use to define a 'derived piece of work'. > > And since > derived pieces of work reuse the original work it seems only fair that > they can only do so if they respect the license of the original work. I might sound good from a open source perspective but it nearly isn't as attrative applied to normal commercial works. > Let's take a couple of common sense examples and assume that the > original work is a book. > - a bottle of black ink is not a derived piece of work. Obviously you > can alter the book quite a bit by dropping its content on it > and the ink > will definitely merge with the book. But just as obviously the ink is > not specific to your book. > (computer science equivalent: a file compression utility) First of all since we have a physical object we defintively in addition have the doctrine of first sale so inkstaining your book and reselling it is specifically allowed by law. By selling it the author lost control over that copy. > - a critic's book about the original is not a derived piece > of work. It > is clearly specific to the original book but does not modify it and > clearly does not combine with it to form a single piece of work. > (no real equivalent to this one, closest thing would be an > application/script that uses another, like a script that calls 'ls') This is not all clear IMHO. What a single piece of work is not well defined. Sure a combined work will not be a book since a book normally is something that can be read in linear order and combining with the critisism will not likely form a normal linear book. However, just because it doesn't combine to something normal doesn't mean that is doesn't combine. > - as long as you have the right to sell the original book, you should > have the right to sell it bundled with other books. The reason is that > this does not alter the original book and that it does not form a > combined piece of work. > (linux distributions) Again, you seem to miss that just because thing does not combine in normal ways it doesn't mean that they don't combine. > - but leaflet that replaces the last chapter of the book to provide a > different ending is a derived piece of work. The reason is that it is > specific to the original book, alters the story (the original work of > which the physical book is nothing but a printed > representation) told by > the book, and combines with it to form a new work (a new story with a > different ending). Thus you can only distribute it with permission of > the original author, even if you do not distribute the original book > with your leaflet. > (that's your patch example) Here it combines in a linear readable way. In short: Everything combines with everything else is some way, so unless you define some exact criteria on where the legal border talking about what can combine is rather pointless. The only trend, in your examples, I can see is that you wish to give work that combine in linear readble way more protection, for some, not mentioned, reason. Can you please explain why? > > No particular problem, > > except that some companies might be greedy and want more, > > but hey, do you really wish to give them more? > > I did not express any wishes and in any case they are irrelevant: I > do not have the power to give companies more or less. Now, when I'm > world-dictator for life... :-) :-) > > Open source is more problematic since the end user legally can > > get hold of the work for free and thus any distribution > > restrictions is meaningless since the end user doesn't distribute. > > From my point of view open-source is not any different from any > commercial work. Obviously there are legal means to obtain > the original > work in both cases (whether you have to pay for it is irrelevant). > Otherwise the point is moot. > > But saying that open-source is different would mean that > because you > are not making a direct profit from this work, you are not entitled to > any protection under copyright law. You can't mean that, can you? But you _have_ protection from copyright, everybody that _distribute_ your work must fullfill the license otherwise you can sue them.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> I see exactly what you mean. You mean a binary patch that says > things like: > * delete bytes 2294 to 2297 > * replace bytes 38455 to 39345 with "...." > * insert "...." at offset 41753 Yes. > Such a patch is very specific to a given source version > but does not > include any of the original source. Yes, but that is not a very problematic restriction. > Well, if you can legally use such a patch to work-around the LGPL > license, then you can use it to get past *any* license: GPL, AFPL, MS > shared-source, .... whatever. And this is not only true of > source files, > this is also true of binary files: you can apply such a patch to > executables, libraries, mp3s, mpegs, ... It means what you mean by get past, but OK for the sake of argument: Yes. > This has already been done and the author very quickly got into hot > water. IIRC it was less that two years ago, about a GPL game and an > individual who published a mod as a patch to the game binaries but > refused to publish his source. I'm not sure how it ended. You can > probably research it in your copious amounts of spare time, I think > there was an article on it on Slashdot at the time. I rememember. Of course it was impopular, I do not question that. The question is: Was it it illegal? > But I can assure you that no company in a 'developped' > country would > try such a thing. In the form above perhaps not so likely, but doing a proprietory Crypto API implementation with a patch to make Wine use it, much more likely. > If such a stunt were recognized as legal > then it would > spell the end of copyright of all electronic forms of songs, movies, > books, ... You can be sure that the RIAA, MPAA and all the other > entertainment companies in the world out would never allow such a > thing... and for once I say that they would be right. Please calm down. You forgot that the end user still need to legally get hold of the work somehow. For normal commercial stuff this involves paying for it and the author will get payed just like he did in the old non-digital world for _each_ copy. No particular problem, except that some companies might be greedy and want more, but hey, do you really wish to give them more? Open source is more problematic since the end user legally can get hold of the work for free and thus any distribution restrictions is meaningless since the end user doesn't distribute. But hey, do you really think this so important that you wish to give companies more power than they already have?

2 1

CryptoAPI (no, this has nothing to do with licensing! YAY!)
by David Elliott 20 Dec '01

20 Dec '01

A while ago I started hacking out an implementation of CryptoAPI. It sat idle for a while and a few days ago I decided to start doing a bit more hacking again. The basics of ADVAPI32's CryptoAPI part is that it does nothing except provide an interface for applications to call into CSPs without actually loading the CSPs themselves. At the moment the TESTCSP.EXE with its accompanying CSP.DLL is starting to work. These are from Microsoft's CSPDK and include source code. I have not tried compiling the source with Winelib, that is a later project. At the moment this code keeps track of which CSPs are loaded and which CSP an HCRYPTPROV handle uses. This allows testcsp to load up csp.dll and do a few things, but not everything. What bothers me though is that it does not get Intenret Explorer to load up the RSA CSP. The LoadLibrary fails because the DllMain function in the CSP returns FALSE. I speculate this has something to do with the fact that a real CSP needs to have its image verified before it will load. Or maybe it is something different entirely. Anyway, still left to be done are to keep track of Key and Hash handles (trivially easy) and maybe some other stuff. As far as putting this into the tree goes, I don't think it would harm anything, although I noticed that the GenRandom function had a useless implementation in it. It now has what I believe to be the correct implementation, but if loading the CSP fails that CryptGenRadom isn't going to work. Did somebodies appication actually depend on this behavior or was it implemented just to have something there? In any case, this still needs to be cleaned up a bit, but I am hoping to get some input on why I cannot load a real CSP as this is all completely useless (well, not completely, but for my purposes) if a real CSP cannot be loaded. -Dave

3 4

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So almost all functions would look like > > void CryptFoo() > > { > > #if HAVE_LIBCRYPTO32 > > CRYPT32_CryptFoo(); > > #else > > /* Old Wine code */ > > #endif > > } > > > > with a few minor exception. > > > > So you mean that I can't legally do that despite the fact that > > the LGPL is meant to allow linking to proprietary licenses. > > The LGPL allows using LGPLed code from proprietary applications. It > does not allow making the LGPLed code dependent on proprietary code > for its own functionality. > > > I think you have misunderstood something seriously. > > Please, this is the absolute worst argument from you > > as of yet. You can't seriously believe this. > > > > Also note that the code that I wrote above was supplied > under the LGPL, > > so I don't see how you can claim that I violated the LGPL. > > Of course you cannot violate the license of your own code, don't be > silly. Exactly. > But if you put this code in an LGPL library written by someone > else and distribute the end result, you have to make a good faith Yes and DISTRIBUTE the end result is the key. But why should I do that? I can for example write a script that download Wine for the end user user and apply the patch automatically. > effort to ensure that the library works properly even in the absence > of your proprietary library. This means you need to implement the > #else case and release that under the LGPL. Go read the square root > example in section 2 of the LGPL. Perhaps, but I need not distribute so it doesn't matter. The point that I have been tried to make all along that only the doctrine of can make my trickery illegal. Without it, it doesn't matter that I use Wine in a, hmm, let call it a non standard way. Anyway I think this discussion, at least the one between you and me, are running around in circles and doesn't move forward at all, so lets just end it. > > Could it be that they rely on that that the dotrine of derived work > > will save them from people trying to use the lopeholes in > the licenses? > > Sure, maybe you understand the law better than all the lawyers who > looked into this issue. I'm not betting on it. It is not primarily understanding that is the issue here. I have said that I believe, and have tried to explain why, that a strong doctrine of derived work is not good for society, because it leads to all sort of absurd consequences. Therefore is believe (or rather hope) that the courts will se sanity and only constitionally allow a very weak doctrine of derived work and thus render viral licenses such as LGPL of most (all?) of its power since it will be quite easy avoid the requirements with a little trickery. Note that this will almost exclusivly effect viral open source license since normal commersial work will get their $100 or whatever regardless since there is no trickery that can legally avoid it.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> But, I hear you say, 'why change the license if it doesn't > give you any > protection?' Well, this is where your reasoning is flawed, because the > LGPL gives you quite a bit of protection. And this is because > there is at > least a 50% chance that it is enforceable, and this is > _good_enough_ in > practice. This is trivial to see: the market place is littered with > unenforceable EULAs, yet they seem to do the job. Why? Because big > companies will have not desire whatsoever to test these > licenses in court, > since they have to much too loose (remember, big companies = > have $$$), > while small companies can build on a business plan based on such shaky > grounds, as no one is going to fund such ventures. Add to > this the immense > public pressure, and you have Protection, with a capital P. Sure it is true that what people (read: companies) believe is true is more important than what really is true. The problem is that the example of things you could do that I consider trickery might be considered perfectly normal for some companies, in fact something are not really something strange at all if you applied to the normal world. I adjust the thing I bought a little and then resell it. Then their lawyers tell them that it is unclear if they can do it. Many might not not bother at all and thoose are lost to Wine, some might risk it a later find themselves it a situation that they can neither move forward nor backwards because of "public presure", and because of the amount of money invested they have little choice but to say the LGPL is absurd, we don't not believe we ingfringe on somebodies rights and move forward hoping that somebody doesn't sue them. > And just for shits and giggles, if you think _any_ license > will give you > absolute protection, you are sadly mistaken. And the reason > this can not > happen is rather simple: the laws change. I have said it before and I say it again: I have no illusions that something gives absolute protection.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel