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

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

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

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

[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

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