Slashdot Mirror
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?
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?
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
(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 ..."
OK but if you want to sell software you need to understand licensing.
Yes, glibc is licensed under the LGPL which is compatible with non-free software.
I suppose so, but unless you are some kind of algorithm genius (and I don't think you are) it is not really going to be worth anybody's while to do reverse engineer it.
http://michaelsmith.id.au
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. ;)
RebateFX.com - Spread rebates for Forex traders
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
...for the answers.
Next.
That says it all.
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.
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...
Ignore this signature. By order.
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.
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.
LL
She is the world's expert on software licencing.
> "I want to start (very small) software/hardware business. The code in question
> will be closed source. I won't modify or use any GPL code or any 3rd-party sources.
Maybe not in your own code, but if you distribute linux boxes, you are using GPL code.
> It will be my own handwritten C/C++ code from start to finish. I am planning to sell
> embedded-like boxes with an OS (Linux or BSD) and this code.
This is possible. TiVO do something like it.
> I am more familiar with Linux but I am scared a 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.
"I think it would be a good idea!"
Gandhi, about Internet Security
This has all the hallmarks of some good flamebait...
This space is intentionally staring blankly at you
One look into the lgpl libraries two, remember that the fanboi thing is a relatively new phenomenon. Get out that asbestos underwear.
C|N>K
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.
Trust the Computer. The Computer is your friend.
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.
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.
Why can't I mod "-1 Idiot"?
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.
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 zealots and you'll be OK. There are a lot of people who care about free software and are willing to help around here.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
8 of 13 people found this answer helpful. Did you?
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.
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.
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.
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.
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).
Why can't I mod "-1 Idiot"?
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.
This space is intentionally staring blankly at you
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.
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.
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.
... You definitely need it if you want to hide your gpl violations properly.
Good idea to cover your tracks that way!
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.
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.
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.
I am TheRaven on Soylent News
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
... 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.
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 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!"
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 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.
Love many, trust a few, do harm to none.
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.
[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.
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.
>north
You're an immobile computer, remember?
Oh, and go to hell with your @#$ closed code. Why should we help you when you're not going to help anyone else?
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.
"I think it would be a good idea!"
Gandhi, about Internet Security
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.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Some one beat you to it, It is called a Mac.
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?
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 and write wierd songs about their trips there while brainwashing the youth of America to give up the competitive advantage that their forefathers faught and severely died for to be used by a country with a population three times larger than ours, further empowering our modern day robber barons 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.
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.
>north
You're an immobile computer, remember?
"Little does he know, but there is no 'I' in 'Idiot'!"
>>> 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.
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).
Yeah, those insignificant Microsoft cooks.
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.
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.
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.
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.
A polar bear is a cartesian bear after a coordinate transform.
Most of the people who get really worked up and adversarial about closed source on linux are usually kids or stuck-forever-in-academia student types who've never held down a real job or had to earn money for their family using their own intellectual property. If you just ignore those fantasists they'll eventually get bored taunting you and go back to their playstations. Good luck with your project!
If I catch you including my GPL code in your closed source app I can't force you to open source the entire app or release/publish/whatever the source of it. I can, however, force you to stop distributing it. And I can sue you to chunky kibbles and into next wednesday for 10 bazillion dollars of damages for copyright infringement and some other illegal activities. And if you use my code and you don't opt to open source your app I probably would sue.
.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.
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
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.
We suffer more in our imagination than in reality. - Seneca
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!
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.
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)
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.
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
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.
Hey, kosmosik, you made an ass of yourself. Now just live with it. Till you die or the Internet dies, whatever comes first.
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.
avoid the linux gpl all together. 'you cant do this, you cant do that, you must include this... blah blah blah'. It's free with tons of strings.
read the freeBSD license. DO WHATEVER YOU WANT, WE DONT CARE! pretty sweet aye?
>Get a lawyer
Ya, because we all know that lawyers (as in any other jobs in fact) are only made of experts that will always give you the correct answer. No matter if it is on a difficult, often misunderstood, and generally not tested in courts topic...
Seriously, I don't understand why so many answers say that, is it some kind of magic formula?
When will we get rid of that THE LAWYER KNOW-IT-ALL crap? It's just sad.
Sigh...
6 Can I make a living at it? A.. not likely.
The truth shall set you free!
This does not constitute legal advice, but consider this:
the point of the GPL is to set up a community wherein source code is treated as chess pieces. Everything sits in plain view. You're asking to change a fundamental assertion about how the community functions. You want a face-down playing card on the board to represent one of your pieces, in your variation.
No one gets enthusiastic about having their basic assertions tweaked. The reaction is going to range from silence to rage.
Admired from a distance, one has to admire your courage. It's akin to walking into a kosher restaurant and ordering a ham and cheese sandwich.
Best wishes,
C
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Basically mr. anonymous coward "businessman", if you don't like the license, don't use it.
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
4. Could I be forced to publish this code by some 3-d party?
The 3-d people are harmless, it's the 2-d people you need watch out for. They have no depth!
you can take your closed source code and shove it up your @$$...
QNX. Get a commercial license for it, use qcc and do whatever you want. It is perfect for the job. You can test development on the free evaluation which reverts to the non commercial (NC) version after a period of a month I believe. The "QNX Momentics 30-day Eval - QNX Neutrino x86 Host" would be the product to try. An application developed for QNX should also build on Linux\BSD\gcc with minimal configuration. Give it a try.
That's curious.
If you're doing any interop with system commands, local daemon, local facilities, etc., it may behoove you to use the same libraries that they use - and those would be the system-wide shared libraries. Also, if you plan to do field patching and your application consists of several programs that use the same application libraries, you can save yourself a lot of CM headaches by using shared libraries.
Suggest you read and understand the ld(1) man page, especially the '-rpath', '-h', and '-i' options.
Best of luck.
In the course of every project, it will become necessary to shoot the scientists and begin production.
I avoid purchasing anything that isn't disposable and can not be serviced multiple places.
Would I buy a car that could only be fixed at one service station? Would I buy a home that can only be fixed by one contractor? No way.
I heard Eben Moglen explain this in a presentation he gave a few years ago about the SCO mess. The GPL is only a license. You either abide by it or you don't. It can't force you to do anything.
Even if you included some GPL code in your app (which from the sounds of it, you want to avoid), you have two choices. You either release your source code under the GPL so you can continue distributing your app (binary), OR you don't distribute anything. It's your choice. A third choice would be to remove the infringing code.
I'm not going to take the "go to hell" route - what you do is up to you, but consider the practical implications of what you are doing to the consumer - the fact is that I am averse to buying hardware that I cannot get an open-source driver for. The driver won't be installed by default with my distro, it may involve the use of a kernel patch to work, and I can't guarantee that you will always keep your driver up to date with future releases of linux or the GNU utils. If you drop dead, then there may be a kernel release in the future which your hardware won't work with, and I'll be left holding a piece of junk.
In other words, if you choose the closed source driver route, you are choosing something which is going to be a complete pain in the arse that nobody is going to want to buy. If you really need to hide trade secrets, there's nothing stopping you putting closed source into a chip on the hardware itself, and just use an open source driver in linux to talk to it. Problem solved.
I wrote my first program at the age of six, and I still can't work out how this website works.
hey, the GPL, LGPL and BSD licenses are there for you to take and use. They have been through the lawyers and are well understood. If you want to write your own code and distribute it under other terms while using/linking against software under any of the mentioned licenses, you need to pay up for the legal advice. Go see a lawyer.
But is it actually beneficial to use proprietary licenses for your code? This really requires you to write some awesome code that everyone wants - enough that they also want to pay you. OK, nice with some ambitions.
Otherwise, as a startup, you may actually advertise it as a security that your software is open source: If you go out of business your code will be available for some one to continue and not in the hands of your creditors. Once you get some solid stuff going then you may change the terms.
Everyone considering linking statically to anything should read http://people.redhat.com/drepper/no_static_linking .html.
The issues with dynamically loaded modules it particularly important. For example, if your program's statically-linked copy of glibc tries to load an NSS module from a different version... BOOM! If you link to another library that an NSS module that you load is also linked to, but with a different version... BOOM! And so on. This doesn't apply only to glibc, it applies to any library that may load DSOs at runtime, for whatever reason. For example, gtk theme engines, gnome-vfs protocol handlers, gdk image format handlers, input modules...
>Example: lots of people I know have Linksys (WRT54G[L]) wireless routers _because_ they know they can
/product/ was software, I, too, would be leary about giving away the code for free.
/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.
>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
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 guess I just still don't understand the free software movement as a business.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
Only alchemists and very poor cooks feel the need to have secret recipes. Look how little mark they leave on the world.
Nonsense. This individual has just as much right to develop closed-source software as you do open-sourced. There's nothing wrong with arguing a point, but stick to reality. Are you implying that, love them or hate them, companies like Microsoft, Apple, Oracle, IBM, et. al, haven't left a "mark on the world?" Or are you just dealing with your imaginary alchemists and poor cooks?
Do you have access to the source for every bit of embedded firmware in the electronics you own? Most likely not. Does that make you a hippocrate? (answer left as an excersise to the reader).
It is actually possible making a living. My employer gives away an Open source entireprise CMS, and sells suppport for it.
In the case of the OP, if he's selling it with hardware in a nice and friendly package, he could probably safely Open Source his own code, as people will not be paying for the code, but for the hardware and for the convenience of not having to install it themselves.
I think you could make a handsome living selling sleek boxes with MythTV installed, for example. Most consumers don't care that they could also do it themselves, they simply want to buy a box that works.
Write it first for BSD under whatever license you so choose. Then port it to the Linux kernel (but it must be a port and not a re-implementation). The software is then a derivative work of your BSD driver and not of the Linux header files. It's not exactly ethical but it's one of those funny loopholes in how the GPL has bastardized copyright law into contract law. If your code is not a derivative work of their copyright then their contract does not apply.
For the record. If you're selling hardware that you manufacture you're better off releasing under a BSD-ish license. It will increase the likelihood of both hobbyists buying it to tinker and other small companies buying it to resell it with their own special sauce.
Slashdot is a forum for legal research, not legal advice. So is Groklaw. The point is to get the legal research out of the way so that you don't have to pay an attorney to pay his paralegals to do it. Then you show the research to the attorney, and checking the references that Slashdotters provided goes faster than doing the research from square one, saving the project money.
> 2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
Huh? Dynamic linking, in a controlled environment, is too much to bear?
This guy is obviously a troll trying to whip up the GPL fanboys and show what an irrational bunch they are. The way the question was phrased made me suspect it, but this question clinches it... this guy is a troll.
Rather than try to answer the questions directly, I thought I'd try a different approach.
From the perspective of the software you are writing:
- BSD vs. Linux is irrelevant, in terms of the GPL. Commercial, closed source apps can and are built on both, with no encumbrance due to the license of the OS itself.
- In terms of libraries you may use: the OS itself (BSD vs Linux) is irrelevant. If you go with BSD OS and use a LGPL library, you are still bound by LGPL wrt that library. If you go with Linux and avoid all encumbering licenses, as you suggest write it all from scratch, then you are also in the clear
From the perspective of the hardware:
- If you go with Linux, you are considered a distributor under GPL, and bound by it to the extent that it covers distributors, even if you don't do anything with your Linux except install it. iirc this means you need to be able to provide users with the same source media you received with your Linux, so that they can hack the OS (and any other GPL you include, such as GNU tools) however they see fit. I *think* that your own code is o.k., but the line can get blurry, esp. if you start patching the OS to make your app work (ex: TiVo). It's a good idea to get a copy of GPL yourself and read it, talk to the FSF if you need clarification (you may get a "closed source is bad spiel", but you should get the information you're after), and sit down with your lawyer to make sure you understand what you're getting in to.
- If you go with BSD, you avoid this entire hassle, other than possibly if you use a version of BSD that has an acknowledgment / advertising clause, then you still have to comply with that. Unlike GPL, BSD doesn't burden distributors with a political agenda.
...called hd24tools. I have my reasons for wanting it closed- among other things to stay out of trouble with Alesis.
Go ahead and write closed-source- but be aware of the licenses of the libraries against which you link. FLTK is 100% liberal for any open or closed source use, be it commercial or not; mysql allows you to include it in commercial apps, as long as it is not the *only* database engine that your app supports. Libsndfile does not allow you to statically link to it in closed-source software, but requires you to provide the shared library. In my opinion that's a small price to pay, so that's how I distribute my software. Do check out the terms for each individual package that you use.
I suppose you have no trouble providing the source code of the GPL stuff that you use- but as long as you don't modify the GPL'd stuff you won't have to as the official source already *is* online. If you need to change the GPL'd stuff, put a fork online.
As for the bits that *you* write: Whatever license you put those bits under is your business. Give credit where credit is due- if you use zlib, no harm in thanking the authors. Don't take credit for stuff you didn't build.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Yes, you may. But millions of people license software in this manner and have no problems with the arrangement. If there is a level of trust with the vendor, people don't mind having things closed source. I know a lot of folks on /. would probably use software that is GPL'ed and has major functional limitations compared to a similar commercial closed-source product. However, in the business world, the reality is, you have to use what is most efficient and works best for you, even if your up front cost is greater and the custimization of that product on a fundamental level is not an option.
6. I really appreciate the cost and effort saving to my business that I make by leveraging the efforts of other workers, but I believe that my business model doesn't work if I open my own sources.
How can I give something back to the community in an attempt to show that appreciation ?
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.
1. Why would you _give_ your code to sf.net?? You can _use_ sf.net as a host for your project, but you would not be giving anything to them. Ditto for savanna &c. 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. 2. Leave transitioning to MySQL as an exercise to the reader, then.It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
To me what Richard is talking about is immoral.
Personally, i feel that restricting me in ANY way is immoral to me. Perhaps RMS needs to reconsider and seriously weigh the risk and benefits.
( sure, im joking here somewhat, but you get the point: you cant start tossing in morals in a purely legal discussion about licenses )
---- Booth was a patriot ----
I work at a company where we sell turn-key solutions based on Linux at 100K$ a pop and you can bet the legal department went over everything and there is nothing to be scared of. Just don't use librairies that don't allow binary only distribution.
Why aren't you a freedom warrior? Just a thought - because the fact that these things (Linux, BSD) are provided for you for free, would make this potential business of yours possible! Perhaps you'd prefer to pay Microsoft's licensing fees?
Look at the networking products that are gpl'd. Even the proprietary ones have bugs. The proprietary ones charge you for the license then charge you for a "support contract". The GPL'd ones are more upfront and just charge to custom code the features you want/implement the network. Software becomes your product still, but its an implemented running piece of software, not a box on a shelf. It delivers more value to the end customer, and becomes a mature, robust codebase with less resources for the parent company. (Sorry, too early in the morn to dig up links)
My Babylon
Agreed. But he'd already offended a lot of us, by saying he's just trying to make a living, so he wants to use closed source, but not acknowledging that he'd be making his living off the backs of the many thousands of people who worked on the open source stuff he wants to use.
To questions one, two, three, four and five: eat a cock, shithead. And by "cock", I mean "penis" -- the "meat" in front of the "two veg".
We don't need your kind around here. You want something for free, to make a profit out of? Fuck off. Go leech somewhere else. People shouldn't be answering questions for the likes of you, regardless of how frothy-mouthed they may be.
Note, I'm not a lawyer. Contact one today.
1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
YES. Nowhere in the GPL, ether version 2 nor 3, precludes you from running a closed source binary on a Linux system. If it did, we wouldn't be as far as we are now -- and I wouldn't be running Second Life on a Nvidia Geforce 7 series card.
2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
Yes, check the manual pages and info pages on GCC. To keep on the licence issue, the GPL does not transfer to code compiled by GCC, and the "Lesser GPL" that is used on libraries allows you to staticly link them into closed code.
3. Can I obfuscate my code (e.g. encode it)?
It would be useless. If you ship a binary only, the obfuscation would already be worked out by the compiler, and a decompiler could be used to steal the code. Since you're not licencing under the GPL, you must make a licence that prohibits decompilation and disassembly without permission.
4. Could I be forced to publish this code by some 3-d party?
No. Since you are not licensing it under the GPL, the BSD variant licenses, the Apache license, the Perl Artistic License, or any Open Source Foundation approved license, it would be under what you specify in your own license.
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
It is only a legal issue, not a technical issue. You really need to consult a lawyer who is willing to delve into the GPL, the Lesser GPL, and the BSD licenses.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
"The source code for a work means the preferred form of the work for making modifications to it."
It doesn't seem that this guy needs to release his code in any event, however.
It's not wasting time, I'm educating myself.
That's the first thing I thought when I read the blurb: I think _statically_ linking is an incredible hassle and far more difficult than dynamically linking... especially in Linux.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
for your project(s).
There you go - do as you like!
Seriously - why do you want to use and open source OS at all given your frame of reference? VxWorks, QNX, Windows XY, there are a mariad of closed source OS's out there that would fit your needs.
Consider open sourcing your work. I think you wil find that if your product is good, most people will not be interested in the slightest about your code, and your competitors will for the most part play by the rules.
Here is a question of my own - can you charge exra for the code and still be GPL compliant?
I am very small, utmostly microscopic.
dude, you fucking moron
have you learned anything about customer goodwill? been living under a rock lately? let me enlighten you
if you are selling HARDWARE that requires some software to go with it, you are only pissing off potential users of the hardware by not letting them tinker with the software. What good is making some software closed source if it can only run on your hardware anyway?
But I do know that if my sole
Very true I hate to admit. If there is not hardware or a service to sell then selling the program and giving away the source just will not work together. I can not tell you how I hate to admit that.
Those that do not know, pay for it.
Open source is given away freely,
It doesn't have to be. You can sell it if you want. Normally I wouldn't mention this because It's a bit pedantic, but it's relevent to my next point.
and if you believe in that freedom, you also believe in others having the freedom to choose differently.
But doesn't this mean that if you believe in freedom, then others should also have the freedom to do what they want with your code?
The thing is, the GPL doesn't require that you give the source to the community. It does require that you give it to the customer and it does prevent you from stopping them giving the source to the community. The only significant freedom that the GPL removes is the freedom to publish the binaries without the source. It's not hugely inconsistent to believe that people should be able to do what they want with software.
IMHO the submitter padded a single doubt with superflous questions to make it legit, here is the corrected questionary:
:)
4. Could I be forced to publish this code by some 3-d party?
This guys knows that building what he wants to do will make it work for ages if he does not rely on some GPLed work, so being sure that no one could force him to release the code its top priority...
I woke up in a cynical mood today...sorry
NEOCA - Custom LED Flashlights
YES!!! The BSD license is basically a wordier version of the MIT license, which is displayed below:
Thus BSD and MIT licensed code are treated as public domain, except for the the forced attribution, and sometimes advertising / promotional restriction, clauses. If you give credit where credit is due you won't have any problems....
Please use are software in your software:
MIT Licensed: http://freshmeat.net/browse/188/
BSD Licensed (original): http://freshmeat.net/browse/187/
BSD Licensed (revised): http://freshmeat.net/browse/1023/
Public Domain: http://freshmeat.net/browse/197/
---
"The way it was characterized politically, you had copyright, which is what the big companies use to lock everything up; you had copyleft, which is free software's way of making sure they can't lock it up; and then Berkeley had what we called 'copycenter', which is 'take it down to the copy center and make as many copies as you want.'" --Kirk McKusick
mmmm, you are a one-horse-show. You will be coding an embedded system, under closed source. If I install it in my company, and you get run over by a bus, I'm up sh*t creek without a paddle. Thanks, but no thanks.
10 ?"Hello World" life was simple then
I just want to do my job and make a living.
Why do some software developers only see one way to make money in software? Software development has several revenue models that work quite well. Seems a little whiny and narrow-minded to think there's no way closed and open source can co-exist.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
> glibc is not LGPL, though -- it is "GPL with the libc exception" which does allow you to link an application statically against it.
What's your source on this? glibc appears to LGPL licensed.
Your submission is kinda like stepping in a biker bar wearing a gay pride t-shirt to ask if someone can fix your Miatta.
Go for it,write it,license it,see if they come.We,as you see by the majority of posts,DON'T CARE!
If you've been reading Slashdot for some time and still don't know how to make money from open source,could be you're kinda clueless anyway.
Damn,you're scared of sharing code that goes in an embedded system.Is it such a simple device a little girl could do it?
Where's the fear factor in this?Can't you just sell the machines and service the code? You could still get help from others that way than to continue in your path and perhaps miss some vital bug.Whatever,you made up your mind.
Best turn tale and run to an import shop and leave the bikers to their pursuits.
*Repent!Quit Your Job!Slack Off!The World Ends Tomorrow and You May Die!
First: You want to *gasp!* earn a living? pshaw! Your living should be done in your mother's basement! Code for free, comrade, for the good of the community! (whatever "the community" actually is)
Second: Get a lawyer. Most Slashdotters are not lawyers, and taking intellectual property advice from non-lawyers -- even though they may be reasonably self-educated on the subject -- is probably less-wise for a businessman than coughing-up the $75 for a hour-long meeting with a real practicing attorney.
Finally: Yes, with BSD you can effectively do anything you want. Take the code and close-source your copy and modifications forever if you so choose. You can even sell it as part of the world's most-popular desktop OS, like Microsoft has done...
The downside to BSD, if there is one, is that there are a lot more software ideologues (and license-set-ignorant developers who choose GPL simply because that's what they've heard is "the open source license") than anybody ever imagined, and they work on Linux rather than the BSD OSs.
Is Capitalism Good for the Poor?
Just write your program in undocumented assembly language, and you can safely release the source code. That way, 99.9 percent of the programmers out there won't know what the heck you're talking about, and it'll act as perfect obfuscation. Then, if you're *still* a bit paranoid about people reading your code, do what some professionals do: sprinkle some meaningless or irrelevant comments throughout the (otherwise comment-less) code. Paris Hilton's birthday, written in octal, is an ideal candidate for this.
Excuse me, I have some paper tape to program. Can't let anyone get my Secret Family Recipe, you know.
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
If you're serious, ask a lawyer or two about it. Most likely, if the BSD vs. Linux thing is so seamless then you're not doing any real kernel mods, you're just running code on top of a POSIX like OS. So you're free to license it as you wish, your use of 3rd party libraries is the only thing to be concerned with. If you're going to change the kernel, there are some other, very important, factors to consider also.
If you include any GPLv3 code in your project, you must also provide a way for people to update the code on your box; you cannot lock it down.
Did somebody already make the joke about potentially getting sued by SCO?
To a politician, one email equals one voter.
You don't need a reason to go closed source. Its not something that has to be justified. Do Apple, MS, IBM and Oracle seem stubborn and inflexible to you? They produce software products all over the IT spectrum! Seriously closed source is a perfectly legitimate option. Not everyone, check that, mostly everyone doesn't buy into the "proprietary software is immoral" ethos of Richard Stallman. Heck most people aren't technically competent enough to even concieve of how the production of an intangible like software could be immoral without kidnapping the programmers and holding them hostage unless they write code. I'd like to know why you think someone needs a reason to go closed source.
Mac OS X and Windows XP working side by side to fight back the night.
Perhaps if one wishes to not be taken advantage of, they should not release their work for free?
Where I come from thats called "Asking for it"
Mac OS X and Windows XP working side by side to fight back the night.
But the original question is not about using GPL code and then closing it, it's about putting closed source on Linux without contravening any licences - he trying to respect the OSS community without succumbing to their evangelism.
Understand now?
I can't believe people keep repeating this. glibc is not licensed LGPL. It is GPL but with a special exception that allows linking with closed source software. There is no problem linking with glibc or the standard C++ library and there is no requirement to distribute the source. Assuming you just use the library as is, and don't modify it or do anything else but distribute your program.
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.
To make money off free software, it mostly comes down to finding a niche that businesses find important. If you get a lot of users, a small percentage will be large businesses that like buying expensive support contracts.
"Yes."
From my understanding GPL3 is the same as GPL2 except for added provisions preventing the tivoization of the GPL. That is preventing vender imposing DRM type restrictions on what the end-user can do with his computer.
What's too much to bear about dynamically linking ?
"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"
What's viral about the GPL is it says you are free to use the code without restriction with full access to the source code. The only provisor being that you must also pass on those FREEDOMS with your source code. Else dynamically link to the GPL, else use a different license, else use the BSD license.
"This has not been tested in court"
According to this gpl-violations.org prevailed in court against D-Link regarding them not publishing the full source, as per the license. It this doesn't satisify you, what criteria would satisfy you that the GPL was 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"
'vigilante' ?. I assume you are refering to gpl-violations.org. What's right about a company getting benefit out of selling hardware incorporating GPL code and not complying with the license. Here BT is selling a Thomson router based on GPL code. Thomson failed to publish all the code and were called on it.
"No. It all depends on which libraries you use
I hadn't realized it was so complicated. I thought all you had to do was include the following 21 lines of text in your product to be covered and you don't have to include your source. Besides which if up to now the GPL was so problematical, then why is it that Tivo, Sony, Toshiba, NEC, Fujitsu, Hitachi and Mitsubishi are happy to sell product incorporating Linux.
--
was Re:Answers
Comrade could you tell me about how the GPL prevents those capitalist looters from infringing on the GPL. Certainly Comrade, first of all our clever scientists have made it viral and we have set up a team of vigilantes to intimidate them
davecb5620@gmail.com
I've had experiences where code under one license that was fine for use in my commercial projects moved to a different license in a later version i.e. LGPL to GPL making it impossible for me to use. As a result of this experience I am now working to get rid of all LGPL code from my application.
Before deciding to use a particular piece of code in your project take a look at what the overall options are, and consider the possibility that what you are using may go to a different license in the future. Have a fallback position. If two libraries are available pick the one with the more liberal license all else being equal. And as always whenever using a 3rd party library encapsulate calls to it so that changing to a different library or replacing it with your own code is not painful.
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.
Oolite: Elite-like game. For Mac, Linux and Windows
There are lots of good answers for the questions you asked. So I won't bother repeating them.
However, let me at least make a token effort to raise some questions that you didn't ask.
Why closed source? You mention that you just want to do your job and make a living? Personally, I think that is admirable. But is closed source the best way to go for this goal. I am making the assumption that if you are closing the source, this means that you believe that you will have an "asset" worth "protecting". And this probably means that you are going to write the code before you get paid.
From a business perspective, my advice is that this raises an unacceptable level of risk. There are two reasons: What if you spend all that time and effort but discover that there is no market for your product? What if you spend all that time and effort and discover that there is a market, but you have gotten the requirements wrong?
A much less risky business plan (*especially* if you are planning to sell hardware, which costs real capital to create) is to find your customers first. Sales is the #1 important thing. Get a customer with a specific, defined problem and get them to pay you to fix it. Then fix it. Rinse and repeat.
You say that you just want to do your job and get paid. If that is true, free/open source software is a considerably better approach. With "closed source" you have to speculatively invest your time (and money) building something that might not provide you a return and then hope you can sell enough to make back your investment with some profit. You do a whole bunch of work without getting paid and then you get paid without doing any work.
With F/OSS you get paid for your work directly. Your unpaid work is in sales. But this is where opening the source helps you. It is free advertising for work. Since you aren't trying to get paid for the "software product", but rather for adding features to the software your reputation is what will bring in work.
Anyway, it's something to consider. Remember that VC companies want a 20:1 ROI in proprietary software companies. That's because this is the only way they make a profit (since only 1 in 20 make money). The proprietary software business is unbelievably risky.
You can only drink 30 or 40 glasses of beer a day, no matter how rich you are.
-- Colonel Adolphus Busch
Maybe in your mind you sick pervert
The questions and line of reasoning lead me to believe that the hardware "platform" in question is probably a commodity PC and the end "appliance" probably one of the small form factor motherboards out there.
The reality is that there are many dual licensed software on Linux, in addition to the standards of GPL, BSD, and LGPL. S?He will have to check the code/library that they wish to use. They may find some libraries that allow you to pay for using them in a closed source fashion, such as Qt. In addition, we also have BSD libraries available.
4. Could I be forced to publish this code by some 3-d party? Not if you do it rightIf the person has sold boxes AND used GPL, it is possible for the owners of the GPL code or the boxes to insist on it and go to court. Of course, the court may offer the ability to swap in a different (non-gpl) library, or they may not. The real problem is spending time/money in court. There are several simple solutions to this.
- Do not use GPL or closed source without paying for it. The licenses are very clear. You have to make a conscious choice to use it, so it is trivial to avoid it. If you use a closed source code without paying for it, they can and will drag you in court just for the fun of it. Why? Because you WILL pay all court expenses. If you use GPL code, chance are the developer will allow you the chance to deal out of court.
- Release your code. Do you really believe that you, a single coder, have something so unique that a company like MS, IBM, SGI, or even several college students can not do it? Somehow I doubt it. The GPL actually helps to protect you from this.
3...It doesn't really help, but go aheadyeah, it is amazing how many folks think that obfuscating helps. Companies like MS employ it and it does NOTHING for them. Ppl still crack their systems like it is nothing. Why? because it is so easy. And yet, ppl think that it helps. Amazing that facts and reason are so easily overlooked.
I prefer the "u" in honour as it seems to be missing these days.
I think that really depends on the product and target audience. IE most software projects probably never get noticed on a big enough scale to wory about posting your code to sourceforge, etc. Esentually it would be free advertising for your product, ie the people who find it their would never have otherwise found it and been customers, but some will contribute to a paypal link, some may contribute with enhancements adding value to your paying audience. With any consumer level product, 99% of (non corprate) customers will never do anything with source code given to them, even those that would know how.
Of course if the only people who would use your product are geeks already running linux, then ya back to the hope of paypal. Also if your product really takes off after you sell say 5000 units a competitor will likely say, hey I got the source code, I can enter that market too, You still got the advantage of first entry, track record, name (you did copyright your product name right?.)
"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.
You mean companies like Google and Amazon that built their entire infrastructres on GPL code? I'm glad that I can run my highly-scalable search and shopping site using their contributions. Oh wait...
I was replying to the comment, not the poster, hence the nesting level.
Understand?
I, like most GPL users, don't evangelise as I don't see the need to. There are enough excellent people working with GPL'd software to not require encouraging selfish assholes to join in.
I do, however, have a problem understanding why people don't seem to make the link between the success of GPL'd software and the terms of said license. It is successful BECAUSE of the license.
I could also rephrase the last part of your statement....
He wants to shaft the OSS community whilst ensuring that no-one can shaft him.
2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
If you are distributing a box hence the entire OS what is so hard to bear about dynamic linking?
You're the one building the OS not the customer so make sure the dynamic libraries you need are there.
But honestly this just sounds like a lame excuse from an inexperienced coder.
Yes and Yes.
2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)Depends on what libraries and the license of those libraries (same goes for BSD). Btw; you realize that if you statically link with a library, then it is no longer 100% your own hand-written C++ code - right?
3. Can I obfuscate my code (e.g. encode it)?Yes.
4. Could I be forced to publish this code by some 3-d party?No.
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?No. But there really shouldn't be any issues if you own all the copyright for your code.
" I am planning to sell embedded-like boxes ..."
That means you are a hardware company. Yes you write code, but you sell hardware.
DOn't confuse possible business contacts by saying software/hardware. Keep it simple. You want to let them know what you do, who they are and determine what they can do for your business in 1-2 minutes, tops.
They are doing the same.
The Kruger Dunning explains most post on
Does this make sense in this context ?. If you are using window or OS X, you are already tied to the service packs these companies provide. For day to day use, it is somewhat true for linux also. I do not always tinker with all the glitches in all the applications I run. I usually wait for it to be fixed.(usually by the creator/maintainer of the source ).
Yes. They are called Judges. Someone who thinks enough in the GPL would have to get up the gumption to sue you. Go research the Virgin WebPlayer and then look into how many 'fanboys' are actually bothering to sue. As far as I am aware, the only GNU/Linux coder(s) who's using the law and the GPL is the netfilter group.
Going BSD is one less group of people who could choose to sue. But its your business, you d o what you want to.
We sell commercial (closed-source) code on Linux. However, we are rather unusual because we ship our products with full source code and allow our customers to modify the code. They cannot redistribute it, however, which is what makes the product a traditional closed-source one.
I though about going to all kinds of lengths to obfuscate the source code, and came to the conclusion that it's not worth it. If someone is determined to rip us off, we'll be ripped off. And the great advantage of shipping with source is we sometimes get patches from clueful customers! :-)
I think the ship-with-source proprietary model is a great way to go; I'd encourage you to consider it. In addition to the benefits I mentioned above, it also lets our software run on a wide variety of UN*X-like systems, some of which we don't even have in-house.
Could I be forced to publish this code by some 3-d party?
Nope, but the Flatlanders might be able to force you to publish the code...
----------------------------------- My Other Sig Is Hilarious -----------------------------------
He may have trademarked his product name, but you can't copyright such a thing, at least in the US. IANAL, but product names are trademark material. The source code and object code would be copyright material.
It looks like you want to create a business with a business model that relies on you controlling access to your source code. If you really want to do that, you shouldn't build your software on top of a Free Software infrastructure. A lot of effort has been put into Free Software licenses to ensure that the software remains free, and trying to work around that is just going to cause you headaches. Use closed-source software instead. That world understands your needs and desires much better and, as a side benefit, won't make any annoying moral judgements against you. Sure, it costs money, but so will your product.
If instead you really want to build a build a business on top of Free Software, you should look at using a business model that is compatible with Free Software. That means no secret source code, but there are lots of other options for making money. Contrary to popular belief, there are quite a few companies out there legitimately making money from Free Software. Look at what they do.
A non-exhaustive list would include making your money off of support, hired development of new features, branding and packaging, access to non-infectious licensed libraries, early access to fixes, or sales of your hardware. The last option sounds promising for you, but this is something you should look into.
1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
Yes, however you will have to provide the sources for the exact copy of Linux you use. The easiest way to do this is to simply provide a DVD along with the product the contains all of the sources.
2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
No, not unless you want to distribute your code under the GPL as well. If you're selling an embedded box where you control which and where libraries are present, what exactly is the hangup with dynamic linking? In the scenario you describe, its downright trivial.
3. Can I obfuscate my code (e.g. encode it)?
Yes, unless you're required to distribute it under the GPL. You'll find, however, that its not worth the effort. If the box you're distributing can decode it then so can any hacker in posession of the box... Assuming they want to. If they don't want to, they'll never decompile your code anyway.
4. Could I be forced to publish this code by some 3-d party?
That depends on how you approach the problem in legal proceedings. If you agree that you're bound by the GPL then you will be compelled to release the code. If you do not agree then you are never so compelled, however you could then be liable for infringement of the copyrights owned by the folks who wrote the software yours touches since your only right to use it derives from accepting the GPL.
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
Its not that simple. The core kernel and basic system libraries are in fact licensed in way that permits you to take them closed source. However, a great deal of GPL software is available to and used on BSD machines. If you pick it over the system with a fine tooth comb and carefully exclude all of the GPL software, you may no longer have a system which does what you want.
I'm not a lawyer and this is not legal advice but as a commercial software developer, I have dealt with this issue before.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Ah, another AC with a well articulated argument against something said in the Parent. It is always a pleasure to meet such tolerance and understanding in a forum that is, quite honestly, not limited to F/OSS users. /sarcasm
Have a look at soylentnews.org for a different view
You have actually presented a good ethics question.
You have picked up a copy of an operating system that was created by people with the intent of SHARING their knowledge with the rest of the world. The responsibility you accepted when you agreed to use this operating system is that if you create something with it that you will SHARE also. You believe that you may have a killer application. Your doctor has stated that you will die if you do not eat digestible food. The only way you can get digestible food is to buy it with money earned from selling your killer application to anyone willing to pay money for it.
How people are making money using open source is not buy selling code, but by selling their services to enhance their code to a company's requirements; And as any first semester business student knows, "All businesses are different." At some point during this reading you should have figured out that your time is worth money, and a stripped down version of your killer application would make an excellent advertisement about your services. And as any marketing student will tell you, advertising is not free.
Of course, you could always market your application, but I envision a larger profit percentage for you. Good luck; Good Hunting.
"Please correct me where I AM WRONG." - Isham Thompson
I have a feeling this little set of questions is a hypothetical, most of the questions are ridiculous.
You don't have to switch to FreeBSD just because you want to avoid the GPL. The various BSD and GPL libraries can be used anywhere you want to use them all you have to do is satisfy the license. Alternative? Write one/Buy one.
Also, whenever stuff comes up even remotely related to BSD licensing, there seem to be a lot of people getting into a fanboi fit trying to convert developers away from the GPL because it restricts developers rights (free software is about users not developers). I think it's because people are so fond of FreeBSD they feel they have to defend the BSD license at every turn. You can love FreeBSD and not be a rabid BSD license weasel at every turn.
I think you mean leery. But then, as my dad used to say, "I'm a little Leary of taking acid.
Please stop stalking me, bro.
I want to start (very small) software/hardware business.
I am planning to sell embedded-like boxes with an OS (Linux or BSD) and this code.
The reason that it can make a difference is that, as others have pointed out, if the hardware he is selling is commodity hardware (maybe Soekris boxes?) then he's offering little or no incentive to purchase his product for a premium when someone can buy a box, download the code, and use his work for free.
If you are thinking of starting a company and you are worried about things like this, do yourself a favor and go get a job.
> But I do know that if my sole /product/ was software, I, too, would be leary about giving away the code for free.
If I had a software house, I wouldn't base my business off the code I just downloaded from someone else's FTP and of which I do not know anything (e.g. I am not contributing to). What would happen if something breaks or there's a bug? Or if the customer asks some extra features (cause, with big companies, it's what _every_ customer does, in my own experience)?
I would be royally screwed, the customers will be pissed, demand back his money, I would fail.
IMHO, if you are a small shop, you should try to focus on providing services rather than products.
The problem with the normal product development, these days, is that you need a huge initial investment, that you're going to get back into it only in a long time span, and that you also need a huge marketing effort to convince people they need the features you offer (look at Apple, where they rebrand everything they do as completely revolutionary).
Selling services, as hookers have known for centuries, is just a way more sane business model.
nbody2002:If you can read this you may be addicted to the internet
IANAL (nor a programmer), but this is what I've heard and read many times on these same questions:
;)
1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
A.: Yes, and yes.
2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
A.: Depends on the library. Some allow it, some don't. As a rule of thumb, if the library is licensed as GPL (any version), don't do it. But to be absolutely sure, read the license anyway. Some authors make changes to these default licenses allowing or prohibiting specific things.
3. Can I obfuscate my code (e.g. encode it)?
A.: Yes, but I don't see the point. It's akin to lock mechanisms or game protection: anyone wishing to reverse engineer the binary will do so no matter how much obfuscation you put into either the source code or the compiled output itself. See for example FreeDOS, which reverse engineered Microsoft DOS, or the Wine and ReactOS projects, which are reverse engineering Windows itself! Adding these security measures has only one practical effect: to make your software slower. No actual benefits, at all.
This is also a reason for you to not worry that much with your source code being published or not. Either your software is so valuable that it'll get reverse engineered anyway, or it's almost useless outside a niche market and as a result no one will be interested in reimplementing it no matter how much you post and repost the whole source tree all over the Internet. Besides, copyright laws already provide you full protection. If you in your license don't allow neither redistribution nor derivative works, both redistribution and deriving is forbidden no matter how many people can read your source code. Microsoft itself shows lots of its code to 3rd parties, but no one among those can use if for anything. It remains the sole property of Microsoft.
4. Could I be forced to publish this code by some 3-d party?
A.: If you follow "2" carefully, no. Otherwise, if you make a dumb choice of linked library, yes.
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
A.: Doesn't make a difference, since you must follow "2" anyway. What if that specific library you're statically linking into your compiled software isn't actually under BSD, but under something else? The best thing is to always read the license.
In any and all cases (and I mean it! GPL, BSD, Windows or whatever, doesn't matter) consult a lawyer if you have any doubt. Legal counseling is expensive for a reason.
Conservatism: (n.) love of the existing evils. Liberalism: (n.) desire to substitute new evils for the existing ones.
This comes up now and then in the closed source world, especially with smaller vendors, but even with huge ones. The solution is generally that the code is put in escrow. Failure to update/repair as per contract then triggers a legal process for the customer to access the code.
Of course, this does nothing to help the individual user/customer, but can be of substantial assistance in certain circumstances.
Holmwood
...it seems very likely that your interest in Linux and/or BSD (presumably FreeBSD) is based primarily upon keeping your costs down both for development, testing, and deployment; ergo, you are potentially making a greater profit because you're using a system others have devoted enormous amounts of time and energy to in the spirit of being 'open' with source.
This doesn't mean you can't do that, but to express surprise/shock/dismay/disappointment that people are going to dislike you because you're going to make money off other people's effort (the operating system kernels, kernel modules, drivers, window managers, desktops, APIs, et cetera) is ridiculously naive.
Now, you may very well claim that you're using BSD/Linux for stability and security reasons and that would just indicate that you don't know what you're doing; therefore, I presume it is an 'out of pocket' expense decision.
Loading...
You should always ask a lawyer legal questions, but lots of companies develop closed software on open platforms. As long as you ensure that all the libraries you use are LGPL you are safe. As far as GPL3 the only thing particularly relevant is the anti-tivoisation policies. Basically you can't make custom hardware with the intent of not letting people modify the open-source software you use on it.
Starting with a Linux platform is a great way to cut costs and start a small business. But do not be a ****, if you need to make a driver for your hardware, open source it, if you use a smaller library, LGPL library help out the project. Not doing these things is what pisses most people off when make a closed Linux app. Just remember they've saved you tens of thousands of engineering hours and licensing fees, give a few back by helping to resolve bugs and improve things.
Frankly, if you can't do what you want to do, then Linux is in serious trouble.
Open source developers have created a lot of great applications, but they can't do it all. On the desktop particularly, Linux will only succeed if closed source developers feel comfortable writing software for it.
But that's the nature of Slashdot, any moron can say whatever he/she likes.
Open Source doesn't have a PR department to weed out the one bad comment in a hundred.
Who-ever it was probably hasn't contributed a line of code or even a bug report.
If you hang around, you'll learn to ignore such things.
I see it as a small price to pay for all of the other advantages of open source.
Competition Good, Monopoly Bad.
I have no idea what this guys problem is, but from my own perspective of selling embedded solutions/canned software to companies using the GPL I fail to see how he infers, you can't make a living unless he uses closed source.
:-)
I haven't found that to be the case so far, if anything, most companies I.T. departments offer me or suggest a source contract for about 6-8 more months beyond the project to train I.T. programmers and related staff to assist them in making modifications that are safe, secure.
What typically happens is giving people access to the source code opens up a lot more questions than answers, usually, and they come back for more.
Not only that, but I have seen companies with the attitude, "Oh yeah, this guys is stupid!! he is giving us the source code with our new network monitoring system!!!"
Only to find that yeah, they have the source code, but the time that is required to make use of it, doesn't come with it.
So they end up hiring me to maintain the code, add modifications, etc because management at said company finds out nobody wants to work on weekends on top of all the other responsibilities they have during the day.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
This 'guy' doesn;t actually exist in reality, he is a hypothetical invention, or in laymans terms, a troll. Anybody who actually wanted to find this information out would be able to get it much easier from one of about a million faqs on the web.
my password really is 'stinkypants'
But in all fairness, have your lawyer check the specifics. You may have noticed already some "level of agreement and understanding" among posters -- but no uniform, clear answers across all posts. If your lawyer reviews the license involved in your development, he can advise you as to whether your proposed model is compatible or not (legally).
The best answer to all those questions... start writing for Windows. Programming is so much easier when you don't need to be a lawyer to do so.
According to this poster those who chose GPL are like pot smoking idiots who just pick a license because the next door idiot did it...yet their code are better or more useful than the intelligent and thinking BSD license choosers.
If somebody provide you something with a license use..it with that license or don't use it....don't go impugning the intelligence of the licensor if you don't like the license he/she chooses. That's nasty.
You might be able to get away with it on FreeBSD, but on Linux, people will actually make a point of not using your application if it doesn't conform with whatever the FSF's stated requirements are, whether that's the GPL v2, v3, or whatever.
Write it for Windows, and if you can, figure out a way to do a fairly trivial port for FreeBSD. Ports allows for divergent licenses, as long as you clearly stipulate such.
Developers should not have anything to do with Linux unless they are willing to be entirely submissive to the will of the zealots. If you try to be resistant to them in any way, your application simply will not be used.
Whose scientific "code" do we still base much of science on hundreds of years later? People like Avogadro, Boyle, etc. who published their work? Or some alchemist who may have discovered the same things but kept it to themselves? Will MicroSoft exist in 300 years? Will kids then study in school the basis of the OS they are using owes framework to MS? I sincerely doubt it. By then MS will just be another dead corporation in a long line of them, replaced perhaps by some other alchemists who gain the favor of the king and for a time shine very brightly but contribute little or nothing to the public good codebase. My argument is that work which is made freely available WILL be incorporated in other people's work. If all you want is to MAKE MONEY go be a licensed plumber or electrician. Those guys make quite excellent money and without a lot of schooling.
Free software isn't, and will never be, a business.
The way to make money from free software (I'm aware of only one) is to sell overpriced service contracts to suckers hoping that they don't grow/hire some brains to operate your product without you. Kinda like Best Buy does, only with a bit more of a "hands on" approach.
"So, would you like to buy a service plan? There's no warranty on this free software, you know. If anything breaks, you're toast. But if you buy our service plan, you can just bring it back to the store and we'll replace it, no questions asked."
It sounds like a poor way to win friends and influence people, and a good way to not make money.
<flamebait>RMS is a dirty commie hippie.</flamebait>
>If I had a software house, I wouldn't base my business off the code I just downloaded from someone else's FTP and
/didn't/ know anything about it so much as people who /do/.
>of which I do not know anything (e.g. I am not contributing to).
I wouldn't worry so much about releasing my product to people who
There seem to be many examples of this. I don't know if these are open source examples (I always assumed they were), but how many flavors of different P2P clients are out there these days, all presumably running the same basic guts behind the scenes?
I have also assumed that all these different flavors of linux out there today are likewise derived from a common, open ancestor. I'm sure all the folks that developed these different flavors know quite a lot about it.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
Yeah, so you want to build this embedded widget to sell to my company. Yet you are a one-man show intent on keeping all the secrets of how it works to yourself. What happens when it breaks down, or I just need it modified to fit some new requirement, and YOU *LONE* *RANGER* ARE NOT AROUND? I can't see any sane businessmen buying your product.
If you want to continue on Linux, try Prelinking the libraries (see 'man prelink' and Google for more information). It resolves a lot of the performance issues with dynamically linked libraries, without actually statically linking them. Not only does this resolve the GPL issues, it also removes problems with, for example, being able to update OS libraries independently of your application.
Of course, BSD is a fine OS as well, and I've had good experiences with both platforms. Good luck!
Write good software, make it open source, then:
1) Sell service/support contracts to businesses that use it.
2) Sell conversion consultation services to help businesses convert from their old product to yours.
3) Sell code customization services, working out in your contracts whether or not the code customization in question is for that business only (they will keep the code and not distribute it in any way, and it will not become part of the source tree) or a paid modification of the core source (you own it and open source it and distribute it with the base product).
4) Publish and sell books on how to use your product. You could also sell training classes on how to use it.
5) Consult as a specialist with domain knowledge in the industry to which your product caters.
6) Profit!
If you can't do this sort of thing with your product, then it may be that the open source business model is not suitable for what you have in mind, in which case you will either have to work within a closed-source OS (so there will be no licensing conflicts), or be very careful in what your product links to (LGPL and BSD style stuff are fine, pure GPL and similar may not be so fine). Be aware, however, that selling closed-source code to an open-source crowd doesn't always go so well.
If all else fails, your product could be the demonstration of skill that lands you a job at Google.
I meant closed software on embedded 'linux' systems.
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.
An alternative strategy might be a dual license: a GPL version and and a commercial version. Of course, this model seems only a good option if your software is going to be used in other commercial products (like Trolltech's Qt is an excellent C++ library used in other commercial software). I really doubt if that would work for end-user products like a text editor...
The view from between the lines is somewhat less rosy. Your questions (2) and (3) suggest that you don't know very much about programming, and the fact that you want to keep your Source Code closed at all suggests that whatever you're doing isn't actually going to be all that special. So, be warned: some third party is most probably going to come along and blow you out of the water, offering a superior and True Open Source solution to whatever problem you are trying to solve. In fact, if and when they do just that, they can probably expect a hefty wodge of donations from Slashdot readers eager to see a closed-source product fail spectacularly.
Je fume. Tu fumes. Nous fûmes!
There are plenty of open and closed-source embeddeed OSes out there - http://en.wikipedia.org/wiki/Embedded_operating_sy stems lists some... Why are you considering Linux or BSD specifically?
Make a list of the features that you need, and find out which ones have what you want. Even in the closed source world the licensing can often be quite reasonable, especially if you don't actually require a lot of features.
If you're sure you need a full-on OS like Linux or BSD rather than a simpler one or an RTOS, then the licensing issue is best taken up with a lawyer who specialises in this kind of thing. If you can find a commercial effort which lines up with your needs at the right price then the licensing should be easy enough - that is after all what you are payig for...
I have to say this has been a very interesting thread and it does ask some questions I have been wondering about as of late as well. First I would like to say that up til this point all software that I have written to run on Linux is on a freely useable license, therefore I feel that I have contributed to the open source movement, these include various emulators, games, and development tools and libraries, all are not necessarily on the GPL but much closer to the BSD license, I have granted free rights to modify and distribute so long as it is not used for comercial use.
But at the same time I do have to earn a living and I have decided to take one of my previous open-source projects and enhance it with the purpose of selling it. The original version will remain freely available, only the new one will be closed. I know I do not run afoul of any of the licenses since the only library I use is libc, everything else in my projects are my own libraries, but at the same time over the years I have benefited from the open source model (not financially, but availability of a solid platform and development tools) and I feel that I have given much back in that I have distributed most of my software on an open-source model. Would I still get the evil eye from the OSS world under this circumstance??? What is the opinion if most of my software is open-source and 1 or 2 projects are not???
IANAL seems to rule my life, so much so i really dont often know whether to unleash something i do upon the general public because i dont know (even though everything i do is completely free and OSS):
a) who's feet i might tred on
b) if my project really is GPL'able
c) how i release it in such a way as to make it GPL'able.
Its really quite hard to comprehend. As an example, i had a project that i wrote that combined a nice firewall gui with a bunch of projects of various licenses. It had QOS, load balancing, routing and alot of other features with software provided by a tonne of other projects. I wanted to release a binary image (iso) of it, and then release the build code. This is where i got very lost. I eventually decided that i'd release the code i'd written without any of the code from the other OSS projects plus the binary iso and as part of the INSTALL for people who wanted to build the project they'd have to download the original source themselves, put them into the tree and hit make.
But i didnt cause i didnt know how right or proper it was to release any of this, and i wasnt in a position to take (or even want) money for it, which resulted in one thing - i abandoned the project. Even more frustrating, i didnt even know where i could turn to find out how to do it aside from "ask slashdot".
The only zealot around here is you.
You seem to wrongly believe that open source software is about defeating Microsoft. As a GNU/Linux user the only time I ever have to think about Microsoft or their Windows product is when Microsoft threatens to sue Linux users or when a Windows user starts marking me as some kind of windows hater because I don't use the one true OS.
You are the one not seeing the clear picture.
He wants to lock down the code. How is that promoting a GNU/GPL operating system?
This guy would be better off with BSD code and I wave him good luck. The less thieves in the GNU/GPL community the better.
You might be Timothy Leary, but in this case I suspect you might be "leery," smart slashdot poster.
Yes, Google have never contributed anything back to the open source community.
Those evil yahoo people have also never contributed too!
oh wait!
a) No need for code obfuscation
b) You can open source it without any worries about competition or parasitism
> 1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
Yes you can. It does not look like linux will move to the GPL3, so you won't have to worry about its Tivoisation clause.
> 2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
You can, if it is a LGPLed (not GPL) library. Read the license and make sure it allows statically linking.
> 3. Can I obfuscate my code (e.g. encode it)?
YES. ABSOLUTELY.
> 4. Could I be forced to publish this code by some 3-d party?
Only if your code is based off of GPLed code. If your code is your own and does not borrow from GPLed code, you are fine. You would be able to package this code on an appliance running linux. That would require you to provide the source code to the GPLed code on the appliance, but not your proprietary code.
This is what Tivo does.
> 5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
You may be correct in that.
+1 Insightful. Parent post mirrors my thoughts exactly.
But embedded, you're using one Linux kernel (possibly customized) and tightly interacting with your app. At the very least, you will have to distribute source for that kernel. You will also have users complaining about your source. Many fairly deep pocketed embedded-linux mfrs have decided to publish source (even TiVo) rather than fight a battle they are likely to lose in court.
I have worked most of my life in the private sector in big multinational corporations. I understand who drives the movement and made aware my employers or clients of these issues when they arise. Many more companies that you can possibly imagine, making gazillions of money, are perfectly comfortable with the concepts spoused by Richard Stallman (hint: they are not in the business of writing software).
I am in support of FOSS and resent any prospective freeloaders that want to use Free software and give nothing in return. They should use closed source (and see how their business never taking off).
You stereotype people at your own peril.
IANAL but write like a drunk one.
It is about respecting other peoples wishes to which you received the gift of code from them.
The GPL forces the author's original intentions on to those that wish to use it. So if the author wanted their project and code to be GPL then you should respect those wishes and not complain.
1. Yes, you can do this with a Linux distribution. Note that you are technically selling a Linux distribution (with hardware), so you'd have to either include the distribution sources, or offer them online, or include an offer to supply any source for any GPL'ed binary in your distribution. And Linux probably won't go GPLv3 anytime soon.
2. Legally using a statically (or shared!) linked library with your own code creates a 'combined work'. If you use GPL'ed libraries (they exist), you have to supply the source code to the whole combined work. The LGPL only states that you have to supply the source code of the library you used, not the whole combined work. The LGPL doesn't differ between statically or shared linking, which is a common misconception. See http://www.gnu.org/licenses/lgpl.html for details.
3. Sure you can obfuscate your code. Write it in Perl, and you get the obfuscation for free.
4. No, you won't be forced to publish your code by some 3-d party. Not unless you use a GPL'ed library or code in your combined work, or make changes to GPL'ed code.
5. It depends on what you see as a problem. It is true that you would be able to distribute your hard+software without having to supply any source code if you only use BSD licensed binaries and libraries, but as long as you use BSD/LGPL-licensed libraries you wouldn't have to supply the source code of your own work.
And don't be put-off by the Linux fanboys. Kudos to the people who are trying to make the free software model work for their business and play by the rules.
This sig is intentionally left blank
The licensing for using GNU/Linux as your core OS isn't too bad, really. If you distribute it, you'll have to make the GNU/Linux source code available to your customers. You don't have to distribute it to them, you just have to let them know they can get it from you at any point. If you make any modifications to the GNU/Linux source code, you must make the source code to those modifications available to your customers, as well.
The source code to your application is yours. You do *not* have to distribute it, nor make it available. That's how Oracle can sell its RDBMS system for Linux. That's how other embedded companies can sell their applications.
As with any operating system, you'll want to check the requirements for the libraries on which your application depends. For LGPL libraries (which should be most anything), you can dynamically link against them. You'll only have to release the source code to the libraries themselves, so if you make a change to the library, you must release the code to that change. You don't have to release the code to your application.
I'm not sure why you consider dynamic linking onerous. It's dead-bloody simple, really, and though it adds a little to the application start-up time, there's no practical difference between that and static linking.
There's no reason not to use GNU/Linux, unless you have a preference for *BSD or MS-Windows CE/Embedded/Flavor-of-the-month.
If you are uncomfortable reviewing the licensing yourself, I suggest hiring a consultant to review them for you. I suggest this no matter which OS you choose, as licensing is a quagmire on all fronts.
I am available, for a modest fee, but I suggest you trust whomever you hire.
Microsoft is to software what Budweiser is to beer.
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.
This is a fallacy. There's lots of closed source for Linux.
The huge arguments are about people usurping Linux itself, about closing up Linux. It's not about applications, it's about the OS.
Closed source applications are no problem whatsoever.
Microsoft is to software what Budweiser is to beer.
I thought the point of the GPL was the whole Copyleft idea. Meaning, anything you release with that license must follow the rules of the license(Open Source...).
Way to push the FSF FUD some more. There is no way for anyone to take free code and "hijack it and close it". The GPL is about controlling others and pushing agendas, not protecting anyone or anything. Notice how X, apache, sendmail, BSD, BIND, etc, etc have never had any problems with anyone "hijacking and closing" them? How could they, its not possible. The code is there, if someone adds something to make a new version and doesn't release the code for their changes, the original is still there, and still open. Nothing has been lost.
It's not that simple.
... until problems arise with them.
I've been evaluating newspaper accounts and bookings systems recently. A key requirement is that I have some means of carrying on if the providing company goes out of business or is bought out. This means that I want something like a 3rd party support agent, code & documentation escrow, or some other form of safety net. I (well, the company I work for) has been burned before.
Companies will um and ah about such issues, then cry "look, a turkey!" and evaporate from the room. They reassure you about their continued profitability - and when you point to your past dealings, and to outfits like PeopleSoft (hardly unprofitable), they tend to get nervous.
If that were the only issue, the company I work for might bend. It's not. Most of this software is designed so that customers cannot effectively support and maintain it, it usually builds on top of various third party tools the developers have little control over (anybody who says "FileMaker can never go away" didn't see Visual FoxPro), and it's all arranged to make you dependent on them for ongoing support and licensing. You can't just buy the rights to use the damn thing and be able to go away if the quadruple the price for the next version.
We're now considering building in-house. Carefully. The result won't be as functional or have the same history of robustness, but it will be documented, designed to be maintained by any reasonably skilled software professional, and it'll be ours. It'll also, without any doubt, be much better than what we have (but so would pen & paper at this point). Thankfully there's practically no accounting involved and what there is just involves low level data to be fed into the main accounting system, so compliance won't be too much of a problem.
My point is that these are not just technical concerns. There are real business problems involved in these issues, and buying "turn-key solutions" may not always be the best long term decision for business infrastructure that cannot easily be swapped out. People think very hard about dependence on suppliers, individual employees, etc, but so rarely about dependence on critical pieces of software technology
what stops someone else from adopting the same business model? Nothing at all, they'd have to write their own code, but nothing will prevent people from following someone's else business model. You can't obfuscate *that*, unless you, hum, don't sell your product and keep it safely locked in your basement. I'd hardly call it a viable business model then, but who knows.
Where is that guy who'd die defending what I had to say when I need him?
If none of your code is running in kernel space, then you're home free. As long as you write all of your code, or use LGPL, BSD or similarly licensed libraries. Don't be afraid.
Salut,
Jacques
1. Yep - if you follow the GPL rules. 2. Nope. The resultant binary is a "derivitave work" of the libs and is a copyright violation. 3. Yep - do as you wish with your own code. 4. Maybe - if sued for infringement you may have to settle by publishing or face major legal costs, injunctions, and all kinds of other nasties. GPLViolations.org guys are pretty vigilant about their enforcement efforts. I know if I found any GPL code I wrote in your binary I would seriously consider a suit. If I license code under GPL, it's for a reason and I absolutely demand that the GPL rules be followed. 5. Yep - You can pretty much do anything you want with BSD code. GPL is specifically designed to prevent taking any of it propritary in any way, shape, or form. BSD doesn't care. I'd say you really, really, really should use BSD to meet your goals.
From all the other comments it appears that you should have no problem given your current expected deployment.
However, have you considered future possibilities where you may have to tinker with L/GPL code. For example if you discover a bug in a GPL/LGPL library or in the kernel and need to fix it for your purposes. Do you think releasing the fix would pose a problem for you?
If the answer is that you think releasing the fix is against your best interest, you should go the BSD route. Otherwise, L/GPL is probably fine.
I wish more people would understand software as a service and not a product. What you explain here is exactly that, a service. If a particular company or user wants to use your software, they can do that. If they need any type of support, they can pay at that point (and this isn't much different then commercial closed-source software, which very often includes no free support.) But if they need features, they can also pay for that.
I guess it almost becomes something like outsourcing your development work. You can pick a product you like, and use it. You can then contract out feature improvements and support to the company that wrote it in the first place. Being open source only helps the product become even better for anyone that uses it.
It's a different way of looking at software, and I believe it's inevitably the way things are headed. The problem is that there's just too many programmers that think the old fashioned way - that software is only something to sell on a shelf, and if you don't, you don't get paid.
- It's not the Macs I hate. It's Digg users. -
If you're really writing it all yourself, none of these issues matter. If you're really writing standard C/C++ with only POSIX library functions, you're not linking against the kernel (so the kernel license doesn't matter), and you're not linking against any userspace libraries except for libgcc/libg++ (permissive license) and glibc (generally permitted). Dynamic linking is only actually a pain when either you're writing the library, or the library provider's versioning is lacking, or you've got a million libraries, or you're shipping the software not aggregated with the library you want to use.
Of course, you'll want to use other people's code for some things. You'll almost certainly want to start your program using some shell scripts, but those don't have a non-source form and are generally not worth obfuscating. If you want to use more libraries, you'll have to look at their licenses (many important Linux libraries are BSD-licensed anyway, though). If you're writing kernel code, you probably want to open-source this part and do as little of the interesting stuff there as possible (for technical reasons: kernel bugs cause a lot more damage than userspace bugs; for maintence reasons: kernel developers will maintain cleanly-written open-source code for you across trivial API changes; and for legal reasons: it's a pain to avoid making your module a derivative work of the kernel).
The ideal thing is to build a little computer running Linux with nothing in it that you wrote, and then use it to run a program that's entirely yours, and sell the whole thing to people.
"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."
It can also be used to free up resources. You only load what you need, as you need, then release it. It can also make startup times quicker, again, by only loading what you need at start. Use "RTLD_LAZY" - Runtime-load-lazy, so that you don't try to load everything at startup.
The real reason - the poster thinks its "too hard" to #include <dlfcn.h>, and insert one lousy call to dlopen().
More info here (with examples).
Lame, lame, lame ... tsk tsk tsk. Where's the "-1 I wish a dingo ate this article" mod?
Kevin Smith on Prince
This was my take on it too...
Although I would argue with the "takes up less RAM" point as dynamic linking allows only one copy of the library to be loaded with every process sharing it, while static linking forces multiple copies of the library to be loaded...
It's a six of one issue that depends on particular circumstances and can go either way depending on what you're doing.
Z.
-- Under/Overrated is meta-moderation, and therefore is Redundant.
This is really the key issue, because if you do not include anyone else's code with the distribution of your product, then nobody -- not the Linux copyright holders, not the C library copyright holders, not FSF lawyers -- has any say in what you're allowed or not allowed to do, because you don't need to license anything.
If you dynamically link, then all your "Can I.." questions are answered with "Yes." (Some people are going to tell you otherwise, but their arguments will be based upon the argument that the licenses themselves try to define what a derived work is, thereby causing licensing to be necessary. It's a circular-logic bug on their part; they forget that you first determine if you're making a derived work, and if the answer is Yes, then you read the license. No wording in the license has any bearing on the copyright question.)
Ah, but you want to statically link. Then there's your problem. If you want to include someone else's code with your product, then you're going to have to get their permission (unless you want to violate copyright). If you're talking about the C libraries, then it's probably LGPL, so read that one carefully.
Bascially, yes. If you decide to statically link someone else's BSD-licensed code and distribute it with your own stuff, a lot of "Can I.." questions get answered as "yessily" as though you weren't licensing anything at all.As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
on Unix systems, which is a lack of standardization between platforms. The only way to reliably distribute your code is in source form. So yes, you can distribute closed source, but your maintenance costs will be very high, since you'll have to recompile the code for a bazillion different platforms. Eventually, you'll get tired of that and publish the source.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
2. Can I statically link the code with Linux libraries? Only if it's LGPL, otherwise no if you want to stay closed. Unless it's BSD then see #5.
3. Can I obfuscate my code (e.g. encode it)? Dont see a purpose for this but it wont change anything.
4. Could I be forced to publish this code by some 3-d party? Only if you're linking to GPL code. If it's LGPL or BSD you're fine
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems? From my understanding yes. BSD is more or less public domain + copyright notice.
Obligatory Note: IANAL, so take it with a grain of salt, but I've been a dev for 11 years dealing mostly with FOSS
Here's what you need to Buy a commercial compiler or buy a commercial license for GNU C. Write all your own libraries or buy
commercial llicense for the code you use. Create static binaries. Or take the open source route. Release your source
and earn money supporting it! Obusifcate the install process so either technical people can install it like me can, and
business types can't. Release a vm based demo of the application that will sell your app. Trust me, if the application is worth it
you will get business.
Don't bother with static linking and obfuscation. Make sure that any libraries you're using other than the standard GCC C libraries, (GCC has a special GPL exception for this case, go read it if in doubt) are not GPL (some libraries have BSD-type licenses with little to no restriction on their reuse). If you're using a stock linux distribution out of the box, you don't have to worry about it really; technically someone can request all the source code to that linux distribution, so keep the copies used in each version of your product in a safe place (like with your backup tapes) on CDs or something (including source code packages) just in case. If you modify any of the GPL programs from that distribution, note you have to provide the code for your modified (derived) versions if someone asks for it, but that doesn't affect licensing of your product.
If still in doubt, just email the FSF with specific and clear but detailed questions.
Reed
Yes, software is both service and product. However, the product side of it makes a lot more money usually.
If all you sell is service support for a product you created, you are vulnerable to other companies who can provide the service more cheaply. Ie, a large company takes your code, bundles it with their existing open source packages, and supplies discount service rates that you can't compete with.
There is also a very large number of products where you just can't sell service profitably.
Especially if it's pure software as opposed to a system. The way that many large open source software products succeed is by having a huge user base willing to support it. If you've got a market of 1000 people, and the software can be copied, chances are 999 of them will never pay for service, just live with the bugs, fix it themselves, and just wait patiently for new features. This is fine for a hobbyist, but you can't make a living that way. To make a living with an innovative product that has a small market, you have to sell the product up front instead of hoping for back end service sales.
And after all that, you have to hope some company doesn't steal it, since most developers don't have the ability to audit and investigate all competitors, much less take legal action against them (especially if the thief is in a foreign country).
You talk as though such a company cares about customers? Many companies will gladly sell stolen products, then ignore any complaints from customers and keep support to a minimum. If they're in a foreign country that doesn't care about intellectual property very much, there isn't anything the original author can do except complain and regret that he hadn't locked up the code more tightly.
Even "reputable" companies (names withheld) have made a business model out of buying small companies, taking their just finished products and slapping their own label on it, laying off all but 1 or 2 developers, and making those developers provide support. The company makes a lot of money of off initial sales, gets a few really disgruntled customers, but smooths it all over by paying off industry analysts to give them a good rating. In other words, they buy lemons, squeeze them dry, sell the lemonade, then look for other lemons to buy.
Including the object files with the release does not mean, at all, that you'll end up having to link at installation time or anything remotely similar. It only means that you need to include the object files of your non-open code so that, if the user so chooses, he can link with them a modified version of the open dependencies.
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.)
which libraries? how can you possibly imagine anyone will give you a straight answer when there are thousands of libraries? Are you even talking about the Kernel or confusing it with the greater GNU+Linux system?
3. Can I obfuscate my code (e.g. encode it)?
You can even not publish it at all, why wouldn't you be able to obfuscate?
4. Could I be forced to publish this code by some 3-d party?
If you include software someone else wrote, you have to respect the conditions. If the conditions demand that you use the same license, you have two choices:
a) you comply with the license
b) you don't include the software someone else wrote
If you don't include any code you yourself didn't write, you are never forced to publish.
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
Neither GNU/Linux boxes.
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.
Minor correction: Linksys (prior to the Cisco purchase) did not appear to have any intention of leaving the software open, to allow the world to improve it or for any other purpose. It wasn't until someone discovered they were using Linux that they were forced to open up some or all of their code.
A useful lesson was hopefully learned that at least for a hardware-based business model like that, opening up the code is far more beneficial than detrimental.
We are selling closed-source software for Linux, just like you want to. So here are the ACTUAL answers:
1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
Yes there is no difference. The set of things that can be closed source is not reduced in GPL3 (all changes are to things that would require you to distribute the source code anyway).
2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
You do not want to statically link libc++ or any other standard library. DO NOT DO IT, some things in fact will not work if statically linked because of the dependencies on doing dlload of other parts. If you are really worried, you should distribute your program as an "app dir" that contains your copies of the shared libraries, and use the rpath linker switch so that the program looks in it's own directory for the libraries. The end user is free to remove your copies in order to expose and use the ones installed on their machine.
Personally I have seen zero trouble on modern machines with libc, etc. We have had trouble with libjpeg, freetype, and libtcl, and include those.
For non-standard libraries: well if it *really* is LGPL then you cannot statically link. Instead include it into the app dir as above. However I think you will find that *ALL* non-standard libraries you want to use are either not GPL/LGPL, or have an "exception" added to the license to allow static linking. This is because the authors of those libraries realize that nobody would use them without such an exception.
3. Can I obfuscate my code (e.g. encode it)?
You are not going to be required to distribute source code, so it does not matter. If in fact you had to distribute your source code, such obfuscation is not in compliance with the GPL, because that code is not "in the standard form for working on it".
4. Could I be forced to publish this code by some 3-d party?
NO. Even if you directly violated the GPL, you are only guilty of copyright violation. Copyright violation offenses can get you monetary fines and cease & desist letters. They CANNOT force you to do anything else, in particular they cannot force you to relase any information. An obvioius reason would be if your code is in fact a copyright violation of somebody else, if the GPL "forced" you to release your code, then you could violate anybody's copyright legally by just combining the copyrighted work with GPL.
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
The only thing that is at all a problem is the LGPL libraries, and those exist on BSD, so there will be no difference there.
> Could I be forced to publish this code by some 3-d party?
I really doubt it, no. In the unlikely event that you _did_ get invited to a real, 3-dimensional party, the chances of the conversation rolling round to your oh-so-clever software are pretty slim.
You've just made a great case for the BSD license.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
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"
I have no idea what kind of software this guy intends to write; however, "dynamic linking" is dangerous ground in GNU/Linux. Here's an example:
When I was in junior college, I helped administrate a small computer lab in the math department where we used a proprietary, binary-only piece of software called Matlab on GNU/Linux. Octave+gnuplot was not good enough for our purposes. One semester, we upgraded to the newest Redhat distro and Matlab suddenly started crashing on startup. I don't remember exactly what the problem was, but it had something to do with NTPL and the errno symbol in glibc. We were able to work around it with an environment variable, but later on the operating environment changed so much that we weren't able to run that version of Matlab any more without strange crashes.
Anyway, the exact problem isn't important. What's important was the attitude of the glibc developers at the time: if our change to glibc broke your application, that's a bug in your application. You need to fix it because we're not going to provide backwards compatibility.
After a response like that, it should be clear to any developer of closed-source applications on GNU/Linux that they need to statically link everything they can if they want their product to stand the test of time.
*nod* I admit I was thinking in terms of only one application being loaded (possibly even replacing init), no daemons, and all threads being owned by either the kernel or the single application. So I probably should have specified that static takes up less RAM if and only if only one copy of the library needs to be loaded.
But as you point out, it all depends on exactly what is going on.
You're asking the wrong questions, and I would argue you're asking the wrong questions because you haven't thought about your product from the point of view of the consumer. Imagine there are two products available which do something you really want to do. Both of them come from little teenie companies with no track record, which could go bust tomorrow.
Which one would you buy? Seriously?
Face it, if your product is any good, then any reasonable tech company could do a black box reverse engineer of it whether they had the code or not. Keeping your code proprietary scarcely bothers your competitors one bit, but it makes your product much less valuable to your customers. Do this, and watch the market walk away from you.
I'm old enough to remember when discussions on Slashdot were well informed.
If you really don't link against any third party libraries and only depnd on the kernel, no problem at all, you can just go ahead and do it. The license coming with Linux clearly states that this is OK. And my interpretation is, that they couldn't have forbidden you from doing this, even if they wanted to.
Since Linux is explictly licensed under GPL version 2 only, nothing is likely to change. After all changing Linux from GPL version 2 to GPL version 3 would require every author's permission. (Or the code would have to be identified and replaced).
Even if the kernel or libraries you depend on are switching to GPL version 3, you could still be using the old GPL version 2 versions to build your software. If it happens to still work with later versions (and if you depend only on the kernel it is very likely to work), that is none of your fault. It is the users who decide to run your software together with some GPL version 3 code. And it is highly unlikely that the user would be doing anything illegal by doing so, since forbidding that would go completely against the spirit of the GPL.
Strictly speaking there is nothing called Linux libraries. What you have in mind is probably glibc, which is licensed under LGPL. This license allows static linking provided that you allow the end user to relink it against a different version of the library. So you'd have to include not only the linked executable, but also the
If you are talking about glibc, keep in mind that it is not easy to link statically. If you try, you are very likely to end up with only parts of glibc linked statically and other parts still linked dynamically. This is going to break if the user is using a different version of glibc, because internal interfaces may have changed.
Relying on dynamic linking might be a much easier way to go. If you are unsure avoid linking against GPL libraries. People disagree on whether a closed source program is allowed to dynamically link against a GPL library (I believe it is legal, but IANAL). Statically linking a GPL library into a closed source program is clearly a copyright violation.
What would the point be in that if you only intend to publish the compiled code?
Probably not. If you are violating a third party's copyright, they can sue you. But only the author whose copyright you violated can sue you. In such a case you should obviously be stopped from distributing violating code, and may have to pay some compensation. But as long as you are able to pay a reasonable compensation, I don't see how you could be forced to give them code as well.
I'd say you are unlikely to run into problems in that case as well. It all comes down to which libraries you link against. If you use the same libraries on both platforms, you will have the same potential problems.
Do you care about the security of your wireless mouse?
Otherwise, what's all that crud about static linking? the license change between v2 and v3? The "not a problem on BSD"? If it's NOT about taking the code that is GPL'd, these questions don't make sense.
IMO, the anonymous was trolling, trying to "prove" BSD is far better than GPL or that the changes in GPL3 are going to cripple acceptance of GPL code. Only under those conditions do the odd questions without any context make any form of sense.
Unless you can explicate.
True, obfuscating or encrypting binaries has been around for a while. When he asked about obfuscating his code, though, I thought he means "source code." Still, you're very right with that correction. Thanks.
A polar bear is a cartesian bear after a coordinate transform.
Will your program eventually be replaced by a FOSS alternative?
Resounding yes. No reason to play the same Quixotic game the big corporations are all falling for. There are plenty of ways to make money with FOSS anyway.
I hold very few opinions. I hold information based on observation and fact. If you wish to disagree, please use facts.
Something to consider about opening your source up...
Some open-source developers make money by working on their open source code. They contract for companies that use their code, developing features for hire. (I think this is how some Apache developers make their living, but I'm not sure.)
If your "box" is commodity hardware and your software is easily reproducable, you might find that an open approach to your proprietary software is worth considering.
No, I will not work for your startup
1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
Yes
2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
That's what you get for using Windows.
3. Can I obfuscate my code (e.g. encode it)?
Not if you're GPL, but you don't show any signs of wanting to.
4. Could I be forced to publish this code by some 3-d party?
No. At most you could be forced to stop distribution and pay copyright damages. And that's only if you violate the GPL or similar license. (I.e., write your own code and you're safe.)
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
What problems?
a) None of the questions that you have raised appear to me to be a problem.
b) The base of the OS is almost irrelevant to every question that you have posed.
I think we've pushed this "anyone can grow up to be president" thing too far.
Add to that duel licensed libraries. Last I heard Trolltech was still in business.
The GPL does not mean you are giving away your source code, it means you are charging the right to see changes in return for your code. So....
Service: I charge one person for my code, and frankly release it under BSD if you are thinking Give it Away, GPL if you want to see improvements back.
Hardware: I'm not charging for my code, but I very much want to see improvements back... go GPL. (iRex iLiad, asked the community for calibration code, most of their own under GPL).
Duel License: I either want money from people not willing to publish their changes or changes from people not wanting to give me money.
And there is probably some other method of making money while still publishing code under the GPL that I haven't listed. The trick is to remember that GPL code is not code given away, its code sold for changes in return, a barter. Saying that GPLing code is giving it away kinda misses the whole point of the GPL.
Back to the poster. The GPL isn't as bad as it seems to cash development. Like I said, you are not giving your code away, you are asking for something different back. Be very clear over who will give you money and what they want.
"He wants to shaft the OSS community whilst ensuring that no-one can shaft him."
...understand now?
No. He. Doesn't.
Unless you think that ONLY open source applications can be allowed to run on Linux, and I don't think you're THAT stupid.
RTFA, PROPERLY, then maybe you will...
So, yes, if you distribute a linux kernel that you downloaded from "xyzzyplugh.com" you can direct people to "xyzzyplugh.com" for sources. But if "xyzzyplugh.com" goes out of business, you still need to be able to provide the sources.
The same is true if you use a BSD kernel, but include the GPL application "spork" embedded in the device. You need to be able to provide the sources to "spork" regardless of where you obtained the "spork" binary and regardless of whether the "spork" sources are available elsewhere.
No. If you statically link the Linux libraries, or any GPL licensed library, then you are obligated to license your application under the GPL. If you statically link a LGPL licensed binary, your application can remain closed source. However you must make source for the LGPL licensed library available, again for at least 3 years longer than you distribute the application. Source or object code? In either case the answer is "of course" for all licenses. But if you are under GPL or LGPL, you need to make the means to decrypt it available to anyone who wants it. No, but you could be required to cease distribution and potentially be penalized in either civil or criminal court for any copyright violations you commit. This could apply regardless of the licence of the OS kernel you use. Be sure to understand the license of any software or libraries that you distribute.Support SETI@home
But I do know that if my sole /product/ was software, I, too, would be leary about giving away the code for free.
/I/ wouldn't invest in a new product where I couldn't make any money selling the actual product but only support for it.
I would be leery about ANY business where the sole product was software, because ultimately any company starting up today whose sole purpose was to develop and sell a software application as a product is doomed to failure--it will either be swallowed up whole by another company (MSFT) or will die in obscurity. Even in the entertainment software industry, probably the last great hope for closed-source development, the barrier to entry is pretty damn high, and the biggest startup successes lately have been in the "casual gaming" category, where the business model is more around the game as "multimedia content" and revenue is made by advertising and employing an almost "network television" type of model.
In your Linksys example, there is a hardware component that is not easy to replicate - there is a barrier to duplication.
An entry-level router is NOT that hard to replicate. A user inclined to tinker might just use an old PC off ebay as a router--all it takes is a compact Linux or BSD distro and some spare network cards and some time. Furthermore, there are many players out there with competitive products that have non-Free embedded software and it hasn't proven to be of particular advantage to them to be more proprietary than Linksys--in fact it is to their disadvantage as tinkerers opt to go for the more open solution automatically.
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.
Well, that might happen with a BSD-style license, though at least the world will know YOU did it because of the attribution requirements of the BSD license (that is how we know that MSFT couldn't be bothered to write their own TCP/IP stack for NT so they just lifted a BSD-licensed one). GPL, however, does its best to ensure a wide-open, level playing field. Yes, a competitor could undercut you by giving away a derivative product for free, but he has to play by the rules and let everyone see HIS code too, or you can quite rightly slap him with a copyright-infringement lawsuit. So, if that is what happens, jsut take this derivative product back, improve it even more and one-up him.
Well, *I* wouldn't invest in any venture that was focused on selling software as a product and treated service and support as afterthoughts.
As I said, if your business model relies on selling a copy of software like it was a widget you will be doomed to failure, so you'd better adjust your business model. In return for revenue you must add value. From an end-user perspective, there is ZERO value in a software license--it doesn't make their lives easier or make their business more productive or efficient. Generally licensing is one big pile of bullsh!t for a user--he has to punch in product keys here, activate software there, insert dongle god-knows-where to remove some deliberately-engineered artificial constraints on what he can do with his computer. GPL keeps the bull to a minimum for the end user--if you redistribute you must make source available on request which is no burden at all to end users.
That said, I think it is very hard to justify more than a few dollars it takes to produce and ship a shiny plastic disc and a printed manual in a spiffy box UNLESS you have some REAL value to add in the form of support, consultation, customisation, hardware, etc.
I guess I just still don't understand the free software movement as a business.
the Free software movement ISN'T a business--it is a software development philosophy, and it is clear you don't have a full grasp of it. Obviously if you are a software developme
I had to implement a security auditing program for a government agency (don't ask which one: NDA) that would probe their whole network from a set of strategically placed boxes. Being familiar with both FreeBSD and Gentoo, I couldn't care less which platform those boxes would run on. The program itself was a somewhat convoluted big program in C++ that ran as a process and the dependencies on libraries (except libc or glibc and, of course, STL) were near zero.
The interesting bits here were:
Programming this had been easy as pie, of course, but the licensing discussions went on and on and on. In a nutshell, their lawyers were first afraid that releasing the code under GPL would force them to disclose the source (a big no-no), so they insisted on a custom license first. This wouldn't have solved their problem, if the code were accidentally GPLed through some careless linking etc... After some thinking, they finally agreed on a BSD-license for the code with the extra provisions to be extra-careful to avoid any external GPL and LGPL code dependencies.
Then there was the problem of the platform itself. Specifically FreeBSD or Gentoo? Here again, their lawyers were totally nervous that this program would, by dynamically linking to glibc, get "virally license-infected" (their quote) so that it would magically become at least LGPLed, or at worst GPLed too. The assumed (wrongly) that they were under the obligation to automatically release the source code if it were GPL; while in reality, they were not planning to distribute the program at all! Without distribution, there were not under any obligation to release the source code to the public either! They had no qualms about BSD-licensed libc on FreeBSD though.
Now, all this is pretty silly, and showed a big confusion about the scope of the GPL and LGPL; even among lawyers who should've know better. This special application was never intended to be released to the outside world; so licensing it under GPL wouldn't have been a real problem anyway (no distribution == no accompanying source code).
To wrap up: what should you do? Since you're planning to sell (distribute) the software, you should definitively consult a good lawyer before going the LGPL/GPL route. You can't distribute closed-source software that is [L]GPLed (be it intentionally, or unintentially). The BSD route is less risky, but beware: there are some GPL and LGPL bits in BSD systems as well!, so you want to be careful what you link against and what you include in your code.
But better yet: why won't you give back to the community? Is there any special reason for not disclosing your source code? Esp. under Linux and the BSDs, binary-only programs are a nightmare to maintain! Every new release of some dependent libraries, every ABI change across major release versions could break your binary app; and you'll have a lot of angry customers to care about, who would scream at you for newly compiled versions. You really want to save yourself all this hassle and sell them the source code directly. That's the only really sensible and reasonable thing to do.
cpghost at Cordula's Web.
Sounds like what you really want to be using is Windows Mobile. No problems there with having to release your source code. No problem with worrying about which licenses you may be infringing upon. The only thing you have to do is pay the license fee for each device shipped. (Unless of course, the main reason you're trying to leverage OSS is that you want something for nothing..)
How is this informative? This is a classic example of a "NO YOUR WRONG Listen to me... by the way you are right" post. They seem to be the current rage on /.
The writer states "LGPL does not allow you to statically link the code" which is incorrect.. They personally say so "This cannot be done with a statically linked executable (unless you're also distributing linkable object files)."
Why are people so eager to state "ooo ooo you're wrong" when they don't even go on to say that the person was indeed wrong. Do you really think that by talking long enough before admitting someone else was right that people think you are intelligent and correct (although sadly the +4 says otherwise)
This is what julesh SHOULD have said:
"While it is correct that you can statically link your code, you can only do so if you provide the statically linked object files. This allows others to relink their code and thereby satisfy the requirements of the LGPL"
Its shorter, sweeter, and that would actually have been informative. When the first thing you utter is "you can't do this" is contradicted by your post wherein you admit you can, then you are not informative. I have mod points but would rather point this out than modding and posting AC.
of course this is basically what someone replied with, which magically was also +4 informative.. How its informative w/o providing any new information other than rephrasing a previous post is beyond me. It's a very basic premise of commenting and english writing, your main point should be made pretty much first and immediately, and the rest of your text should come to support it. yes there is a large variance with forums, but its a waste of our time if your post opens with "this is proof that x=1" and then you spend some number of lines on the (flawed proof) before finally saying and indeed x=1 unless you noticed that it doesn't because x=2. Save us some time, save yourself sometime, and figure out what your point is and make that first.
"Jazz isn't dead, it just smells funny" ~Frank Zappa
EdelFactor
I gather from your concerns you are not producing said boxes. You buy them and would like to write a smallish program and profit.
Before you completely dismiss the possibility of GPL'd software, You should take some time to bring your understanding of the license up to speed. First off, there is no incompatability between GPL'd Software and profit motivated software developers. to quote the fsf:
Does the GPL allow me to sell copies of the program for money?
Yes, the GPL allows everyone to do this. The right to sell copies is part of the definition of free software. Except in one special situation, there is no limit on what price you can charge. (The one exception is the required written offer to provide source code that must accompany binary-only release.)
If your boxes contain GPL code then you must still provide the GPL'd portions source for download or a written offer to supply the code. So your situation becomes, do I allow people to download everything they need to make the box work except "my program". (If you are selling it to them, isn't it really their program?)
What drawbacks do you see to opening your code?
Competition?
You always face competition. If you fancy yourself so clever that it would be impossible for someone else to duplicate your effort, then you are in for a hell of a disappointment. Just ask the fine folks at MS (Office), or the fine folks at Sun (java), or the fine folks at AT&T (Unix).
What are the advantages of opening your code?
The entire GPL'd codebase to tinker with. Every GPL'd library/toolkit/OS. To be tweaked and twisted to serve your specific needs. Don't discount the value of "the community" testers, coders, hosting, the list goes on and on.
Worse case scenario is a competitor uses your code in a similar if not identical product. They are legally obligated to not change the copyright notices that contain your name. The community will bury a violator. Now there are 2 products shipping your code. If the company is large enough they are more likely to approach you as the maintainer of the software than to just take your code. Additional income opportunities come around this way all the time. Check the newhire list at Microsoft and IBM
Finally, the idea of immortality does not often come up in software development but the truth is: If your application is popular/usefull it lives on even well after you've lost interest. BusyBox, Sendmail, etc..., etc.. , could go on all day. No Bruce does not recieve a dime for the millions of users of busybox, (Common embedded application found in everything from mp3players to routers to Full linux pcs) but at times in his life he has recieved considerable sums of money to tailor its needs for a specific application. Nowadays a wholly different maintainer handles Busybox.
You are trying to build $product and sell that $product. Open or closed you recieve money for every $product sold.
Just food for thought. Its not so bad over here on Light side.
GPL'd Software has been very good to me and I try as hard as I can to be good to it. You're welcome to join as is anyone else. Generally speaking, the more competent people looking at the source, the less bugs there are.
OSGGFG - Open Source Gamers Guide to Free Games
But it isn't tricky. Licensing is licensing the only difference between licenses is what you get and or give (pay, exchange). If you are going into the software business on any platform without proper understanding and respect for the licenses of any code you will be using then you are destined for failure or massive legal problems. THis is true of any license,
Going closed source is not "any more "tricky" on Linux than it is on WIndows. Indeed, as far as licensing goes I'd put my money on it being easier. No endless negotiations and NDAs for the fundamental libraries and so forth - the vast majority of libraries are simply licensed with publicly available terms.
For example say you want to make a proprietary application that is essentially a means to store, modify, and view data. So you use QT4, and SQLLite or PostreSQL. How is it tricky from a licensing standpoint? You purchase a license to make a closed source application using QT4 from TrollTech, you use the built in DB support for whichever of those libraries and there you go. How would you do the same on Windows? Well, exactly the same. Ok, so you purchase the Windows license instead of the Linux License. Hell the exact same process works for OSX.
Yes, the flexibility there is due to QT, but the underlying platform is simply a platform in each case. And that is the point. Developing software where you don't write the whole infrastructure from scratch in-house involves licensing other people's code. That is no more tricky than the authors of the code you want make it. It so happens that BSD, GPL, and LGPL make it pretty simple.
So your "hypothetical" is entirely without merit.
My Suburban burns less gasoline than your Prius.
Seriously. If you lease the hardware/software combo instead it isn't distribution.
My Suburban burns less gasoline than your Prius.
My understanding of the GPLv2 is that if you use/modify existing code licenced to you under the GPL then you must also release your own code under the GPL.
To circumvent this you may find that the libraries etc. You are wishing to use are release under multiple licences, where for a small fee you can licence the code for use in your project under a comercial licence. This effectively circumvents the GPL as you are now using the same code under a different licence and (in accordance with whatever comercial licence you are using obviously) you should be able to release your application as closed source completely legally.
The GPL is there to promote free software and keep it free from initial developer to end user. If you want people to pay for your applicaiton it is only fair that some of that profit is passed to thoes whos code you have chosen to adapt/extend.
Paul Gogarty
It's bad enough with the big vendors, who might discontinue a product without warning.
With a small vendor, there's all that PLUS a very real chance of bankruptcy.
Of course, Open Source software almost entirely eliminates the worry.
Now, how do you plan to make your customers feel safe?
On the other side we have free open source OSs with free open source development tools. People who have spare time write open software so that anyone with enough money for a computer can get a working OS and some application programs and enjoy computing.
What is missing here is something in the middle where people who have committed their lives to software engineering can write useful software, make some money, and survive in a world where it takes money to live. I remember when their were a dozen commercial Unix versions we asked for a unified API so that we could write software that would just run. I am truly sorry that Java wasn't it. I am sick to my core that Microsoft says .NET is it.
It is great that RMS (and other people) worked hard and their is an alternative to Windows and SCO Unix/Xenix. While RMS was busy making sure there would be some free software, he made very few allowances for how motivated skillful people could write software and distribute it, and profit from their knowledge, skill, and efforts.
I have never pirated source code in my life and I have worked for hundreds of companies as a consulting engineer. I don't need to hide my code to hide unethical behavior. But around the time people started talking about reverse engineering as a legitimate competitive engineering technique, I fell of the cabbage cart and couldn't keep up with what they were thinking. Over my career, I have bought dozens of proprietary language compilers for various operating systems. That was how I worked for thirty years. It was a required tool of the trade. If I want to write a unique contemporary software product, and sell it to assure my financial stability in my old age, it is very unclear how to do that any more when the big players have patent portfolios, and the small players insist on an open software world. RMS says programmer's art should belong to the world. To the best of my knowledge, he has plenty of money, so he figured out how to leverage the marketplace and make a living. I am not a devious businessman who knows how to leverage everyone to make a fortune. Just a hard working engineer who solves technical problems one at a time for people who have problems.
I am clinically depressed about the current state of the computer industry, and my pride of being part of an unfolding technological society has faded as my talents and experience become worthless in the current marketplace where saving a few dollars on engineers results in technical jobs being sent offshore, and marketing costs are so high you have to sell the majority interests out to make a visible mark in the marketplace. When I started programming, hardly anyone even knew what that was, and I thought I hade found a good niche. I read that soon there will be a billion personal computers. I guess that means there will be some part of a billion people who think they are programmers cluttering up the product space too.
Things have really gone to hell. Bill Gates is the richest man in the world. Computers are so cheap that they aren't worth fixing any more. People expect that they should be entitled to all the software they need for free. I know that releasing your hobby code into the free software world is a good way to let people see how smart you are. I don't know what else to say, and that's saying something. I usually have something to say about everything. Douglas Goodall (Internic nicname DG223) SNMP Private Enterprise number 204, goodall.com domain registered in 1991. Started on 1620s and 360/20s. Worked at arpa host #1 network measurement center.
Take a look at the differences between two systems/groups that parallel your questions.
Sveasoft on the commercial side.
OpenWRT or DD-WRT on the Open Source side.
And if you are familiar with the discussions/flame wars around this platform and code, I think it's safe to say there's a market for either one. Albeit, sometimes there's bad blood between closed source companies and the Open Source community, other entities who have profit as their prime motivator instead of passion for the idea have and do work and play well with the community.
At the end of the day, the choice is still yours since it is after your Source.
Scientia et Potentia
If you are distributing an embedded system that contain Linux (and other GPL/LGPL software) you must either bundle source code / configs (e.g. kernel config) with those boxes or make an offer to supply the code for a reasonable fee (i.e. shipping & handling) for the components that fall under this license. This has nothing to do with whether your application falls under GPL or closed-source status. Also, you can't say go download X.Y.Z kernel source from kernel.org. You will need a copy of all the source code. In the past, I've made a CD ISO of all source code for embedded systems. If a customer was to ask for GPL code, I'd just copy the ISO and mail it out, usually for $5 - $10.
It has been my observation that developing closed source software for linux does not work. As most of us know Linux has a significant community of users that will develop a open source alternative to your closed source software. It is not beyond the average linux user to find open source equivalents to closed source software. The real question should be why pay for something if you could get an equivalent item for free(legally of course).
Well, thanks for the agreement... :-)
Given that we know pretty much nothing about the exact scenario that is being discussed here there are several reasons that he might want to statically link rather than dynamically.
Memory usage could potentially be an issue, particularly if he's basically using the kernel to manage hardware and one program is doing all the work. This assumes limited hardware in some respect, and the question has to be asked is it cheaper (in the long run) to use hardware with more memory or do more development to keep the memory usage down?
Speed might be the issue, if there is basically one program then the issue would have to be start up speed. Loading dynamic link libraries does take a small amount of time, but again, if the start up speed is that critical then wouldn't better hardware resolve the issue more reliably?
Finally disk space could be the issue. Assuming that you use a fairly smart static linker that only links the modules needed from each library then you could save "disk" space by static linking a single binary. However, if space is that constrained do you want the overhead of a full blown Linux distribution?
It seems that these issues could all be resolved by either spending more on hardware, or spending more on development, and ditching the whole OS idea. If it's a single use device then do you need a full Unix kernel or do you just need a piece of software that can boot and control the minimal hardware that it needs?
Again, I don't have any information that can answer these questions, I'm just speculating.
Z.
-- Under/Overrated is meta-moderation, and therefore is Redundant.
This guy says that he want to sell software for living and can't link dynamically: he's clearly a troll.
this post contain no useful information, no need to mod it down
But if your product can be so easily copied, then your business model is flawed... It will only work at all with government interference to prop up your flawed business model. In a purely open market, you'd be forced to compete hard.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
> 3. Can I obfuscate my code (e.g. encode it)?
use perl.
>But if your product can be so easily copied, then your business model is flawed... It will only work at all with government
>interference to prop up your flawed business model. In a purely open market, you'd be forced to compete hard.
How would you do it?
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
Specifically, part 3(c) of the GPL v2 says:
Since the OP intends to distribute commercially, the OP can refer others to "xyzzyplugh.com" but only as a mirror of the OP's own site under part 3(b) (or, alternatively, simply distribute sources in accordance with 3(a)).Copyrights, Patents, Trademarks: temporary loans from the Public Domain, not real property ("intellectual" or otherwise)
Come up with something that can't be easily/affordably cloned (like a hardware product), or:
Sell my easily cloned product at such a price point that it wouldnt be financially viable to undercut it.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!