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?
Answers (Score:5, Informative)
Sounds OK to me (Score:4, Informative)
OK but if you want to sell software you need to understand licensing.
Yes, glibc is licensed under the LGPL which is compatible with non-free software.
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.
In Response to Your Questions (Score:2, Informative)
DP
Answers (Score:5, Informative)
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)
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)
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)
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)
Re:Answers (Score:3, Informative)
Re:Sounds OK to me (Score:1, Informative)
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)
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)
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
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)
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)
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:
Re:Closed code (Score:3, Informative)
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)
Don't statically link libraries (Score:4, Informative)
Re:Answers (Score:5, Informative)
Re:Even so, (Score:3, Informative)
LGPLv3 (Score:5, Informative)
Re:Just use BSD (Score:3, Informative)
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)
"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)
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)
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?
Re:Hardware gives you a leg up, though in that cas (Score:3, Informative)
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)
Yes and Yes.
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?
Yes.
No.
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)
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.
Try Prelinking Libraries (Score:2, Informative)
Of course, BSD is a fine OS as well, and I've had good experiences with both platforms. Good luck!
Free software as a business. (Score:2, Informative)
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)
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)
Re:Hardware gives you a leg up, though in that cas (Score:5, Informative)
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.
Future considerations (Score:3, Informative)
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)
still, 4d1 is ugly and seems to imply static linking is still not allowed by the LGPL (contrary to thread starter)...
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:
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)
Re:Ok thanks... (Score:5, Informative)
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
Re:Even so, (Score:5, Informative)
> 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.