Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Wine Software

WINE May Change To LGPL 314

Posted by Hemos from the yeah-probably dept.
isolation wrote to us about the proposal to change the Wine license to LGPL. Jeremey's got his ideas and reasons in the e-mail there, and it makes sense - Jeremy's a smart guy. There's a call for opinions on this as well, so read through it, and offer commentary.
This discussion has been archived. No new comments can be posted.

WINE May Change To LGPL More

WINE May Change To LGPL

Comments Filter:

  • Other project ? (Score:3, Interesting)

    by boaworm ( 180781 ) <boaworm@gmail.com> on Thursday February 07, 2002 @09:10AM (#2966838) Homepage Journal
    Im a bit curious, does anyone know what that "other propiatory" stuff he is talking about, but cannot reveal any further, is ? It sounds to me that we could be talking Lindows, but I dont know that much about Lindows to know how it "emulates/wraps" Win32 API.
    Any other ideas ?

  • LGPL.... (Score:2, Insightful)

    by MrBandersnatch ( 544818 )
    No ones linked to them yet this article [gnu.org] and this article [gnu.org] give a bit more information on what LGPL is and why there is an issue.

    Although I understand the reasoning this sort of issue is what will drive companies away from adopting Linux. I'm already finding that I have to read the small print for every damn piece of software/code that I use just in case I end up using something which I will have to pay for or be prohibited from using if I use it commercially. Pain in the backside.
    • this sort of issue is what will drive companies away from adopting Linux
      Feed the trolls, tuppence, tuppence.

      Come on, get a grip! Do you run a MS OS? Have you read the license agreement? And for all your shareware, careware, postcardware (you do send a postcard don't you) and proprietary software (reading those licenses has to be one of the funniest things in the world as long as you don't want to use the software). One reason to move wine from a.n. other license to LGPL would be to have it under a common license, that way you can read one line and know whether you can use the software or not. This is a reason why people will move to Free software.

    • I'm already finding that I have to read the small print for every damn piece of software/code that I use just in case I end up using something which I will have to pay for or be prohibited from using if I use it commercially.

      How is this different from using third party software and code on any other platform?

      If you're in the habit of using third party software of code in your product under Windows or Solaris without reading the small print, you're making a very dangerous mistake.

      The fact that so many tools for Linux use standard licenses like the BSD license, LGPL, and GPL makes it easier to consider using third party software or code in your project. Consider each of the major licenses and make a decision on them. Is your project open source? BSD, LGPL, and GPL are all fair game. Closed source? BSD is safe, LGPL is safe with a bit of caution, and GPL software is safe to use but probably not safe to take code from or link against.

      Sure, there are a myraid of other licenses. If you can't justify the time to review them for compatibility with your goals, just don't use them. You can develop under and for Linux dealing exclusively with the three big licenses quite easily.

      • How is this different from using third party software and code on any other platform?

        Simple. Windows comes with a huge default set things you're allowed to link against. Somewhere, it says: "you can link against all this stuff for no royalty". If I go out and buy a copy of Windows and write a Windows apps, then I dynamically link against all libraries in Windows. I sell my app. Done.

        Imagine if a Windows developer had to review every single DLL inside of c:\windows\system to check for licenses. It takes time. Some licenses are written such that only a lawyer can figure out what they mean [att.com]. "Oh, yes, Mr. Lawyer, please read these 423 licenses and tell me which one I can use. What, that will only cost $35,000 for your time? Nevermind!"

        If I got out and buy a copy of Foo linux, it has 500,000 libraries on it, each with a different license. Each time I link in a different one I have stop and read to see if I'm allowed to do so.

        Now here's the kicker: to get anything non-trivial done in Linux, you need to link against the libraries. But you can't link in a GPL library unless you plan to give away your software.

        So, if you want to sell something, you have to roll your own. THAT is what's slowing down progress on Linux.

        I think it is 100% retarded to write a low-level library and release it under the GPL instead of the LGPL. (And yes, I write both free [nedit.org] and propietary software. I have no paranoid delusions about one destroying the other.)

    • I'm already finding that I have to read the small print for every damn piece of software/code that I use just in case I end up using something which I will have to pay for or be prohibited from using if I use it commercially. Pain in the backside.

      So with commercial software you have to read a small-print license AND pay for it AND can'd modify/redistribute it without retribution.

      With Free software, you'd probably be best to read the license, but you typically don't have to pay for it, and when you have a copy, you can do basically ANYTHING you want to it except for denying others the freedoms given to you when you received the software. The problem here is where? :)

  • Offering Opinions (Score:5, Informative)

    by Asic Eng ( 193332 ) on Thursday February 07, 2002 @09:20AM (#2966875)
    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

    It seems to me, that they really want Wine contributors to express their opinion, not the general public. They might be interested to hear from users, too, but it doesn't state that anywhere.

  • Important point from Joerg Mayer On Wine List (Score:4, Insightful)

    by Karma Sucks ( 127136 ) on Thursday February 07, 2002 @09:20AM (#2966881)
    On Wed, Feb 06, 2002 at 07:51:04PM -0500, Dimitrie O. Paun wrote:
    > Yeah, that could work. But I still don't understand your objections about
    > the proprietary drivers: LGPL would work just fine with that. What's your
    > concern?

    Look at the copy protection stuff that transgaming have added to their
    tree: they licensed it and thus quite likely can't publish the source
    for this - but I still want to see this in the binary only releases
    they make :-) Other scenarios I can imagine: drivers for hardware -
    think of a company that wants to port their software to Linux via wine
    but continue using a dongle or something like that: the dongle code
    is quite likely to go into the kernel itself (and may need some support
    for that by the wineserver).

    Ciao
    Jörg
    -----------

    PS Since I have been modded down on previous posts, I have been slowing learning how to be a good Karma citizen from other examples on Slashdot.
    • A good point. Unless they're going to add plugin functionality to wine (although I can't imagine a driver functioning well if it's a plugin) before they LGPL it, this is going to do more harm than good.

      Face it: the only reason you would want to use wine is so you can run proprietary, closed windows software anyway, so any political arguments for making wine lgpl are basically moot.
      • Being a plugin doesn't necessarily mean something needs to be slow -- it may mean that you look up a pointer to a function from a memory address before calling it rather than having it hardcoded in, but what's one movl, more or less?
      • Face it: the only reason you would want to use wine is so you can run proprietary, closed windows software anyway, so any political arguments for making wine lgpl are basically moot.

        No, the reason many of us want to use Wine is so that we can run a more wide variety of software, open and closed, free (as in beer, or as in speech). I'd like to run Trillian under wine - it's a much better piece of software than anything out there that's open source, but it's still free. CDex - another great program, it's open source even, but do you see a linux port? Nope... wouldn't it be great if you could run it natively? Wine gives choice - plain and simple.

    • Re:Important point from Joerg Mayer On Wine List (Score:4, Interesting)

      by Spoing ( 152917 ) on Thursday February 07, 2002 @10:14AM (#2967111) Homepage
      Transgaming already runs into this problem with thier own CVS of Wine (WineX).

      If someone wants to build the latest WineX, they have to wait for Transgaming to release a binary; no CVS. People have asked for the Macrovision module to be broken out, but Transgaming have not been able to (yet?).

      For those who haven't followed this, the complaint TG gives was that the copy restriction code needs to be patched in to various parts of WineX to get it to work. While I see this as a problem, it can't be a really big one.

      The sticky issue is that providing a binary copy restriction module might cause problems with Macrovision Inc. -- the folks who provided this code (likely under a quite threatening NDA).

      Can Transgaming make a seperate module...and will Macrovision like Transgaming's ideas well enough to allow it to be released? My bet is that Macrovision really don't want that part seperated from WineX. Right now, it's mixed in with a bunch of other code and is harder to understand. As a stand-alone module with hooks it would have a much higher chance that it could be easily thwarted on both Linux+Wine and Windows systems.

      Personally, I *hate*, *lothe*, and *dispise* this type of thing. I have a few commercial non-game CDs that are useless largely because Macrovision's "Safedisc". Transgaming's version works...but only on a few CDs. Mostly, it doesn't. History keeps repeating...

  • LGPL information (Score:3, Redundant)

    by cr@ckwhore ( 165454 ) on Thursday February 07, 2002 @09:24AM (#2966892) Homepage
    For those unfamiliar, you can read the LGPL at the following URL:

    http://www.opensource.org/licenses/lgpl-license.ht ml [opensource.org]
    • Moderators: how is this insightful? The original can be found at: http://www.gnu.org/licenses/licenses.html#LGPL with several format options, a discussion of why *not* to use it, and what to do in case of a violation. In any case, the FSF wrote the LPGL and they are the most likely source for a correct and up-to-date version of it.
    • Ouch, my head hurts after trying to read that thing.

      Something is wrong with the world when computing is more about legal document than writing code and fiddling with electronic gadgets.

      Sometimes I think that GNU just makes matters worse by adding another layer of complexity.

      I know it's not true. I know they really do try and help, but my head still hurts.

  • makes sense (Score:3, Insightful)

    by spike666 ( 170947 ) on Thursday February 07, 2002 @09:24AM (#2966894) Journal
    after reading the email and then finding the wine license [winehq.com] it makes a lot of sense to me why they would want to switch to LGPL. As someone who works with computers and has seen the myriad of license and contractual negotiations that are caused by corporate use of software, i've always wondered how free or open software would survive, and always had thought the apache and lgpl licence schemes gave the most advantage to software companies in promoting/using said software while still making a dollar with their enhancements.
    No matter what we want, if there is a company behind a product, it needs to make money.
    • ...always had thought the apache and lgpl licence schemes gave the most advantage to software companies in promoting/using said software

      Yes, and no one is clamoring to change the Apache License to the LGPL. So why the clamour to move Wine to LGPL? Apache is under an X11 style license and Wine is under an X11 style license. If an unrestricted license works for Apache, why wouldn't it also work for Wine?

  • Transgaming (Score:2, Informative)

    by SquierStrat ( 42516 )
    For those of you following the development, this was brought up because of Transgaming, several weeks ago. Although, at that time, the plan was GPL.

    Personally, I'm not bothered by it. They have a right to do as they wish with the project they created, and LGPL prolly won't harm to much else.
  • 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.
    Lindows anyone? I'm not saying that Lindows has caused harm to the Wine project, ahh heck, maybe I am. Charging $99 for basically what is Wine and Linux? If I'm wrong, someone let me know ;)
    • The person who pays $99 is buying a product that they don't have to set up other than to install their own software. A loose analogy: You buy a car pre-built and drive it off the lot, install your own stereo, maybe some tint, and it's yours. You did some customization beyond the what was ordered, but the bulk of the work has been done by engineers and Inspector 5 at the car plant.

      Lindows is not aimed at current Linux users, but at the Joe Sixpacks who don't give a damn about most of the things here on Slashdot. It might be premature, it might not work, but it is not wrong, as such.

      I'm on the outside of the argument - personally, I use another OS for my desktop, but I don't understand all the resistance to Lindows that I see here on Slashdot. I would think that you guys would be thrilled that someone is finally building a Linux/Wine combo that my mother can use (she's not computer-illiterate, but she's no Shakespeare, either).

      So, in answer, to your query - there's nothing wrong with Lindows. So why the beef?
    • It's not the cost of Lindows or infact that Lindows is probably reselling Wine+Linux, it's the fact that from screenshots it appears that Lindows has made some improvements to Wine and as far as anyone can tell these improvements will never be contributed back. Codeweavers and Transgaming have made it very clear on their stance towards this, they will contribute back whenever possible and have done so, Lindows on the other hand has made no such statements or sent any patches as of yet.
  • Jeremy said, "we would like to release all new code we develop under an LGPL style license" [emphasis added]. The actual proposal is:
    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?
    I am not a Wine contributor, or even a frequent user, but I really hope they don't invent yet another open source license. There will be enough flaming and meta flaming about a license change, without a bunch of clueless weenies (not necessarily excluding myself) debating the finer points of EULAs, contracts, etc.

  • Good for LGPL, too (Score:5, Insightful)

    by MikeCamel ( 6264 ) on Thursday February 07, 2002 @09:33AM (#2966930) Homepage
    I've had some commercial dealings around software which had been GPLed, and from my experience in the world out there, OSS licenses really scare companies, both big and small. I believe that the LPGL is a great half-way house, in that it allows people to create software that makes the most of the platform and libraries which are already available, without necessarily "tainting" (this it the word used whenever I've been involved with license discussions) the code that, in the end, the company wants to sell, and make money from. Although I'd like to see more sofware being free, I think that driving the platform will produce more software full stop, and some of it will be free, which is a start.

    The LGPL allows commercial activities on a non-commercial platform, and encourages commercial companies to feed back improvements into the LGPLed code which will improve the quality of the platform. Wine is a major project, and if it moves to LGPL, this should help the license, and by extension, the platform, as well as the availability of software. I'd definitely vote "yes".
  • It's hard to tell what the motivation is for this license change. Is he perhaps talking about Lindows? Is Lindows using WINE and not giving back to the WINE project?

    I think a change to an LGPL-like license should be done in such a way that commercial efforts like Lindows are still economically feasible (i.e., that they can add value in terms of packaging and add-ons), but that changes and bug fixes to the core WINE functionality are fed back into WINE. If that can be accomplished, then I think a change of WINE to LGPL is the right thing to do. If the WINE license becomes so restrictive as to make any commercial distributions of WINE-based systems uninteresting (because they exclude, for example, commercial add-ons from being bundled), then I think it would harm WINE.

  • LGPL Versions (Score:3, Interesting)

    by mirabilos ( 219607 ) on Thursday February 07, 2002 @09:46AM (#2966980) Homepage
    If they chose the LGPL, there still would be the
    issue whether to choose v2.0 or v2.1
    The latter is called "Lesser" instead of "Library"
    and calls itself deprecated due to RMS objections
    on non-GPL software.
    Yes, read non-GPL, not non-open, not even non-free.
    RMS wrote the GPL to exactly achieve the aim that
    all software has to be free as in GPL, and so he
    invented (or copied?) the viral/tainting thing.

    /me votes for MIT or LGPLv2.0
    • /me votes for MIT or LGPLv2.0


      Isn't it currently under a MIT-style (or similar) license? Various people in this discussion have claimed that it's moving from GPL to LGPL, but this [winehq.com] sure doesn't look like the GPL to me.


      I thought that they knew what the ramifications of the license they chose were, but apparently I was wrong; the authors didn't really want their code available under the conditions that they had set forth. I prefer MIT to GPL or LGPL, but it's their business to choose a license that gives them the protection they want. (From which you can see that I'm rather opposed to RMS' "all your license are belong to me" world as well.)


      Of course, since the code has been released under the current license, Lindows/Transgaming/whoever we're talking about is still free to use the current codebase to do what they want, right? The new license will only come into play if they want to use newer versions of wine, as far as I understand things.

  • Transgaming?? (Score:3, Interesting)

    by friedmud ( 512466 ) on Thursday February 07, 2002 @09:52AM (#2967009)
    What will this do to Transgaming? They will no longer be able to make changes and keep them to themselves - kind of seems like it destroys their business model.

    I guess the only thing they could do is to for Wine themselves and never touch Codweavers code again - but that means that they now have to deal with a completely larger set of problems than they currently are.

    Personally I think this is bad for Wine - Transgaming has already given so much back to the Wine project it is not even funny (including the fact that Transgaming is now looking to sponsor some portions of Wine progress) - but this switch is going to create some animosity between the two.

    Maybe they should have a dual license - kind of like mysql, where it is GPL, but some companies can license the code and they don't have to contribute back.

    It is a tough situation - but let's hope that forward progress does not get stopped because of it!

    Derek
    • ... Transgaming has already given so much back to the Wine project it is not even funny (including the fact that Transgaming is now looking to sponsor some portions of Wine progress) ...

      If it were me, I would feel this license-change request to be an unwarranted smack in the face. I give you something and then you turn around and accuse me of stealing. That is not very nice.

      • Re:Transgaming?? (Score:2, Informative)

        by Spoons ( 26950 )
        If it were me, I would feel this license-change request to be an unwarranted smack in the face. I give you something and then you turn around and accuse me of stealing. That is not very nice.

        That is pretty much how they will see it. But it is really transgaming that has sparked this debate (at least initially). Transgaming has taken the wine code and developed an open source but not free software business model. They have written code which they are not willing to give back to wine that has nothing to do with DirectX. They wrote a bunch of the COM architecture which has not been in wine for a while. This code would really benefit wine in moving it to the next level (it allows install schield installers to work on wine for example). The whole problem now is not that transgaming wrote the implementation and won't give it back, but that they say they might give it back at some point in the nebulous future. So now there is no incentive for any developer to work on this major portion of the win32 api because all their work would be useless if transgaming release their code. So it is not the fact that transgaming isn't releasing the code, but the fact that they are holding the wine source hostage. The bsd license allows commericial companies to adversely affect wine either intentionally or unintentionally.

        • So it is not the fact that transgaming isn't releasing the code, but the fact that they are holding the wine source hostage.

          They can't hold it hostage. Someone should just write their own version. If a company could truly hold software hostage like this, Linux could never have been written while commercial UNIX existed.

          Think about this: it is even harder to write code when an open source version of what you want to do already exists, yet look at all of the VI clones. Someone just needs to start; they can't expect others to just give it to them.
          • A more analagous problem would be if AT&T or whoever starting making noises about (maybe) open-sourcing pieces of UNIX that Linux didn't have yet and contributing them to Linux.

            It'd be a major psychologial deterrent to anyone else starting work on those areas in Linux independently.

            Maybe that's not a technical or legal problem, but as long as coders are human you have to consider psychological factors too.
            • A more analagous problem would be if AT&T or whoever starting making noises about (maybe) open-sourcing pieces of UNIX that Linux didn't have yet and contributing them to Linux.

              It'd be a major psychologial deterrent to anyone else starting work on those areas in Linux independently.

              Maybe that's not a technical or legal problem, but as long as coders are human you have to consider psychological factors too.

              I do understand this and agree that there is a psychological factor involved. OTOH, the issue with AT&T was using the law to prevent open source as opposed to just a competing fork.

              I never said it was easy, but people should be able to overcome this obstacle.
              • Ignore the fact that I used specifically AT&T in the parallel example. It could have just as easily been any Unix vendor for that purpose -- I was just trying to draw a (hypothetical) situation parallel to the Transgaming one.

                It's not just a matter of lazy people waiting around for Transgaming to do the work -- it's also the problem of otherwise motivated people thinking:

                "Well, crap, what happens if Transgaming releases their superior COM implementation before mine/ours is ready? I'll have wasted a lot of work ... never mind. I can spend my time on other things that need solving."

                COM is also orders of magnitude more difficult to implement than a vi clone.
              • Relicensing would certainly be one way to overcome the obstacle, at any rate. Political problems have political solutions.

    • Re:Transgaming?? (Score:3, Insightful)

      by Havokmon ( 89874 )
      What will this do to Transgaming? They will no longer be able to make changes and keep them to themselves - kind of seems like it destroys their business model.

      Remember, Transgaming also has a subscription server where subscribers can 'vote' on the options that need work.

      For example, I want my FoxPro 5 apps to work. The only current problem is Window regression. My current issues were only caused after major code changes in June 01. IIRC, one of the top 'voted' options has 400-some votes. Again, IIRC, If each vote is $2, I could spend $1000 one votes for Transgaming to work on my issue caused by the regressions.

      I can easily see even a small company like mine paying for something like that.

  • For those wondering... (Score:3, Informative)

    by Hard_Code ( 49548 ) on Thursday February 07, 2002 @09:54AM (#2967016)
    It seems it was a BSD-style license before:


    1 @c This file is processed by GNU's TeXinfo
    2 @c If you modify it or move it to another location, make sure that
    3 @c TeXinfo works (type `make' in directory documentation).
    4
    5 Copyright (c) 1993-2000 the Wine project authors (see the file AUTHORS
    6 for a complete list)
    7
    8 Permission is hereby granted, free of charge, to any person obtaining a copy
    9 of this software and associated documentation files (the "Software"), to deal
    10 in the Software without restriction, including without limitation the rights
    11 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
    12 copies of the Software, and to permit persons to whom the Software is
    13 furnished to do so, subject to the following conditions:
    14
    15 The above copyright notice and this permission notice shall be included in
    16 all copies or substantial portions of the Software.
    17
    18 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
    19 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
    20 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
    21 COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
    22 IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
    23 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

    • It seems it was a BSD-style license before:


      This is called the X11 license. It has basically the same effect as a
      2-clause BSD license, but is different from a 3-clause or 4-clause BSD
      license.

      The difference between the X11 license and the LGPL is that the LGPL is what
      is called a "Copyleft." The X11 license imposes no limitations on what you
      do with the code, as long as you acknowledge copyright and disclaimer of
      warranty; the only basic difference between the X11 license and public
      domain (giving up all copyright altogether) is that the X11 license protects
      you from litigation with the no-warranty clause (you can't impose a
      no-warranty stipulation if you don't have copyright on the code).

      Copyleft licenses like the LGPL, on the other hand, impose certain
      limitations on what you can do with the code. The most obvious limitation
      is that any code derived from copyleft code must remain under the same
      license (ie, if you make any changes to copyleft code and distribute those
      changes you also have to distribute source).
    • Thanks, I was wondering. This BSD-style license allows a commercial enterprise to incorporate the free code into their product, giving credit to the authors of the free code, but not publishing the enterprise's changes to it. That is, you can take it, use it, and change it, without giving anything back to the community (aside from free advertising, plus whatever enrichment we might get from having a possibly superior commercial program available).

      Have I got the other alternatives right?

      The GPL still allows using the unmodified free code without giving back, but it severely limits combining the free code with proprietary code. If you sell something where your code works with GPL code, you have to publish your source code under the GPL.

      The LGPL allows linking proprietary and free code together. If you insert your own code into an LGPL module, then you have to publish the changed module (when you sell anything including that module). But if you link separate modules to LGPL modules, you can keep your modules proprietary.

      The good thing about GPL is that it allows only the most basic commercial use of free software without giving back to the community of coders who created the software. (An OEM selling PC's pre-loaded with Linux doesn't have to give back, for instance. The bad thing is, it's so far reaching that it's rather scary to commercial enterprises, so they'll tend to avoid GPL. Which means that if the GPL programs are the best available (gcc definitely is; Linux might be), available commercial products are likely to be second rate because they used something else as a starting point. Quite often, we won't see free programs that adequately cover the more specialized needs either.

      LGPL is a nice compromise in-between. You can't just grab the code and start modifying, unless you are planning to give it back to the community. But you can _use_ it without risking your rights to your own work.

  • LGPL -- what are the downsides? (Score:3, Insightful)

    by Spoing ( 152917 ) on Thursday February 07, 2002 @10:53AM (#2967310) Homepage
    With the LGPL, as I understand it, you can...
    1. Package an unmodified Wine in with your Windows app.
    2. Compile against unmodified Winelibs to port your Windows app.
    3. Make changes to any part of Wine.

    The only resonsibility anyone has under the LGPL is is to provide the modified LGPLed part of Wine to those who;

    1. Ask for it.
    2. Have recieved the binary (as a paid customer or if provided at no dollar cost).
    3. Are willing to pay a nominal fee for the effort to provide the source (optional).

    The only problem I see with this is if a company makes substantial changes to the LGPLed source, and they are unwilling/incapable to seperate the parts they want to keep for themselves into little propriatory modules, they would have an attitude problem.

    Since patches to the LGPLed parts could be used as hooks to link in the propriatory modules, it does not seem like a dire problem for a half decient programmer. After all, they get the rest of Wine/Winelib for no dollar cost or effort.

    • Perhaps this stems from my lack of understanding of LGPL, but I don't see how this really keeps anybody who is determined to take their proprietary mods to themselves. If you need foo() and foo() is broken or missing in the library, you just create a wrapper library which has your implementation of foo and just hands off to WINE for everything else. It might not be a bad way in general to deal with the incompatibilities of WINE and WIN32.

      It seems to m that at best it gives the engineers (who tend to understand better the contributions of the community) an excuse to keep their employers from freeloading. Or it may cause some people with vestigal senses of fairness to balk. The intent of GPL and LGPL, as I read them, is to create a kind of social contract between the creators of software and people who would modify and redistribute it, that ensures fairness through the mechanism of granting certain inalienable rights to the user. To work around the limitations of LGPL would require a deliberate act to disrupt this fairness, something which people might scruple not to do where they might not scruple given a license had in implicit invitation to do so.
  • To me it always seemed the strangest part of the LGPL license was a requirement to either use shared object libraries or to supply the object files so your propprietary software can be re-linked with a new version of libfoo.a.

    Is there an intermediate license which requires that your changes to a library's code be shared, but don't require you to supply the user with the ability to "improve" the program you ship?
    • Apparently the common solution is to add a paragraph of "exceptions" to the start of the LGPL and say this is your license. The exceptions basically say "as a special exception to the following rules, you can statically link your program with the library and release it without source".

      I don't like this, it is another license, and as far as I can tell the vast majority of people writing LGPL would be happy with this modification. I wish there was an official modification of LGPL to say this.

  • I think that what needs to be focused on isn't really the "purity of the FSF/free software", but which of the open licenses works.

    The concept of open software and it's use with a corporate, or business, structure is new and many people/companies don't really know what to do with it. We don't know which license works best in a corporate environment. Is that the point? Maybe, maybe not. If Open Software is going to have widespread use and acceptance, it's THE point.

    I don't want to speak for anyone else, but personally it would improve my life, both at work and home, if Open Software WAS a staple. I prefer Linux as both a workstation and personal PC OS. It would be helpful if mgmt wasn't resistant to it's use in the workplace and more of the "warm and fuzzy" apps (games, some of the streaming media kinda junk, blah, blah, blah) were available for Linux at home.

    So from that standpoint, we need to see which of the Open licenses really works. Being able to establish a revenue model is key for Open Software to really get going in the business world. Right now that points to a BSD-style license.

    Yeah, we may have MS "snitching" the BSD TCP/IP stack, but we also now have lote of APPLE users on a BSD-style OS! Who would have thought that was possible a few years ago? That's real progress and it's also bringing the benefits of Open Software to the masses. I'd think even RMS would support that, although he may choke on the BSD license.

    On the flip side: IBM is pushing Linux, but how much of that is media/hype based? I'd think the BSD method of development is much more to IBMs liking, not too mention the license! Yet here they are...

    Anyway, I wouldn't mind buying a copy of "wine" (or whatever it might be sold as) if I had greater confidence it would work properly and had better documentation. I've played with Wine, and I had some things working, but not everything I needed to make the effort worthwhile. I WAS frustrated with the lack of doc, which contrary to what some people say, I usually find plenty of with the Open Software I typically use (Apache, Tomcat, etc).

    I'm NOT ragging on the folks who write Wine, they've done a great job, but I DO think that Wine would benefit from a BSD or LGPL style license.

    If anyone cares...

  • This is slightly off topic, I admit, but I have a problem with the GPL as applied to libraries. Here we go:
    1. According to RMS, if I write code that links with a GPL'd library (say, readline), my code must be GPL'd
    2. Now suppose I write, in a clean room, an exact duplicate replacement for readline (say, greedline) from reverse engineering.
    3. I offer to license to UNIX vendors for $10,000,000
    4. Now I can write non-GPL code with readline hooks and distribute it

    Now, the FSF may argue that it would be illegal for third parties to link my non-GPL code with readline, but this doesn't sound very feasible, and it isn't what is stated in the license. [opensource.org]

    (Another thing: Now suppose I merely claimed to have written greedline. It'd cost you $10,000,000 to call my bluff)
    • You can do the above scenario, and RMS couldn't get mad at you over legal issues. If there are two identical APIs, one of which is not under the GPL, then you can legally link to the GPL version without creating a derivative work.

      This is because you can't copyright an API, and the GPL does not restrict usage. GPLv3, if based on the DMCA instead of classic copyright law, could restrict usage. But it would then cease to be free.

      Tom Christiansen has already done what you proposed. He has rewritten readline, and called it "freedline". It's not a true rewrite, but a clever hack. Nonetheless, it should be sufficient to allow you to dynamically link to the real readline without contaminating your own code.

      p.s. Which numbnut judge declared that dynamic linkage contituted derivation? Or is RMS just making this stuff up?

  • Why BSD-style licence is the kiss of death (Score:2, Interesting)

    by Anonymous Coward
    I just think this contribution to the Wine lists is especially interesting, and deserves to be quoted here:

    On Thu, 7 Feb 2002, Dan Kegel wrote:

    > It's about time. Putting Wine under the xGPL is the best way
    > I can think of to ensure its future. The xGPL makes it possible
    > for competitors to cooperate for their common good - which is pretty amazing.

    This is a fundamental point which we haven't had a chance of discussing
    last time as we argued over silly future (unlikely) possible changes in
    copyright law.

    One important argument was that building a thriving economic environment
    around Wine is essential for its success.

    Everybody agreed on this premise, IIRC.

    The argument followed that BSD license is better for creating such an
    environment, and hence better for Wine, since more business will
    contribute more code back.

    This, I'm afraid, is entirely false.

    I argue that in fact, the BSD license is a STRONG DETERANT for businesses
    to contribute code back, while the LGPL provides an INCENTIVE.

    Note that I do not care, for the purpose of this discussion, about
    businesses which don't intend to contribute code back. They are of no help
    to Wine, and thus irrelevant (if not a little harmful, for reasons so
    eloquently explained by Alexandre).

    A BSD license is a STRONG DETERANT for a business to contribute code
    back. The reason for this is that they have no guarantee that another
    business will not improve a little the code, and thus get a competitive
    advantage. Or that other companies will not use that code on top of the
    code they wrote but not released, and thus again, get that edge. This is a
    fantastic _deterant_ for releasing code back. In fact, Gav validated
    exactly this point when he tried to argue for the BSD license last time:

    But there are companies out there who will benefit significantly
    from commercial use of this code, and who can afford to sponsor a
    portion of the development cost. Until such a sponsorship happens,
    we cannot apply the WineHQ license to that code.

    In other words, they needed that code. They invested some money do get
    it. They are happy with the results. Why not release the code? They have
    what they needed in the first place? The reason is clear -- it cost them
    to get there, they can not aford to bring everybody there for free. I can
    100% understand that. But if the code was under the LGPL, it would not
    matter, because even if they brought everybody there, other companies
    could not step ahead of them, since if they did, they themselves could
    have used that code.

    In other words, TG could have kept Direct3D proprietary, released
    everything else back under LGPL, and they could have _known_ they still
    have the competitive edge in the D3D work! This is why the LGPL is in fact
    an _incentive_ for such colaboration.

    Bottom line is clear: as the project matures and becomes more useful, the
    deterant of contributing code back from a business perspective is going to
    greatly increase, while at the same time, the incentive under the LGPL
    would have also increased.

    In economic terms, for Wine, one spells death, the other, life.

    --
    Dimi.

  • If you follow the link you will see that what type of license is finally selected is still very much up in the air. An X11-style license/mixed license is one of the latest suggestions. X11-like license for the kernel side, so if any closed stuff must be included for functionality it can but any dlls/libs beyond that would be LGPL.

  • You spelled Jeremy two different ways in the discussion. Hint: The first one is wrong.

    Why should I care? Well, his name is my name too, and I get pretty sick of people misspelling it.
  • If WINE is placed under a restrictive license (and both the GPL and the LGPL are highly restrictive compared to the current licensing), it's time to do what the OpenBSD/OpenSSH crowd did with SSH: Create a truly free version of WINE that isn't covered by a nasty license that's specifically intended to prevent free use of the code. It's a shame to have to do a fork, but it is the only way to keep WINE truly free. I have just downloaded the latest version of the code, just in case Jeremy & Co. attempt to make it unavailable. OpenWINE, anyone?
  • Time for some more of that Conspiracy Theory stuff:

    The recent rumours that AOL was looking to buy redhat... There is usually something behind the smoke...

    What if AOL was looking for a distro to use for their settop boxes (or easily installed on a standard PC). A disto that can have Wine installed on it.

    A distro that AOL can use with wine, and minimal changes to their AOL client would allow them a VERY quick deployment of a Linux based installation of an AOL client.

    A distro that can be bundled with Wine+the client in a single install.

    Or... A client+wine package that can be installed on any distro that the standard users would be familiar with.....

    --
    You may be paranoid, but that does not mean that they are not after you.... --Someone on IRC somwhere..
  • This license change would, effectively, close WINE to me and any other developer who writes commercial software.

    Here's why. As most people already know, the GPL and LGPL require developers who create "derivative works" to give their work away for free. But what most people do not understand is that if a programmer so much as looks at GPLed or LGPLed code, and later writes some code that performs the same function, he or she is open to accusations that the code produced later is a derivative work. (The late ex-Beatle George Harrison fell into a similar trap when he heard a song and, years later, wrote one with a similar melody. A court convicted him of "unconscious" copyright infringement because he'd heard the original song.)

    For this reason, commercial programmers simply cannot look at source code that's published under one of the FSF's licenses without taking a tremendous risk which could destroy their careers as programmers. This may be fine with Richard Stallman -- who in the GNU Manifesto stated that programmers should code for love rather than money and that good salaries for programmers should be "banned" -- but for those of us who need to put food on the table it is simply a risk we cannot take.

    Thus, if WINE is GPLed, I can no longer look at the code, fix bugs when something breaks, or contribute to the project. Nor can I peruse the code in order to learn from it. It will, effectively, be as closed as a closed source product to me and to any other commercial programmer. WINE will be un-free, and only a truly free fork (which I sincerely hope will occur if CodeWeavers attempts to change the license) will be accessible to those who want to code for a living.

  • This debate is OVER! Slashdot is a month late. (Score:3, Interesting)

    by Dr. Spork ( 142693 ) on Friday February 08, 2002 @04:00AM (#2972952)
    I've followed this somewhat closely, and it is indeed true that there has been a discussion about the LGPL. This debate was held openly, with Alexandre actually advocating the LGPL switch. However, Codeweavers programmers and other core WINE hackers gave some excellent reasons for staying on the less restrictive license, and Alexandre quickly saw that there wasn't enough support among the important contibutors and politely backed down.

    I thought their open debate was interesting enough that I submitted it here on Slashdot [slashdot.org]. However, the issue is now dead. They are NOT changing to the LGPL. Please leave the WINE coders alone and let them write code. They deserve credit for having a very civil and constructive debate about licensing issues, in a climate where flamewars are the rule when the issue gets brought up. WINE coders are not only excellent programmers, but they are also wise for having settled the issue. This "Jeremy" may be a smart guy, but his position lost out. Him trying to stoke up the issue and cause dissention in the improbably civil WINE community does not seem very smart to me. Last year was the time to discuss this. Now is the time to shut up and code.

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close