Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Closed Source On Linux and BSD?

kdawson posted more than 7 years ago | from the license-ramification-details dept.

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?

Sorry! There are no comments related to the filter you selected.

Answers (5, Informative)

rilak (1099845) | more than 7 years ago | (#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

Ok thanks... (0)

Anonymous Coward | more than 7 years ago | (#19488407)

...for the answers.

Next.

Go to fucking windows with your @#$ closed code !! (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19488815)



Go to goddamn fucking windows with your goddamn fucking @#$ closed code !!

You making the shit up arsewipe

Re:Answers (5, Funny)

Anonymous Coward | more than 7 years ago | (#19488475)

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


Hmmmm, maybe you could compile it.

Re:Answers (0, Informative)

Anonymous Coward | more than 7 years ago | (#19488503)

On point 2, you're incorrect. There is no LGPL 3 and you're interpretation doesn't match that of people creating libraries... see http://www.uclibc.org/FAQ.html#licensing [uclibc.org] for example. Your best bet would be to look through this list for a Linux compatible, BSD licenced library: http://www.uclibc.org/other_libs.html [uclibc.org]

Re:Answers (3, Informative)

x_MeRLiN_x (935994) | more than 7 years ago | (#19488715)

'3' was the next question number..

Re:Answers (3, Informative)

tokul (682258) | more than 7 years ago | (#19488529)

5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
You can do whatever you want with BSD code
Even BSD OSes have some code licensed under GPL.

Re:Answers (5, Informative)

SLi (132609) | more than 7 years ago | (#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, (5, Insightful)

hummassa (157160) | more than 7 years ago | (#19488687)

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:Answers (1)

Goaway (82658) | more than 7 years ago | (#19488833)

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 (5, Informative)

julesh (229690) | more than 7 years ago | (#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 (5, Insightful)

Znork (31774) | more than 7 years ago | (#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.

Microsoft shill (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#19488385)

This is just going to stir up the hornet's nest and make Linux and OSS look bad to the outside world. How's about we all try and be nice, and show these shills that we can't be manipulated?

Re:Microsoft shill (-1, Flamebait)

Viol8 (599362) | more than 7 years ago | (#19488749)

How about you go back under your rock , troll.

Legal advice (5, Funny)

Random BedHead Ed (602081) | more than 7 years ago | (#19488399)

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

Sounds OK to me (3, Informative)

MichaelSmith (789609) | more than 7 years ago | (#19488401)

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:Sounds OK to me (1, Informative)

Anonymous Coward | more than 7 years ago | (#19488499)

2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
Yes, glibc is licensed under the LGPL which is compatible with non-free software.

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

Regards

Re:Sounds OK to me (1, Informative)

Anonymous Coward | more than 7 years ago | (#19488547)

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

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

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

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

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

Bunch of daft questions (1, Interesting)

Anonymous Coward | more than 7 years ago | (#19488605)

If you include code you need to abide by the license.

If you include pre-compiled libraries you need to abide by the licenses.

If you DON'T include code or use pre-compiled libraries, you don't have to agree to a license.

So, given these three truths (that are part of COPYRIGHT, not GPL or BSD or even MS's EULA), the answers are:

1) If "it" doesn't include adding the GPL code in to your project, then yes (no license needed so irrelevant question)

2) The GPL (and LGPL) don't allow static linking: it becomes one piece of code and you must open the source. This is basic copyright again.

2b) if you *dynamically* link, then that still isn't allowed by the GPL without opening the source code, but the LGPL only requires you to open up the source for the LGPL'd library (and any changes you made to it to make it work in your project).

NOTE: If you use MS's runtime libraries, you must agree to the EULA and licensing terms of the runtime libraries. The user of your product must ALSO agree. Your issue is only whether the terms of the license are acceptable.

3) As long as you aren't including others code, go for it. Though since you can keep the code secret, why obfuscate?

4) No, but you can be forced by a third party to either abide by the license of the code or not to use it if you decline.

5) BSD will still require that you keep the notice. If you don't, you can be forced to open the code, be fined for using the code, required to remove the code or whatever the owner of the code you are infringing on requires and can get a court to agree to enforce.

Only #1 and #2 have anything to do with BSD or GPL. And, you may want to consider this: since your code is combined with the BSD, the combined work is under the BSD. Now, you don't *have* to release that code but if I get a copy of that code (a derivative of BSD code) then I can argue access is granted under the BSD to that code. So with BSD you can be opening yourself up to loss of all your work gratis to a competitor if they can get hold of your code. If you used the GPL, your competitor will have to do free bugfixing and enhancement of your code if they wanted to use it.

Can we mod this article, "Troll"? It's obviously a "BSD is Best" troll.

Re:Sounds OK to me (2, Informative)

julesh (229690) | more than 7 years ago | (#19488641)

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

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


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

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

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

Actually, won't help anyway (1)

Moraelin (679338) | more than 7 years ago | (#19488765)

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.

E.g., if you went and unrolled loops per hand, well, it won't do much of a difference once the optimizer would do the same unrolling anyway. Using macros and copy-and-paste to inline lots of code and make it hard to follow the logic? Chances are it will look roughly the same as the compiler's own inlining. Etc.

The only way to really make a difference in the binary output is to really mess the algorithm itself. It's possible, but I wouldn't advise it anyway. I doubt that _that_ many people are qualified to invent a brand new algorithm that (A) does the same thing, (B) does it efficiently, and (C) is harder to understand. Most just manage C, via some spaghetti code or such, but quite often lose A (via bugs) and B.

Re:Sounds OK to me (1)

ultramkancool (827732) | more than 7 years ago | (#19488781)

3. Can I obfuscate my code (e.g. encode it)? Well, if you're going to do anything like in the windows world and just use some pre-ready packer, that's the #1 stupidest idea I've ever heard! These pre-written packers often make programs easier to crack, because the authors then rely on something that has already been cracked thousands of times over. Take armadillo for example. Many trial-ware programs use it. 90% of those trialware programs can be "cracked" with mm_dillodie (an armadillo unpacker). If you want actual protection, do it yourself!

Go for it (4, Insightful)

Jafar00 (673457) | more than 7 years ago | (#19488403)

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

In Response to Your Questions (2, Informative)

dpninerSLASH (969464) | more than 7 years ago | (#19488405)

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

Go to hell with your @#$ closed code (1, Funny)

Anonymous Coward | more than 7 years ago | (#19488421)

That says it all.

I second that! (1)

nietsch (112711) | more than 7 years ago | (#19488455)

This has all the hallmarks of some good flamebait...

Re:Go to hell with your @#$ closed code (0)

Anonymous Coward | more than 7 years ago | (#19488569)

And if you have trouble understanding what is meant by "go to hell," here is the practical version:

If you don't plan on sharing your source, then don't use any GPL code with it. It's that simple, really. GPL stuff is written by and for people who want to share their code, so please don't try to exploit it.

Why closed? (-1, Flamebait)

MilesNaismith (951682) | more than 7 years ago | (#19488423)

What is your motivation for closed source? And why do you feel you need to use all the benefits of open source yet keep your code under lock and key? Will you only use it yourself in a locked room and never allow it to be run by anyone else?

Perhaps you should look into DRM restrictions and lawyers. Lots of lawyers.

Only alchemists and very poor cooks feel the need to have secret recipes. Look how little mark they leave on the world.

Re:Why closed? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#19488521)

Because he wants to make some money out of his programming without having to work for a massive company.

He's also trying to create a product for Linux users that, I dunno, might actually make Linux more attractive to current non-Linux users, which would help defeat the Windows menace.

Take your blinkers off and look at the big picture, your zealotry is what gives the rest of us a bad name.

Re:Why closed? (2, Interesting)

moranar (632206) | more than 7 years ago | (#19488683)

He could easily sell his boxes while providing code: the markets for the boxes and the code just need to be separated enough. An example: digital picture frames could be running GPL code: the buyers of those don't quite intersect with the people who want the code, and even in that case, they normally wouldn't be interested in the hassle of reproducing the product.

This assumes two things:
1) The complete package is worth more than the code.
2) You don't sell it exclusively to potential competitors.

In these cases, it should be possible to make a living out of it.

Re:Why closed? (5, Insightful)

dhfoo (238759) | more than 7 years ago | (#19488759)

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.

Re:Why closed? (0)

Anonymous Coward | more than 7 years ago | (#19488701)

Only alchemists and very poor cooks feel the need to have secret recipes. Look how little mark they leave on the world.

You mean like Sir Isaac Newton [alchemylab.com] ?

People can have all the benefits of open source code in their closed source products, they just need to stay away from the stinkin' communists who fly to Communist enemies of the free world [blogspot.com] and write wierd songs [stallman.org] about their trips there while brainwashing the youth of America to give up the competitive advantage that their forefathers faught and severely died for [wikipedia.org] to be used by a country with a population three times larger than ours, further empowering [microsoft.com] our modern day robber barons [wikipedia.org] to ruin the lives of all of generations of Americans to come. Take what you want and tell the Communist or Self-Serving foreign open source people to S.T.F.U.

Re:Why closed? (0)

Anonymous Coward | more than 7 years ago | (#19488745)

Yeah, those insignificant Microsoft cooks.

Re:Why closed? (1)

TheCouchPotatoFamine (628797) | more than 7 years ago | (#19488817)

this comment is pure poppy cock, or FUD as someone like yourself would say. You know, for a *individual* keeping source closed makes a lot of sense, especially to begin with. You know why? Listen up, people like to think. To get it right, to not be *rushed*. If he opened sourced this thing and YOU came across it, sounds like the only reward he'd get is you tellin' him how "it's already been done here, here, and here, why bother?"

exactly the type of motivation that gets you up in the morning, right? Midsize to large companies usually have a persuasive case for opensourcing, but the little guy? When. ever. they. feel. like. it. and because of bullyish peer pressure.

Re:Why closed? (0)

Anonymous Coward | more than 7 years ago | (#19488823)

Actually, you clearly don't know much of the embedded market.
In this market, competitors will try to copy your product by the simple fact that you are selling it and they don't. Because copying hardware is so easy, one has to rely on some software to give it an market edge (because it will eventually get copied anyway). And once your competitor has it, there usually is some price wars that hurts your botton line. There are already products out there that are not worthy manufacturing outside China due to the ridiculous costs and selling prices.

One has to understand that proprietary software makers have their own reasons, and they are entitled too. Unfortunally there is no such thing as GPL rentals, supermarkets and gas stations where you can "contribute" some work to get to be able to use their products ;)

I do closed source software, but I also do open source. Sometimes you can contribute, but one can't realisticly expect that everything to be free and still be able to bring food home. Unless matter-energy convertion and free energy is discovered, we will rely on money for sometime.

Re:Why closed? (1)

jandersen (462034) | more than 7 years ago | (#19488851)

Don't be silly.

Open source is given away freely, and if you believe in that freedom, you also believe in others having the freedom to choose differently. I am myself in favour of open source and would definitely be willing to give my software to the community, but there can be many valid reasons why one would have to produce closed source. Eg. if you do a project for a customer who doesn't want the source for his program to be published.

We shouldn't be religious about this - religion, by and large, has always been and always will be harmful.

Answers (5, Informative)

DrXym (126579) | more than 7 years ago | (#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.

Re:Answers (1)

dedazo (737510) | more than 7 years ago | (#19488577)

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.

Re:Answers (1)

DrXym (126579) | more than 7 years ago | (#19488707)

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 library uClibc cuts out some of the crap of its big brother (localization tables, modular design for selective compilation etc.) and is also covered by the LGPL.

Re:Answers (5, Informative)

julesh (229690) | more than 7 years ago | (#19488589)

2. Yes if they are LGPL. Which includes the standard C++ libraries. Some components such as the kernel also have certain binary waivers.

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

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


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

Re:Answers (0)

Anonymous Coward | more than 7 years ago | (#19488597)

As a clarification: if the GPL is used and if it is in effect, you cannot obfuscate the source when publishing it. The GPL reads:

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

This is not an obfuscated version stripped from comments and helpful variable names. Therefore, if you choose to use GPL-licensed libraries you're obliged to publish the source in the version you use for editing. If you don't want to publish the source, stick to LGPL, BSD, MIT or similar licensed software. And in that case there's no need for obfuscating unless you're a sado masochistic.

Good answers here (1)

Cheesey (70139) | more than 7 years ago | (#19488679)

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 can just continue to use GPLv2. GPLv3 doesn't automatically supercede GPLv2 - you'll only be forced to adopt GPLv3 licencing terms if you incorporate GPLv3-only code.

Re:Answers (0)

Anonymous Coward | more than 7 years ago | (#19488725)

So, to summarize:
1. Yes.
2. Yes, with an if.
3. Yes, with a but.
4. No, with an unless.
5. Yes with a but.

Well... (1)

cp.tar (871488) | more than 7 years ago | (#19488433)

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, you're home free; no-one[1] can force you to publish your source code.
That is not to say that people here wouldn't prefer you to make your project an OpenSource one, but most of us here realize you have to make a living.
I do not know why you'd want to obfuscate your code anyway; it would only make your code harder to read - to you. I don't see why you couldn't encrypt binaries, though.

And yes, going with BSD would completely eliminate your problems (mostly non-existent as they are anyway) - and would even allow you to include all the code in your proprietary program, which you may or may not need.

[1] Well, maybe a few guys with rubber hose pipes or something...

Re:Well... (0)

Anonymous Coward | more than 7 years ago | (#19488783)

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.

Don't use ATI/nVidia drivers as an example. He was (as far as I can see) talking about developing programs for, NOT kernel code. I.e. userspace.

Closed source userspace is fine (but check the answers to the rest of the questions, especially the static linking one).

However, binary kernel modules are a completely different thing. They are in a "walk very carefully here, with lawyers checking every step" area. I can assure you that both nVidia and ATI have lawyers checking everything very carefully. Those drivers have dual-licensed (GPL + proprietary) separation layers, that can link to the kernel because of the GPL and link to the driver because of the proprietary license. And yet we still have arguments once in a while about the legality of this.

Some answers (5, Insightful)

Anonymous Coward | more than 7 years ago | (#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 (1)

aarggh (806617) | more than 7 years ago | (#19488663)

I didn't get the feeling that the submitter was trying to inflame or insult anyone by his terminology, and while I myself would certainly qualify as a linux fanboy, I don't blame him in the least that he was concerned about this aspect. While being passionate about something can be admirable, some fanboy's ( and there are a fair few of them) approach people with genuine questions like these with the sort of zealotry akin to the Spanish Inquisition, and in turn give the entire Linux community the "fanboy" or " fanaticist" label. Not good! But good on him for asking some genuinely good questions that at least a fair amount of people have tried to answer in a helpful way as only a (generally) like-minded, well informed and resourceful community can.

Re:Some answers (3, Insightful)

PopeRatzo (965947) | more than 7 years ago | (#19488719)

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 (4, Insightful)

LLuthor (909583) | more than 7 years ago | (#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:Closed code (1)

Tillmann (859300) | more than 7 years ago | (#19488539)

Hi,

for LGPL-licensed software, "it must be possible for the software to be linked with a newer version of the LGPL-covered program".

How are you going to do that, without distributing either source or object files?

I doubt that it's OK to statically link LGPL libraries and just distribute executables.

bye,
Till

Re:Closed code (2, Informative)

julesh (229690) | more than 7 years ago | (#19488661)

glibc and libstd++ are LGPL, which permits binary only distribution.

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

Have you asked PJ? (2, Funny)

Anonymous Coward | more than 7 years ago | (#19488439)

She is the world's expert on software licencing.

Some answers (1)

moranar (632206) | more than 7 years ago | (#19488449)

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

You will get some of those here, just read on for the advice, and check it before acting upon it.

> I am not a GPL guru

Check with a lawyer. This would be my advice even if you said you were a GPL guru.

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.

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

Not sure about this: if you are using GPL libraries, then I think it's not only "your code", but also someone else's. Check the GPL or other comments about this.

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

It's your code, do what you want with it. You can also obfuscate the kernel code and the rest of the code you distribute, but it will be useless: you have to provide the code for that.

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

You will be forced to publish all open source code you distribute. Even if it is useless outside the device (and I think the GPL3 is going to do something about that).

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

True, I don't think you have to worry about it under the BSD license, only proper attribution is required.

Re:Some answers (1)

El_Muerte_TDS (592157) | more than 7 years ago | (#19488553)

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.

Re:Some answers (1)

moranar (632206) | more than 7 years ago | (#19488617)

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.org/rms-why.html [fsf.org]

coupla things (1)

inode_buddha (576844) | more than 7 years ago | (#19488457)

One look into the lgpl libraries two, remember that the fanboi thing is a relatively new phenomenon. Get out that asbestos underwear.

Tentative answer (3, Informative)

JanneM (7445) | more than 7 years ago | (#19488465)

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.

not to disparage, but (4, Interesting)

rucs_hack (784150) | more than 7 years ago | (#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.

Re:not to disparage, but (1)

tacocat (527354) | more than 7 years ago | (#19488697)

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

I am not an expert in all things so I have to sit down and spend days learning a lot of detail about things that I just never expected to deal with.

I'm just about ready to try releasing this but for me, I'm not sure how/where to do this. Not sure I want to give my code to sourceforge or if anyone is interested in yet another spam filter. Especially if it runs only on postgresql databases. Transitioning to MySQL is not something I have any interest in doing and with the MySQL Zealotry being almost equal to Linux I don't think I'll find much interest.

It depends. (0)

jnelson4765 (845296) | more than 7 years ago | (#19488469)

Although it is generally accepted that you can link to GPL libraries in closed-source software, it has not been tested in court. You can obfuscate code - I've talked to people who wrote encrypted binaries as CS projects. But, if you are going to be releasing a product that has a mix of open- and closed-source, you will still have to provide the source of every bit of GPL-licensed software you do use. That includes things like drivers for any custom hardware that you have - look at the troubles Linksys had with the WRT54G.

BSD is completely unencumbered by these restrictions, and if it works on your hardware platform, it's not a bad option.

IANAL, though, so if you are truly concerned, get yourself a lawyer that knows how OSS works and get some pointers if you want to go the Linux route. Generally, though, if you look at how Linksys/Cisco handles the WRT54GS, and make a similar effort (an FTP site with the source code, and references to it in documentation, in the device OS, and on your website) you should be okay.

oops - oversight in previous post (1)

jnelson4765 (845296) | more than 7 years ago | (#19488527)

Missed the "static linking" in the OP - that does need to have a compatible license.

But honestly, the last time I built something statically-linked for distribution, it was a tweaked OpenVPN for DD-WRT - unless you're running this on a device equally small, don't bother with it (it's a real pain).

Hmm (3, Informative)

Anonymous Coward | more than 7 years ago | (#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.

I'll give it a shot (1)

dedazo (737510) | more than 7 years ago | (#19488485)

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 anything can be reverse-engineered given enough time and motivation.

4. If you link to a GPL library or use GPL code, yes. But again, we don't know what you're doing so if you're not stepping on #1 you're OK.

5. Pretty much, yeah. Or at least it would be simpler. These days you need to rent a lawyer to interpret the GPL. The BSD license does not restrict your rights in regards to distribution and it does not compel you to do anything if you're just linking. There's lots more software for Linux than there is for the BSDs though.

As for the "join us or die" crowd, I'd just stay away from the resident [slashdot.org] zealots [slashdot.org] and you'll be OK. There are a lot of people who care about free software and are willing to help around here.

Answers (0, Redundant)

cerberusss (660701) | more than 7 years ago | (#19488487)

1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
If you make modifications to GPL software (for example the kernel) with both GPL2 and 3, you must also make the source available. If you create your own software, that's not necessary. With GPL3, you're forbidden to create hardware obstacles for users to run modified GPL code. Search for 'tivo gpl 3' for an explanation.

2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
If you want to link without having to distribute your source code: only if the libraries are not GPL. But GPL, BSD licenses do the trick.

3. Can I obfuscate my code (e.g. encode it)?
That's a stupid way to try to work around the GPL. Don't do it. Just don't link in GPL code. Or modify it and distribute it without the source.

4. Could I be forced to publish this code by some 3-d party?
Not if you stick to the rules. I.e. don't modify GPL code and distribute it. Or link to it.

5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
Well, if you stick to BSD-licensed software, of course. However, the Linux community is much larger and much more software comes out. Weigh the advantages and disadvantages yourself.

Don't think you'll have a problem. (0, Redundant)

MadTinfoilHatter (940931) | more than 7 years ago | (#19488491)

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.)
I think you could do it with BSD & LGPL:ed code, but not GPL:ed code. Not 100% sure on this one - someone please correct me if I'm wrong.

3. Can I obfuscate my code (e.g. encode it)?
Sure, but why would you want to, if it's going to be closed source anyway?

4. Could I be forced to publish this code by some 3-d party?
Only if you used other people's code in a manner that violates the licence. E.g. you used GPL:ed code in your software. Linux is however designed in such a fashion that it's quite possible to run both free and proprietary software on it side by side. (Proprietary kernel drivers are a different matter, but that's not what you're doing, right?)

5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
I don't think you'll run into problems in Linux either - but if you thought that the Linux-free-software-fanboys are bad, wait 'till you meet the BSD-ones... ;-)

Just use BSD (3, Insightful)

node 3 (115640) | more than 7 years ago | (#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.

GNU/Linux ideology conflict (1, Troll)

dircha (893383) | more than 7 years ago | (#19488513)

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 system may be convenient, their goals are in direct conflict with your goals - they consider your goals to be outright immoral - and they control the licensing of the GNU projects that make up the system.

I'm sorry, but if your business model depends on benefiting from the continued maintenance and security support of GNU/Linux system projects, you need to very seriously weigh the risks and benefits.

Selling a closed box solution, you're really doing yourself a disservice if you don't start with *BSD and prove to yourself why you should risk basing your product on GNU/Linux.

I think GNU is great personally, but I really think it's funny to see corporations jumping on the bandwagon without realizing who's up front driving.

Re:GNU/Linux ideology conflict (0)

Anonymous Coward | more than 7 years ago | (#19488747)

isn't that it's made for-profit by a company but that you've bought a useless binary. Useless in the sense that, though it is an expressive work (otherwise no copyright) you can't learn anything about programming from it. Despite knowing there are updates needed (bugfixes), you are unable to fix it yourself (unlike, say, your house). Despite it being technically possible, if the supplier doesn't want to port it, you can't either. Despite copyright lasting "forever" the owner can abandon the work at any time they wish.

FSF's four freedoms are not an attempt to remove propriatory code but to remove from any code/binary the bad things that the propriatory model allows to happen.

It is the bad results that are immoral, not the model that gets it made.

PS I seem to remember something VERY similar a few years ago on slashdot with very nearly the same questions.

Yes, of course you can (1)

kripkenstein (913150) | more than 7 years ago | (#19488517)

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 at all. Yes, BSD is somewhat simpler in that you don't need to check these issues. But really there is no reason not to use Linux (if it suits your goals, of course, BSD is also very good).

Since you intend to give out boxes including the Linux kernel, etc., you will need to abide by the GPL, i.e., provide source for for the kernel, etc., NOT for your own code. Note, however, that from GPL3 and onwards, assuming projects adopt it, you will not be able to Tivo-ise your hardware. If you run in userspace anyhow, this probably won't be an issue, but you do need to consider this beforehand.

What is certainly good advice is the following. Don't get too tied to a single platform! Write your app as portable as possible, so that you can deploy it on Linux, BSD, OpenSolaris, etc. (and if you have a GUI, then using a cross-platform toolkit, and separating GUI from backend as much as possible to facilitate even changing that). Then should issues arise (not just with licensing!) you can adapt.

Re:Yes, of course you can (0)

Anonymous Coward | more than 7 years ago | (#19488809)

"In fact you can even use a GUI, assuming you pick GNOME/GTK+ (not KDE/Qt)."

LOL, not only there are BSD trolls here, but there also are some GNOME/GTK+ trolls...

1. GTK+/QT are toolkits for GUI building GNOME/KDE aren't
2. You can have closed source, statically linked application that uses Qt. Opera is a good example of this kind of application. You just need to get Qt with a correct licence and statically link to that.

Get a lawyer. (-1, Flamebait)

kosmosik (654958) | more than 7 years ago | (#19488531)

You don't get basic stuff, consult your concerns with lawyer - that would be safer than asking on Slashdot but if you still wish to know my answers:

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

Do what? Write closed source applications for Linux? No problem.

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

WTF are Linux libraries? Linux is a kernel. Get more specific.

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

Why not? And what for? You think it will be safer then? :))) BTW obfuscating has nothing to do with encoding. You don't get even basic stuff right.

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

Which code?

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

What are BSD boxes?

Re:Get a lawyer. (1)

oliderid (710055) | more than 7 years ago | (#19488673)

[snip] the smart ass answer

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

>What are BSD boxes?

A Computer running BSD. Genius.

Re:Get a lawyer. (1)

kosmosik (654958) | more than 7 years ago | (#19488727)

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

>> What are BSD boxes?

> A Computer running BSD. Genius.

And does it changes anything in terms of GPL? I mean the posterd doesn't even know what he is asking for. He is not asking about linking with some specific libary (then go check it's license). He is basically asking if on BSD boxes different license goes for the same things? If you wish to use some GPL library it is GPLed no matter if your un it on BSD, Linux, Solaris, Win32 etc.

Re:Get a lawyer. (0)

Anonymous Coward | more than 7 years ago | (#19488849)

Hey, kosmosik, you made an ass of yourself. Now just live with it. Till you die or the Internet dies, whatever comes first.

Why you will fail: (1)

nietsch (112711) | more than 7 years ago | (#19488551)

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 weak, and you are just trying to dodge the flak on it. That makes you stubborn and thus inflexible.
I think you are not seriously considering anything like this, you just found a good way to stir the pot and enjoy looking who is taking your flamebait. Yes, I did too, always glad to make some loser happy.

Yes you can (1)

mikefocke (64233) | more than 7 years ago | (#19488557)

I just bought a Sony TV that has embedded Linux and whose documentation contains the appropriate credits and disclaimers. You can assume they did the appropriate legal investigation before they based their rendering engine (the software that converts one form of display coming in over cable to the native resolution of the TV screen) on Linux and OSS libraries. My cable box does too.

So be reassured, if the big boys do it with much to lose (the rendering engine is one of the few product differentiators the flat screen TV makers have and the cheap panel makers would love to have Sony's), so can you.

Having said that, every time you use a library, you need to read and understand the licensing terms of that library.

Answers (1)

jrumney (197329) | more than 7 years ago | (#19488565)

  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? (5, Insightful)

winchester (265873) | more than 7 years ago | (#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.

Obfuscation is great... (0)

Anonymous Coward | more than 7 years ago | (#19488579)

... You definitely need it if you want to hide your gpl violations properly.

Good idea to cover your tracks that way!

Some answers (1)

NoOneInParticular (221808) | more than 7 years ago | (#19488583)

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. The GPL version comes with readline (dynamically linked, but still forcing that version to be GPL). The non-GPL version comes without (dynamic linking suppressed).

However, for your stated goal, all you will do is link against libc and libstd-c++. Both of these have an exemption clause. Just be sure that all other libraries you link against are LGPL or BSD licensed, or otherwise try to buy a license.

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

If you are not licensing it under GPL or such, of course you can obfuscate it. Don't see why though, as you are distributing executable, right? If you are forced to open source it due to using GPL code, no, you cannot obfuscate your source.

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

Unless you illegally distribute someone else's code, you can't be forced. Can Microsoft be forced to publish their code? Not unless they do something illegal.

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

No, BSD boxes also come GPL libraries, you just have to know what you use.

As with all software development, you have to make sure that if you use 3d party code (be it BSD, GPL, LGPL or proprietary), that you are allowed to do this. Don't use a library if it doesn't give you permission. Static/dynamic linking is not the issue, it is use. Just play it safe and don't use any GPL code that doesn't give an explicit exemption (the necessary libs give that exemption).

For your stated goal -- completely self-contained code that doesn't use any outside libraries except the system ones -- it doesn't matter whether you use Linux or BSD. All changes you need to make to linux to put it on your embedded device should however be open.

And in general, especially if you go the proprietary route: be nice to your free environment, and don't try to leech beyond what is given to you.

Answers (1)

TheRaven64 (641858) | more than 7 years ago | (#19488611)

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't really know what you mean by 'Linux libraries,' and it makes me wonder if you really do know enough about Linux to do this. Most 'Linux libraries' are actually GNU libraries. The standard C library for Linux is glibc, which is LGPL. If you statically link to an LGPL'd library, then you are required to make the object code for your application available so that your customers can re-link your code to a new or modified version of the LGPL'd library.

If you are making an embedded system, this could be difficult, since it would require you to make it possible for end users to modify the code running on the device. Note also that some libraries for Linux, such as GNU readline and Qt, are distributed under the GPL, so any code that links to them must also be GPL'd.

3. Can I obfuscate my code (e.g. encode it)?
I thought you said you were making it closed-source?

4. Could I be forced to publish this code by some 3-d party?
In theory, if you violate a license, it's possible. What is more likely is an injunction preventing you from distributing the (L)GPL'd code that you were using in contravention of the license.

5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
Correct for the most part. Of course, if you use any LGPL'd or GPL'd libraries on top of any BSD then you are still bound by the license.

If you are making an embedded system, one of the BSDs is probably a better choice. The clean separation between the base system and third party software makes it much easier to develop this kind of thing, and to audit licenses. If you take something like OpenBSD, then everything in the base system can be used in an embedded context with a closed-source application, and you can check the license of anything else you install after that quite easily.

Linux has the buzzword-compliance, but it's not always the right tool for the job.

Remember Kororaa? (1)

andersRson (1114881) | more than 7 years ago | (#19488623)

The kororaa project made a live-cd with linux, x11 and proprietary drivers for video cards from nvidia and ati. They stopped distributing it because som kernel devs claimed it was a violation of the GPL to distribute GPL software and GPL-incompatible software on the same media. That sounds like what you were planning on. Also, i think that you are not allowed to link statically to GPL'd code, not sure about LGPL either. You can link dynamically to LGPL though. see http://kororaa.org/static.php?page=gpl [kororaa.org]

Re:Remember Kororaa? (1)

jrumney (197329) | more than 7 years ago | (#19488669)

violation of the GPL to distribute GPL software and GPL-incompatible software on the same media.

That's not quite the full story. Binary kernel modules live in a grey area already. They get away with distributing them separately, because it is the end user who links the shim to the binary module, and under the GPL the end user is free to do what they like if they do not distribute the results. Once you start shipping a distribution with those modules enabled by default, you are breaking the GPL.

Nobody can force you to open your code (1)

GauteL (29207) | more than 7 years ago | (#19488629)

... 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 finances to stop selling the product and remove all GPL-code.

GPL-code and proprietary code are thus not different. If you include either in your product without permission, you are at risk to being sued. But in neither case does the owner of included code have any claim to your code. The GPL is thus not viral, that is just a lie fed to people by for instance Microsoft marketing. Using GPL-code does not 'infect' your code, but of course you can be sued for copyright infringement.

The only difference between using someone elses proprietary code without permission and using GPL code without permission is how easy it is to find GPL-code to misuse.

detailed answers (0)

Anonymous Coward | more than 7 years ago | (#19488633)

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

Yes, you can. Just remember that both GPL2 and GPL3 force you to provide the source code of the kernel (and any modification you make to it) to your customers. The same applies to all other software included covered by the GPL, like for instance the GNU C library (glibc).

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

There's no problem with glibc. For other libraries you plan to use, have a look at their respective licenses. If it's LGPL it will be OK. Again, remember you have to provide the source code of the libraries to your customers.

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

Of course you can, but this will buy you nothing. If you have to modify the kernel or some library to make it work with you device it would be much better for you to share your modifications with the community. This way you get good PR and maybe some help maintaining those modifications from the developers. Beeing open will help you in the long run. That's what Open Source is about ;-)

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

Only if you violate their license. Those are the things you want to avoid:

- linking with a library under the GPL (not LGPL!)
- modifying a GPL or LGPL library or program.

Watch out for other licenses (not all is GPL or LGPL): X11, MIT, BSD, MPL... It all depends on the software you're using.

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

No. First, programming in Linux doesn't tie you to any license, only *distributing* the program ties you. Second, in a BSD box you can have programs and libraries under any license: GPL, MIT, whatever. Using BSD doesn't magically free you from your obligations if you use a GPL'd library. But... you will not need to distribute the source of the BSD kernel and the BSD C library to your customers, even if you make modifications (but you won't get any help).

You're trusting your businesses legal fate to /.? (0)

Anonymous Coward | more than 7 years ago | (#19488635)

You need to ask a real lawyer these questions and get their answer in writing. A lot of good the answers you receive here will do you if you get dragged into court. "But your honor, a bunch of kids who live in their moms' basements said it was legal!"

NetBSD (1)

PhotoGuy (189467) | more than 7 years ago | (#19488645)

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 processors, greatly increasing your choice of embedded platform. It is used a lot in embedded systems, and it would be my first choice. It's a small, fast, portable distribution. Try it out. If it does what you need, use it. That would be my recommendation.

As far as a development environment goes, I had it fired up awhile back, and installed all the optional (and GPL) port stuff, including KDE, Gnome, yadda, yadda, yadda. Everybody who saw the desktop assumed it was a Linux box. It's pretty hard to tell the difference in daily use when you install all the optional gunk. So if wanting to use Unix for it's desktop development environment is a factor, do try NetBSD (or another BSD) with all the add-ons.

the basics are: (1)

Britz (170620) | more than 7 years ago | (#19488647)

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.

Don't be lazy. Read the licenses. (0)

mmcuh (1088773) | more than 7 years ago | (#19488681)

1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
Have you even read the license for Linux (the GNU General Public License, version 2) ? Writing a program for an OS licensed under that licence does in no way force you to use that licence for that program.

2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
What "Linux libraries"? If you mean glibc, then yes. Have you even read the licence for it (the GNU Lesser General Public License version 2.1) ?

3. Can I obfuscate my code (e.g. encode it)?
You can do whatever you want with your code, but since you're not going to show it to anyone that sounds both stupid and paranoid.

4. Could I be forced to publish this code by some 3-d party?
Not for any of the reasons given above.

5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
Which problems? If you're going to write software that uses other people's code (libraries etc) you need to make sure that you are not using that code in ways that you are not allowed to. That goes both if you are writing free software or secret closed proprietary software. Read the licences for all the libraries you are going to use, whether you are writing for BSD or Linux or Windows. Really.

Oh, and go to hell with your @#$ closed code. Why should we help you when you're not going to help anyone else?

Macs? (1)

mr-Shutter (1114883) | more than 7 years ago | (#19488693)

Some one beat you to it, It is called a Mac.

What type of embedded system? (1)

Cheesey (70139) | more than 7 years ago | (#19488709)

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. You should ask your question again on the mailing list or forum for the specific embedded Linux that you intend to use, because general Linux licencing advice may not apply. Find out what licences do apply and seek legal advice.

One other thing. Remember that even if your Linux distribution does incorporate GPLv3-only code in the future, that cannot stop you from distributing the current version under the GPLv2 if you find the GPLv3 terms objectionable in some way.

You can if you want to... (1)

dkf (304284) | more than 7 years ago | (#19488721)

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. encode it)?
I'm sure you can write code that any sane programmer would rather gouge their eyes out with a rusty spork than read. It's a bad idea, but it's your code. Be aware that you can't prevent someone determined enough from taking your code apart anyway; you can only make things hard so they don't bother.

4. Could I be forced to publish this code by some 3-d party?
For releasing a binary that runs on Linux? No. For fouling up your licensing? Yes. For annoying a court? Yes. Seek legal advice on this if you're worried (but if you don't link against the wrong things, you should be OK).

5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
I don't see them as being big problems anyway, but you right in that BSD-based boxes won't have them at all. Whether you can live with the smaller community developing for that platform (and consequences like less broad hardware support, etc.) is your call.

Talk to the FSF (1)

Pvt_Ryan (1102363) | more than 7 years ago | (#19488735)

If you ask them nicely they will tell you what you can and can't do with your code, at the end of they day that's (imo) why they exist (to educate people as well as defending OSS).

Don't statically link libraries (3, Informative)

geoff lane (93738) | more than 7 years ago | (#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.

Answers (0)

Anonymous Coward | more than 7 years ago | (#19488763)

Theres no substitute for professional advice, but this should get you started.

1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
Without knowing what you intend to do its somewhat hard to provide a specific answer. But here goes. Currently under the GPL2 its possible to create a locked box with an underlying GNU/Linux system supporting your commercial applications. Also known as Tivoization. GPL3 will put a stop to that. Ultimately you have an obligation under either version of the licence, the main one being to provide sourcecode for the GPL components you distribute (along with changes you make to those components). GPL3 adds a further obligation, essentially the GPL portions of your product must be freely modifiable by the user (the screw Tivo provision). As long as you meet the obligations either licence impose upon you, then your free to do whatever you want.

2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
Yes you can statically link. But if you control the hardware and software on the box dynamic linking isn't really an issue, and does make it easier to upgrade the various free parts of the system without causing to much work for your non free portions.

3. Can I obfuscate my code (e.g. encode it)?
What would be the point? The application you write would be distributed as a binary so most users wouldn't be able to view the source. If you encrypt the binary in some way, then you need a way to decrypt the binary prior to execution, and that would be found by the type of user who's interested in decompiling your app.

4. Could I be forced to publish this code by some 3-d party?
No. As long as your code is independant of any GPL code then its entirely your decision if you publish the source or not.

5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
Tivo as an example has no problem selling boxes based on GNU/Linux, but the BSD licence is far more commerce friendly and theres no risks that a later draft of the licence will screw you.

I wish you luck in your commercial enterprise, but I fear it may not be enough if you can't distinguish between the value of forum and professional advice.

Ignore the rude fanboys (1)

Viol8 (599362) | more than 7 years ago | (#19488771)

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 app (1)

Qbertino (265505) | more than 7 years ago | (#19488787)

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 about open source. OSS is mostly a devmodel asked for by developers (because it has significant advantages over closed source). End customers just want the app to work. If you app is good and has a fair price no one will give a damn if it's GPLd or not.

But *you* *absolutely* want to make sure that you're not using some pure GPL source in your libs or something. Otherwise you will hopefully get caught and recieve a legal ass-chewing. Professional developers are fed up with people not giving a shit about copyright just because they are in OSS territory - and for good reasons too. Which, btw., has nothing to do with 'fanboyisim' or something. Do you call Bill Gates a fanboy when he comes to have your behind on a silver platter for you using MS .Net Studio or the likes for something it isn't licenced for? No? Thought so. Ask a question like this in the MS forums and you'll get some snailmail from the MS legal team the next day.

Bottom line: Be fair and square and don't cheat and OSS will be the best plattform and community to run your stuff on. Cheat and you'll get the bill someday. Good look with your business.

thats the overall problem with Linux (1)

zakeria (1031430) | more than 7 years ago | (#19488793)

Company's really need to feel secure when developing for Linux, its all this licensing garb thats screwing with everything including game development. I know first hand that it stops potential commercial development for the OS therefore stopping the development of Linux in general!

Answers (1)

thetagger (1057066) | more than 7 years ago | (#19488801)

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

Depends on the license. Your problem is with the GPL: do not link to GPL libraries at all, ever! Closed apps can't use them. You can, however, use LGPL libraries if you link to them dynamically (or provide another way for the user to relink the library himself). I don't think you can statically link to them unless you provide that mechanism, which is weird.

You can, however, ship your own dynamic libraries if you wish. You don't have to use the system's libraries. This is as good as static linking and avoids the legal problems by allowing the user to change the GPL'd portion, which is the point here.

Also notice that some libraries have special exceptions to the GPL: the Linux kernel itself and the GNU libc are two of them. (You can link proprietary code to the Linux kernel, and you can statically link the libc, IIRC).

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

Yes, but there's no point in doing so.

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

The GPL attempts to be viral - that is, if you do something wrong like statically linking to a GPL library, it tries to force you to license your code under the GPL. This has not been tested in court. What GPL vigilante efforts usually try to do as a first step is get infringers to clean up their code. So, do not willingly violate the GPL, and if you do get one such notice from the community, do stop everything and be sure you are clean and forthcoming about it.

(This makes GPL compliance look harder than it really is - GPL infringement is, I am sure, intentional and usually made by people who think they can get away with it. This is not your case.)

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

No. It all depends on which libraries you use. BSD systems usually rely more on BSD-licensed libraries, while Linux systems usually rely more on GPL-licensed libraries, but there are BSD and GPL libraries on both sides of the fence, so you should be careful either way. Hell, even if you do Windows development you have to carefully consider every license for every library you use - and there are GPL'd libraries under Windows too. As a developer, you have to respect copyrights and licenses no matter what platform you are developing for. That's boring, but that's the way we get along.

Pay for it (1)

fuliginous (1059354) | more than 7 years ago | (#19488805)

If that is your philosophy and total intention why not pay for all the things you are going to use and then have total entitlement to keep things hidden within your world?

I don't say except to highlight that you sound completely closed to the idea that picking up and using all those things for free leaves you a moral obligation to reciprocate at all.

It is that perception that probably got you the slurs. For example instead you could price everything you needed in the commercial realms and just donate a small fraction of that to one of the projects, say 10%. Why do that, because if you start using the Free tools it is in your interest for them to perpetuate and so some level of giving back helps ensure your future.

And looking at your questions yes I think all of them are fine. You really need to go read some of the things the likes of Linus has said about connecting to the kernel. Use the API and build on it and you're fine, integrate beyond that API boundary with actual internal tinkering you begin to infringe the GPL and must publish. (In short)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?