Closed Source On Linux and BSD?

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?

Comments

Answers

[rilak]

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

[Anonymous Coward]

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

Hmmmm, maybe you could compile it.

Re:Answers

[SLi]

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

[julesh]

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

[julesh]

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

[Znork]

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

Re:Answers

[TheRaven64]

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:Answers

[Arancaytar]

Indeed. Select "Plain Old Text" in the list below (it's actually default for me).

See?

Linebreak!

It's magic. :)

Legal advice

[Random BedHead Ed]

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

Go for it

[Jafar00]

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

Answers

[DrXym]

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.

Some answers

[Anonymous Coward]

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.

Closed code

[LLuthor]

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.

not to disparage, but

[rucs_hack]

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.

Take, take, take?

[winchester]

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.

Even so,

[hummassa]

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,

[Anonymous Coward]

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:Even so,

[darnok]

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

Re:Why closed?

[dhfoo]

You seem to be looking at it from the wrong angle.

If you don't care about the GPL, don't use GPL'd software. Simple.

The only reason we are having this discussion is because GNU/Linux has become so succesfull BECAUSE no-one has been able to hijack it and close it.

Understand now?

It's not about zealotry, it's about denying greedy, selfish people the ability to build on the shoulders of others without giving anything back.

LGPLv3

[tepples]

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, which will be released at the same time GPLv3 is released.

Hardware gives you a leg up, though in that case..

[maillemaker]

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

Re:Hardware gives you a leg up, though in that cas

[Alioth]

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.

So hard to make an application on Linux

[iONiUM]

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.

Re:Hardware gives you a leg up, though in that cas

[jythie]

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.

Re:Uh, guess what

[Jack9]

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

[IdleTime]

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