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

Re: Fwd: Re: New Open Source License: Single Supplier Open Source License [rschi@rsmba.biz]

by Jakob Eriksson

Richard Schilling wrote: >Several licenses on opensource.org permit code to be incorporated into a proprietary product and sold. This means, also that the person creating the deriverative or combined work can restrict others from selling their product. In this respect there is no difference from my license. Under my license if a developer wants to release > [snip] How is any of this related to Wine? Even the Wine-related license discussions got its own mailing list, wine-legal. I'll help your cause though: http://www.RSMBA.BIZ/ /Jakob

Jan. 25, 2004

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

by Brian Vincent (C)

Please take the discussion over to wine-license @ winehq.com --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

Jan. 25, 2004

Re: shell32 patch 20

by Dmitry Timoshkov

"Jakob Eriksson" <jakov(a)vmlinux.org> wrote: > 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. What way will you decide to go, if in the next Platform SDK release Microsoft will remove some of the existing APIs and simultaneously add some previously undocumented? Rewrite all the affected parts of your code? > I understand your fight against code duplication and such, but IMHO cross > compilation is something that needs to happen. I wonder then, how you are going to cross compile most of the kernel parts of ReactOS code. If you would rely only on the documented APIs and headers ReactOS would not be in the state it is now. -- Dmitry.

Jan. 25, 2004

RE: Winedbg: Parse symbols in libc, libpthread, etc

by Robert Shearman

> > > Robert Shearman a écrit : > > Hi, > > > > This patch allows winedbg to parse symbols in libraries directly linked > > to the wine binaries, like libc and libpthread. This will usually mean > > just using the symbol table, but this is better than nothing. > Hi Robert > > I don't understand why you need to walk the shared object (from > lm.l_ld)? Normally, all loaded shared object will appear in the main > module loaded linked list, so we should only need to walk that list. I'm not sure which you mean by the main module loaded linked list, but I guess you mean the one we get the rest of the modules from. On my system (Fedora Core 1), the modules directly linked to wine-pthread/wine-kthread don't appear in the main module list (i.e. don't get listed at all when you run, for example, winedbg notepad). > The > rest of the patch is correct The first part of the patch makes winedbg not give up when it doesn't find a .stab section, but the rest of the patch is finding these extra libraries and moving stuff around to not duplicate code. > (I'm currently working on fixing some of > the issues of the debugger: get around WINELOADER issue, report > unsupported debug format (like Dwarf2...)). Cool. If this patch will get in your way, just let me know. Rob

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 > > 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. Submit the patch in the form as you wish. Alexandre will either accept the patch and fix some minor cases, or will explain what you need to change in it to make the patch acceptable for inclusion. -- 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. > > No, it doesn't detect it. It sets all the flags to 0. Then you have to cope with that single case on your own. -- Dmitry.

Jan. 25, 2004

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

by Ivan Leo Murray-Smith

> 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. > 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. Sorry for the language but this is pure bullshit. The Free Software Foundation has enforced the GPL many times, forcing proprietary vendors to GPL the code of works deviated from GPL'ed code, and has always reached a settlement before getting to court, that shows how good the GPL is. > 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. IMHO you're quite confused, and don't have a good idea about what open source is all about. You license closely remembers the shared source license. Ivan.

Jan. 25, 2004

Re: Winedbg: Parse symbols in libc, libpthread, etc

by Eric Pouech

Robert Shearman a écrit : > Hi, > > This patch allows winedbg to parse symbols in libraries directly linked > to the wine binaries, like libc and libpthread. This will usually mean > just using the symbol table, but this is better than nothing. Hi Robert I don't understand why you need to walk the shared object (from lm.l_ld)? Normally, all loaded shared object will appear in the main module loaded linked list, so we should only need to walk that list. The rest of the patch is correct (I'm currently working on fixing some of the issues of the debugger: get around WINELOADER issue, report unsupported debug format (like Dwarf2...)). A+

Jan. 25, 2004

Re: New Open Source License: Single Supplier Open Source License [rschi@rsmba.biz]

by Richard Schilling

Sent this to winehq.com, so sending it to winehq.org in case it bounces. On 2004.01.24 17:24 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. Several licenses on opensource.org permit code to be incorporated into a proprietary product and sold. This means, also that the person creating the deriverative or combined work can restrict others from selling their product. In this respect there is no difference from my license. Under my license if a developer wants to release the code to you, and allow you to distribute, he/she can. The point is that the developer has the exclusive right to make that decision. > > 2. Source Code > > The program must include source code, and must allow distribution in source > code as well as compiled form...." If a developer chooses to not release their code, that's up to them, in which case I would not call the _software_ an Open Source product. However, the license is Open Source because it does not prevent the distribution of code - it simply requires the end user to get the code from the source that the developer approves of. If a developer says the product can be distributed through Sourceforge, then it can. > > See http://www.opensource.org/docs/definition.php. I read that very carefully. Richard ----- End Forwarded Message ----- ----- End Forwarded Message -----

Jan. 25, 2004

Fwd: Re: New Open Source License: Single Supplier Open Source License [rschi@rsmba.biz]

by Richard Schilling

On 2004.01.24 17:24 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. Several licenses on opensource.org permit code to be incorporated into a proprietary product and sold. This means, also that the person creating the deriverative or combined work can restrict others from selling their product. In this respect there is no difference from my license. Under my license if a developer wants to release the code to you, and allow you to distribute, he/she can. The point is that the developer has the exclusive right to make that decision. > > 2. Source Code > > The program must include source code, and must allow distribution in source > code as well as compiled form...." If a developer chooses to not release their code, that's up to them, in which case I would not call the _software_ an Open Source product. However, the license is Open Source because it does not prevent the distribution of code - it simply requires the end user to get the code from the source that the developer approves of. If a developer says the product can be distributed through Sourceforge, then it can. > > See http://www.opensource.org/docs/definition.php. I read that very carefully. Richard ----- End Forwarded Message -----

Jan. 25, 2004

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. 24, 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. 24, 2004

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

by Tom

From: Cordula's Web (cpghost_at_cordula.ws) > # 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. Hi, Maybe i've misread your re-ply.. do you care to elaborate why the GPL, LGPL woul'd "prevent commercial vendors from adopting this license." Like I said before maybe ive made a mistake. Regards, Tom

Jan. 24, 2004

Re: LockResource16 in ole32.dll

by Dmitry Timoshkov

"Ge van Geldorp" <ge(a)gse.nl> wrote: > Just to be sure: if I understand you correctly you suggest doing the > LockResource16 in LoadAcceleratorsA/W, then GlobalAlloc a new block of > memory, copy the table to the new block and return the global memory > handle as the HACCEL. Then in IsAccelerator use GlobalLock to get at the > contents. Please correct me if I'm wrong. I was suggesting to avoid using GlobalAlloc16 in LoadAcceleratorsW at all, and use 32-bit GlobalAlloc instead. Alexandre answered another part of your message. And yes, you are right that support for sharing accelerator handles between processes will require complete rewrite of that code. -- Dmitry.

Jan. 24, 2004

Re: shell32 patch 20

by Dmitry Timoshkov

"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. > shell32 has currently only a > few reasons why it can't be compiled and linked in Visual C and I think it > is a good idea to improve on that. Improve, not break, or make the things uglier. > This of course isn't any reason but maybe an indication: native shell32 does > not import RtlCreateUnicodeStringFromAsciiz() either. That fact actually simply proves that Wine's implementation is completely independent from a Microsoft one, nothing more. -- Dmitry.

Jan. 24, 2004

Re: shell32 patch 20

by Dmitry Timoshkov

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > Well I would agree with you if it was just not defined in Mingw but > there is nothing we can do about getting Microsoft to add it to the > PSDK. If we want to build/test on MS_VC what are we to do? Microsoft provided headers and libraries usually miss a lot of things, sometimes even documented ones. So, I don't think that screwing Wine source due to that fact is worth the trouble. -- Dmitry.

Jan. 24, 2004

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

by Cordula's Web

[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. > # 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. > # 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. > # 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. > # 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. > # The developer has complete control over the product forking. Same as above. > # 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 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). > 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? > Richard Schilling -- Cordula's Web. http://www.cordula.ws/

Jan. 24, 2004