Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
BSD Linux

Closed Source On Linux and BSD? 526

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 @04: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
    • Re:Answers (Score:5, Funny)

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

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


      Hmmmm, maybe you could compile it.
    • Re: (Score:3, Informative)

      by tokul ( 682258 )

      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.
      • Not in the kernel, or any libraries, however. The main thing is GCC. For OpenBSD, this part of the tree [openbsd.org] contains everything in the base system that is GPL'd. Note also that a lot of the directories in here are now empty; for example sudo has been replaced by a BSDL version, and sendbug will be in 4.2.

        • Re:Answers (Score:4, Interesting)

          by samkass ( 174571 ) on Wednesday June 13, 2007 @07:23AM (#19489397) Homepage Journal
          Interestingly, Apple is working on a C/C++/ObjC front-end for LLVM so that they can do away with GCC as well. It should be possible to use and develop on an open-source BSD without any GPL code whatsoever in the not-too-distant future.
    • Re:Answers (Score:5, Informative)

      by SLi ( 132609 ) on Wednesday June 13, 2007 @05: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.
      • Even so, (Score:5, Insightful)

        by hummassa ( 157160 ) on Wednesday June 13, 2007 @05:36AM (#19488687) Homepage Journal

        1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
        A1. Yes -- unless you are making some kernel module that is a derivative work of the kernel, where your kernel module will have to be licensed under the GPLv2.

        2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
        A2a. Linux (the kernel) does not come with any libraries for you to link.
        A2b. GNU/Linux (the whole system) comes with many libraries, some of them BSD-licensed, some GPL-licensed, some GPL-with-linking-exception-licensed, some LGPL-licensed, etc... it's a common interpretation of the GPL that if you link to a GPL-(no-linking-exception) library (like GNU readline or Qt) you are making a derivative work and thus, you have to license your work under the GPL.

        3. Can I obfuscate my code (e.g. encode it)?
        A3. You can do this in any case -- except (maybe, IIRC) if you are distributing your code under the GPL/LGPL.

        4. Could I be forced to publish this code by some 3-d party?
        A4. Not really (parent poster is right on the mark)

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

        and I mean this respectfully: as you will be selling your box as an embedded utility, what do you have to lose by GPL'ing (or otherwise opening) your code? If you do things right, you will have:
        I. a community of people that are willing to buy your box to start;
        II. a community will want to tinker and make your product better, fast, and you get to incorporate the changes for the next versions of your product;
        III. the respect of a lot of people.

        Example: lots of people I know have Linksys (WRT54G[L]) wireless routers _because_ they know they can tinker with it, that there are lots of new, interesting uses to it with the alternate verstions of the software, etc. I, myself, when installing SoHo wi-fi networks _only_ recommend WRTs to my clients, as opposed to non-tinkerable D-LINKs that here in Brasil cost 30-40% less.
        • Re:Even so, (Score:5, Insightful)

          by Anonymous Coward on Wednesday June 13, 2007 @06:36AM (#19488983)
          Yeah but Cisco makes money off of the hardware. This guy doesn't sound like he's going to be doing that. I think his concern is if his code is open, what stops someone else from adopting the same business model?
        • Re: (Score:3, Informative)

          by MindStalker ( 22827 )
          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.
        • by maillemaker ( 924053 ) on Wednesday June 13, 2007 @06:47AM (#19489095)
          >Example: lots of people I know have Linksys (WRT54G[L]) wireless routers _because_ they know they can
          >tinker with it, that there are lots of new, interesting uses to it with the alternate verstions of the software, etc.

          I'm not in the software industry, and I don't know much about GPL.

          But I do know that if my sole /product/ was software, I, too, would be leary about giving away the code for free.

          In your Linksys example, there is a hardware component that is not easy to replicate - there is a barrier to duplication. So in that case it is a great benefit to create and sell the hardware, but leave the software open so that the world can improve the functionality and attractiveness of the hardware you are selling.

          But I don't understand how this works with a pure software product. If you give it away to the world, then someone else is just going to take the code and make a derivative product from it that does the same thing but is free. The way I see it, the only thing authors of free software can sell is support. /I/ wouldn't invest in a new product where I couldn't make any money selling the actual product but only support for it. What if everyone wants your product but no one needs or wants support? You've just invented the perfect software - but it's worthless to you.

          I guess I just still don't understand the free software movement as a business.
          • > I'm not in the software industry, and I don't know much about GPL.

            But I do know that if my sole /product/ was software, I, too, would be leary about giving away the code for free.

            Very true I hate to admit. 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 can not tell you how I hate to admit that.
            • Re: (Score:3, Informative)

              by Dare nMc ( 468959 )

              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, som

          • by Alioth ( 221270 ) <no@spam> on Wednesday June 13, 2007 @08:18AM (#19489969) Journal
            If this person is making a pure software product, firstly it's pretty clear that he's a one man band, and secondly, since he complains about dynamic linking (which is utterly trivial to do in Linux, Windows or BSD) being too hard, it's not that hard to come to the conclusion that at most he's "ordinarily skilled in the art" - more likely, he's a candidate for an appearance on The Daily WTF.

            A one man closed source project that involves no particular genius is also susceptible to being duplicated since it won't be all that much effort for someone else to write the same thing from scratch.

            So he either is filling a niche where no one else is likely to go (in which case, it doesn't really matter if he uses a closed or open source approach), or it's actually not pure software - perhaps a pre-packaged OS plus hardware plus support for an appliance type system. In which case, given the resources he has to hand, it still wouldn't really make any difference whether he goes closed or open source.
      • by Goaway ( 82658 )
        In that hypothetical case the most a court would probably do is force you to stop distributing,

        "Open the code or stop selling your one single product" isn't a way to force you to open the code?
    • Re:Answers (Score:5, Informative)

      by julesh ( 229690 ) on Wednesday June 13, 2007 @05: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:Answers (Score:5, Insightful)

      by Znork ( 31774 ) on Wednesday June 13, 2007 @05:25AM (#19488655)
      " '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."

      With an added caveat; you can statically link the code with an LGPL library, but _you have to provide the option for the recepient to dynamically link should they so desire_. Include an unsupported dynamically linked binary, or perhaps better, object files so the recepient can relink statically against another version (again, you dont have to support that, just provide the option).

      This is so that if the libraries are changed and upgraded, security bugs fixed, etc, the user isnt stuck having to use that particular statically linked version.

      "'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"

      As long as it's only BSD code, of course. Depending on the definition of 'BSD-based boxes', they can perfectly well include GPL, LGPL, or code under any other license. Anything you link against or in any other way include you have to check for licenses, wether it's Free, free or proprietary software.

      And of course, no matter how careful you are with licenses, you can get legally nuked when the USPTO with its usual competence level grants a patent on "putting obfuscated code linked with free software on an embedded device" (or whatever your device is supposed to do).

      You may just want to do your job and make a living, but those the 'freedom fighters' are trying to protect you from have no interest in your wishes. They want your money if you're lucky. Or they want you off the market if you're not.
    • 6 Can I make a living at it? A.. not likely.
    • Obfuscated != source (Score:4, Informative)

      by FuzzyDaddy ( 584528 ) on Wednesday June 13, 2007 @07: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.

  • by Random BedHead Ed ( 602081 ) on Wednesday June 13, 2007 @04:43AM (#19488399) Homepage Journal

    (Pre-Slashdot conversation ...)

    "Hi, this is Bob from Smith, Smith and Wendell returning your call. I'm afraid we're not interested in advising you on matters of software licensing and distribution, but have you considered asking a few hundred thousand opinionated geeks in a public forum? Because that's what we advise most of our potential clients to try first. Here, let me get the URL for you ..."

    • Slashdot is a forum for legal research, not legal advice. So is Groklaw. The point is to get the legal research out of the way so that you don't have to pay an attorney to pay his paralegals to do it. Then you show the research to the attorney, and checking the references that Slashdotters provided goes faster than doing the research from square one, saving the project money.

  • Sounds OK to me (Score:4, Informative)

    by MichaelSmith ( 789609 ) on Wednesday June 13, 2007 @04: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.

    • Re: (Score:3, Informative)

      by julesh ( 229690 )
      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, prov

    • Actually, if it's C or C++, I wonder what's obfuscating the source code going to achieve anyway. Once you've compiled and stripped the debug info, it's all machine-code instructions and addresses.

      - The adresses are the same whether you randomized the variables and method names or not.

      - The machine-code instructions... well, an optimizing compiler already does a decent job of jumling that, _if_ you compile with optimizations on. And most simple obfuscation techniques tend to not make a huge difference there.
      • Re: (Score:3, Interesting)

        by AdamKG ( 1004604 )
        Obfuscation of binaries is, regrettably, an increasingly refined art. I would take a look at this [secdev.org], a presentation about how Skype does a lot of it's obfuscation, to see the state of the art today. Admittedly, this is Skype, with resources, know-how and a lot of people, but it's quite possible to make reverse engineering difficult. It's just usually not worth it.
  • Go for it (Score:4, Insightful)

    by Jafar00 ( 673457 ) on Wednesday June 13, 2007 @04:44AM (#19488403) Homepage
    If you want to develop a closed source product, and the product is good, it will sell. There are many successful closed source projects out there in Linux/BSD land. You have to be extra careful about bugs though. The OSS community makes more noise when your code is buggy, and they aren't allowed to come in and fix it for you. ;)
  • 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
    • by FST777 ( 913657 )
      Beware though, using FreeBSD instead of Linux and then statically link to some library that is NOT provided / developed by the FreeBSD project, there is a fat chance that the library is GPL'd or LGPL'd.

      Using the OS says nothing about the software you further need to provide a working system. My advice: hire a lawyer who does understand the various licenses.
  • Answers (Score:5, Informative)

    by DrXym ( 126579 ) on Wednesday June 13, 2007 @04: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.
    • by dedazo ( 737510 )

      if you use gcc as your compiler for the C++

      Yes, but that's irrelevant. Using GCC to compile a binary doesn't automatically force the GPL on your code. No one would use it if that were the case.

      • by DrXym ( 126579 )
        The original poster said specifically C/C++ which rules out the cc you get with BSD. This implies they have to use gcc or a commercial compiler. I would assume that most people would lump for gcc which normally implies using the GNU standard C & C++ libraries (or uClibc). That being so, you would have supply the source to them irrespective of whether you used BSD or Linux as the operating system. Naturally there are other C++ compilers where this would not apply, but for gcc it basically would. The libr
    • Re:Answers (Score:5, Informative)

      by julesh ( 229690 ) on Wednesday June 13, 2007 @05: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.
    • Parent has good answers.

      Basically, making non-free software for Linux really isn't a big deal - at least, no more so than making non-free software for any other OS. Check the licence terms on the libraries that you make use of, and use dynamic linking to avoid having to build LGPL'ed code into your program. This is exactly what you would do if you were making non-free software for Windows or Mac.

      GPLv3 does not affect this advice, because even if GPLv3 is incompatible with your requirements in some way, you
  • Except for linking to GNU libraries, of which I know very little anyway since I'm no programmer (yet), from what I know, your problems do not exist.

    Namely, you can run proprietary code on Linux. For instance, nVidia and ATI provide proprietary kernel drivers (though with something like that may be problems in GPL 3; however Linux will in all probability remain GPL 2). Adobe provides it Acrobat Reader for Linux and so on and so forth. No problem there.

    As long as you do not use any code under a GPL license,

  • Some answers (Score:5, Insightful)

    by Anonymous Coward on Wednesday June 13, 2007 @04:49AM (#19488435)
    1. If you want to start a bussiness and have legal questions, go ask a lawyer, don't ask on slashdot.

    2. Even if you decide to post on slashdot, at least try to read the licenses in question before plus the many articles on the subject that are readily available online.

    3. If you want to have good and honest answers, avoid the word fanboy in your original post. Starting off by insulting the very people whose help you ask for isn't a very good idea.
    • Re:Some answers (Score:4, Insightful)

      by PopeRatzo ( 965947 ) * on Wednesday June 13, 2007 @05:44AM (#19488719) Journal

      1. If you want to start a business and have legal questions, go ask a lawyer, don't ask on slashdot.

      He probably will ask a lawyer, but that doesn't minimize the value of asking on Slashdot. One of the concerns the guy had was about the Linux fanboy community, and the rich community of /. has one or two of those.

      If you've ever prepared to start a major project, you know that sometimes getting advice from a wide range of sources is valuable. Personally, I've gotten some extraordinarily valuable information here on Slashdot that's directly helped me with my own projects. There was a recent article about video codecs that was a huge help to me.

      2. Even if you decide to post on slashdot, at least try to read the licenses in question before plus the many articles on the subject that are readily available online.

      I've seen a few of these scoldings around here lately, this notion that you should do research online before you do research online. One of the reasons you ask a question on Slashdot is because you're not an expert in that particular subject and you're looking for opinion.

      Plus, reading TFA is against the Slashdot EULA.

      3. If you want to have good and honest answers, avoid the word fanboy in your original post. Starting off by insulting the very people whose help you ask for isn't a very good idea.

      "Fanboy" is an insult? I actually think it's a highly descriptive and precise term. Anyway, he wasn't referring to Slashdot readers as fanboys, he was describing a subset that would rip somebody for trying to make a living by making a product and not giving it away. If the shoe fits...

      I hate the very idea of IP, but not everyone can live out here where the air is thin.
  • Closed code (Score:5, Insightful)

    by LLuthor ( 909583 ) <lexington.luthor@gmail.com> on Wednesday June 13, 2007 @04:49AM (#19488437)
    1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
    The license for the Linux kernel is not going to change (It requires the consent of many hundreds of contributors, many of which will decline. Some are dead, others are unreachable.)

    2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
    You can statically link, but why avoid dynamic linking? glibc and libstd++ are LGPL, which permits binary only distribution.

    3. Can I obfuscate my code (e.g. encode it)?
    Isn't compiling it enough? You can strip the compiled code or debugging symbols if you really want, but you only hurt your own ability to debug your users problems.

    4. Could I be forced to publish this code by some 3-d party?
    Not if you avoid linking with code which has a license that require it.

    5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
    Linux and the various BSD flavours both allow this sort of use. See the various wifi-routers and tivo style devices. Hell even my digital picture frames run linux.
    • Re: (Score:3, Informative)

      by julesh ( 229690 )
      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.
    • 3. Can I obfuscate my code (e.g. encode it)?
      Isn't compiling it enough? You can strip the compiled code or debugging symbols if you really want, but you only hurt your own ability to debug your users problems.

      I suppose obfuscation serves a purpose if it is about handling license keys. You don't want to make it too easy for a cracker to overwrite a single subroutine call to check_license() with NOP instructions. But it is rather unclear what he's thinking of with the term 'obfuscate'.

  • by Anonymous Coward
    She is the world's expert on software licencing.
  • > "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.

    Maybe not in your own code, but if you distribute linux boxes, you are using GPL code.

    > 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.

    This is possible. TiVO do something like it.

    > I am more familiar with Linux but I am scared a litt
    • 1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?

      You can do it today, but I think GPL3 is going to be against it. Still, until the license is released, and packages are relicensed, some time will pass.


      That's not completely true iirc. Only if you add some for of DRM or tamper resistance to the system you might get into trouble with GPLv3. But in that case you will get stuck with the GPLv2 versions of the software.
      • by moranar ( 632206 )
        No, I meant this:
        "One major danger that GPLv3 will block is tivoization. Tivoization means computers (called "appliances") contain GPL-covered software that you can't change, because the appliance shuts down if it detects modified software. The usual motive for tivoization is that the software has features the manufacturer thinks lots of people won't like. The manufacturers of these computers take advantage of the freedom that free software provides, but they don't let you do likewise."

        From http://gplv3.fsf [fsf.org]
  • Tentative answer (Score:4, Informative)

    by JanneM ( 7445 ) on Wednesday June 13, 2007 @04: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.
  • by rucs_hack ( 784150 ) on Wednesday June 13, 2007 @04:53AM (#19488467)
    aside from the fact that all your questions can be answered by doing a little research that you *should* be doing yourself, I see one problem.

    Your code will be closed source? Fine, I don't have much of a care about such, dig out, I plan to do a game, and that will be closed source at first. But your planned software will run on linux, and that gives rise to the problem.

    Just say your project proves popular. Well in that case the chances are very high that you will find yourself in competition with an open source equivalent, either existing or created specifically because your software revealed a new need.

    You need to look closely at the closed source rationale. It can work, but not everywhere. You could be beaten to a pulp by a small group of co-operating people out to do better then you. There have been some successes with closed software on embedded systems, but those have been heavily invested in, with lots of developers.
    • by tacocat ( 527354 )

      I was thinking of a similar problem that he is going to face.

      Closed source software development has a serious drawback. It's very expensive to manage and develop. I'm working on a project today that I don't feel is worth releasing for others to see -- making it effectively closed source.

      As a result, development is slow and difficult because every bug I run into is entirely mine to solve.

      All the code changes are done on my time. No one else is spending time on anything: documentation, testing, user int

  • Hmm (Score:3, Informative)

    by Anonymous Coward on Wednesday June 13, 2007 @04: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.

  • 1. I don't see why not, but it depends on what it is you're doing. People get in trouble because they distribute custom versions of Linux without also releasing the modifications. If you're shipping a "stock" Linux with your apps on top, you're OK. Userspace applications and drivers are not "infected" by the GPL. I don't believe the GPLv3 changes this at all.

    2. NVidia does it, why not you?

    3. I'm not sure what this means. If you're using C++ then you're already giving out machine code basically, but anyt

  • Just use BSD (Score:4, Insightful)

    by node 3 ( 115640 ) on Wednesday June 13, 2007 @04:56AM (#19488493)
    BSD is licensed to allow for people to do what you want. GPLd software is not.

    I'm not opposed to proprietary software. Quite the contrary. But 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. What you've described appears to run directly counter to that, completely disrespecting the wishes of the programmers involved. Unless I'm reading you wrong, you deserve a hearty "go to hell!".

    BSD, on the other hand, is meant to allow for use exactly like you are proposing. Have at it. No hard feelings there as that's exactly in line with their programmers' wishes.
    • Re: (Score:3, Informative)

      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

    • Re: (Score:3, Informative)

      by asninn ( 1071320 )
      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
    • Re: (Score:3, Informative)

      by marcovje ( 205102 )

      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
  • As an entrepreneur you should be absolutely clear what you are dealing with when you talk about GNU/Linux, specifically GNU. Richard Stallman has stated time and again that he considers proprietary software development and distribution to be immoral and that it is the goal of his project and organization to eliminate it - that's you! Go to their project page and read their philosophy documents yourself. They make their goals completely clear for the world to see.

    Make no mistake about it, while using the GNU
  • As long as you link externally to LGPL code, or only write in userspace while using something like the Linux kernel, you have no problem. Between these two they allow basically everything you need (assuming that in fact you don't need to write your own kernel modules or make changes inside the LGPL code).

    This is precisely how proprietary apps work on Linux (examples: Matlab, Oracle, etc. etc.). In fact you can even use a GUI, assuming you pick GNOME/GTK+ (not KDE/Qt).

    So, basically you have no problems
  • The moment you wish to start selling appliances(like you do) the software is only a minor part of it. All the other problems of manufacturing and marketing will be a much bigger hurdle. You are not disclosing what market you will be aiming at, which makes me guess that it's a new market that has not proving its profitability yet. Lastly you have decided to go closed source, but you are not letting us in on how you came to that conclusion. That makes me think that you know your reasons for closed source are
    1. Maybe and maybe
    2. Maybe
    3. Yes
    4. Maybe
    5. No

    Without knowing exactly what libraries you're planning to link against, and what DRM "features" you plan this embedded device to have, the answers really can't be any better than that. With regards to static linking, if you can dynamically link to the library then you can statically link. I'm not aware of any software license that makes a distinction.

  • Take, take, take? (Score:5, Insightful)

    by winchester ( 265873 ) on Wednesday June 13, 2007 @05:10AM (#19488575)
    So you are interested in using other people's work, you are interested in getting other people's opinions, all for free, yet you contribute nothing to the community that gave you so much...

    Some people would call that selfish.

    Here is my advice: talk to a lawyer who is knowledgeable on licensing and IP matters.
  • 1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?

    Yes, no problem

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

    Although myth has it that the GPL makes a difference between static and dynamic linking, the opinion of the FSF seems to be that to be derivative code, simply means that the code is dependent on the presence of the library. If it is, it is derivative. If not, it's not. So, take for instance SWI-Prolog. Th

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

    The GPL requires you to give the same freedoms to your customers as you yourself receive in any code that is a derived work of the GPL. If you are not planning on modifying Linux, then all you need to do is make a copy of the source code available to your customers. Note that saying 'get it from kernel.org' has been shown not to be a valid work-around for this; you will need to keep a copy of the source code that you distribute for the unlikely event that the upstream source stops distributing it.

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

    I don'

  • ... as long as you are the copyright holder.

    If you happen to include GPL-code in your closed source software you may get sued, you may be forced to remove your product from the market until you have removed all GPL-code from it, and you may be forced to pay compensation. But you are still the copyright holder, and nobody has any claim to your code other than you.

    The only way I can see you could be forced to open your code, is if your company don't have the means to pay compensation and don't have the financ
  • Unless there is some compelling pieces of Linux software or specific driver support that you need on your embedded system, and even though (as a few have indicated all ready), you *can* do it with Linux, why bother?

    If you use BSD (the base, and not the GPL ports stuff) you're 100% completely free to do whatever you want with the code for kernel and operating system, to your heart's content, without ever worrying about a thing.

    NetBSD [wikipedia.org] is BSD licensed (of course), and runs on such an incredibly wide variety of
  • Look at the license of the libs you want to link to, not the underlying OS. You can run and sell Linux with your code if the program simply runs on top of the operating system. There are many, many people selling servers with Linux and proprietary programs combined. But when you link (especially statically) into libs, it doesn't matter if you run Windows, BSD or Linux.

    But I get the feeling that this is too simple and you might have wanted to know something different. Please comment.
  • I am planning to sell embedded-like boxes with an OS (Linux or BSD) and this code... Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)

    It sounds like you are planning to use an embedded version of Linux that does not support dynamic linking well, e.g. uClinux on some MMU-less CPUs. That suggests you will be using non-mainstream libraries such as uClibc which might have special licencing requirements, particularly if statically linked. Yo
  • 1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?

    You certainly can with GPL2. Many people are doing just that.

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

    Don't static link (for distribution) with GPL or LGPL code unless you are willing to use a Free license for your code. Not that static linking is a particularly good idea if you've got the system locked down properly (wastes space).

    3. Can I obfuscate my code (e.g. enco

  • by geoff lane ( 93738 ) on Wednesday June 13, 2007 @05: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.
  • Most of the people who get really worked up and adversarial about closed source on linux are usually kids or stuck-forever-in-academia student types who've never held down a real job or had to earn money for their family using their own intellectual property. If you just ignore those fantasists they'll eventually get bored taunting you and go back to their playstations. Good luck with your project!
  • If I catch you including my GPL code in your closed source app I can't force you to open source the entire app or release/publish/whatever the source of it. I can, however, force you to stop distributing it. And I can sue you to chunky kibbles and into next wednesday for 10 bazillion dollars of damages for copyright infringement and some other illegal activities. And if you use my code and you don't opt to open source your app I probably would sue.

    Hope that answers your question.

    Don't get all worked up abou
  • This does not constitute legal advice, but consider this:
    the point of the GPL is to set up a community wherein source code is treated as chess pieces. Everything sits in plain view. You're asking to change a fundamental assertion about how the community functions. You want a face-down playing card on the board to represent one of your pieces, in your variation.
    No one gets enthusiastic about having their basic assertions tweaked. The reaction is going to range from silence to rage.
    Admired from a dista
  • you managed to hit every hot button in sight...

    Basically mr. anonymous coward "businessman", if you don't like the license, don't use it.

  • by iONiUM ( 530420 ) on Wednesday June 13, 2007 @10:11AM (#19491539) Journal
    I'm sorry, but if you review the huge arguments going on about how you can release closed source on Linux, well it's no wonder a lot of vendors chose to go Windows only. I'm not saying closed source is right or wrong, I'm just saying that if the option to go close source is so tricky on Linux, well, that's a huge fucking problem.
  • Answers (Score:3, Informative)

    by ajs318 ( 655362 ) <sd_resp2NO@SPAMearthshod.co.uk> on Wednesday June 13, 2007 @10: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.
  • by Coward Anonymous ( 110649 ) on Wednesday June 13, 2007 @11:59AM (#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.
  • by iabervon ( 1971 ) on Wednesday June 13, 2007 @12:08PM (#19493521) Homepage Journal
    If you're really writing it all yourself, none of these issues matter. If you're really writing standard C/C++ with only POSIX library functions, you're not linking against the kernel (so the kernel license doesn't matter), and you're not linking against any userspace libraries except for libgcc/libg++ (permissive license) and glibc (generally permitted). Dynamic linking is only actually a pain when either you're writing the library, or the library provider's versioning is lacking, or you've got a million libraries, or you're shipping the software not aggregated with the library you want to use.

    Of course, you'll want to use other people's code for some things. You'll almost certainly want to start your program using some shell scripts, but those don't have a non-source form and are generally not worth obfuscating. If you want to use more libraries, you'll have to look at their licenses (many important Linux libraries are BSD-licensed anyway, though). If you're writing kernel code, you probably want to open-source this part and do as little of the interesting stuff there as possible (for technical reasons: kernel bugs cause a lot more damage than userspace bugs; for maintence reasons: kernel developers will maintain cleanly-written open-source code for you across trivial API changes; and for legal reasons: it's a pain to avoid making your module a derivative work of the kernel).

    The ideal thing is to build a little computer running Linux with nothing in it that you wrote, and then use it to run a program that's entirely yours, and sell the whole thing to people.
  • More answers (Score:3, Insightful)

    by HiThere ( 15173 ) <[ten.knilhtrae] [ta] [nsxihselrahc]> on Wednesday June 13, 2007 @04:42PM (#19497977)
    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.)
    That's what you get for using Windows.

    3. Can I obfuscate my code (e.g. encode it)?
    Not if you're GPL, but you don't show any signs of wanting to.

    4. Could I be forced to publish this code by some 3-d party?
    No. At most you could be forced to stop distribution and pay copyright damages. And that's only if you violate the GPL or similar license. (I.e., write your own code and you're safe.)

    5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
    What problems?
    a) None of the questions that you have raised appear to me to be a problem.
    b) The base of the OS is almost irrelevant to every question that you have posed.
  • by SETIGuy ( 33768 ) on Wednesday June 13, 2007 @05:11PM (#19498257) Homepage
    IANAL, of course, but I have some experience in these areas.

    1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
    Yes, of course. However if GPL licensed binaries are distributed with it, you must provide source for those binaries for a period of no less than 3 years longer than you distribute the device or application. This, of course, applies to GPL licensed binaries even if they are running on a BSD kernel. This provision applies whether you have modified the code or not. You can rely on a third party to distribute the source code. However, if that third party ceases distribution of the source before the 3 years are up, you are still obligated to distribute the source.

    So, yes, if you distribute a linux kernel that you downloaded from "xyzzyplugh.com" you can direct people to "xyzzyplugh.com" for sources. But if "xyzzyplugh.com" goes out of business, you still need to be able to provide the sources.

    The same is true if you use a BSD kernel, but include the GPL application "spork" embedded in the device. You need to be able to provide the sources to "spork" regardless of where you obtained the "spork" binary and regardless of whether the "spork" sources are available elsewhere.

    2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
    No. If you statically link the Linux libraries, or any GPL licensed library, then you are obligated to license your application under the GPL. If you statically link a LGPL licensed binary, your application can remain closed source. However you must make source for the LGPL licensed library available, again for at least 3 years longer than you distribute the application.

    3. Can I obfuscate my code (e.g. encode it)?
    Source or object code? In either case the answer is "of course" for all licenses. But if you are under GPL or LGPL, you need to make the means to decrypt it available to anyone who wants it.

    4. Could I be forced to publish this code by some 3-d party?
    No, but you could be required to cease distribution and potentially be penalized in either civil or criminal court for any copyright violations you commit. This could apply regardless of the licence of the OS kernel you use. Be sure to understand the license of any software or libraries that you distribute.

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

    No, you are not. Not all code in a BSD distribution is necessarily licensed under the BSD. Nor are you protected from anyone who claims that their code was improperly included in a BSD licensed application. Worse yet, there are potential patent violations in just about any device you might want to sell.

    I only have one follow-on question. Why are you so afraid of releasing your sources? What's the worst that could happen?

Avoid strange women and temporary variables.

Working...