Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Open Sourcing Proprietary Embedded Software?

By h0tr0d in News
Tue Jun 27, 2000 at 04:58:37 PM EST
Tags: Help! (Ask Kuro5hin) (all tags)
Help! (Ask Kuro5hin)

Is it possible to open source software for embedded devices that aren't available to the public? That's what my bosses want to know and I'm hoping the K5 community can help out.


In a recent discussion with management, the idea of moving to an open source license was brought up. We develop software for embedded financial systems so it's not like the code could really be opened up for the world to work on (the hardware isn't cheap and isn't available to the general public). Not to mention the fact that there are many modules that due to industry requirements would need to stay proprietary. I'm not sure if the higher ups are just trying to get on the "open-source" band wagon or if they are really serious about this. So I thought I'd try to get some intelligent feedback from the community before expressing my opinions to management (that way I either have some back up support or don't look like a fool for being wrong). I think the largest issue would be if our current clients who have been paying for proprietary software for years would be willing to all of a sudden let others see their software. And is it possible to just release the source to our clients under the GPL or would it have to be released openly to anyone who wanted it? Any thoughts are greatly appreciated.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Also by h0tr0d


Display: Sort:
Open Sourcing Proprietary Embedded Software? | 11 comments (10 topical, 1 editorial, 0 hidden)
not very useful (1.33 / 3) (#1)
by Arkady on Tue Jun 27, 2000 at 03:52:01 PM EST

I think you may be right about it being a bandwagon effect, since I can't really see much of a use for it. Openning the source to your clients, of course, would be a marvelous gesture and would probably help your business. They'd be able to help spot problems directly and help with developing new features. But the wide world wouldn't be of much help if it runs on expensive proprietary hardware in a small niche market.

I'd definitely recommend that you open the source to your users, though.

Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere Anarchy is loosed upon the world.


GPL? probably not. (3.50 / 2) (#2)
by orthox on Tue Jun 27, 2000 at 03:56:34 PM EST

First off, they need to ask themselves, in what ways will this move benefit the business? If just for PR, then tread lightly. Although it almost seems that they want to create a closed community (of clients perhaps) that can share and benefit from the work of others (and possibly help it become a standard through a well developed application base).

I this case the GPL may not be ideal, but then again there is nothing keeping them from writing their own exclusive source license.

Here is a decent list of opensource licenses. You may be able to use one of these, or roll your own from the ideas contained within.
OSI certified licenses

Re: LGPL? probably yes. (4.00 / 1) (#5)
by MeanGene on Tue Jun 27, 2000 at 04:38:48 PM EST

If I understand correctly, they have a two-piece business: proprietary libraries for pricing, scenario analysis etc. and some sort of "embedded" delivery mechanism. They could open up the second part under LGPL in hopes of capturing the market share through other vendors adopting their framework for, say, future XXX-enabled devices.

[ Parent ]
GPL probably not a good idea. (none / 0) (#3)
by jmcneill on Tue Jun 27, 2000 at 04:08:25 PM EST

Correct me if I'm wrong, but if you wanted to keep parts of the software "proprietary", well doesn't the GPL disallow that? The BSD license might be a better solution in that situation.
``Of course it runs NetBSD.''
There's a bandwagon around here somewhere... (4.00 / 1) (#6)
by eann on Tue Jun 27, 2000 at 05:01:41 PM EST

A few points that come to mind:

There's nothing that says open source programs have to run on anything even remotely resembling modern desktop PCs. It just means you have fewer people who can do anything with it. Well, until somebody gets curious and ports it.

On the other hand, it's not really open source if only a few people can see it, is it? It sounds like the term your bosses are fishing for is "non-disclosure agreement", which makes your customers legally liable for big trouble if you share with them and they pass it on to the rest of the world (or your competitors). Obviously, the terms of that NDA can't look a lot like the GPL, since much of the GPL is really about redistribution. In short, if you want the whole world to see it, GPL it; if you only want feedback from your customers, NDA it.

The trick to switching to an OSI-compliant license could be whether you can convince your customers that they're paying (presumably) thousands of dollars for a handful of CDs, some printed manuals, and a few support calls. It's a business model that can work for at least the short term (see Red Hat), but I can definitely see it'd be tough to switch mid-stream. And, as you noted, if your customers are competing with each other (which sounds likely), there's a chance that more than one will not appreciate having their "secrets" revealed among others in the trade (even if the only secret is that they've been using the same underlying software all along). It's customers--it has nothing to do with rational thought processes.

I'm not aware of any restriction to licenses (including the GPL) that say that you can't distribute proprietary modules alongside open stuff; you just have to be sure you keep them carefully separated. There is the issue that the API to the proprietary bits (or significant portions of it) may be evident in the other code, so, again, be careful.

Finally, yeah, this smells like AOLism: dropping the S/N ratio in a significant discussion by saying "me too". If that's all they're up to, steer them clear of the term "open source". If opening the source is not what they're doing, it's not what they want to call it, and they'll avoid all the customer relations nightmares mentioned above.

Our scientific power has outrun our spiritual power. We have guided missiles and misguided men. —MLK

$email =~ s/0/o/; # The K5 cabal is out to get you.


Re: There's a bandwagon around here somewhere... (none / 0) (#11)
by Louis_Wu on Wed Jun 28, 2000 at 12:48:52 PM EST

It just means you have fewer people who can do anything with it. Well, until somebody gets curious and ports it.

This is something to seriously consider: do you want this ported? If an interested party (a coder at a financial institution or an entreupenurial (sp) coder) gets at the source, it might be possible to port your code. Does your company benefit from the hardware sales, do you have a partnership or good relation with the hardware manufacturer? What would the implications be if your code could be run on a Pentium or a PPC?

All of management will be asking whether an "evil hacker" could do damage if he can see the source. Regardless of whether you have weaknesses a cracker could exploit, what your customers and managment see is important to this decision.

BTW, since the number of people looking at this code would be small, how likely is it that a cracker will find a hole no-one else has noticed? More eyes bring problems closer to the surface, but HOW many eyes is many? Will you get enough eyes to justify the cracker risk to management and customers?

Good luck.

Louis_Wu
"The power to tax is the power to destroy."
John Marshal, first Chief Justice of the U.S. Supreme Court
[ Parent ]

Keep it closed... (none / 0) (#7)
by sugarman on Tue Jun 27, 2000 at 05:29:02 PM EST

Yes, I know that software wants to be free, but there's also the other maxim "if it ain't broke, don't fix it". It sounds like your company may be open to lawsuits from a number of angels if this product is released:


A) from your clients, especially if they are in competition with each other, for disclosing confidential information
B) from some of the other proprietary modules that are being used, if those licenses have restrictions upon their re-distribution
C) from the OSS community, if you happen to step on some toes with regard to the open source licensing, or violate the GPL, or what have you. Witness Corel, and the vast amount of flamage that they have recieved for some minor transgressions with distro.

(Alright, (C) may not involve a lawsuit, but being shunned in a meritocracy like OSS will generally completely evaporate any goodwill you may have recieved for the opening of the software. And isn't that the point of a marketing -based move like this one (because that is what it sounds like)

Also, A & B may not be provable in court, but why open yourselves to lawsuits unnecessarily?

If your applications have a narrow usage, and are unlikely to be picked up by the OSS community, you may recioeve little for your efforts. Just something to keep in mind when weighing the pro's and con's here.
--sugarman--

Releasing source to clients. (none / 0) (#8)
by Anonymous Hero on Tue Jun 27, 2000 at 10:44:37 PM EST

Of course it is possible for you to release the source to your clients, and only your clients, under GPL. Even if you are no longer the sole author (ie: other contributors under GPL), you can pick and choose who you want to distribute to, and you are only bound to provide source to those people. However.. Nothing prevents these people from also distributing this software, so long as they obey the GPL as well.

Open the Code for Them (none / 0) (#9)
by gnuchris on Wed Jun 28, 2000 at 12:05:59 AM EST

I think it would be beneficial to Open Source your code, for your clients, so they can make changes if necessary. Remember back when software was distributed along with the source code? It was for the clients you were selling the code to. If they are buying software, they should have the code too. They may even help you out... You should really look into the implications of using the GPL. I dont' think you can embed proprietary modules into GPL'd code. If you have code you need to keep a secret, I'd advice an alternate policy. Email me if you want to discuss these things more intimately... I think message boards are for general discussions. -gnuchris-
"He had alot to say, He had alot of nothing to say" -TOOL-
Hey look every . . . hello? (none / 0) (#10)
by duxup on Wed Jun 28, 2000 at 02:56:18 AM EST

From your description I can't see what advantage you'd have in opening that software. I sometimes wonder how much "room" there is for useful open source software. There's only so many people actually reading and maybe using the open code that is out there, but that's another discussion.

I work in a company somewhat similar to your description. Our hardware is expensive, and proprietary. The software also is proprietary, and terribly poorly documented too. I've wondered if we opened the code (assuming we could) if anyone would care, or what good it would do. Our customers wouldn't need to work with it, as it is we make the changes for them and the cost for them to hire a programmer and learn the code and OS it runs on and make changes would be far more expensive than pay us to do it.

Other than getting to jump on the bandwagon and announcing that you've opened our software there's no real benefit that I see.

Open Sourcing Proprietary Embedded Software? | 11 comments (10 topical, 1 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!