Management 'Scared' by Open Source

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.

Comments

The main reason is lack of clear knowledge

[freedom_india]

1) 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.
Many managers don't realize that just "using" Spring does NOT force you to open up your systems.
You only need to open up if and when you modify Spring framework with your own code.

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

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.

It requires a maturity level beyond that exists today and i don't blame them since these managers were brought up an era where you pay good money for good things.

Re:The main reason is lack of clear knowledge

[tomstdenis]

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

Re:The main reason is lack of clear knowledge

[pammon]

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.

Re:The main reason is lack of clear knowledge

[rlauzon]

The main reason is the lack of knowledge. Period. (At least for the companies that I've worked for.)

The people who makes these decisions are frequently ex-techies who don't realize that they have no useful knowledge anymore, simply because they've been living in management-land for so long. So they make decision based on simple rules. Back in the '80's, the rule was "no one got fired for going with IBM." Now, it's "no one got fired for going Microsoft."

Time and time again, they choose to pay for overpriced Microsoft products instead of going with an open source alternative. For example: when we "upgraded" to Windows XP, we also "upgraded" to Office XP. No one could give me a clear reason why we chose to pay $75 per license for Office XP instead of going to OpenOffice for free.

The only time non-Microsoft products enter the enterprise is when these people aren't part of the decision process. For example: our new PBX system runs Asterix and the "print servers" that we put in the remote locations are all appliances that run Red Hat.

Re:The main reason is lack of clear knowledge

[Mateo_LeFou]

I don't know much about Spring in particular, but depending on the license it's perfectly legal to download it, learn how to build it, and make someone pay you to install it. Charge whatever you can get; try to keep a lid on how easy it is. Attributing it to yourself would break the license, but it would be *your breach, not the client's.

"If you use any open source code in your company's software, your failure to comply with the legal conditions for doing so (such as the GPL) can and will put you in close communication with your lawyers if the original coder ever finds out you've ripped his code in secret."

The good news is that policy from the highest levels at the free software foundation is "never let a request for damages interfere with a settlement for compliance." So if a manager finds that they are noncompliant, they will get guidance (from Moglen) about how to get back into compliance, rather than a lawsuit.

On the whole, it seems like a much friendlier proposition that having a team of attorneys crawl over every vendor's EULA with a microscope.

Re:The main reason is lack of clear knowledge

[CastrTroy]

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.

Re:The main reason is lack of clear knowledge

[l0ne]

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.

Oh, come on! The dev community has worked twenty years to get to the point where you can reuse existing code without having to copy and paste it. We were calling this inheritance if I'm not mistaken.

Also, it's common sense that other people's code is other people's. If your developers are not intelligent enough to understand that and actively research the license for the code they're taking, they should not be your developers. I can do it, and I'm just a Slashdot-reading moron!

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.

They're also easy not to make. Not as easy as they are to make, but easy enough. Think safe sex.

If any contributions are properly documented (it's easy with a proper source management system), and made by a group of competent developers, as above, things work out correctly. If you cannot keep your devs in check, you have more to worry than just licensing problems. Google does this, Apple does this, Microsoft (!) might be even doing this, and none of them ever had licensing problems of any kind.

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.

Using an open source tool and modifying it are two deeply different things. No FOSS tool that I know of limits what you can do with its output. OS X is compiled with GCC, but it's a commercial OS, for instance.

Re:The main reason is lack of clear knowledge

[g2devi]

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

This is a valid concern, but it goes deeper than you think. It's been a few years since I programmed for Win32 and MFC, but back then, it was quite common for Windows programmer to google for hacks^H^H^H^H^H solutions to problems or copy code from book CDs to solve problems and to cut and paste them into code. In web programming, it's even more common to look for libraries or snippets that solve a problem rather than reinvent the wheel.

Years of blindly clicking book-long EULAs or online EULAs that change silently on you without your notice have taught people that licenses don't matter and are things to be ignored. Most developers who do this don't seem to be aware of licensing issue and assume that if it's on the internet or if it came with or on a book, then it must be public domain and fair game. In a large number of case, this is not the case, and a stricter license ("you may use this code in non commercial code" or "you may use this code but not modify it" or even "this code is for demonstration purposes only, do not use it") is attached. Shared source muddles the issue further since it leaves you to SCO-like "you looked at the code so anything you write is contaminated" type lawsuits.

This is what managers are really afraid of.

What many managers haven't clued in on is that open source makes managing this concern easier because most open source software falls into 10 or so licenses that can be divided into three or so categories "share quid pro quo" (e.g. GPL), "library quid pro quo alike" (e.g. LGPL), "attribution" (e.g. BSD, MIT). So it should be easy to define a policy for them and provide a mechanism for new licenses to be added. If you enforce the policy to make your developers actually *look* at the license and *care*, there's little reason to fear and reason to be more confident than you aren't accidentally setting yourself for IP lawsuits from *non-open source* publishers since your developers will be avoiding those like the plague in favour of open source software of the appropriate type.

Re:The main reason is lack of clear knowledge

[multipartmixed]

What the hell is wrong with using Excel to do graphing?

I regularly generate reasonably complex CSV files with *nix tools, usually out of prof, truss, dtrace or syslog output. A couple of quick clicks in excel, up pops a graph which contains useful visual information. Why, just the other day I solved a multi-process race condition with a floating bar chart derived from a log file...

Excel is really great for that sort of stuff, lots of built-in graph types you can quickly try, it understands things like dates and floats, and if you wind up with something really cool you can take a few more minutes to add some labels and colours and bang it into a PDF.

Compared to what.. What other tool allow that? Hmm. I'm thinking here. Whatever tool that might be, it sure as hell isn't installed on my desktop and I don't know how to use it.

So, in your magic neverland where Excel is not the right solution.. What is? And why should I spend time+money on it, when Excel already does what I want it to?

(And, for the record, I use Excel '97...)

Re:The main reason is lack of clear knowledge

[NickFortune]

No FOSS tool that I know of limits what you can do with its output.

One category of programs that may cause such issues are lexical and syntactical analyzers (also known as lexer and parser generators), since they often include parts of themselves in their output.

Got any examples?

The most common lex and yacc tools distributed with Linux are Flex and Bison - or at least they were when last I had occasion to use such things. It's not true in either of those cases.

Flex, if you look at its sourceforge page is distributed under the BSD licence. So there are no problems with flex.

Bison is more problematical, since it's released under the full GPL. The problem is acknowledged by the FSF

Some programs copy parts of themselves into the output for technical reasons--for example, Bison copies a standard parser program into its output file. In such cases, the copied text in the output is covered by the same license that covers it in the source code. Meanwhile, the part of the output which is derived from the program's input inherits the copyright status of the input.

However the same FAQ entry continues:

As it happens, Bison can also be used to develop non-free programs. This is because we decided to explicitly permit the use of the Bison standard parser program in Bison output files without restriction.

So Bison isn't a threat either.

Which tools were you thinking of, specifically? I'm sure the authors of such tools don't intend to lay traps for proprietary developers, and I expect they'd be happy to make the relevant changes if it meant wider use of their tools.

Failing that, it would be a worthwhile exercise to publicise any such tools that are incompatible with proprietary development processes. As opposed to just going "Open Source! Be Very Afraid!" which doesn't seem to contribute anything of value to the debate

Re:The main reason is lack of clear knowledge

[Presence1]

Lack of knowledge may sometimes be the cause, but not always.

I use the OO apps every day on my machines. They are pretty good, the price is right, and I prefer to avoid the MS tax where possible. I also think MS Word sucks because it tries to do WAY too much for me (turn off all that crap, and just let me write!), and I think Excel 3 was the best version (very nice but still lean).

Yet, in most recent software company I co-founded and served as CTO (building self-service web apps), we made a decision to use MS Office instead.

Why? Compatibility. The business-side partners, while sympathetic to the open source cause, and certainly liking the price, were emphatic that they needed to frequently exchange files with suppliers and customers. I would have liked to make the case for OO, but I could easily find files in Word, Excel and PowerPoint that OO would fail to properly display or edit. So, with these inconvenient facts, I agreed that MS Office was the way to go.

Am I disgusted with MS practices in making compatibility so difficult? Absolutely. But I still needed to make decisions based on the actual facts on the ground, not the ideal that OO will (someday) be fully compatible. We had a company to build and needed the best, most cost-effective tools to get the work done, even if we are being oppressed by a monopoly compatiility issue.

A few years later, my current startup is in development and fabrication of high-performance composite products. We are starting out with OO, and compatibility is better, and MS Office is even more bloated, but I have a suspicion that the same decision will ultimately be made again.

Either way, neither decision will have been made from ignorance, and certainly not from any kind of "nobody got fired for buying XYZ" attitude.

Re:The main reason is lack of clear knowledge

[gnasher719]

'' 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? ''

No matter what the size, it doesn't "trigger the GPL".

Lets say I have written an identical two liner and published it, but without GPL, so nobody is allowed to duplicate it. What's the difference between including your code and mine? Each one is copyright infringement and treated identically. The only difference is that the person copying your code has one more way to make his copying legal (by publishing everything under GPL) which someone who copies my code doesn't have. But nobody can ever be forced to publish their code under the GPL.

Heard that

[tomstdenis]

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

Re:Heard that

[DRichardHipp]

I've actually *sold* a few of licenses to the public domain SQLite 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.

The license issues

[mi]

And the Lawyers are in panic

And for good reason. Just listening to all the talk on whether or not Novell is violating GPL (perhaps by simply partnering with another vendor - Microsoft) should make a lawyer's skin crawl...

If more code was released under BSD-type license, we would've seen wider adoption.

So, GPL was used to wrestle a few vendors into releasing their own code. And what? Who has looked into that code or used it for anything else? And how many other vendors have (foolishly) decided to avoid "open source" and come up with their own (usually inferior) re-inventions of the wheel, because of that?

It is hard enough to use an outside solution because of the NIH syndrome. Restrictive licenses exacerbate the problem...

Re:The license issues

[LinuxDon]

Quote: "I'm not aware of anybody benefiting from this open-sourcing, however, and this lack of benefits (from vendors being wrestled into releasing their "GPL-tainted" code) was my main point."

There are a lot of people benefiting from this actually.
Ever heard of http://www.hyperwrt.org/ and http://openwrt.org/ ?

Now you can actually run a webserver on this device.

Granted, you can create a discussion about the commercial value of it all, but it certainly has a very high educational value. Also, this code (with some modifications) could be used on other/similar devices as well.
The way I see it, this is a big win. Instead of reinventing the wheel people can now start off with the already existing code. And I bet Linksys is actually selling more devices because of openwrt instead of less, so Linksys has won too.

Re:The license issues

[imroy]

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:The license issues

[Bent Mind]

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.

Just off the top of my head, it's been a while.

They took the Linux kernel and patched to support a Broadcom wireless NIC. They then sold the compiled version as their own software. Someone found a bug in the interface that dropped them into a shell and discovered it was Linux. Linksys responded by offering the Linux kernel source without the patch. People complained when it didn't work and legal again was threatened. So Linksys rewrote the patch to use a binary blob. Nothing proprietary was lost.

Open Source developers then used the patch and blob to reverse engineer a Broadcom driver for BSD, and latter, Linux.

My memory of the events is hazy. I'm sure there is a Wiki article somewhere with more/better details.

Strange conceptions indeed

[thsths]

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.

disempowerment

[ex-geek]

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

This makes perfect sense.

[FriendlyPrimate]

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.

Nice one, Bill

[Bloke down the pub]

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.