Forgot your password?
typodupeerror
Businesses Software Linux

Management 'Scared' by Open Source 373

Posted by ScuttleMonkey
from the following-with-a-firm-push dept.
A discussion panel at EclipseCon exposed how managers are freaking out over open source. Apparently a disconnect exists between managers who set corporate open source policies and developers supposed to follow them, but who end up covering their tracks to make it seem like they are not using open source. Developers, though, end up using open source because of its ubiquity and not using it 'puts them at a competitive disadvantage because their competitors are.' And the Lawyers are in a panic.
This discussion has been archived. No new comments can be posted.

Management 'Scared' by Open Source

Comments Filter:
  • Heard that (Score:5, Interesting)

    by tomstdenis (446163) <tomstdenis@@@gmail...com> on Saturday March 10, 2007 @07:35AM (#18298786) Homepage
    When big enough companies use [or acquire companies that use] my software, I usually get a call from a manager or legal dept. Turns out big companies are not only scared of OSS but also public domain software. The idea that I give out something for anyone to use without license seems to scare them.

    It's like a fiver you leave on a bus for anyone to have, people are always skeptical if they can in fact take it.

    On the plus side, it's fun explaining the public domain to folk :-)

    Tom
  • by tomstdenis (446163) <tomstdenis@@@gmail...com> on Saturday March 10, 2007 @07:42AM (#18298812) Homepage
    Along the lines of #1, most folk I meet are fearful of the license issues in terms of "do we owe royalties or something?" Where I work, we use my public domain OSS projects, but we also use others (openssl, swan, the kernel, etc) and we have to be careful of how we distribute things. Fortunately, most of it is in source form which alleviates GPL/LGPL issues. But it's always in the back of our minds.

    Tom
  • by thsths (31372) on Saturday March 10, 2007 @07:50AM (#18298834)
    I had a problem with the BSD three clause license once. If you every read commercial software documentation, there is usually a section full of advertising clauses for contributed software. But no, management deemed this not acceptable. Of course there was no time either to remove the BSD code, so we just left it there.

    On the other hand the leaking of GPL code is a reasonable concern. It happens all to often with common software such as MySQL. And you here statements such as "but if we use Perl, we are not linking against the MySQL code", which are dubious at best. Or "if the customer downloads the library himself, we are not responsible".

    Of course banning open source is not the solution. Actually most commercial software packages have some content of open source code (Windows has the BSD network stack, Matlab has BLAS, Adobe uses the JPEG library...). And even if you ban all open source software, you can still violate the license of a commercial package :-). The only solution is to be careful with what you ship, period.

  • by imroy (755) <imroykun@gmail.com> on Saturday March 10, 2007 @07:52AM (#18298838) Homepage Journal

    So, GPL was used to wrestle a few vendors into releasing their own code.

    I'm sorry. What did you just write? Give me one example of a company being forced to release previously proprietary software under the GNU GPL. One. I dare you.

  • FUD (Score:2, Interesting)

    by mapkinase (958129) on Saturday March 10, 2007 @07:58AM (#18298862) Homepage Journal
    I read the first sentence of the article, and it is clear to me that it is utter BS.

    If the company policy is closed source that is it. Managers are absolutely right to make sure that nobody uses open source in company products, because if somebody sneaks in snippets of GPL-protected code into their applications, that might have big legal ramifications.

    Said that, the company policy to use open source in their productsor not is another issue. That is up to particular company, particular circumstances. For some it is better, for some it is not.
  • Best Buy (Score:3, Interesting)

    by Hadlock (143607) on Saturday March 10, 2007 @08:01AM (#18298870) Homepage Journal
    This amuses me greatly, as my good friend is a manager of a Geek Squad department and they're not allowed to use open source tools, although he frequently sees them being used (and lets it slide for obvious reasons). I forget the exact reasoning, but it does involve liability to some extent. Apparently stand alone geek squad "stores" in strip malls and the like are allowed to use "more advanced" tools for some reason.
  • by pammon (831694) on Saturday March 10, 2007 @08:12AM (#18298916)

    Managers are under the mistaken impression that if i just use spring or Jakarta Commons, the company MUST open up the whole project in which it is used (like a proprietrary trading system) to Open Source.

    Use how? What if one of the engineers needs a snippet of code, copies it from Spring, and incorporates it into their product without attribution? Suddenly, that company is legally vulnerable.

    You only need to open up if and when you modify Spring framework with your own code

    No, that is not correct - the Spring framework does not require you to distribute your changes. You just proved the point: licensing mistakes are easy to make. If you were developing a program that incorporated Spring, and mistakenly believed that it required you to license your source, you would cost your company a great deal of money by doing so. That is why the fear is legitimate.

    Open source hacks is another fear they have: the fear that somehow using open source tools will make their client sue them.

    And that's a reasonable fear. If I sell code that violates a license to a client, that client becomes legally vulnerable and might sue me. Because open source software is so accessible, it becomes easier to inadvertently violate a license.

    Leak Back: Managers fear developers, in their zeal to promote open source, will incorporate company's code into open source for 'benefitting' others.

    I doubt very much that's a concern. No developer is going to risk their job for open source warm fuzzies, and conversely, no open source project is going to accept leaked patches. Any project that did would open itself up to huge legal liability. Corporate espionage and bribery is a much bigger worry.

    You mentioned maturity, but I think you have it backwards - corporations have developed strict, mature processes for keeping themselves on firm legal footing, and licenses are reviewed and vetted by the legal teams. The wide availability of license-encumbered code means that engineers have the opportunity to play lawyer. That's bad, and if you're a manager, you should be scared by that.

  • disempowerment (Score:5, Interesting)

    by ex-geek (847495) on Saturday March 10, 2007 @08:15AM (#18298940)
    I believe that another important fear is that of disempowerment. Open source is usually free of charge, which means that their budgets and thus their importance decreases. Also, there is no need for developers and IT staff to go to their superiors to ask and beg in the first place. They can just download, evaluate and use free software right away.

    Free software is also not advertised unlike commercial products, which means that managers can't even communciate, what is going on, to their kin.

    Compare: "I recently negotiated a licencing deal with <known software company> for <known software product>, which i deemed to be the best solution because of <list of buzzwords>"
    To: "Well, my IT guys implemented a working system on their own, using some software I can't pronounce and really don't understand."
  • by imroy (755) <imroykun@gmail.com> on Saturday March 10, 2007 @08:27AM (#18298982) Homepage Journal

    Now, you could say, the open-sourced firmware was never proprietary to begin with somehow, but that's just semantics

    How is that semantics? I thought that was the whole point - PHB's are afraid of having to release all or part of their precious proprietary software. But that's not what happened with Linksys/Cisco and the WRT54G routers. It was a striped down Linux distro. Ok, they had to put it together, perhaps write some shell scripts. I'm not sure where the web interface came from. But did they have to release any super-secret proprietary source code? I doubt it.

    So really, has there been any actual cases of a manager's worst nightmare, the scenario that Microsoft has been FUD'ing us with for years - having to "open source" their internally developed software because a developer in some way used Open Source Software? That's what I'm after. And I don't believe it's ever happened. It's just FUD but the managers don't know any better.

  • Re:Heard that (Score:3, Interesting)

    by teh kurisu (701097) on Saturday March 10, 2007 @08:43AM (#18299042) Homepage

    I think I understand their concern. Technically you still have copyright over your works, as copyright is automatic, but it's what you do with that copyright subsequently that makes it de-facto public domain work.

    Also, it's not strictly true that you're passing it on without licence - you are entering into a verbal contract with your clients (which I believe is binding in most legal systems, but don't quote me on that) which gives them certain rights over your copyrighted work. A good lawyer would probably prefer a written contract, so that they have some form of proof in the event of a dispute.

  • Re:Heard that (Score:5, Interesting)

    by DRichardHipp (995880) on Saturday March 10, 2007 @08:44AM (#18299052)

    I've actually *sold* a few of licenses to the public domain SQLite [sqlite.org] library. Companies call me up and say they want to license the product. I carefully explain that no license is necessary and that they can use it forever for free for anything they want. But they still want a license. So I sell them one. So far, I've sold them cheap. Maybe I should charge more....

    This appears to be more of an issue in Europe where, apparently, the concept of "public domain" is less well defined than in the US.

  • by LinuxDon (925232) on Saturday March 10, 2007 @09:04AM (#18299130)
    I don't know what kind of manager everyone has, but I can't think of any manager having the time to read such crap like Rob Enderle has produced.
    In my experience managers can actually be educated quite fast/well on open source if you know how to sell it to them. The main keywords are 'cost savings', 'reliability', 'significantly less downtime', 'scalability', 'flexibility', 'performance'.
    And big company's like Novell, IBM and RedHat selling opensource/linux make a very strong case.

    Actually, in my experience management doesn't care what is running on the servers as long as it -just works 24/7 and saves them money-. It's not like they will actually have to fix it should any problem arise. Please note that you will have to take full responsibility for the product your are recommending, anyone will back out immediately when you have any doubt. In contrast to commercial software, 'finger pointing' games cannot be played with open source, so if anything goes wrong you'll be shot on the spot. But in my experience everything will go just fine and expectations will often be exceeded.

    If you take the time to make an alternative cost calculation for the next project and invite a company that can sell it to you, chances are good a manager will change his mind.
    Also, make it very clear that it's the manager's budget and you are just trying to make their life easier. In the long run, your manager will become your friend.

    The main problem are engineers without any Linux/Unix experience fearing for their jobs, they will do anything to sabotage the whole thing and start shouting like the world is coming to an end.
  • by CastrTroy (595695) on Saturday March 10, 2007 @09:23AM (#18299228) Homepage
    There's a big difference between using openoffice, and altering open office and trying to sell it to someone else as a product. If the developers and management can't understand that, then there are other issues. Of course there are a couple issues with packages like MySQL, where simply calling the API can require you to open source your product, but that's just something the company has be aware of. I don't think dealing with open source licences is any more difficult than dealing with the closed source licenses that Microsoft et al give you with their product.
  • by khchung (462899) on Saturday March 10, 2007 @09:43AM (#18299316) Journal

    Developers, though, end up using open source because of its ubiquity and not using it 'puts them at a competitive disadvantage because their competitors are.'


    See the problem here? Using open source give an advantage in the minds of the developers, but not the managers? Why? Because developers' time are free for managers of most in-house IT dept! Developers' salary is fixed cost in the budget, once hired, a manager rarely have to justify it every year. On the contrary, developers viewed as having little to do would have caused more problems for their manager!

    So for a manager, a developer's time is a free resource that happens to have a "use it or lose it" property.

    Now, give him a choice of (1) buying a piece of software for a given price, (2) use a comparable open source software with a license he do not understand so he can (2a) try to understand it himself and thus open himself to any future problems or (2b) send the license to legal dept and gets charged to his budget, or (3) tell his developer to re-implement the software themselves, no further expense claim or budgeting needed. Guess what a lazy manager will do?

    So when the manager chooses option (3), and the developers see months and months of unpaid overtime and endless bug fix headaches coming from re-inventing the wheel, they covertly downloads an open source library and plug it in, with a custom wrapper to hide their tracks. Is that a surprise?

    No amount of education will not cause a manager to take any amount of risk choosing open source instead of using a "free" resource to achieve the same thing (a resource that cannot be saved and use later in any case). The developer's time and effort is an externality in the manager's consideration.

    The only way you can bring the manager to use open source is to add the developer's time into the manager's accounting, either when developers are "pooled" and any effort spent will be charged to the manager's budget, or when the developers have other things to do so there is an opportunity cost to have them do other things.
  • by Anonymous Coward on Saturday March 10, 2007 @10:44AM (#18299544)
    I've worked for many compagnies in a somewhat confidential domain. This means that I use to see almost the same people who, like myself, are jumping from one compagnie to another, as hired, consultant or freelance. Sometimes one of this "community" takes long or middle term responsabilities in a compagnie and get hired at a place which implied management or responsability for some produced code. Some are very good at what they do, or at least are known to be.
            I myself though once that one of them was good, because I heard he did some cool stuff and because I saw with my one eyes some good coded stuff referencing its name as the author. But once, I had to work directly with him, and then I was, to say the least, disappointed by its desgin skills, the guy simply didn't understand basics of middleware design. How could it be that he really designed and coded the previous piece of code I saw? Simple and straight: he didn't. Later, I encountered the real author of the work which impressed me, and this guy had the required skills, what our first intervenant did was simply to steal the original code, jumping from one company to another, working on the almost same subject and re-writting the stolen code in a very directly inspired way, when it wasn't litteral copy.
            The fact is that this is not a so uncommon behavior, in some compagnies I have been considered as dumb when I say that no, I didn't leave my previous work stealling confidential or proprietary stuff like code, document templates or process definition,
    and many managers are pefectly aware of the situation. Using free software code may lead a compagny to expose the code of its products, and they fear that another concurrent compagny read their disclosed code and say "hey, this is our original code".
            If you want to make money with free software:
            1- take well-working implementation of something under BSD license,
            2- adapt it to embbeded software, rougly test it,
            3- (usualy ???) build a compagny and sell your library only to big or medium-sized entreprise, presenting you comagny as owning copyrights for the work,
            4- profit!
            This way, you will seduce managers who will be using free software without nowing it, ignorance is a bless, and with a legal fuse in case of problem. In case of problem, just give up your compagny, which, as a moral person, will endorse all the blame, and just build another one.

     
  • by FriendlyPrimate (461389) on Saturday March 10, 2007 @11:09AM (#18299684)
    This makes perfect sense though. Business want a paper trail that they can go back on if problems arise later. You may now say "no license is required...it's public domain". But what if 5 years from now, you decide to sue them for copyright infringement? How do they defend themselves without the paper trail? From a legal perspective, it's an order of magnitude easier to go back to the license and show that you're not infringing than to try to prove that your software used to be in the public domain 5 years ago.

    Another problem with open source software is that patent liability is placed on the user of the software, not the creator. The SCO/IBM lawsuit shows that. License a piece of Microsoft software, and the patent trolls go after Microsoft. Use a piece of open source software created by Ted in his garage, and the patent trolls go after you.

    IBM is VERY strict with open source now. Nobody is allowed to use open source or public domain code in their projects unless it's gone through a very rigorous screening method to make sure there isn't any copyrighted code in there. And they provide a 'whitelist' of software that has been prescreened and is allowed to be used by developers. This list is rather small though. It requires alot of effort to remain safe from a legal perspective, and I doubt that few companies outside of IBM have the resources or expertise to do it.
  • by gitarman (643115) on Saturday March 10, 2007 @11:13AM (#18299708)

    drsmithy wrote

    "Added to which, the GPL - probably the most popular OSS license - does not require "modification" to apply its restrictions, it merely requires "inclusion"."

    IANAL and it has been a while since I even read the GPL, But IIRC I am free to use / modify any GPL program completely unrestricted up to the point I redistribute, because really, who would care whose programs I use privately (assuming I am not pirating a proprietary code)?

    So as I understand it Spacely Sprockets can build whatever system using Spring or whatever, modify it so that it works the best (for them!) and can only redistribute the modified code under GPL. What is less clear (to me) is what if they only wanted to distribute patches of their own code without distributing the Spring source. I suspect that the same rules apply, but again IANAL.
  • Re:FUD (Score:3, Interesting)

    by wrook (134116) on Saturday March 10, 2007 @11:18AM (#18299732) Homepage
    I'm not sure I read your comment right, but if I did I just can't agree with you.

    There are lots of places where you can legally use open source and Free software in a closed source environment. To cut that out of your arsenal is cutting off your nose to spite your face. Of course it depends on the license and what you are willing to give up. But as previous posters have said, you can use public domain software anywhere. You can use BSD licensed software almost everywhere as long as you don't mind telling people that's what it is. You can use LGPL software as long as you don't mind distributing the source for the LGPL software. You can use GPL software as long as you don't mind distributing the source for the GPL software and you have a good separation between the GPL software and your closed sourced software.

    I've worked primarily in closed source companies. I should be clear that I think such business practices are stupid. They hurt the customer and they hurt the competitiveness of the company using them. I can't tell you the number of times I've spent a company's money writing features that help achieve lock in without giving the user anything in return (or even make the customer's experience worse). I think that's dumb. It pisses off the customer and wastes money.

    Management (and legal) tend to have this idea that they *must* "control" the market otherwise they will lose. They optimize their strategies into tricking customers into locking-in rather than focusing on executing better than their competition. A typical closed source software company does speculative development, spending money up front and then trying to sell what they have already built to customers. In such a company, R&D makes up 10-15% of costs while Management, Sales/Marketing and legal make up the other 85-90%. *This* is why they get freaked out over using open source or Free software.

    Their entire focus is on bamboozling and coercing their customers. Saving even 25% of R&D costs (4-6% of total expenses) is not worth it if they have even a small chance of "losing control" of their market. They basically don't care if the solution will be better. Even an "advertising" clause is usually unacceptable since it shows the user that the company's precious "IP" is actually partially derived from something that anyone can acquire at zero cost. It destroys the illusion that one *must* buy from that proprietary company.

    It's strange to be a Free software advocate working in the "closed software" world. I've mostly spent my time just trying to understand what makes "closed software" tick. In the end, these companies are trying to win the lottery (and if they already have, they are trying to turn the lottery into their own private mint that churns out tonnes of cash on demand). They spend money up front and are looking for a return down the other side. Generally speaking they aren't particularly interested in "building a business" -- i.e. creating a stable revenue flow and making a living off of it.

    Especially with small companies, there is a need to generate some "worth" in the non-people aspects of a company. After investing $2-10 million up front, they are looking to sell the company (not the software) for $100 million to $1 billion. You can't sell a team of people for that kind of money (or so they think -- in other industries people pay significantly more for a portfolio of satisfied customers). "Owning" all the non-people assets of the company is paramount to their strategy. Using open source or Free software to reduce costs is not an attractive position for them.

    However, I've noticed as more and more "up front payment" companies have started to chip away at the "back end payment" companies' market. Instead of selling software as a "fait accompli product", these "up front payment" people sell customization to an organization. They offer the customer more choice at the same price. Slowly, this business model is starting to make an impact (although the potential market
  • OpenOffice (Score:2, Interesting)

    by bjackson1 (953136) on Saturday March 10, 2007 @11:20AM (#18299748)
    I work in IT at a medium sized organization. We recently ran out of Office licenses. I came up with the brilliant suggestion to use OpenOffice on non-essential personnels computers who would not be needing advanced features. Essentially on most of these machines, Office was used only to type letters in Word, or perhaps excel.

    My employer refused to use it, because as a free piece of software, it would not have enough features, would be insecure, etc.

    Well, I decided to repackage it as OfficeLite, I told them it'd cost an extra $15 dollars to install per machine (I did NOT say it cost this per license), and now they love it! They checked it out and thought it was a brilliant piece of software. I have since told them how I duped them, but eh, I get to keep the first 120 I made from it.
  • by paeanblack (191171) on Saturday March 10, 2007 @12:37PM (#18300238)
    From the GP:3) Leak Back: Managers fear developers, in their zeal to promote open source, will incorporate company's code into open source for 'benefitting' others. Much like SCO claimed. Developers are not fools.

    Developers are not legal experts either. "Who retains what rights to which code" can become a sufficiently complicated question without bringing the umpteen F/OSS licenses out there into the mix. If the developers can duplicate what already exists in F/OSSland for less money than the legal team can unravel the rights, then staying proprietary is the right decision.

    Along the lines of #1, most folk I meet are fearful of the license issues in terms of "do we owe royalties or something?"

    Exactly. The trouble is that answering their question can cost more than what incorporating F/OSS will save.
  • by Tassach (137772) on Saturday March 10, 2007 @01:41PM (#18300606)
    A little reducto ad absurdum here... Suppose I release the following program under GPL:

    #!/usr/bin/perl -w
    use strict;
    Does that now mean that any Perl script that "includes" mine is now subject to the GPL? How big does an "inclusion" have to be to trigger the GPL? One line of code? Ten? One hundred?
  • by Lord Kano (13027) on Saturday March 10, 2007 @03:28PM (#18301196) Homepage Journal
    A year and a half ago, I had a professor state matter of factly that Linux was less secure than Windows because anyone can look at the source code and find exploits.

    Involuntarily, I screamed "WHAT?!" He paused and gave me a chance to speak, my response was to take the example of OpenBSD, it's Open Source too(different license, I know but that's not the point) and in the previous 8 years there had been exactly one remote exploit on a default install. Microsoft dreams of that kind of security.

    He really had no response for that. What bother me though is how many times did he give that exact same speech to students who didn't know any better and just assumed that it was true because a high ranking professor had said it? So as these people leave college and become managers in IT, they'll carry the misconceptions that Professor Dvorak had placed in their heads.

    LK
  • Re:Heard that (Score:1, Interesting)

    by Anonymous Coward on Saturday March 10, 2007 @03:36PM (#18301266)
    "This appears to be more of an issue in Europe where, apparently, the concept of "public domain" is less well defined than in the US."

    Actually, it is much more well defined than in the US.

    For example, at least here in Germany, works only become public domain when the copyright term runs out (i.e. 70 years after the author's death); this means you cannot put it into the public domain while you live.

    Thus, writing a piece of software and then saying "this is in the public domain" is not legally valid, you'd need to write up a license specificially for that, otherwise you can sue for copyright infringement.

    To summarize: Over here we take the distinction between "owner makes the source available" and "owner is deceased" somewhat more seriously.
  • by Frumious Wombat (845680) on Saturday March 10, 2007 @03:51PM (#18301366)
    You're forgetting the BSD copyright issues. About the time Linux was becoming public, the various BSD releases had been held back to AT&T owned code, which meant you had to buy an expensive license to get your own copy. If you were a Uni, it wasn't bad, but for an individual, somewhat daunting. When they finally factored the last of the proprietary code out (during the 386BSD days), people were still worried that it wasn't really gone, and therefore waited for someone else to be the first to be sued. I knew Comp-Sci grad students at that time who thought it was great, if it was really clean, but with Muppet-Labs just up the Jersey Turnpike from us, didn't want to contribute to the project, and be the test case for AT*T's lawyers. It wasn't the BSD license, but the licensing of BSD by AT&T that held it back.

    So, some of Linux's success was timing, and BSD being held back by fear of lawyers. Had Linus waiting another year or two to make his public release, you might all be running *BSD on your home machines, and arguing why it hadn't taken over the desktop yet. You'll also notice that the early user environment wrapped around the Linux kernel was heavily BSD flavored, which made an easy transition from the other cheap Unix of the day, SunOS.
  • Nice one, Bill (Score:4, Interesting)

    by Bloke down the pub (861787) on Saturday March 10, 2007 @04:27PM (#18301578)

    The trouble is that answering their question can cost more than what incorporating F/OSS will save.
    Perhaps if you were distributing the code. IANAL(IAOSBDTP), but I thought internal use within an organisation doesn't count as distribution.
  • Re:NMAP (Score:3, Interesting)

    by Dhalka226 (559740) on Saturday March 10, 2007 @05:18PM (#18301942)

    Despite what they claim, it'd be a tough row to hoe to get a court to agree that parsing factual information from NMAP's output constitutes a "derivative work".

    Are you sure? Because it seems to me that you would have a tougher row to hoe to get a court to agree that they are forced to use the terms of the GPL itself rather than the terms that they explicitly laid out for their product.

    Are their terms 90% GPL? Yes. Did they add/modify/clarify (depending on your view) a term? Also yes. What makes you think the court's going to say "no no no, this is GPL and you're wrong, sorry" and not "they created their own license, what makes you think the condition is not valid?"

Only God can make random selections.

Working...