January 2004 - Wine-Devel - list.winehq.org

Re: New Open Source License: Single Supplier Open Source License

by Richard Schilling

On 2004.01.24 17:45 Cordula's Web wrote: > [This is OT for stable@ and wine-devel@, but let's contribute anyway...] > > > # Users have freely available access to source code, documentation just like the GPL. > > Access to source coce, documentation etc... is also possible under the > BSD license. Under the [L]GPL, it is mandatory. Under the BSD, and other licenses it's _possible_ but not required to give access to the code - it's up to the developer. The BSD license and several other Open Source licenses allow deriverative works to become closed and there is nothing the developer can do about it. With the license I provide, if a developer wants to require their product *and* deriverative works to be open to the public they can. That's a big difference in the world of licensing. The [L]GPL license makes this the submission of changes mandatory, but the problem is that the unrestricted distribution of the software makes it impossible for the developer to enforce the requirement. And unfortunately, that fact makes the requirement useless. Strictly prohibiting deriverative works to be distributed in ways unintended by the author is the way to guarantee a product and it's deriveratives remain open source. Under BSD, there is no such restriction, so the original author has absoutely no say in how "open" deriverative works are. Under GPL and BSD the developer has absoutely no control or means to keep their work an open source because they cannot remove distribution from people who don't comply. > > > # Users may use, modify, and install the software on as many computers as they want within their organization. > > Right. The number of computers should never matter. In the context of this license it matters greatly. Since the end user cannot distribute the software to others outside their organization, this clause clarifies that they can use the product in an unrestricted way within their organization. It makes the requirement black and white - within your company use the product on all your computers. But don't let it get to computers outside your company. That requirement becomes very clear with this statement. > > > # Any changes made by the user and others get contributed back into the base product > > This is the main difference between BSD and GPL, and you're using > the GPL model here. This is exacly what would prevent commercial > vendors from adopting this license. But, okay. Commercial vendors may not want to adopt this license because they can't get a free ride. I'm perfectly fine with that because I want my company to be a place where Open Source developers can work for real wages. And, that means the developers on this list. If you want to volunteer your time so Apple and any other company can earn millions on your hard work then that's your choice - use a different license. > > > # The developer's right to control who provides services using the product is protected. > > That's a tough one. As long as the developer is _actively_ maintaining > a product, that seems reasonable. But it happens frequently, that many > developers loose interest in supporting a product. Locking the community > out would be counter-productive, to say the least. If a developer really intends to keep their product open source, they can direct others to distribute the work for them. The point is they retain the exclusive right to make that decision. Consequently the end users have a very clear choice then - if the developer can no longer develop the software because, say they have a new job, then the end users can offer that person a job to make it possible for him/her to continue working on the product. Under GPL and other licenses, that person is simply replaced. That's a huge detrement to the quality of a software product because people skills, not the software are what make a software product great. > > > # The developer's right to control who can distribute the software is protected. > > That's even uglier. Neighter the GPL nor the BSD license would be _that_ > restrictive. And see below, in case the developer drops maintenance. Under this license if a developer wants to let the world distribute their product they can specify it - the point is that developer has the ability to grant and revoke that permission to *distribute*. But when end users have downloaded the software they can use it indefinitely and modify it for their own use. > > # The developer and all contributors retain copyright of their individual works. > > That is already the case with [L]GPL and BSD licenses. What's new here? The problem with [L]GPL and BSD is that if someone does not turn in their changes then the developer has no recourse to enforce the requirment. Under this license they can. > > # The software is always downloaded from the same place by the end user even if it's used as part of a larger product, protecting the quality of the software. > > See above. > > I'd suggest to add a clause of mandatory maintainership, that would > void the exclusive right of the developer/author to maintain and > distribute his/her work, if the originator fails to update his/her > product after some (yet-to-be-specified) time. Orphaned products could > then automatically fall under the BSD license (or GPL, or anything > less restrictive as what you're suggesting). This license would not be appropriate to use if your goal is to create software as purely a volunteer effort. This license gives an incentive for companies to pay the original developer and contributors for their time to continue developing an open source product, or failing that to pay them for the right to distribute the product and provide services. If a particular product is truly valuable to an end user, and it was necessary to "keep the product going" then the user has an incentive to pay the developer/contributors for the time they invested, *and* to pay them for their time to transfer knowledge about the product. Furthermore, by keeping the original developer involved in the transfer of knowledge, the original developer the ability to ensure the quality of training. > > > Please feel free to contact me on or off list about this announcement. > > What are you trying to achieve with this, which can't already be > achieved through BSD or [L]GPL licensing schemes? > I am trying to make it possible for people to earn a living as Open Source developers. I am also making it possible for companies that do Open Source development as their primary activiey to provide jobs to those (like those on this list) who invest their time into Open Source products. Richard > > Richard Schilling > > -- > Cordula's Web. http://www.cordula.ws/ > > > >

Jan. 25, 2004

Re: shell32 patch 20

by Jakob Eriksson

Dmitry Timoshkov wrote: >"Rolf Kalbermatter" <rolf.kalbermatter(a)citeng.com> wrote: > > > >>I was under the impression that it was desirable to cross compile as many >>dlls as possible in different environments. >> >> > >Yes, that's a desirable task, but only if does not require to break Wine >source accomplishing it. > > Depending on how you define break, that argument can be used to stop almost any patch to Wine, if the goal happens to be cross compilation. I understand your fight against code duplication and such, but IMHO cross compilation is something that needs to happen. We need to look at code duplication at a level not only within Wine, but between ReactOS and Wine. Forking a dll between projects is also a lot of code duplication. regards, Jakob

Jan. 25, 2004

RE: INI File Processing Improvements

by Robert Shearman

> > > "Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> wrote: > > > > 1. You are duplicating too much unicode helpers already existing in > > > wine_unicode and include/wine/unicode.h > > > > There are no strnchrW and strnrchrW routines in unicode.h, so how do you > > propose I rewrite memchrW and memrchrW? > > Perhaps just add them into wine/unicode.h I don't really think they belong there, as they don't map to any standard libc functions. However, if people think they will be useful if added I will submit a patch to add them. > > > 2. Are you sure that Windows supports unicode .ini files at all? > > > > Yes. I have and Windows2000 and above installer that uses > > GetPrivateProfileString on Unicode text files to get its > settings. I could > > send you these files if you want. > > I assume they have the same format as unicode .reg files, right? Yes. > > -- > Dmitry.

Jan. 25, 2004

RE: INI File Processing Improvements

by Robert Shearman

> > > "Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> wrote: > > > > Why not simply use IsTextUnicode/RtlIsTextUnicode and fix it > if necessary? > > > > Ok, will do. Any idea if it can detect UTF8 as well? > > I don't see that it's documented in MSDN, but probably it's worth to test > an actual behaviour under Windows. No, it doesn't detect it. It sets all the flags to 0. > > -- > Dmitry.

Jan. 25, 2004

Re: uxtheme Prevent segfault if no theme is set

by Robert Shearman

> > This follows the same lines, in some cases > MSSTYLES_SetActiveTheme would return success when in fact it failed > Apply on top of Vitaliy's patch > > Changelog: > Ensure MSSTYLES_SetActiveTheme fails when theme fails to load ... > invalid_theme: > if(hTheme) FreeLibrary(hTheme); > - if(!hr) hr = HRESULT_FROM_WIN32(GetLastError()); > + if(SUCCEEDED(hr)) hr = HRESULT_FROM_WIN32(GetLastError()); > + if(SUCCEEDED(hr)) hr = E_FAIL; > return hr; You shouldn't be doing this in the first place. As you have seen, at best you will set hr to a random error and at worst it won't be set at all and you need your hack to make it still work. What you should be doing is setting hr to the correct error as soon as you detect a failure. So after a Win32 call: if (callfailed) { hr = HRESULT_FROM_WIN32(GetLastError()); goto invalid_theme; } or after another type of failure: if (somethingnotquiteright) { hr = E_FAIL; goto invalid_theme; } Also, please try to use a more descriptive code than E_FAIL if one exists. Rob

Jan. 25, 2004

Re: Dungeon Keeper thread(s) recently

by Lionel Ulmer

> - I have two mouse pointers. > - The first is trapped in the upper left corner and looks like a standard > mousepointer. When the mouse is moved down or right it follows a bit and > then always jumps back to it's corner. > - The second one is the Dungeon Keeper mouse pointer (some picture of a > monsters head). This one moves down and right if the mouse is moved in > this directions but doesn't move up or left. > Except this the mousepointer behaves absolutely normal. > > > That's the situation. > Any ideas for a starting point for debugging? Well, this looks like a dinput bug in the handling of relative mouse grabbing when computing the coordinates of the middle of the screen. To make a long story short, X does not really provide any way to get relative mouse movements (I do not despair to one day check-out the fd.o X server and add an extension to do that). So we need to 'warp' the mouse to the middle of the window each time it moves and compute from absolute mouse events the relative ones. Anyway, this whole DInput code worked one day (when it used direct X calls and was full of hacks) and was a bit broken by the DLL separation work (basically, to support this properly we cannot use plain Win32 calls as it's done now but need to hook directly at the low level input system). Lionel (back from one week snowboarding in the Alps and still handling the mail backlog :-) ) PS: will look too at the DDraw bug Jason reported. PS2: was not able to run 'kddata.exe' properly (got hangs in Wine in random places), but unzipping directly with unzip worked better :-) -- Lionel Ulmer - http://www.bbrox.org/

Jan. 25, 2004

Re: Sound disappears after few seconds

by Vitaliy Margolen

Disregard this message. It accidentally escaped my "Outbox".

Jan. 25, 2004

Trolling and helping a spammer (was Re: New Open Source License: Single Supplier Open Source License)

by Shachar Shemesh

Hi guys, First, someone who sends the same email to at least four mailing lists (freebsd, wine-devel, postgresql-hackers and ossi) is a spammer in my book. Replying to his email, especially to lists that are not relevant (i.e. - any but ossi) is helping him along. To answer his (asked) question - since this license is clearly LGPL incompatible, I don't think he is likely to make contributions to Wine under this license. At least, not contributions that will be accepted. As his license is also BSD incompatible, I dare say it is equally off topic for FreeBSD and postgresql. This guy is obviously trying to solve the "how can I make money from free software" dillema by introducing a proprietary license and calling it "OpenSource". Interesting idea, but it has been tried before (http://www.microsoft.com/resources/sharedsource/default.mspx, except they didn't have the audacity to call it open source). This is just a proprietary license. Nothing more to see here. Move along. Shachar P.S. I am not subscribed to the stable(a)freebsd.org mailing list. A search of the archives did not show this particular Richard Schilling post. I was not sure whether to dump this mail (which is just as off topic as the original one) on that list as well. I'm sorry if I chose wrong. I did notice that on stable(a)freebsd, Richard is at least an occasional poster. Here on Wine-devel he is a first time poster as far as I can see. This may explain the difference in responses between the lists. Sh. Chuck Swiger wrote: > Richard Schilling wrote: > >> I would like to present to you all a new Open Source software license >> I've written up. > > [ ... ] > > One the face of it, Section III, "Distribution Restrictions and > Obligations." of your license fails to comply with OSD #1 & 2: > > "1. Free Redistribution > > The license shall not restrict any party from selling or giving away > the software as a component of an aggregate software distribution > containing programs from several different sources. The license shall > not require a royalty or other fee for such sale. > > 2. Source Code > > The program must include source code, and must allow distribution in > source code as well as compiled form...." > > See http://www.opensource.org/docs/definition.php. > -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/

Jan. 25, 2004

Re: INI File Processing Improvements

by Dmitry Timoshkov

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> wrote: > > 1. You are duplicating too much unicode helpers already existing in > > wine_unicode and include/wine/unicode.h > > There are no strnchrW and strnrchrW routines in unicode.h, so how do you > propose I rewrite memchrW and memrchrW? Perhaps just add them into wine/unicode.h > > 2. Are you sure that Windows supports unicode .ini files at all? > > Yes. I have and Windows2000 and above installer that uses > GetPrivateProfileString on Unicode text files to get its settings. I could > send you these files if you want. I assume they have the same format as unicode .reg files, right? -- Dmitry.

Jan. 25, 2004

Re: INI File Processing Improvements

by Dmitry Timoshkov

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> wrote: > > Why not simply use IsTextUnicode/RtlIsTextUnicode and fix it if necessary? > > Ok, will do. Any idea if it can detect UTF8 as well? I don't see that it's documented in MSDN, but probably it's worth to test an actual behaviour under Windows. -- Dmitry.

Jan. 25, 2004