Forgot your password?
typodupeerror
BSD Linux

Closed Source On Linux and BSD? 526

Posted by kdawson
from the license-ramification-details dept.
An anonymous reader writes "I want to start (very small) software/hardware business. The code in question will be closed source. I won't modify or use any GPL code or any 3rd-party sources. It will be my own handwritten C/C++ code from start to finish. I am planning to sell embedded-like boxes with an OS (Linux or BSD) and this code. I am more familiar with Linux but I am scared a little bit of Linux licensing, and also of Linux fanboy-ism: I personally got a 'go to hell with your @#$ closed code' slur on Slashdot. I am not a GPL guru and not a software freedom fighter. I just want to do my job and make a living." Read on for this reader's five particular questions.

My questions:

1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?

2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)

3. Can I obfuscate my code (e.g. encode it)?

4. Could I be forced to publish this code by some 3-d party?

5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
This discussion has been archived. No new comments can be posted.

Closed Source On Linux and BSD?

Comments Filter:
  • Answers (Score:5, Informative)

    by rilak (1099845) on Wednesday June 13, 2007 @05:41AM (#19488381)
    1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)? Yes 2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.) Only if it's LGPL 3. Can I obfuscate my code (e.g. encode it)? It doesn't really help, but go ahead 4. Could I be forced to publish this code by some 3-d party? Not if you do it right 5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems? You can do whatever you want with BSD code
  • Sounds OK to me (Score:4, Informative)

    by MichaelSmith (789609) on Wednesday June 13, 2007 @05:44AM (#19488401) Homepage Journal

    I am not a GPL guru and not a software freedom fighter.

    OK but if you want to sell software you need to understand licensing.

    2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)

    Yes, glibc is licensed under the LGPL which is compatible with non-free software.

    3. Can I obfuscate my code (e.g. encode it)?

    I suppose so, but unless you are some kind of algorithm genius (and I don't think you are) it is not really going to be worth anybody's while to do reverse engineer it.

  • by dpninerSLASH (969464) * on Wednesday June 13, 2007 @05:44AM (#19488405) Homepage
    A large number of people who subscribe here are against proprietary software on principal. I am not (although I choose to pay for and support open source), although I can almost assure you using a BSD-based OS will allow you to develop and release your product w/o fear.

    DP
  • Answers (Score:5, Informative)

    by DrXym (126579) on Wednesday June 13, 2007 @05:48AM (#19488431)
    1. Yes. GPL3 is not retroactive to existing source. Even if you used GPL3 stuff, I don't think it has any impact on your own code if it is distinct.
    2. Yes if they are LGPL. Which includes the standard C++ libraries. Some components such as the kernel also have certain binary waivers.
    3. Yes but why bother if you're not releasing the source. And if you are releasing the source, then there are benefits to not obfuscating it (e.g. helpful customers fixing your bugs).
    4. Not unless a court says. Obviously if you violate the GPL you are taking a major risk of somebody finding out and forcing your code out into the open.
    5. Yes, but neither will you have a problem with Linux. However you would have to supply the sources to the GPL / LGPL components of your system upon demand. Most people stick the source up on a web site or link to where they found it, but the latter may not absolve you of not providing it if somebody comes asking for it. Also BSD systems can contain GPL software too (e.g. if you use gcc as your compiler for the C++)

    I think if you're in doubt you should probably go look at some existing Linux dist designed for embedded systems. They're bound to have a FAQ that covers most of this.
  • Tentative answer (Score:4, Informative)

    by JanneM (7445) on Wednesday June 13, 2007 @05:53AM (#19488465) Homepage
    1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?

    Yes.

    2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)

    AFAIK, no. Static linking is incorporating code directly. If you link dynamically then any library that is LGPL (not GPL) is fine, but for static linking I believe you need to have an open license on your own code as well.

    3. Can I obfuscate my code (e.g. encode it)?

    It's your code - do anything you want. If you're not open-sourcing it, just don't ship the source.

    4. Could I be forced to publish this code by some 3-d party?

    No. Again, when people have been found to have violated the terms of the license, they've had to stop selling and distributing the stuff. I can imagine cases where someone may have to retroactively pay for the illegal use of code. But I can't see a situation where'd you actually had to open your code.

    5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?

    Well, 1, 3 and 4 isn't a problem under Linux either. 2 - for BSD-licensed libraries you could link statically. But a lot of libs (user-interface stuff and higher-level libs) in BSD systems are LGPL as well - everything in a BSD-based system isn't BSD-licensed.
  • Hmm (Score:3, Informative)

    by Anonymous Coward on Wednesday June 13, 2007 @05:54AM (#19488479)

    To be perfectly honest, I have to question whether it's wise to enter a market where a) you don't have familiarity with the platform (there are long established answers to most of these questions) and b) don't know anybody you could ask. Having said that...

    1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?

    Today, yes, provided you comply with the terms of the license. Tomorrow, it depends on exactly what you are doing.

    2. Can I statically link the code with Linux libraries?

    That contradicts your earlier claim that you "won't modify or use any GPL code or any 3rd-party sources". The term "Linux libraries" is meaningless. What libraries are we talking about? By statically linking a library, you make your application a derivative work and you are also distributing the library itself, which means you need to make sure that the library's license allows this and that you comply with its terms.

    (My own experience shows that dynamic linking is too much to bear.)

    Your own experience is probably wrong.

    3. Can I obfuscate my code (e.g. encode it)?

    So long as it's entirely your code, although I don't see the point. Of course, if the reason you are obfuscating the code is because it's a derivative work and you are required to provide the source, then no, you probably can't.

    4. Could I be forced to publish this code by some 3-d party?

    At worst, if you infringe on somebody's copyrights, then you could be offered this as an alternative to being sued.

    See, this is the kind of question that makes me think you don't even have the remotest familiarity with Linux. You seriously think somebody can just shake you down for source? Huh? Or are you just spreading FUD?

    5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?

    Ah, that answers my question. Fuck off. You aren't genuinely asking these questions, you're just a BSD troll spreading FUD.

  • Re:Sounds OK to me (Score:1, Informative)

    by Anonymous Coward on Wednesday June 13, 2007 @05:57AM (#19488499)
    2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
    Yes, glibc is licensed under the LGPL which is compatible with non-free software.

    NO, you cannot. You are only allowed to link dynamically. Or you need to provide your program object files, so the end-user is able to link it statically with other version of the library. But it is impractical (IMO).

    Regards
  • Re:Answers (Score:0, Informative)

    by Anonymous Coward on Wednesday June 13, 2007 @05:59AM (#19488503)
    On point 2, you're incorrect. There is no LGPL 3 and you're interpretation doesn't match that of people creating libraries... see http://www.uclibc.org/FAQ.html#licensing [uclibc.org] for example. Your best bet would be to look through this list for a Linux compatible, BSD licenced library: http://www.uclibc.org/other_libs.html [uclibc.org]
  • Re:Answers (Score:3, Informative)

    by tokul (682258) on Wednesday June 13, 2007 @06:02AM (#19488529)

    5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
    You can do whatever you want with BSD code
    Even BSD OSes have some code licensed under GPL.
  • Re:Sounds OK to me (Score:1, Informative)

    by Anonymous Coward on Wednesday June 13, 2007 @06:05AM (#19488547)
    * 2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)

    Yes, glibc is licensed under the LGPL which is compatible with non-free software.

    I find people answering this wrong over and over again, so I have to correct. From LGPL license:

    Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library.

    So to make it short, you can link statically, but that means you have to also provide the object files of your part of the program so that the user can relink the library. This is to make sure that users can modify and replace the LGPL library and still use it with your program.

  • Re:Answers (Score:5, Informative)

    by SLi (132609) on Wednesday June 13, 2007 @06:09AM (#19488571)
    4. Could I be forced to publish this code by some 3-d party? Not if you do it right

    More clear answer: No.

    Even if you publish proprietary code linked to GPL code and swear you are aware of the violation, nobody can force you to disclose your code. It's a copyright violation, and forcing to publish code is not a remedy for copyright violation. In that hypothetical case the most a court would probably do is force you to stop distributing, and perhaps if it's that obvious you knew you were in violation it could order some punitive damages.
  • Re:Answers (Score:5, Informative)

    by julesh (229690) on Wednesday June 13, 2007 @06:14AM (#19488589)
    2. Yes if they are LGPL. Which includes the standard C++ libraries. Some components such as the kernel also have certain binary waivers.

    No if they are LGPL. LGPL requires you to be able to update the LGPL'd license, which effectively means it must either be dynamically linked, or you must distribute your .o files and a script to link them. glibc is not LGPL, though -- it is "GPL with the libc exception" which does allow you to link an application statically against it. Check other libraries for their own terms.

    4. Could I be forced to publish this code by some 3-d party?
    Not unless a court says. Obviously if you violate the GPL you are taking a major risk of somebody finding out and forcing your code out into the open.


    This isn't an expected outcome. Nobody can force you to release your source, even if you violate the GPL. Of course you can be forced to pay compensation to the GPL developers whose IP rights you have violated, and they may be prepared to negotiate if you choose to release your source.
  • Re:Answers (Score:5, Informative)

    by julesh (229690) on Wednesday June 13, 2007 @06:18AM (#19488609)
    2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.) Only if it's LGPL

    LGPL does not allow you to statically link the code. One of the terms of the LGPL requires that it be possible to make modifications to the LGPL'd code and incorporate these into the distributed program. This cannot be done with a statically linked executable (unless you're also distributing linkable object files).
  • Re:Sounds OK to me (Score:3, Informative)

    by julesh (229690) on Wednesday June 13, 2007 @06:24AM (#19488641)
    2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)

    Yes, glibc is licensed under the LGPL which is compatible with non-free software.


    You cannot freely statically link non-free code to LGPL code. See section 6:

    As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. [....] Also, you must do one of these things:

          1. Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work [...] and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink [...]
          2. Use a suitable shared library mechanism for linking with the Library. [...]
          3. Accompany the work with a written offer [to fulfil section 1 ...]
          4. If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.
          5. Verify that the user has already received a copy of these materials or that you have already sent this user a copy.
    [...]

  • Re:Closed code (Score:3, Informative)

    by julesh (229690) on Wednesday June 13, 2007 @06:26AM (#19488661)
    glibc and libstd++ are LGPL, which permits binary only distribution.

    Not of statically linked code. See section 6, which requires that enough materials be given (or offered) to the user to make a version of the program that uses a modified copy of the library.
  • Re:Answers (Score:4, Informative)

    by x_MeRLiN_x (935994) * on Wednesday June 13, 2007 @06:44AM (#19488715) Homepage
    '3' was the next question number..
  • by geoff lane (93738) on Wednesday June 13, 2007 @06:51AM (#19488757)
    You _really_ don't want to statically link libraries. If you do, any security problems with the libraries become security problems with your code that can only be fixed by patching all your binaries and not just the library with the problem.
  • Re:Answers (Score:5, Informative)

    by TheRaven64 (641858) on Wednesday June 13, 2007 @07:37AM (#19488997) Journal
    The LGPL explicitly does permit static linking. In the case of static linking, however, it requires that you also distribute your object code so that your customers can re-link it against their own version of the library.
  • Re:Even so, (Score:3, Informative)

    by MindStalker (22827) <mindstalkerNO@SPAMgmail.com> on Wednesday June 13, 2007 @07:38AM (#19488999) Journal
    Thing is linksys is using custom hardware. This guy is probably using commodity hardware, so what he is selling is his software, bundled with hardware. If people could buy the WRT54G routers as commodity hardware they would.
  • LGPLv3 (Score:5, Informative)

    by tepples (727027) <tepples@gmaiBLUEl.com minus berry> on Wednesday June 13, 2007 @07:45AM (#19489071) Homepage Journal

    On point 2, you're incorrect. There is no LGPL 3
    Yet, just as there is no GPLv3 yet. But here's a draft of GNU Lesser General Public License version 3 [fsf.org], which will be released at the same time GPLv3 is released.
  • Re:Just use BSD (Score:3, Informative)

    by kripkenstein (913150) on Wednesday June 13, 2007 @08:21AM (#19489383) Homepage

    I do find the notion of taking an open source project, slapping on a bit of code, and trying to keep your part to yourself, to be extremely offensive. The people who contributed to GNU software did so with the expectation that their code is share and share alike.
    In some way, yes, they did expect 'share and share alike'. But not entirely. Linux kernel developers explicitly allow you to do whatever you want in userspace; they don't expect anything from you if you use their kernel and 'slap' a proprietary app on top of it. Likewise GTK+ devs don't expect anything if all you do is use GTK+ as your GUI toolkit, i.e., just link to it externally. And in fact a lot of proprietary development prefers GTK+ (which is LGPL in the relevant part) over Qt, which is more problematic for them.

    In fact this is the explicit reason for the LGPL being different from the GPL, and similar things (GPL+exceptions, etc.). To return to the GNOME/GTK+ example, the (GNU!) licensing allows proprietary apps to run on their platform; in that sense this is a very business-friendly license (to FOSS and proprietary businesses alike). And this makes sense: even if apps developed on top of GNOME/GTK+ are proprietary, often during their development some contribution is made back to GNOME/GTK+, in the form of bug reports, patches, and perhaps other things; in addition, if the app is widely-used then it gets more people familiar with the platform underneath it, opening more potential avenues for benefit to GNOME/GTK+ (and of course this example is relevant to other projects as well: the Linux kernel, languages/runtimes like Python, etc.).
  • Obfuscated != source (Score:4, Informative)

    by FuzzyDaddy (584528) on Wednesday June 13, 2007 @08:22AM (#19489387) Journal
    Releasing obfuscated source code does not count as releasing source code under the terms of the GPL. From section 3 of GPLv2:

    "The source code for a work means the preferred form of the work for making modifications to it."

    It doesn't seem that this guy needs to release his code in any event, however.

  • Re:Why closed? (Score:2, Informative)

    by 91degrees (207121) on Wednesday June 13, 2007 @08:27AM (#19489459) Journal
    Open source is given away freely,

    It doesn't have to be. You can sell it if you want. Normally I wouldn't mention this because It's a bit pedantic, but it's relevent to my next point.

    and if you believe in that freedom, you also believe in others having the freedom to choose differently.

    But doesn't this mean that if you believe in freedom, then others should also have the freedom to do what they want with your code?

    The thing is, the GPL doesn't require that you give the source to the community. It does require that you give it to the customer and it does prevent you from stopping them giving the source to the community. The only significant freedom that the GPL removes is the freedom to publish the binaries without the source. It's not hugely inconsistent to believe that people should be able to do what they want with software.
  • Re:Just use BSD (Score:3, Informative)

    by asninn (1071320) on Wednesday June 13, 2007 @08:44AM (#19489611)
    Um, no. The guy who asked these questions, while clearly being extremely clueless, is not actually ripping anyone off. There's nothing that says you can't run closed-source software on a Linux system - quite the opposite -, and it's absolutely not contrary to either the letter or the spirit of the license or the wishes of the programmers in question.

    I suppose you could still be opposed to closed-source software in principle, but you're not - what you seem to be doing (intentionally or not, I can't tell) is put up a strawman of "you're violating the GPL folks feelings by doing this!", even though it is patently untrue, and then use that to justify advising the guy to use BSD instead.

    Are you sure you're not a particularly sophisticated BSD troll? :P OK, no need to answer that, but either you're extremely clueless, or your post was a particularly sneaky and underhanded attempt to discredit the GPL.
  • by Dare nMc (468959) on Wednesday June 13, 2007 @09:42AM (#19490263)

    If there is not hardware or a service to sell then selling the program and giving away the source just will not work together.

    I think that really depends on the product and target audience. IE most software projects probably never get noticed on a big enough scale to wory about posting your code to sourceforge, etc. Esentually it would be free advertising for your product, ie the people who find it their would never have otherwise found it and been customers, but some will contribute to a paypal link, some may contribute with enhancements adding value to your paying audience. With any consumer level product, 99% of (non corprate) customers will never do anything with source code given to them, even those that would know how.

    Of course if the only people who would use your product are geeks already running linux, then ya back to the hope of paypal. Also if your product really takes off after you sell say 5000 units a competitor will likely say, hey I got the source code, I can enter that market too, You still got the advantage of first entry, track record, name (you did copyright your product name right?.)
  • Some answers (Score:1, Informative)

    by Anonymous Coward on Wednesday June 13, 2007 @09:46AM (#19490329)

    1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?

    Yes and Yes.

    2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)

    Depends on what libraries and the license of those libraries (same goes for BSD). Btw; you realize that if you statically link with a library, then it is no longer 100% your own hand-written C++ code - right?

    3. Can I obfuscate my code (e.g. encode it)?

    Yes.

    4. Could I be forced to publish this code by some 3-d party?

    No.

    5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?

    No. But there really shouldn't be any issues if you own all the copyright for your code.

  • Re:Just use BSD (Score:3, Informative)

    by marcovje (205102) on Wednesday June 13, 2007 @10:36AM (#19490993)

    First, BSD has some limitations (like carry notice and not misrepresent its origin).

    Second, one must separate BSD licensed software from BSD based OSes. To my knowledge, all modern BSDs extensively use GNU software to create binaries, libgcc among others.

    Third, one can link to GPL, LGPL code, as long as it is for own use (not redistributed).

    Fourth, hardly any libraries come as GPL. Nearly all come with LGPL. Moreover, (L)GPL is a bit defanged if it comes with the distro. But static linking is still an issue.

  • by elzbal (520537) <elzbal AT yahoo DOT com> on Wednesday June 13, 2007 @11:06AM (#19491467) Homepage
    If you want to continue on Linux, try Prelinking the libraries (see 'man prelink' and Google for more information). It resolves a lot of the performance issues with dynamically linked libraries, without actually statically linking them. Not only does this resolve the GPL issues, it also removes problems with, for example, being able to update OS libraries independently of your application.

    Of course, BSD is a fine OS as well, and I've had good experiences with both platforms. Good luck!
  • by Anonymous Coward on Wednesday June 13, 2007 @11:08AM (#19491509)
    Write good software, make it open source, then:

    1) Sell service/support contracts to businesses that use it.

    2) Sell conversion consultation services to help businesses convert from their old product to yours.

    3) Sell code customization services, working out in your contracts whether or not the code customization in question is for that business only (they will keep the code and not distribute it in any way, and it will not become part of the source tree) or a paid modification of the core source (you own it and open source it and distribute it with the base product).

    4) Publish and sell books on how to use your product. You could also sell training classes on how to use it.

    5) Consult as a specialist with domain knowledge in the industry to which your product caters.

    6) Profit!

    If you can't do this sort of thing with your product, then it may be that the open source business model is not suitable for what you have in mind, in which case you will either have to work within a closed-source OS (so there will be no licensing conflicts), or be very careful in what your product links to (LGPL and BSD style stuff are fine, pure GPL and similar may not be so fine). Be aware, however, that selling closed-source code to an open-source crowd doesn't always go so well.

    If all else fails, your product could be the demonstration of skill that lands you a job at Google.

  • Answers (Score:3, Informative)

    by ajs318 (655362) <sd_resp2 AT earthshod DOT co DOT uk> on Wednesday June 13, 2007 @11:18AM (#19491651)

    1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
    Yes, though you will have to distribute Source Code for any GPL and similarly-licenced components you distribute. As for GPL4, who knows?

    2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
    Not unless the libraries are released under LGPL. Many libraries nowadays are under the full GPL specifically in order to prevent people statically linking closed code against them.

    3. Can I obfuscate my code (e.g. encode it)?
    There's no point obfuscating Source Code which you aren't releasing because nobody else is going to see it. There's no point obfuscating binaries because the code to de-obfuscate them is required to run them.

    4. Could I be forced to publish this code by some 3-d party?
    Only as part of a settlement package if you were doing something you shouldn't, and even then only by mutual agreement unless the law changes in future to make "intellectual property" subject to forfeiture. There will always be an alternative (though that may well be to pay out a large sum of money and not sell any more of your product).

    5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
    Not necessarily. Even BSD systems contain some components which are under GPL and/or LGPL. Of course, you can buy commercial versions which do not have such restrictions.

    The view from between the lines is somewhat less rosy. Your questions (2) and (3) suggest that you don't know very much about programming, and the fact that you want to keep your Source Code closed at all suggests that whatever you're doing isn't actually going to be all that special. So, be warned: some third party is most probably going to come along and blow you out of the water, offering a superior and True Open Source solution to whatever problem you are trying to solve. In fact, if and when they do just that, they can probably expect a hefty wodge of donations from Slashdot readers eager to see a closed-source product fail spectacularly.
  • Re:Answers (Score:3, Informative)

    by samkass (174571) on Wednesday June 13, 2007 @11:19AM (#19491671) Homepage Journal
    Apple had originally been working on merging GCC and LLVM. I'm not at the WWDC this week, but from what I've heard they have decided to do away with the GCC bit and write their own front-end called "clang". Slides are available in the "Using LLVM" section of this presentation [llvm.org]. They also further discuss their OpenGL shading language front-end for LLVM.
  • by jythie (914043) on Wednesday June 13, 2007 @12:21PM (#19492685)
    I read 'too much to bear' as taking too much system resources rather then 'too hard'.

    In an embedded system dynamic linking can eat up scarce resources. Static linking is faster to load, faster to run, and takes up less ram.
  • by Coward Anonymous (110649) on Wednesday June 13, 2007 @12:59PM (#19493363)
    From all the other comments it appears that you should have no problem given your current expected deployment.
    However, have you considered future possibilities where you may have to tinker with L/GPL code. For example if you discover a bug in a GPL/LGPL library or in the kernel and need to fix it for your purposes. Do you think releasing the fix would pose a problem for you?
    If the answer is that you think releasing the fix is against your best interest, you should go the BSD route. Otherwise, L/GPL is probably fine.
  • Re:LGPLv3 (Score:3, Informative)

    by Creepy (93888) on Wednesday June 13, 2007 @01:16PM (#19493647) Journal
    seems they noticed my (or other similar) rants about LGPLv2, because the definitions (section 0), the combined library clause (section 5) and clause 4d1a finally make mac application bundles with shared frameworks that include an LGPL library legal.

    still, 4d1 is ugly and seems to imply static linking is still not allowed by the LGPL (contrary to thread starter)...

    Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

    Since a statically linked library is bound and copied into the application at compile time, it would be in violation of 4d1a.

    And while I'm sure this clause is meant to forbid static linked libraries, it also inadvertently could make a closed source application violate the LGPL without trying. Here's how: create an LGPL plugin (which is a really a dynamic library that does linking in runtime) and then have a non GPL/LGPL browser download and use it without shutting down. Think of how browsers load something like Flash players now - you don't restart the browser, you just click a link to download and install it, then you view Flash media. Since the library did not exist at the OS when the application was started, you could argue that the plugin did not exist on the OS at run time and therefore violates the LGPLv3. The other alternative is to say that a plugin is not a library - fair enough, then the plugin cannot be LGPLv3 because according to clause 0:

    "The Library" refers to a covered work governed by this License, other than an Application or a Combined Work as defined below.

    That said, you could alway do something like that by removing a non-LGPL library and replacing it with an LGPL library to cause the application to violate parts of the LGPL, so I would expect that is unenforcible. I'm just giving a hypothetical scenario of how someone like Microsoft might read it, just so they can say LGPL is EVIL.
  • Re:Uh, guess what (Score:5, Informative)

    by Jack9 (11421) on Wednesday June 13, 2007 @01:47PM (#19494225)
    I don't see how he is a troll. The fact people ask questions that could be answered by doing the proper research (how would you qualify what is proper in many cases, specifically the legalities of licensing?) does not mean they are trolling, they are simply asking in a forum they are comfortable with. What's your problem with that?
  • Re:Ok thanks... (Score:5, Informative)

    by IdleTime (561841) on Wednesday June 13, 2007 @02:54PM (#19495299) Journal
    Oracle is running it's products under Linux and it is all closed source.

    In fact, development of new versions are done on Linux and then ported to other platforms. Here is a good starting page if you are interested in seeing how and what s done by Oracle on Linux, both closed and open source: http://www.oracle.com/technology/tech/linux/index. html [oracle.com]
  • Re:Even so, (Score:5, Informative)

    by darnok (650458) on Wednesday June 13, 2007 @06:07PM (#19498213)
    > But as a small developer, he's pretty screwed anyway...

    > If his product becomes popular, it's likely to get cloned either by a larger company selling a commercial version, or by a group of
    > enthusiasts making a free version. Either way, he has no control over the situation and the clones will ultimately take over
    > because they have more developers and in the case of the commercial company, greater marketting clout.

    Come on - it's quite possible to make a popular product and derive a quite nice income from it, without attracting the attention of cloners and large companies.

    Big Co are only interested if they're going to make mega millions out of it - if you're making a few hundred thousand a year, you won't even show up on their radar. There's an awful lot of software out there that falls into that category.

    If you're selling to a tight niche of customers, then only people in and around that niche are likely to even be aware that your product exists, never mind want to clone it themselves. If you're building software for e.g. dentists, while a few dentists may want to add new shiny features to your product, it's highly likely that they'd want YOU to do it for them, rather than track down some software developer, pay him to clone your software and add their desired features to it. Conversely, while a random software developer might come across your software and think he can clone & extend it, he then also has to create a means of distributing his software (no, dentists won't downloaded their critical software from SourceForge), building relationships with an existing base of dentists, then providing support to those dentists (with all the associated issues of dealing with non-IT literate users).

    I've got a mate who runs a garbage collection business. Many years ago, he paid a student to create software to allow him to manage his business - sort of a highly-customised piece of accounting software. He still uses that software, still engages that ex-student (now working in IT) to support & extend it, and is extremely happy with it. Shock, horror - it runs on MS Access. He's very happy with the software, and the guy who wrote it has both made a nice side income from it and sold it to a bunch of other garbos - I wouldn't be surprised if he's collectively made a tidy sum from it over a period of several years. Nobody's gonna clone this software, and no big company's gonna be interested in it either.

COBOL is for morons. -- E.W. Dijkstra

Working...