Convincing Your Superiors to GPL the Code?

jakobgrimstveit asks: "At work I've been developing an intranet/extranet portal framework in PHP based on many other peoples work, including quite a few PEAR modules. I've always wanted to release the coding framework as GPL and publish it on SourceForge, and my boss has - impressively enough - not been too negative about this. This has been going around in the organization for quite a while now, and finally the reply from the company's president was (not surprisingly): 'Why should we do so?' I now have the task of writing a document listing the main reasons for GPLing the code, and this is where I turn to the highly competent Slashdot crowd: How do I convince my bosses to GPL the code I've written? I assume many other developers have the same problems trying to convince their bosses to open up their code."

Comments

hahahaha

[heinousjay]

the highly competent Slashdot crowd

Oh, sure, them. We'll just wait for them to get here...

Don't

[Anonymous Coward]

We don't want another fucking PHP portal system.

Re:Don't

[theapodan]

Although stated a bit corrosively, parent has a point.

If this code is GPLed, it may make more sense for it to be left stagnant and community development focused on integrating features from teh new codebase into an existing product.

One great products is worth 3 mediocre ones, at least.

Meh

[interiot]

You must work in a different corporate america than I do. My biggest hope is that my company doesn't enforce their "all your copyright are belong to us" policy, wherein every little unix script I write, no matter how small, and even if nobody at the company will ever make money off of it or even use it, can't be taken with me to my next job.

In Fortune-100-America, everything possible must be stamped with a (c) or (tm) or patent#. Advancement up the technical ladder is difficult without getting a few patents for the company.

I think people here would have a heart attack if they knew I ever even thought about GPL'ing code, as that's almost tantamount to selling trade secrets.

Re:Meh

[jakobgrimstveit]

Just to clear up the wrong assumption here: I'm not working in corporate America, though my company has a few offices there. We're located in sunny Norway (it's funny, laugh).

In Norway, the basic rules in IT is that whatever I code, whatever I construct while working is their property, and is not to be carried with me over to a new employer. And that is not a problem for me.

Re:Meh

[OmniVector]

Contrast that to the small company I worked for, and my boss actually ASKED ME if we should open source it. It's all about perspective.

Re:Meh

[ivan256]

My biggest hope is that my company doesn't enforce their "all your copyright are belong to us" policy.

In the past when I've worked for companies with overly broad copyright assignment clauses in their contract boilerplate, I've had them reword it to allow me to maintain copyrights on code that could be considered general purpose. The wording generally goes something like "... with the exception of code that implements functionality basic to the day to day tasks of software development," but sometimes is " retains the copyrights on pre-existing code brought to the company with him, and on modifications and enhancements to such code." I've never had anybody say no when I've asked in the past. Typically the terms are written by lawyer-folk who try to get as much as they can when writing contracts with the expectation of negotiations later.

Either way, it can't hurt to ask. Worst case scenario, they say no. Same goes for when you're discussing salary.

Re:Meh

[Yaztromo]

In Fortune-100-America, everything possible must be stamped with a (c) or (tm) or patent#. Advancement up the technical ladder is difficult without getting a few patents for the company.

As someone who had four patents pending at one of my former places of work, and who was canned anyways after his project was cancelled, don't count on it being a huge amount of help. Being a corporate suck-up usually counts for more than real technical prowess.

Yaz.

Re:Meh

[MrResistor]

Well, yeah, that's because Corporate America is run by MBAs who could care less about actually running a successful, efficient company, and really only implement policies aimed at getting them the cost-reduction bonuses specified in their contract, and then move on before anyone has a chance to realize how badly their cuts have screwed the company.

The upside is that they generally have no idea what their employees are actually doing, so it's pretty unlikely that one of those clauses will actually get enforced.

Still, shame on you for signing that contract. You should have negotiated.

Re:Meh

[BLAG-blast]

Being a corporate suck-up usually counts for more than real technical prowess.

I guess that explains why american corporations keep running out of money.

Re:Meh

[Brandybuck]

...wherein every little unix script I write, no matter how small, and even if nobody at the company will ever make money off of it or even use it, can't be taken with me to my next job.

I once saw the source code to the "yes" script on a commercial Unix. One half line of code, three screenfuls of nasty legalize about unpublished code.

Re:Meh

[Eightyford]

couldn't care less

Re:Meh

[ErikZ]

"Either way, it can't hurt to ask. Worst case scenario, they say no. Same goes for when you're discussing salary."

Actually, the worst case scenerio is that they say "I'll get back to you on that". Then they go to their managers, who talk to the laywers, who discuss things with the manager you'll be working under, the the higher-ups get involved, meetings will be made. Research will be done, and four weeks later, they come back to you with a "Ok, we're making progress on that contract thing. Once we've written up a new one we'll get back to you.

And because of all this focus on contract issues, no one is paying attention to the actual running of the company. An issue comes up which isn't attended to and the whole place goes under.

THAT my friend, is a worst case scenerio.

Who, us?

[elemental23]

highly competent Slashdot crowd

It's funny, laugh!

Sources of advice

[NitsujTPU]

I now have the task of writing a document listing the main reasons for GPLing the code, and this is where I turn to the highly competent Slashdot crowd

Well, that was your first mistake.

Tell them your reasons

[Finuvir]

If you've wanted to GPL it since the beginning you must surely have some good reason for wanting that, right? Just tell them that reason, focusing on the business benefits. If there are no business benefits and you want to open-source it for idealogical reasons then you might need some help. Find business reasons (by looking at other business-led open-source projects, preferably similar to yours) or give up.

Re:Tell them your reasons

[jakobgrimstveit]

Sure. I have many reasons for publishing the sourcecode, but couldn't write them all up in the post. Here's a few reasons:

* Other people can gain knowledge from my code
* I can gain knowledge by other people commenting/submitting patches to my code
* Security vulnerabilities will be found under peer review
* I will get Good Karma [tm].

But me wanting to publish the code is not reason good enough for a boss, of course. He needs to see what he (as in "the company") can gain from this, so I'd like to get as much input as possible on how to articulate myself.

Re:Tell them your reasons

[Marxist Hacker 42]

It's that second one that will convince your boss- but it needs rewording. Plugging into the Dogbert Buzzword Generator for a second, try:

"I wish to maximize my productivity by leveraging the efforts of the Open Source Development Community, thus getting us development resources at no extra cost to the company."

Re:Tell them your reasons

[heinousjay]

If I were granted mod points, I would mod you Evil.

Re:Tell them your reasons

[XO]

Yes, agreed.

Exactly why IS it that you want to GPL the code?

Will ANYONE benefit by having it GPL?

Difficult to present a sales pitch only knowing what we want to achieve, and not having any inkling of the steps inbetween.

Re:Tell them your reasons

[FLEB]

If it's good, you can also give the organization Good Karma [tm] by prominently mentioning them as the creators. If the software isn't worth selling, it's not revealing any secrets, and it would otherwise languish in-house, then it becomes a low-cost marketing and mindshare boost.

It's also a good way to have somewhat of a "short list" pool for future relevant hiring. It could allow the company to easily assess the person's work, and the potential employee to already have a relationship (however small) with the company.

Re:Tell them your reasons

[alecthomas]

I think the inverse of Dogbert's Buzzword Generator must be Bullshit Bingo.

Re:Tell them your reasons

[DerekLyons]

Sure. I have many reasons for publishing the sourcecode, but couldn't write them all up in the post. Here's a few reasons:

* Other people can gain knowledge from my code

If they use it, if they bother to understand it.

* I can gain knowledge by other people commenting/submitting patches to my code

That's a pretty theory - the reality is that few OSS/GPL projects ever get any code back.

* Security vulnerabilities will be found under peer review

In theory. Again, reality shows that they are found not by peer review, but by Black Hat review.

Re:Tell them your reasons

[PastaAnta]

Yes, it is of course important to use the right wording, but I have found that these simple steps will generally lead success:
- Be honest. Do not exaggerate any perceived benefits or skew the facts.
- Be balanced. Write both positive and negative effects. Strengths and weaknesses. Cost/Benefit. Every coin has a flip side.
- Be brief. Your boss will not take his time to read a report. If possible keep it within one page of text. If that is not possible it should contain an "Executive Summary" in ~200 words.

3. profit...

Re:Tell them your reasons

[Shads]

Actually I've contributed to several small oss projects and been a developer in several more. I've found you usually get code back.. just not significant code. More people submit bug reports and little things that you didn't see that are just as valuable as the code itself though.

Re:Tell them your reasons

[stinerman]

-1 ... you didn't use "synergy".

Re:Tell them your reasons

[Anonymous Brave Guy]

Difficult to present a sales pitch only knowing what we want to achieve, and not having any inkling of the steps inbetween.

You must be new here. Everyone knows the step before "Profit!" is:

(2) ...

Re:Tell them your reasons

[darkonc]

Sounds good, but we need to expand on that a little bit, and focus in on the company's benefits....

• 1 and 4 become: "Good PR". Copyrights remain with the company and all notices indicate that the company was willing to make this software available to the public. As the code improves the company gets the primary PR benefit.
• 2: Patches to the code come back to the company. This increases the value and stability of the code faster than if only maintained by you(r group).
• 3 is a subset of 2 but good to break out as a separate point.

Linux is a blatant example of 2/3: There is absolutely no way that Linus could have brought Linux from a hobby system to Microsoft's biggest threat in under a decade. Linux is an extreme example, but it clearly points out that giving more people access to the code (with a self-interest in improving it) results in more and faster bug fixes than any one of them could have achieved in he same period of time.

"Software is like love -- the best way to grow it is to give it away"
-- me

Re:Tell them your reasons

[Johnboi Waltune]

A company exists to make a profit. If you really want to convince them, you need to show how GPL'ing the code will lead to $$$$.

Anyway, here are some likely responses you will get. Up to you to decide how you will handle them.

* Other people can gain knowledge from my code

"Irrelevant to the company."

* I can gain knowledge by other people commenting/submitting patches to my code

"We didn't hire these people or evaluate their qualifications and references; we have no reason to trust them. How do we know you will catch any intentional vulnerabilities they add to our code?"

* Security vulnerabilities will be found under peer review

"You mean these people we don't trust and have no relationship with can figure out where the bugs are in our product? Are you mad?!?!"

* I will get Good Karma [tm].

"Waaaay irrelevant to the company."

good luck

[quewhatque]

you might think it's a good deed for society, donated quality code to the public, but what would a business care about good deeds. they are doing business, which into itself stifles good competition, creating a better market, which does benefit society.

the only way you can convince him is to state the advatages it gives your company, and not what it gives society.
1. other people can fix your bugs and security holes for you
2. other people can add features for you
3. no need to pay for beta testers

tell him you can still maintain your rights of it in that you still have the final say in what gets merged into the source code, and that code vandalism wont happen (people putting in their own backdoors)(as if anyone can immediately donate code and have it show up).

do tell him that one negative of it is your competitors could also use your code, you wouldnt want to get fired for not telling him that someday.

Re:good luck

[chris_mahan]

There is an advantage to your competition using your code, especially if a lot of the competition is using your code. You will be seen as the de-facto standard settig body for the software, and that will attract good-will in the industry, allowing you to potentially hire their finest and brightest.

Also, bear in mind that this will give you an insight of how they run their business.

Finally, you could then turn around and sell them "SuperSoftware Enterprise Edition", since they alreay know and use and love SuperSoftware Standard.

Ultimately, though, your boss does not care unless the business makes moeny off it before year's end.

Remeber Google: If you want to build an $80B company in 6 years: Use linux and develop your own software.

Re:good luck

[Anonymous Coward]

These are the three points that I was going to mention about OSS licensing in general.

Also, please consider other OSS licensing along with the GPL option, such as LGPL, BSD, Apache, etc.

step by step argument

[rnd()]

Here is the argument:

• GPLing the code may have the effect of creating a community of people to enhance and debug the code.
• If it's not a product that provides significant competitive advantage to your company, there is no harm in spreading it around in exchange for the benefit in the first bullet point.
• There may be some positive PR associated with the company "founding" an open source project. Who knows, there may even be some way to consider it a charitable donation and write it off of the company's taxes.
• Most importantly, there are a variety of Open Source licenses, so if your president balks at the GPL, consider the LGPL or one of the variety of others. They provide many of the benefits of the GPL but allow the boss to feel a bit more in control. You can always move to full GPL next year once his/her comfort level has increased.

Re:step by step argument

[Anonymous Coward]

• Never suggest that others are more competent than you.
• It might provide advantage to the competition.
• The kind of people who don't know why they should GPL a product don't care what the kind who do know think.
• The fact that there is a dizzying array of licenses to choose from is not going to make management's decisions any easier.

Re:step by step argument

[rnd()]

wrong:

No suggestion was made that others weree more competent, just that the combined effort of many would be more productive than one person alone.

If it provides advantages to the competition, then the president should probably not go along with it if he wants to keep his job. QED.

I don't know what you mean by "the kind of people"... This guy clearly wants to GPL the software but the decision isn't in his hands. He's trying to persuade someone else, hence the need for an argument.

The variety of licenses will certainly make the president feel empowered. On one end of the spectrum is a Microsoft style EULA, and on the other end is the GPL. Every niche in between is possible, and depending on the specific business circumstances, the boss may be inclined to go with a license that is somewhere in the middle.

Re:step by step argument

[Omnifarious]

I think it's to most places benefit to put stuff under the GPL unless there's a specific reason not to. One worry in GPLing your code is a competitor commercializing your code in a way that you can't work with. The GPL is one of the better licenses for making sure that can't happen.

Re:step by step argument

[jakobgrimstveit]

I don't know what you mean by "the kind of people"... This guy clearly wants to GPL the software but the decision isn't in his hands. He's trying to persuade someone else, hence the need for an argument.

Thanks for spelling it out for me. English is not my native language, and some essence may have been lost in the mental translation. This is exactly what I want to achieve. And if I get enough constructive feedback I will group the arguments together and feed them back to the community. Keep the good tips flowing! :-)

Re:step by step argument

[Hikaru79]

Most importantly, there are a variety of Open Source licenses, so if your president balks at the GPL, consider the LGPL or one of the variety of others. They provide many of the benefits of the GPL but allow the boss to feel a bit more in control.

Correct me if I'm wrong, but the LGPL actually will make the boss feel less "in control" because it will allow competitors to use your code without releasing their changes to the GPL. It's probably got less of a chance of succeeding in the poster's situation than GPL.

Re:step by step argument

[rnd()]

The LGPL still requires permission for others to sell derivative works. But since it allows for some closed source arrangements, it may be preferable to some bosses.

Re:step by step argument

[rnd()]

You may be right about this... but showing the boss the "top 5" varieties of licenses with the various nuances highlighted would create the impression of more control over the terms, and make the boss feel comfortable that a variety of terms are embraced by the OSS community, and this would make the boss more likely to comply.

Re:step by step argument

[swillden]

The LGPL still requires permission for others to sell derivative works.

No it doesn't. As long as the others distribute the source of the LGPL'd code along with the closed binaries, they're in compliance. No additional permission is required.

But since it allows for some closed source arrangements, it may be preferable to some bosses.

Why would some bosses prefer that others be able to use the company's property in closed source products, commercially, without permission? I would think that they'd prefer to start with a license that is more restrictive than the GPL, rather than one that is less restrictive.

Re:step by step argument

[RAMMS EIN]

``...if your president balks at the GPL, consider the LGPL...''

I can't imagine why the boss of the company releasing the beast would prefer to use a license other than the GPL. The GPL's viral nature ensures that nobody else can incorporate the software into a product of theirs, without GPL'ing that product, too.

At the same time, your company still can use the software in non-GPL'ed products, because they are the copyright holder. When you have contributors assign copyright to you (like the FSF does), you retain that right even when you check in patches from third parties.

Almost any other license would put your company in a less favorable position, by allowing others to modify, extend, link to, etc. your software, without sharing their improvements with you.

Re:step by step argument

[anno1602]

The LGPL still requires permission for others to sell derivative works

Neither the GPL nor the LGPL do that. However, you have to give the source code to your customers, too, and you may place no additional restrictions on the redistribution of your product or your sources (that is, a customer could buy it from you and then distribute his copy to third parties for free).

The LGPL differs from the GPL in one important ascpect: If you link with a library that is under the GPL, you have to GPL your product, too. If you link with a LGPL'd library, you have to distribute the source of the library and any changes you made to it along with the product, but not the rest of your product.

Re:step by step argument

[rnd()]

No argument here.

Re:step by step argument

[rnd()]

Well, in some instances the boss might want to reserve the right to sell the code to another company for a closed source product.

Re:step by step argument

[RAMMS EIN]

``Well, in some instances the boss might want to reserve the right to sell the code to another company for a closed source product.''

Which they _have_. That's exactly what I was trying to clarify. Since they are the copyright holder, it's perfectly alright for them to license it as GPL, and at the same time sell it under a proprietary license. For example, Trolltech does this with Qt.

The only complication is if third parties contribute patches without assigning copyright to the boss. If these patches are accepted, the complete work can no longer be sold under a proprietary license without the permission of the contributors. This makes things a whole lot more complicated. The easiest way around it is to just have the copyright assigned to the original copyright holder. IIRC, this is what happens with GNU software.

Re:step by step argument

[vettemph]

and he shouldn't for get to mention that he built upon the efforts of the GPL community who provided 99 percent of the work from the get go. Consider it compensation to the thousands of FOSS contributors before him.

Re:step by step argument

[rnd()]

My post misattribued more control to the LGPL, then, but I think the gist is true that showing the boss the variety of OSS licenses and explaining the differences would make him/her feel empowered.

Re:step by step argument

[rnd()]

that may be true, but it's not boss speak and would thus not likely be very persuasive.

Re:step by step argument

[heck]

The GPL's viral nature ensures that nobody else can incorporate the software into a product of theirs, without GPL'ing that product, too.

Would people please quit repeating this? It's not true. The GPL does not work that way.

"New code" you create which includes GPLd code is your code and does not have to be GPL'd due to some viral nature clause.

Repeating the "viral nature of GPL'd" canard actually hurts the GPL - because people then shy away from using GPL'd code thinking that they will then lose control of their code.

Here's an analogy (and I'll use copyright): if Tom Smith publishes a article which lays out the basics of a concept I am allowed to quote from that article so long as I attribute the passages to Tom Smith. But if I copy the passages and attribute them correctly that does not mean that Tom Smith can force me to publish the article where he wants. Now, if I copy the entire article and try to pass it off as my own, that would be wrong. If I copy the entire article and only change 10 lines I'm still in violation of the copyright. But if I create a new work which delves deeper into the concepts which Tom Smith only covered in basic - so which extends Tom Smith's work - the work is mine.

The GPL works in a similar way - you are allowed to incorporate GPLd code provided (a) you attribute it correctly (b) you include the source as specified by the GPL. The only pieces GPL'd are the original code which was GPL'd; you are not forced to GPL your entire code base.

support

[file cabinet]

sell the support. that's what the linux folks do (RH, SuSE, etc.)

Some ideas

[Zocalo]

• Free development of new features, some of which you might not otherwise have thought of yourselves if you can get a development community started.
• Free beta testing across a broader range of users and operating environments which should identify and enable the fixing of bugs far sooner.
• Free positive P.R. for your company, especially if things really take off.
• Free advertising for your company as well if you brand the package with your company logo and colours by default. Lots of people don't bother taking that kind of stuff out if it's not too obtrusive.

There's far more things that can be free than just "beer", and it's libre too, so you can even have some free Karma.

Realistically though some of that is going to need kickstarting which will require some small financial and time outlay. Things like provisioning the initial website and forums for your applications users to bounce ideas and code back and forth. Some man hours, probably yours, to apply patches and integrate new features until such time as you hopefully have an active enough community to let others external to the company help maintain the code on their own time and dime. Be realistic and give them some negatives too, albeit with a positive spin, to show that you've thought things through and demonstrate that the benefits outweigh the expense.

Oh, and if you do eventually get the product GPL'd, submit the news to Slashdot as a "Slashback"; that should give your fledgling userbase and development community a running start!

Re:if that doesn't do it...

[rowama]

Tell the boss you couldn't possibly have done it without him; that he should take the credit for this bold and heroic act of selflessness. Make sure his name is all over it.

Believe it or not this type approach has worked for me in the past.

What kind of doc will you write?

[torpor]

I'll tell you what you should write: code.

Seriously, if you want to convince anyone of the 'superiority' of open source versus hidden source code, then simply write some glue code of your own which does something special.

That is to say, position yourself with GPL/OSS code in such a way that you prove that the open stratification of code, abstract on whatever levels you choose, is worth the effort. Write an app using GPL'ed API's that nobody else could've written, quite so quickly, if a deep and sudden understanding through direct study of contributed frameworks wasn't done first.

The way to profit from F/OSS begins with your own territory. Stake out a claim, find those who support your effort, apply their work to yours, and do it fast.

I wouldn't bother with 'reports' and 'presentations'.. thats all horseshit in the reality of "./configure ; make ; make install ; ./run" style working processes. GPL and F/OSS are about code and code is all about what runs, not what someone 'thinks' about it.

Face reality: it ain't good enough until you've added your bit.

Re:What kind of doc will you write?

[XO]

Well, that's a pretty darn good reason why most gpl developers fail miserably in the commercial software world....

Re:What kind of doc will you write?

[jmt9581]

What the hell are you talking about? The question isn't "Hey, can you motivate me to write some useful open-source code?" He already has code that he'd like to GPL. How can he convince his boss that this is a good idea?

That is to say, position yourself with GPL/OSS code in such a way that you prove that the open stratification of code, abstract on whatever levels you choose, is worth the effort. Write an app using GPL'ed API's that nobody else could've written, quite so quickly, if a deep and sudden understanding through direct study of contributed frameworks wasn't done first.

While those are some nice multi-syllabic words, you've missed the point. Convincing your boss to let you use use GPL/OSS code is not the same as convincing your boss that you should release your code under a GPL license. It sounds from the OP that he app he's writing is an internally used piece of software, which means that the source doesn't even have to be publicly available (until the app is distributed somehow).

GPL and F/OSS are about code and code is all about what runs, not what someone 'thinks' about it.

I disagree with this as well. Don't you think that the perception of OSS affects how many people will run it and how it will be used? Think about it this way: if I wrote a paper that inspires my boss to allow me to open-source some of my code, doesn't that benefit the open-source community? If I can code open-source software at work, doesn't that result in more open-source software being written? Isn't that a good thing?

I think that code is very important, but I think that a myopic view of source as the end-all be-all of life is disturbingly myopic. Especially for those of us who live life in the real world, with jobs that pay in real money.

Re:What kind of doc will you write?

[torpor]

How can he convince his boss that this is a good idea?

i guess you don't know what stratification means. he can convince his boss its a good idea by showing him how, working together with other GPL'ed code, he was able to work better and faster...

Re:What kind of doc will you write?

[jmt9581]

i guess you don't know what stratification means. I understand the meaning of the word. It generally refers to the separation (conceptual or physical) of a group of objects into their separate components (or strata). It's often used in geology, meteorology and statistics has a context-dependent meaning associated with the environment in which it was used. I'm assuming that the strata you're referring to are disparate software layers, many of which can be GPL. That's not the issue.

The issue is that you didn't address a single point that I made in my post, so I'll break one down for you: showing your boss that use of GPL software increases productivity does not clearly support the argument that your software should be GPL. If I were your boss and you made this argument to me, I would say: "Great! Use all the GPL software you want!" Nowhere in that discussion would I think about letting you release your software as GPL or open-source.

Businesses are driven by bottom-line performance. You can fart around with concepts of software "wanting to" be free all you want, but until you can provide concrete evidence that releasing open-source software benefits your company's bottom line, I wouldn't expect to work on open source software at work.

Other threads have provided some good arguments for releasing OSS. Here's some of the ones I like:

• Releasing open-source software can stimulate adoption of a platform, which can later be leveraged by other software products at the company.
• Open-source software allows external programmers to add features and fix bugs in software.
• Testing can be done at a reduced cost by setting up and monitoring a mailing list or forum.

I'm not saying that you're wrong, I'm just saying that you're not making a compelling case from a business perspective.

Re:What kind of doc will you write?

[torpor]

if your boss can't understand that the productivity gained from sharing your code with others is as easily represented by your own case as it is for the flipside, then he's a stupid boss.

if you can't say 'look, here is a project that is only possible because people shared code', and 'shared code means more productivity, as this project demonstrates', then, just perhaps .. you should be a document writer, not a coder.

stuffy case making and argumentation aside, the only real test of GPL is the effect that GPL has on the productivity of a particular project .. because GPL isn't about keeping secrets, its about revealing all secrets, far and wide, and allowing those secrets to be improved upon in as productive manner as possible ..

My boss was pretty cool about it

[vsync64]

He even let me set up a Web site to host some projects that we've made from scratch (more on the way) as well as just submitting patches to existing software. As far as convincing, it wasn't hard:

• He already knows a little bit about open source (although he did complain about how TightVNC "ripped off" VNC), and said that he's seen firsthand that good software can come out of that process
• Fixes and enhancements for things we use internally
• A chance that if I get hit by a bus, someone else out there has already used the code and can be hired to help
• Recruiting tool to technology people; shows some of our techniques, style, discipline
• Increases our perception as a participant in the community, thereby making people friendlier when we ask for help, enhancements, etc.

The real question

[Zphbeeblbrox]

The real question here is why did you wan't to GPL the code if you didn't already see tangible benefits to doing so. Don't get me wrong I love Open Source. I use it all the time in my job and at home. But if you don't already have tangible benefits in mind toward opens-ourcing the code then why did you want to open-source it in the first place.

Or were you asking for benefits your companies exec's would understand? That may be a trifle more difficult to expound upon since we don't even know what your company does.

Re:The real question

[jakobgrimstveit]

The reasons for me wanting to GPL it was answered here.

And yes, what I need is good boss-convincing arguments besides what I've already outlined.

My company does not sell any IT products (we're in the shipping business).

Re:The real question

[Gorath99]

Does your code give your company a competitive advantage over the competition? In other words: is it something that could (directly or indirectly) convince a potential client to choose your company over the competition?

If so, then it will probably be hard to convince your CEO to open up the code. He will be worried about your competitors using your code against you. Rightly so, if you ask me. That's not to say that GPL'ing is necessarily a bad idea, just that's it's something that should be considered very carefully.

If not, then things are a lot easier. The usual arguments of (potentially) free testing, free coders and good PR should prove convincing. After all, there's little to lose and a lot to gain.

why did you want to in the first place?

[mister_jpeg]

It sounds like you wanted to GPL the code for ideological purposes. If that's the case, there are plenty of GPL zealots around here who will show up sooner or later.

I think it would be more productive if you would share a practical reason for GPL'ing the code, if you had one.

Re:why did you want to in the first place?

[FLEB]

For one personally-selfish reason, you would be opening it to yourself, along with everyone else, allowing you to extend, reuse, and keep it beyond your scope and tenure at your company.

Re:why did you want to in the first place?

[vettemph]

> plenty of GPL zealots around here who will show up sooner or later.

Actually, we've been lined up at the door waiting for this one.

Relicensing

[Dioscorea]

Another potential positive aspect is relicensing. Some companies are so GPL-phobic that they will pay to have you (or your company) give them a one-off, non-exclusive waiver, so they can use your code without the (perceived) GPL albatross hanging round their necks. I've worked on open source projects (e.g. HMMER) that have made money this way.

Re:Relicensing

[FLEB]

How do you deal with community-contributed code in that case, though? Do you simply license out a version of only what you made in-house, without outside improvements, or is it covered in the license?

Re:Relicensing

[Dioscorea]

Depends... for the link I posted (HMMER), there have been very few contributors, and to my knowledge all have been bought off with pizza, beer and (as the s/w got more successful) plane tickets and hotel bills.

More generally, I suppose you would have to restrict the relicensed version to in-house code. (I've heard that Richard Stallman considers this suspect, but that might be a mis-statement of his position.)

Re:Relicensing

[simcop2387]

or what you could do is require that the code that is contributed be signed away to some entity that manages the gpled code, this would allow that entity to relicense it later. IIRC mysql and a few other packages do it this way.

Re:Relicensing

[Synbiosis]

Well, WashU does love money....

It's all upside

[bwt]

First off, there's no downside:
- It costs nothing
- It risks nothing, as there is no marketability
- The licence clearly states no warantee, no support

It's "fair" and good for "the community"
- You use open source, so you should "give back"
- Others may benefit from it, appreciate you
- If everyone takes cost free steps for mutual benefit, everyone will be better off

The upside is all positive:
- You may get help finding & fixing bugs
- You may get help enhancing it

It highlights publicly good work that your company has done
- Releasing code is comparable to publishing in a trade journal, and is valuable for the same reasons
- Associates your company, department, and you specifically with an area of expertise
- May place your company in higher esteem among the IT community, which helps hiring
- Generally, networking with others with similar business problems is good experience

Re:It's all upside

[jakobgrimstveit]

Thank you very much. This is a great start! This will be very nice to include.

What licence do you have on these ideas? :-)

Re:It's all upside

[EraserMouseMan]

zero cost? Unless he's going to do all the GPLing on his own time then his company has to pay him to do it and keep up with it on an ongoinng basis.

zero cost? Suppose the software is some sort of sales workflow process that gives the business an edge over the competition. GPLing the code would cost the company it's competitive advantage.

I know I'm gonna get modded down but the sad fact is that most people in a capitalistic economy don't see benefits from giving something away that cost you a lot to make.

The other fact of life is that whether you are a giver or a taker (over the course of your OSS life) is also a matter of perspective.

Here's an example. I'll play devil's advocate. Let's say you own an auto insurance broker company. You have 5 employees. I also have an auto ins. company and I have 5 employees also. We both pride ourselves on providing the best customer service possible and we are both OSS zealots. However, you have 2 of your employees dedicated to developing a proactive customer service website that has really pleased your customers. You also GPL the code every month. I download and install your GPL code monthly for my company.

Who's the giver? Well you're giving OSS code. But your customers are switching to my company because I'm giving much better customer support. I've got 5 people dedicated to customer support and you've only got 3. In the end I'm giving great customer support and you're giving great OSS.

Moral of the story: Can you blame me because I choose not to give OSS and as a tradeoff choose to give my customers the best service possible?

What do the slashdotters think?

Re: It's all upside

[gidds]

I'm not at all convinced by your claim about lack of downsides.

It clearly does cost something: the poster's time in tidying up the code, packaging it, releasing it, maintaining the web server or whatever he uses to distribute it. It may well also cost his time in answering emails, reviewing code submissions, merging in patches or maintaining a version control system, making future releases. (Of course, I'm assuming his time is worth something to his company...!) The web server or whatever may also cost time and money to get/support.

And there are associated risks: releasing code may potentially open them up to lawsuits for patent or copyright infringement. Depending on what's in there, it may even leave them liable for trademark infringement, libel, or release of trade secrets or other sensitive information.

Now, these costs and risks might in practice be very low, and outweighed by the benefits, but he needs to establish clearly that they are so -- which will probably cost more of his time, etc.

Re:It's all upside

[drsmithy]

- It risks nothing, as there is no marketability

You risk any competitive advantage the code gives you. This is a _huge_ issue to consider if the company is a market leader or experiencing strong growth due to the things its in-house software can do.

If some company is kicking arse and taking names in its market segment because of the advantages provided by in-house software, quite possibly one of the *dumbest* things that company could do would be to release that software to the world.

What's the problem?

[hahafaha]

You could turn to our good friend GNU Emacs for help. Just type in C-h-C-p. Or, if that doesn't work here are some reasons to use the GPL:

• It's risk free
• It allows competent people who do not have the opportunity to work for your boss to help your company along
• It opens the software to a broader scope of people

Best reason

[PunkOfLinux]

The company would not have to pay for bug fixes; just 'employ' the open-source community to fix the product for you!

duh! save money!

[larry bagina]

Think of all the money your company will save when they fire your ass and you work for free.

More seriously, it can build goodwill and be an effective means of advertising. Like Hans Reiser and the ReiserFS.

I agree...

[joto]

...with your boss.

If you can't find a coherent argument for why it's in your companys interest to release the source code under the GPL, then there is probably little reason to do it...

Then again, unless your company is in the business of selling "intranet/extranet portal framework"s then it shouldn't hurt much.

Apart from GNU ideology, the decision boils down to:

• Will it create good relations to someone the company cares about?
• Is the source code embarassing to show to others?
• Will the company actually benefit from other users sending patches? (and no, this isn't as clearcut as open source ideologes claim, see the question below...)
• Will this take significant amounts of your time that would be better spent doing other things that benefit the company more?

If you can find reasonable answers to those questions, a reasonable boss will make a reasonable decision :-)

Re:I agree...

[slamb]

Those are good questions. I'd add:

• Will it help your company attract excellent developers? (This is a specialization of your "Will it create create good relations to someone the company cares about?") Arguably, yes - people like to work places they know OSS is respected and where they know interesting work is being done.
• Will it improve the quality of your code? Patches are one way. Pride is another - people polish stuff much more if other people will see it.

Another Route

[pete-classic]

If the company doesn't feel okay about GPLing this piece of software, but doesn't really care about hanging on to it you might be able to talk them into simply disclaiming copyrights over it. One imagines that copyrights would then devolve to you, and you could GPL it.

Outside of that check out ESR's various works for "business minded" reasons to go "open source". He has particularly compelling arguments for just the sort of thing you've written.

-Peter

Simple Reason

[toolz]

"If you GPL the code, you are no longer at my (the sole developer's) mercy - even if I quit, you can be reasonably sure that the code will continue to be maintained and improved".

Sure, no guarantees, but that applies to anything in the world today (including job security :).

You want to do it, but why?

[artifex2004]

If you can't list reasons for yourself, having us come up with them for you is indicative that it's not such a hot idea.

So start by explaining what you want out of this, why you think GPL will be good for what you are doing.

Reasons to NOT GPL private code.

[WarmNoodles]

1) Assume, you're not as bright as you think you are
The security architecture flaws in the code will be revealed, exploits developed that with your self ingratiating credits attributing your handiwork to your company by way of email addresses with the companies domain and along with the unwitting conspirators names and emails who helped with the code all of which are very easy to track down using Google.

GPL Lesson 1
Do not attribute the code so that it can be linked back to the associates or persons or company you work for that uses it.
Do not gain personally from your companies work. It just smells like your trying to look good in the GPL community.

Assets of a company are company property even though you conceived developed and birthed the ugly baby, remember you're just its care taker.
Do you really need that much attention; are you able to keep up with and tolerate hands all over your pride any joy?

What happens if that encryption code you implemented, you know the one with the name "Base64_encryption() turns out to NOT be encryption at all, but no one bothers to tell you for 6 months?
You and your company could suffer irreparable damage to the public's opinion when all their accounts are stolen from your base 64 encoded databases.

Lesson 2 if you still have to enlarge your ego,
Get a large consensus of reviewer in company, including legal department, and at least one officer of the company before anonymously releasing your baby into the world.

By eliminating the perception of self ego ingratiation, you will gain true respect( A harder commodity)

If the resulting GPL release could ever be traced back to theft of records, the SOX and HIPAA folks would roast those responsible.

But the best reason to forget your idea, is simpler then all of the above.
If god wants your source code GPL'd he will accommodate you by way of haxxors who will know if your code is good enough to publish better then you do when they see it.

--
Why did the haxxor cross the road? To bit to the other side..

Re:Reasons to NOT GPL private code.

[An Onerous Coward]

All I can say is, "Huh?" And further, "Huh?"

Note to moderators: If it takes three readings of each paragraph to figure out what the hell a poster is talking about, it's probably not worth modding up. I know there's this tendency to think that, if a post is more than three paragraphs long, the poster should be rewarded for all his hard work. But fight it.

If I understand your arguments correctly, you're basically saying the following:

1) Security through obscurity is a great defense. Don't even bother trying to defend this old canard. Security flaws have a way of coming out, code or no code. GPL'ed code almost always gets much more positive, constructive attention from people looking to use the code in their own systems than negative attention from the black hat crowd.

2) If the author's company GPLs this code, and somebody out there gets data stolen because of problems in the code, the author's company will be held legally liable. Please, please, please show me one legal case where a company has been successfully sued for flaws in its code. If this was a legal possibility, it should already have happened to some company that was charging money for their code, rather than giving it away in such a way as to disclaim all liability (as the GPL does).

Since I haven't seen Bill Gates out on the freeway offramp with a cardboard "Will Code for Food" sign, I think it's up to you to back up your assertion that this is a reasonable concern.

3) If the code is worth GPL'ing, all the author needs to do is wait for some "haxxor" to break into his website, recognize how cool the code is, and GPL it for him. Just how big a fool are you? Only the copyright holder is able to GPL a work, and I don't think anyone in the world cracks websites for the purpose of doing code reviews on them.

4) You keep rambling incomprehensibly about how GPL'ing code is nothing more than an exercise in ego gratification. Well, maybe it is. So friggin' what? Sure, it's gratifying when somebody uses my code rather than going and re-implementing basically the same thing. Yeah, it's gratifying when your work saves someone else hundreds of hours of work. That doesn't mean we should withhold it because we're afraid of looking like glory hounds.

In summary: I find your ideas intriguing, and would like to subscribe to your newsletter.

Re:Reasons to NOT GPL private code.

[maxume]

Go upstairs and tell your mom that you have been using the computer too much.

Re:Reasons to NOT GPL private code.

[dhasenan]

"Security flaws have a way of coming out, code or no code."

This is true for popular products. Note that the article was asking about a framework over existing libraries; it probably isn't too vulnerable, no more so than its components, and his company obviously isn't a top software company. The chances that there will be a targeted attack on it that probes deeply enough to find flaws in that...well, by then, the company's pretty much screwed anyway; the attacker will find a way in.

On the other hand, if there's a flaw and the code is published, with references, any script kiddie who sees the exploit will think it's fun to go to the originating organization and haxx0rz their b0xx0rz.

So the sane way of GPLing the work, if it's obscure (and it is), is to do so without being traceable to the originator.

Re:Reasons to NOT GPL private code.

[WarmNoodles]

Want another reason to mod this up, how about real life examples.

Here is Real life example of where you are proven wrong.
http://64.233.161.104/search?q=cache:h-1fz6LRxFsJ: mail.zope.org/pipermail/zope/2002-June/117241.html +%40bankofamerica.com+base64&hl=en

And with about an hour I could easily document 30 more nearly identical real life Whuupses.
Now if we didint have google to show us all the idiots you'd be quite correct but we do.

Had this fool not connected his company, email servers, passwords and lack of authentication up to his code, he would be completely OUT of MIND not obscured.
His systems are MUCH more likley to face attack (which are likley to be successfull) not becasue of his stupid code, but becasue HE is!
This Moron at the Bank of America published not only the source in a base 64 zip attachments any child could decode. He follow up with which servers use no authentication, no password needed its in the zip.

This is not about GPL'ling vs or convincing your boss on merits its bout not committing carrier limiting moves BY HOW you DO GPL your code.

How you GPL it is much more important that the code or the GPL it's self.

How did I find the above security abomination by Googling for @bankofamerica.com base64 , it's on the first page half way down.

I have had several other real life experiences in coders compromising their companies. With respect to security I have personally been witness to by way of programmers GPL'ing code huge confidential information disclosures due to GPL and poor brain use by the GPL'ing coders.
.
This fools code his email finding its way to Google has made his systems a lot more vulnerable. And IM sorry I can't blame Google, so I have to blame the coder with the small ego.

Obscurity is not the same thing as knowing how and when to keep your mouth sgut and your email address private.
Had he not disclosed who he is and who he works for the same email would have had virtually NO VALUE given the same content.
He has identified the server targets by name which we would not know the meaning of but because he she disclosed its a bank system they have inherently larger value.

Now the because this moron is blathering their code, server names, passwords, associates names, non use of authentication we DONT know if its related to a GPL ego trip but this is exactly what I have seen when coders DO GPL their code.

The risks include direct hacking, blackmail, spear physhing.
This is not a theoretical risk.

Follow my previous advice and the chances of stepping on your own dick are greatly reduced should you want to GPL company code.

I didn't say code should not be GPL'd. I said HOW its GPL'd will make the difference between day and night!
If I forwarded the link to Bank SOX auditors(I have those email addresses handy) this moron would face investigation, suspension, perhaps firing.
We don't know and I don't care about this cases particular circumstances.

Google hacking for code is common, books written about it. Look it up on slash Dhot.

--
Hacking is what happens between the lines of code.

Read the GPL

[hubertf]

Have your company lawyer read it, then.
And then think again if it's whaat you want.
Maybe BSD is better for your and your company's future goals (which neithe you now your company may not know today!).

  - Hubert

Never tried, but

[dtfinch]

Ask "Is keeping this closed going to make us money?"

If it won't, and it's something that others (not your competitors) may find useful, then you may as well GPL it, to let others discover the bugs before you do.

Re:Never tried, but

[thebatlab]

Don't forget to also ask "Is opening this up going to cost us money"

If the answer to both questions is no, it's pretty cut and dry whether to release it or not.

My boss was an easy sell

[MarkusQ]

It's also a good way to have somewhat of a "short list" pool for future relevant hiring. It could allow the company to easily assess the person's work, and the potential employee to already have a relationship (however small) with the company.

My boss was an easy sell, but I think it was basically this point that tipped her. Plus, we'd had reasonably good luck paying bounties and use a huge amount of GPL/MIT/etc licenced stuff around the office (gnu/linux, X, Apache, Mozilla/firefox, mySQL, Ruby, etc., etc.) so it wasn't a strange idea.

Basically, anything that doesn't incorporate confidential information, trade secrets, etc. is fair game to GPL where I work.

--MarkusQ

Re:My boss was an easy sell

[WebCrapper]

I can agree with this point. I'm helping start up a small business and we needed some software custom made since its barely out there (but still not what we needed.)

Right from the beginning, we decided that if we made this software OpenSource and just put our name on it, not only would it help businesses as a whole, but free advertising always helps us.

References to the company are in the code, on the website, our logo is on the website, etc... Its basically like IBM releasing something - you know they made it, but you can use it for free.

how about these

[Tom7]

Here are some easy bullet-points:

builds goodwill of a community (that may be your customers (?))

can result in free development work by hobbyists that use your code

allows you to legally make use of the vast library of other GPL code out there

a free alternative may supplant proprietary solutions of your competitors (see IBM's various contributions..); best if you have no commercial plans for your product

open source is a cool buzzword to have attached to your product and company at little cost

Of course, if you can sell him on FSF dogma, then there are loads of philosophical advantages, too.

Re:how about these

[An Onerous Coward]

Don't use the word "hobbyists". Say that the code will be reviewed by "other IT professionals".

Now, his code can already take advantage of any amount of GPL'ed code that he would like. It's only a legal issue when his company goes to sell the code. So I would refrain from using point #3.

Here is the overall argument I would use: "Mister boss, sir? We use a great deal of GPL'ed code here at XYZ Corp. If it weren't for open source, some of that code might have cost us thousands of dollars in licensing. The rest of it might not be available for any price, so we would have had to implement that functionality on our own and at enormous expense. In short, this company is much more productive and efficient because of the existence of a large library of freely distributed code."

"Now, the code we're suggesting should be GPL'ed is the result of hundreds of hours of labor. Yet it is very unlikely that we could capture that value by selling it. Frankly, we're not in the business of selling code, and it would be more of a hassle than it's worth to get into that business."

"In exchange for saving people those hundreds of hours, we will get their undying gratitude. Occasionally, that gratitude might come back in the form of good publicity, new customers for our products, etc. More frequently, it will come back in the form of improvements to our code base, such as security patches and new features."

"Our competitors? Admittedly, they'll have as much right to use the code as anybody. But remember that 'anybody' includes our customers, suppliers, and distributors, and we stand to gain when those companies become more efficient. Besides, this code isn't part of a process that provides us significant competitive advantages over our competitors."

"Finally, a properly managed GPL project (understand that there will be more to GPL'ing than just throwing a .tgz file up onto an FTP site) can leverage tens or even hundreds of developers. From a business perspective, it's like hiring developers who accept each others code as payment. We know you like paying your developers next to nothing; I just got my paycheck."

"No, sir. I guess it's not funny. Yes, sir, I'll be cleaning out my desk now."

Re:how about these

[Tom7]

Now, his code can already take advantage of any amount of GPL'ed code that he would like. It's only a legal issue when his company goes to sell the code. So I would refrain from using point #3.

Well, not just sell, but distribute. If this program isn't just for internal use--like if they are installing it at customer's sites as part of some service contract, perhaps, then they need to abide by the terms of the GPL if there is GPL code in there. He wasn't really clear about how they're using it.

But yes, I am unable to speak the IT-speak indeed.

Re:Legal verus Ethical

[Anonymous Coward]

whaa?

Sell it to them using language they'll understand

[phaze3000]

You need to put it in terms familiar to board members. There's no point trying to sell them some hippie "it's the moral thing to do, man!" ideal.

• It reduces the total cost of ownership (TCO) by getting other people to add features for free!
• It means people will work on the project for free, without falling foul of any of those annoying anti-slavery laws
• People around the world will be fixing bugs and adding new ideas for free
• The code will be maintaned for the company, for free.
• Source code audits will be done by third parties for free

If that doesn't work, you could point out that it won't cost them anything to GPL the code, but they stand to gain a lot.

Reasons

[Julian Morrison]

1) Savings on coder time, extra bugs fixed - in each case by external devs your company doesn't have to pay. Downside: unless your project becomes well-known, this may never actually happen, or not enough to pay for itself.

2) Code stability. You can sell services or derived products to third parties and tell them that the product is safe against your company going bust because the code is public. Downside: you then have to do the harder work of convincing the buyer not to "cut out the middleman" and implement a homebrew with the published GPL code. GPL code cannot be your only source of value!

3) Compatibility with 3rd party extensions. If you GPL, you get a license to merge in anything else GPL'd and thereby add maximum features for minimum effort. Downside: if you muddy up who has the copyright, you may not be able to un-GPL it (nor sell special-case licenses to users who'd prefer closed source)

4) Why not? If it's not a "strategic" asset but only an in-house tool for a secondary task, GPLing can't hurt. Downside: publishing code and dealing with bug-reports and user gripes can eat expensive dev time. If the business case is that marginal you may be forced to "publish and abandon".

You do realise that it will often NOT make sense to open-source the code? In particular, a "strategic" app, or one that implies sensitive info through its design, or one that presents a public face you don't want to be hackable. Or simply if your boss thinks "I can't spare dev time for this nonsense". Businesses aren't charities (unless you're tax deductible).

Re:MehFortune-100-America includes IBM, Sun, HP,..

[hadaso]

> In Fortune-100-America, everything possible must be stamped with a (c) or (tm) or patent#.

Fortune-100-America includes a few small corporations (E.G. IBM) that find it useful to contribute to open source. They don't do it because they "feel like giving away their property". They do it because they figured out it would produce more money for them.

So the first thing one should tell one's boss is "See, it's good for IBM!".

The point is not that if it's good for IBM it must be good for you. The point is that Releasing the code that you don't intend to sell as proprietary software might save you in development and maintenance (even if you do have a product that might be sellable, you still might gain more from releasing it and getting IBM to contribute in its development).

If your boss understands the reasoning behind IBM's contribution to to "free software", then the boss's reasoning would become "reasonable, as in evauating savings in costs. (Actually the experience emplyees would obtain in one open source project can save indirectly when it applies later to incorporating "someone else's" open source project into your company's infrastructure).

What can happen to a new OSS project?

[mwvdlee]

1. Code is released under GPL, nobody cares, code is never updated and might as well never have been released.
2. Code is released under GPL, code is pillaged and partially moved to other systems leaving the original code obsolete and inferior.
3. Code is released under GPL and takes off as a succesful project.

Option 3 is least uncommon by far.

Unless you have good reason to think your system will be sufficiently popular to actually gather a community (remember; there is no OSS community; only individual OSS developers), you'll have a hard time making a business case.

Re:What can happen to a new OSS project?

[Dysproxia]

Option 3 is least uncommon by far.

So what you are saying is that #3 is the most common case? Weirdest double negative I've seen.

Re:What can happen to a new OSS project?

[mwvdlee]

Typo: "least common" or "most uncommon" would've been correct.

Re:What can happen to a new OSS project?

[timle]

switch (option)
{
    case 1:
        No biggie. Didn't cost you anything to GPL it, just nothing was gained.
    case 2:
        Again no biggie, you see the better system and switch to it, as it is GPL'd also.
    case 3:
        Much love from the community and features and bugs start getting some work.
}

I don't see a negative option in the bunch.
 

Re:What can happen to a new OSS project?

[StrawberryFrog]

Option 3 is least uncommon by far.

um, no. option 1 (or something close to it) is what happens to 90%+ of the stuff on Sourceforge. But this at least is better than the fate of 99% of comercial closed code, which eventually reaches the end of its use, is forgotten by the long-departed coders, and just dries up and blows away.

Sell 'em the beer

[carndearg]

My experience of corporate culture is that emotive arguments dont work but financial ones do. So dont sell them the free speech, sell them the free beer side of the argument.

I appreciate this goes against the whole spirit of something like the GPL but if you have to tell a few white lies to get something to happen then the important thing is that it gets to happen.

I'd sell it on the "Any holes will be fixed and new features will be created completely free of cost to you by a vibrant community that will spontaneously spring up around this wonderful product. And you the bosses at megacorp gets loads of wonderful PR that money simply cant buy from your public spirited action".

Yes. I know it's BS. But BS in a good cause.

Uhh....

[Anonymous Coward]

Slashdot has a compent crowd of which to speak? *drops joint*

Highlights a weakness in GPL

[pfafrich]

The viral nature of GPL may actually work gainst the goals of creating a global commons of reusable code.

Consider this senario: you want to convice your boss to open source. To do you could first show him all the other open source code which is available to use. Without the viral clause this would work fine, your boss would see all this code, use bits of it and a year down the line might actually consider contributing some of their own code.

The viral clause means this senario won't happen. Your boss will read the GPL and notice that by linking in that code they will need to also release their code under GPL. For an open source newbie this is not something he'll be willing to do. The consequence of this is that the boss will instantly dismiss the ideas of open source and never get to see the advantage. In essence the viral clause creates a block to acceptance.

To get around this block, hunt out LGPL code or the other open source licences which do not restrict the freedom to distrubute products incorperating open source code under their chosen licence.

Alternativly consider becoming a contractor. The rules of engagment of different here. As a contractor you have more freedom to develop your own code base. Employers pay you for the knowledge (and code) you have built up over the years and be more understanding of your need to continue building that.

p.s. Yes I know viral probably not the best term to use here (see slashdot passim), just can't think of a better term.

Re:Highlights a weakness in GPL

[drsmithy]

p.s. Yes I know viral probably not the best term to use here (see slashdot passim), just can't think of a better term.

The correct GNU/terminology is "freedom".

one possible method

[Anonymous Coward]

(lots of disclaimers apply)

from the two-wrongs-make-a-right department*:

if you need an app...

1) find one that does 75% of what you need
2) make needed changes, send back to project or release on your own

or

1) roll your own from other OSS
2) release on sf.net or whatever

either way, you then...

3) point to the package you created/modified; tell boss "hey, here's a package that does 95% of what we need!"
4) make final 5% of trivial modifications--fonts, colors, etc.

* more generously known as "what they don't know won't hurt them"

Probably too late for this project, but keep it in mind for the future. :-)

Ask him...

[seanellis]

That's what I did.

One of my team wrote a little interface wrapper between Ant (build system) and AlienBrain (source code management software), because he couldn't find one anywhere else.

I argued that, without the FOSS nature of Ant, we had saved money and it was therefore our duty to contribute.

The main stumbling block was that I had to show that this wouldn't materially advantage our competitors.

The final version is at http://sourceforge.net/projects/antab/ in case anyone wants to look at it.

Re:Ask him...

[Anonymous Coward]

The final version is at http://sourceforge.net/projects/antab/ in case anyone wants to look at it.

No one does, apparently.

Re:Legal verus Ethical

[Anonymous Coward]

You're a dickhead. There is nothing unethical about closed-source. Stallman can go fuck a goat.

My personal Method

[MrCopilot]

#1 Use GPL code & librarys to do rapid development.
It costs the company nothing & you get a near complete app which needs further development.#2

Impress him with the features and ease of use/cost.

#4 Explain that it must be rewritten at a significant toolkit/developer cost
or
for nothing, we can release it under the terms of the GPL.

His next question is what are our requirements under the GPL? Every CD ships with the source code, keep copyrights & GPL notices, done. In my case, He agrees, since we are a hardware house and his money isn't made with CD sales anyway but with device sales.

YMMV, he wants to know whats in it for him, NEVER FORGET Your time costs him money.

Raising all boats

[rfisher]

Simple. Infrastructure code is not a competitive advantage. If we don't GPL it, our others will simply build effectively the same infrastructure on their own.

If we GPL it, though, other people will adopt it instead of writing their own. We then reap the benefits of their improvements to the infrastructure.

And just to be clear: We aren't GPLing our code that makes us unique & that is our real value.

Not to mention the goodwill GPLing the code will generate for the company. Or possibly good press. Or the karmic benefits of giving back after having leveraged PHP & other open source code in building our business.

Credibility

[Anonymous Coward]

The only real advantage the higher-ups would consider is whether people who use the program would be people who are interested in whatever products your company sells. Open Sourcing a program is a good way to get your name out to people who may not have heard of your company's name (and make sure to put the name in the program to keep them happy, and the 2.0 release to say bad things about them because you got fired last week). The only problem is if your company doesn't have anything would be of special appeal to the open sourcers, then it might not make much sense. Heck, if they sell some product, could just call it free advertising. Yeah, yeah, we could talk all day long about linux, GNU, FSF, and the GPL, but the higher-ups' brains would have checked out long ago. That's the only really special appeal I could think of that they might consider.

Company or personal copyright irrelevant to GPL

[AHumbleOpinion]

My biggest hope is that my company doesn't enforce their "all your copyright are belong to us" policy ...

That's nice but irrelevant. GPL doesn't invalidate a copyright, it relies on a copyright holder to offer the source as GPL. Whether that is a person or a company does not matter.

... wherein every little unix script I write, no matter how small, and even if nobody at the company will ever make money off of it or even use it, can't be taken with me to my next job.

If you don't like the company owning everything you write don't take their money, their health insurance, etc. That's the tradeoff, every relationship has some give-and-take. "Size" doesn't really matter, why should the company spend time/money evaluating your code and scripts to determine what is worth keeping and what is worth letting go? And finally why you expect one employer to allow you to take something they paid for to your next employer?

As I programmer I understand being emotionally attached to what one writes but come on, be realistic. Sure I would like to have some of the stuff I wrote in the past but damn I sure did like those regular paychecks that never bounced and just kept on coming so predictably.

Re:Company or personal copyright irrelevant to GPL

[Anonymous Coward]

And finally why you expect one employer to allow you to take something they paid for to your next employer?

Because in the country where I live, we are not all lobotomized between jobs. When I move from one job to another, I am able to provide something called "experience" (When you grow some pubes, maybe you'll know what it means, until then make use of the dictionary for something other than getting your chin up to the level of the table), which includes EVERYTHING I've done in my life up to that point, including things that *gasp* someone else paid me to do. Said experience allows me to negotiate a better price for my services at the next job as I can prove I come equipped and ready to rumble.

Imagine a country where the army had to melt down all their weapons and tanks and stuff between each war. They'd never be ready for the next war, and end up doing stupid stuff like marching around in a desert without body armor.

Re:Company or personal copyright irrelevant to GPL

[AHumbleOpinion]

"And finally why you expect one employer to allow you to take something they paid for to your next employer?"

Because in the country where I live, we are not all lobotomized between jobs. When I move from one job to another, I am able to provide something called "experience" ...

When you fail to understand the topic in the first place a labotomy is not required. Clue: The topic was taking finished scripts and other source code to your next job, not the experience needed to rewrite new scripts and source.

... (When you grow some pubes, maybe you'll know what it means ...

Perhaps if you spent less time contemplating and inspecting pubes you wouldn't have your reading comprehension problem. Apologies if pubes are a national fixation in your country and I'm being culturally insensitive. Good luck.

Re:Company or personal copyright irrelevant to GPL

[gurps_npc]

Different programmers have different jobs.

Your logic works great if you work for software company X and are writing code that they sell.

It even works if you work for company Y and you are writing code at their request to be used by people in company Y.

But when instead (like me), you work for company Z that pays you to do job A, and to od that you need to write scripts, then that company has NO business taking the scripts that you wrote. They did not tell you "make this scripts" to do your job. They did not pay you to write those scripts. If you never wrote those scripts but did your work anyway, they would not complain.

But some companies think that just because they paid you that they have the right to take everything you made. That is bull crap. If they pay you to specifically do something, then they have the right to own code that does that. But if they pay you to do job X, then should own the software that YOU figured out would help YOU do the job.

Just as I own my car that I bought with my own money, even if I use it for work purposes, I own my scripts that I wrote, even if I use them to help me do my work.

If the company wants to own my car, they have to have paid for it. Similarly, if the companies want to own my scripts, they have to have asked me to make them. Otherwise, they are mine.

Advancement? I wish

[Austerity Empowers]

Engineers at my grade are required to file for 2 "company patents" per year as part of our yearly performance review. Not to get promoted, just to get an average rating.

US patents are not for us to pursue, that's a legal/business decision. We must simply supply the material, and the suits figure out where it goes. No one on /. would be shocked by the sheer crap that gets sent on.

It also says in our company code of conduct and in our IP accountability training, that we are not allowed to modify GPL code without VP permission. The reason is not that our VP is a soulless bastard, he's actually a very good engineer, it's that our shareholders are afraid that it "destroys the value" of our company. It's all tied into the new age of corporate accountability.

Re:Advancement? I wish

[Anonymous Coward]

It also says in our company code of conduct and in our IP accountability training, that we are not allowed to modify GPL code without VP permission. The reason is not that our VP is a soulless bastard, he's actually a very good engineer, it's that our shareholders are afraid that it "destroys the value" of our company. It's all tied into the new age of corporate accountability.

Who the hell cares? Do what you want. Have fun being an engineer. What they don't know won't hurt them. I work at companies that don't want me to take code with me. But I do anyway. Unless they've got security preventing you from doing so, then what's the problem?

Maintenance costs

[Anonymous Coward]

70% of software development costs are maintenance. If it takes off and others use it, and develop it, then you can go away and your company does not pay for maintenance.

seek first to understand

[the-build-chicken]

You're going to sde a lot posts about "show him the business reasons" and "make a business case for it" and "find a company that's currenlty benefiting from open source and share that"...and they're all great reasons if you want to spend the next 2 years convincing him (in which time your framework will be out of date and worthless).

Or you could take a couple of steps back and think a bit about human nature. Most people (99.9999%..ok, I can't back up those stats) will take 2 years to make a logical decision and 2 minutes to make an emotional one (yes, even CEOs)...and what's the biggest emotional motivator? Fear!

"Hey bob, did you hear company X (where X is a random competitor) is open sourcing their framework?"

Now forget all about it, go have a coffee, when you come back to the office you will miraculously have one of upper management not only giving you permission, but actively directing and tasking you on his/her new "open source vision"...which he/she will sell as their idea, which is a double bonus, because if anything goes wrong it's not you in the firing line, however if it all goes right then people know who wrote the code :)

Niccolo would be proud :)

Re:seek first to understand

[Anonymous Coward]

Not really. What would happen is the boss will pop upstairs and pass on the news.
"So, I guess we don't need that programming guy when we can get X's stuff for free?"
"Guess not. Shame, but theres no use carrying dead weight".

Tax write off?

[vwjeff]

This is just a thought.

I'm not a tax law expert but could a "code donation" be considered a charitable donation. Figure out how long you worked on the project and determine the monetary value.

Tell them that using GPL code reduces their costs because you do not need to "reinvent the wheel" every time you work on a project.

Technically you don't need to release any changes or additions you made to GPL'ed code if you keep the project in house. If your employer does allow you to release the code, you can always argue that there will be "free labor" from developers in the community. In reality, most projects on Sourceforge get little help from the community. Many projects go unchanged after they are posted. This does not detract from their value. There have been many circumstances where I have found a project that fits my needs but the maintainer is no longer active. These projects are often a great reference or starting point for a new project.

If your employer still does not allow you to GPL your work tell them you will not use GPL code in future internal projects. You can tell them future projects will take longer because you will have no base to work off of. More time and lost productivity from you.

Re:Tax write off?

[Anonymous Coward]

If your employer still does not allow you to GPL your work tell them you will not use GPL code in future internal projects

Yeah, real professional. If Mommy won't give you a lollipop, throw your toys out of the pram.

Re:Tax write off?

[vwjeff]

Yeah, real professional. If Mommy won't give you a lollipop, throw your toys out of the pram. My logic here has a point. You clearly don't see it since you posted AC. BTW, what is a pram? If the employer does not want to GPL the code, you must assume they will be selling or distributing the program in the future. The company would then need to make the code available to be compliant with the GPL.

Re:Sell it to them using language they'll understa

[drsmithy]

None of this things you've listed are even remotely guaranteed to occur. At best, they're optimistic assumptions.

If that doesn't work, you could point out that it won't cost them anything to GPL the code, but they stand to gain a lot.

Ot could cost them their competitive advantage in the market place. What sane businessman would give that up ?

What is this, a religion?

[Anonymous Coward]

Count yourself lucky it's got as far as the CEO. It wouldn't in most companies - and for good reason. They paid you to write that code for them, not to give it away to a community. The rules are different now you're a professional.

I suggest starting your own company - not only will you be able to GPL any code you like, you will also learn first-hand why it's a stupid idea, in most cases, to GPL code that you are hoping to earn a living from.

Go at it from the other end.

[gurps_npc]

Explicitedly ask:

"What benefit would we get from NOT GPLing this code".

1) Our competitors will not use it. Hm. Is this code REALLY that fantastic that competitors would WANT to reuse it? Yes I know, we all like to think we are coding Gods and that all should bow down to own superior code. But truthfully, the competitor will instead say "I have no need for that/already got one."

2) Other people will not be forced to pay us to use our code. Were they going to anyway? Ask to see profit projections for the code.

2) Trade secret. (Coke formula for example.) Companies like to keep secrets cause that way they look smarter than I are. Again, bullcrap. Pepsi has NO interest in stealing Coca Col'as formula. People read Dilbert, they know how foolish an inept the company is. Keeping "trade secrets" for image purposes just does not work, while gaining a reputation for publishing GPL actually does increase your rep on the street.

Re:Go at it from the other end.

[Sigma 7]

"What benefit would we get from NOT GPLing this code".

That's basically a limited analysis. What you forget is that any piece of code can immediatly improved on and suddenly generate a small profit stream. As soon as it is released, the cahnges are easily made withoit help from the company, this sealing off that source of potential revenue.

While there are ways around this problem, they generally require planning beforehand (e.g. source release scheduling).

Besides - a lot of people haven't read the GPL fully enougd te understand it's ramifications. There's bound to be at least one newbie lawyer or administrator that thinks nothing can't be dane against code obfuscators.

But truthfully, the competitor will instead say "I have no need for that/already got one."

Do you know that for sure?

R&D costs cannot be recouped as easily. Any competitor that needs to cut back will explore existing software before attempting to write their own.

As a variation on a theme: "Give a man a fish, you feed him for a day; teach a man to fish, you created competition."

2) Trade secret. (Coke formula for example.) Companies like to keep secrets cause that way they look smarter than I are. Again, bullcrap. Pepsi has NO interest in stealing Coca Col'as formula.

Of course Pepsi isn't interested in Cake's formula. However, this does not mention other companies that would just love to get a boost in sales with something like counterfeit Coka Cola.

There's plenty of arguments for GPLling code - the trick is finding some that work best for the business. Anything else is BuckShot reasoning.

How I succeeded

[brlewis]

When I went from MIT to another employer, I succeeded at being able to GPL code I wrote here using my essay about Solving the Buy vs Build Dilemma.