Forgot your password?
typodupeerror
Programming Businesses IT Technology

Properly Contributing to Open Source While on Company Time? 400

Posted by Cliff
from the avoiding-the-SCOrn-of-your-superiors-isn't-a-WASTE-of-time dept.
egeorge asks: "I was wondering what kind of paperwork/policies developers have at their jobs concerning contribution to open source projects. I develop software at a company that derives almost its entire revenue from software. Some software is licensed to customers, some is run internally in a service model, but the software is our whole business. We have recently been doing more and more modification and customization of open source products, and we would love to give some of this back. As developers, though, some of us are a little hesitant to just start flinging code that technically still belongs to the company out into the world. We want to make sure we get clarification about what is or is not covered by our NDAs. So, what kind of procedures do other developers have to go through to get adequate coverage for Open Source submissions? I would like to suggest a policy to my superiors, and could use a few good suggestions."
This discussion has been archived. No new comments can be posted.

Properly Contributing to Open Source While on Company Time?

Comments Filter:
  • Simply put: I don't. (Score:5, Interesting)

    by Vengeance (46019) on Thursday June 05, 2003 @12:57PM (#6124939)
    I'm a consultant, paid for my time and the IP I develop. I would not dare to risk cross-contamination by doing anything more than downloading and using open-source packages at the office.
    • Re:Simply put: I DO (Score:4, Interesting)

      by pubjames (468013) on Thursday June 05, 2003 @01:00PM (#6124975)
      Well, sometimes I will be working with a OSS software package and I see a way to make a little change to make it better, or fix a bug. Why should any employer/client worry about that?
      • by dreamchaser (49529) on Thursday June 05, 2003 @01:07PM (#6125041) Homepage Journal
        Because you are doing it on their time, not your own.
        • Re:Simply put: I DO (Score:3, Interesting)

          by Anonymous Coward
          but if what your doing is only helping you to perform your job better, what's wrong with that?
          • by GoofyBoy (44399) on Thursday June 05, 2003 @01:35PM (#6125283) Journal

            Then you should have no problem in formally writing up to them what you plan to return to the Open Source project.

            Outline exactly what you intend to send the maintainer and why it benefits your job/the company.

            Just don't do it because you can't see why you shouldn't. Your boss might have a different opinion.
      • by Ngwenya (147097) on Thursday June 05, 2003 @01:16PM (#6125135)
        Well, sometimes I will be working with a OSS software package and I see a way to make a little change to make it better, or fix a bug. Why should any employer/client worry about that?

        Vicarious liability, for one reason. Your employer (in most jurisdictions) is at least partly responsible for your actions whilst you are in their employ, and on their time. It hardly seems fair for them to be expected to assume liability without having the capacity to mitigate it, does it?

        And all the disclaimers in the world won't help you if a case can be made for malicious code being deliberately released - your company would still be accountable.

        --Ng

        • by 1u3hr (530656) on Thursday June 05, 2003 @01:33PM (#6125267)
          And all the disclaimers in the world won't help you if a case can be made for malicious code being deliberately released - your company would still be accountable.

          Legally sound, but immoral and practically insane. The same argument could be made for preventing you from doing almost anything you don't have to do, regardless of how public spirited.

          And in particular, when in the history of this world, has "malicious code [been] deliberately released" as part of an OSS?

          The upside for the company is an increase of good will, which transates into sales.

    • by Ngwenya (147097)
      I'm a consultant, paid for my time and the IP I develop. I would not dare to risk cross-contamination by doing anything more than downloading and using open-source packages at the office.

      Clearly that is your right - but I would venture that you are losing (or at least lowering) one of the essential values of Open Source: the ability to lower support, development and maintenance costs by having them amortized amongst the various businesses that to whom you might consult.

      Moreover, I have yet to see a rep

      • It's part of my personality naturally, and when navigating the American legal system, it's an asset.

        Essentially the facts are as follows: I code for fun, and I code for money. When I'm coding for money, there are expectations, and those expectations include copyrighting the code. When I code for fun, Eclipse generates GPL templates automagically for every source module I create.

        More than one fellow has tried to engage me in business ventures during work hours, but I'm always careful to defer all such d
        • by sharekk (654035) on Thursday June 05, 2003 @02:35PM (#6125784)
          This only works so well though. Many companies have small print that they basically own your brain while you work for them. Even IBM, which pays people to work on open source code has some paperwork for you if you want to work on your own projects. I believe it's fairly straightforward as long as you're not making money off something that looks a lot like your job but you Do have to fill it out. It does make sense from the company's perspective - they don't want to pay you to work on some propriatary code and then have you go home and use the expertise they paid you to gain to apply the same features to a free product that's their competition. Sadly I don't know the actual process one has to go through so I can't be of any help to whoever asked this.
    • What's the problem here if you are paid for your time?

      Just bill for the time you put in on submitting patches to GPL/Open Source software.

      It's a reasonable expense and you offer a more "standard" industry solution than a near worthless one man spagetti job of code that has no community or testing infrastructure (i.e. many eyeballs)

      If you are charging for IP... well here's hoping that when that horse and buggy goes into the crapper, you have a backup plan.
      • by Vengeance (46019) on Thursday June 05, 2003 @01:22PM (#6125171)
        It's not that I am charging for my IP. It's that the terms of my contractual agreement dictate ownership of work I create during my paid business hours.

        I personally do not have a moral or ethical quandary with opening up my development process, busting a hole in the firewall to allow CVS or at least SSH access, and making wholesale changes to open source projects on company time. I just don't want to be the subject of a 'Your Rights Online' story here.
      • by Chibi (232518) on Thursday June 05, 2003 @02:09PM (#6125589) Journal

        What's the problem here if you are paid for your time?

        Just bill for the time you put in on submitting patches to GPL/Open Source software.

        It's a reasonable expense and you offer a more "standard" industry solution than a near worthless one man spagetti job of code that has no community or testing infrastructure (i.e. many eyeballs)



        Try explaining to a client how you just charged them to add some functionality to something that will be used by others for free. It's great karma, but most suits aren't too interested in karma...

        Another problem is that most people are more interested in short-term costs. Look at all the publicly-traded companies that will lay off people in order to boost their stocks in the short-term. The only people that really care about long-terms costs are either people in direct ownership or people with some level of perspective. Most grunts these days are probably figuring they won't be around at a specific company for long (whether it's their choice or the choice of someone else). And the best way to look good quickly is lowering short-term costs...

    • by phamlen (304054) <`phamlen' `at' `mail.com'> on Thursday June 05, 2003 @02:07PM (#6125566) Homepage
      I'm also a consultant, working for a not-for-profit, and I added a specific contract clause allowing me to contribute to OSS.

      The big code issue for my client was that they wanted explicit ownership of the code. They didn't want partial ownership, or to give me the rights to reuse the code, etc. I wanted the right to reuse what I developed elsewhere. We ended up compromising with a clause that allowed me to contribute any "fixes or improvements" to open source code back to the community. Interestingly, they were quite willing to accept this clause at contract time.

      So I actually have an explicit contractual clause that allows me to contribute back. It makes me happy. :)
    • by mcrbids (148650) on Thursday June 05, 2003 @02:45PM (#6125859) Journal
      I'm a consultant, paid for my time and the IP I develop. I would not dare to risk cross-contamination by doing anything more than downloading and using open-source packages at the office.

      As a fellow consultant, I have a few questions for you:

      1) Do your clients require that *you* wrote it, or that the thingamajig works?

      2) Do your clients mind if sections of their codebase that aren't part of the core deliverable (libraries and the like) improve with time without further investment on their part?

      3) Do you read the licenses for the stuff that you develop in proprietary software to ensure that "contamination" is not happening there, too? Some of the EULAs for compilers and IDEs can be quite frightening when you actually READ them.

      I use *alot* of GPL and LGPL stuff in my work. The key is to ensure that the GPL stuff is called as an external process, (so it's effectively its own program) and the LGPL stuff sits in its own, separate file.

      I contribute changes and improvements constantly.
  • Copyright (Score:5, Insightful)

    by krisp (59093) * on Thursday June 05, 2003 @12:58PM (#6124950) Homepage
    As I understand it, as far as the copyright law goes, if you create it at work on your companies' computer, the copyright belongs to them.
    • by p3d0 (42270)
      That's why he's asking about paperwork and policies. If they sign a contract saying they don't own certain kinds of code, then that can supersede the "work for hire" copyright issue.
    • by agentZ (210674) on Thursday June 05, 2003 @01:04PM (#6125019)
      Not always. As an employee of the US Government, my work is not eligible for copyright protection in accordance with 17 USC 105 [cornell.edu].

      Thus, the programs I've written and been allowed to distribute are available as public domain. You can check out my programs for computer forensics and system administration, foremost [sourceforge.net], and md5deep [sourceforge.net], on Sourceforge.
      • by IncohereD (513627) <mmacleod&ieee,org> on Thursday June 05, 2003 @01:12PM (#6125096) Homepage
        Lucky bastard....Her Majesty the Queen of England of all people holds the copyrights on MY code. :)

        • But in exchange, you get full rights and privliages as a loyal British citizen!
          • Actually, Her Majesty the Queen of Canada holds copyright on stuff created by Canadian government employees. Canadians are not British citizens or subjects anymore; the current Citizenship Act defines Canadian citizenship as something distinct.



            When I submitted my Master's thesis, I had to give the Queen in right of the National Librarian the non-exclusive right to reproduce that thesis.

      • you're so fired (Score:5, Insightful)

        by joe_bruin (266648) on Thursday June 05, 2003 @02:55PM (#6125950) Homepage Journal
        if you were my employee, and you wasted your time writing 'md5deep', you'd be fired. this is a 5 minutes shell script.

        md5deep, reimplemented in shell, for your benefit. not tested, i'm sure there are some bugs. yes, it could use refinement, but this is a one minute job.

        recursion:
        $ find . -type f | xargs md5sum

        time estimation:
        #on my machine i get about 40 megs per second
        #using md5sum (openssl is faster)
        echo "`du -sk | cut -f1` / 40000" | bc
        • Re:you're so fired (Score:3, Informative)

          by gurudyne (126096)
          And, the shell script for Windows is????
        • Re:you're so fired (Score:3, Informative)

          by agentZ (210674)
          First, remember that I have a government job and pretty much can't get fired. [wink]

          Secondly, as somebody else noted, there is no default scripting ability in Windows. md5deep was originally developed a module for a Windows incident response tool called the First Responder's Evidence Disk (FRED). We have just obtained permission to make FRED public and will be releasing it soon. The linux/*BSD/OS X versions of md5deep were all ports written by people outside of the USG.

          Ironically enough, however, it was e
    • by brlewis (214632) on Thursday June 05, 2003 @01:09PM (#6125061) Homepage
      According to title 17, an employer owns the copyright to "a work prepared by an employee within the scope of his or her employment." I don't know the case law myself, but I wouldn't expect this to be measured by whether you're using the company's computer, any more than I'd expect they would hold copyright to all phone conversations made on company phones.
      • ..., but I wouldn't expect this to be measured by whether you're using the company's computer, ...
        It certainly would be a major factor if and when a company tried to assert copyright ownership to software created by an employee, along with things like whether the software in question was developed during business hours.
      • There are some contracts that broaden the IP that is passed to your company.

        (Also, phone conversations are, AFAIK, not copyrightable.)
    • Re:Copyright (Score:5, Interesting)

      by spazoid12 (525450) on Thursday June 05, 2003 @01:24PM (#6125196)
      It has nothing to do with copyright law.

      What you state is true most of the time, but not all, because of company policy.

      And...I hate it.

      They always pull the old "we own the computer, therefore" line. It's the same reason given for why they feel justified in reading your emails and such. Well, they own the phones, too, but they cannot legally record your calls without notice.

      A friend and I were talking about this a while back. We were allowed to play games at work from time to time, and so sometimes I did. He teased me that I played games on company time. Technically, that can't be said...because we were salaried employees. An extreme analogy would be: make me an hourly employee, and put a timeclock on my desk. I might clock-in and clock-out at intervals of only 10 seconds here and 2 minutes there. A salary employee is essentially doing that, but without the physical timeclock on the desk...just as a mental exercise. Therefore, a salary employee never plays games on company time... and, possibly, might always be free to develop his own ideas which might still belong to him... aside from the fact that he used the company-owned PC at the time.

      I'd better check with the carpenters that built my house... it's possible that they own the house, and not me, because they owned the hammers and saws used to build it!
    • Re:Copyright (Score:5, Interesting)

      by Spazmania (174582) on Thursday June 05, 2003 @02:52PM (#6125922) Homepage
      Yes and no.

      If you are an actual employee, paid a salary or paid hourly where they withhold taxes and social security and what not, then any work done within the reasonable scope of your employment is considered work made for hire, thus the copyright vests in the employer rather than in you.

      However, in almost every other circumstance, the copyright vests in you and must be explicitly transferred. This means that if you're a consultant, you own the work. Or if you're paid by the job, you own the work. Or if the work isn't reasonably within the scope of your employment, you own the work.

      Some examples:

      You are a janitor at the local school. While at work, you go into the computer lab and write the next Microsoft Windows. Who owns the work? You do. Although done on your employer's time and facilities, it was not within the scope of your employment. (Note however that the school can fire you and sue for misuse of facilities.)

      A local ISP pays you $1000 to write a spam filter. Who owns it? You do. You were not an employee of the ISP.

      A local ISP pays you $1000 to write a spam filter. You sign a contract which says, "I agree to write a spam filter and the copyrights belong to the ISP." Who owns it? You do. You can't assign rights to a work that hasn't yet been created.

      A local ISP pays you $1000 to write a spam filter. After writing the software you sign a contract which says, "I assign the rights to this software to the ISP." Who owns it? The ISP does. You did first, and then you assigned the rights.

      Here's a tricky one:

      You work (as an employee) for a company writing accounting software. You sign an employment contract which says, "All software I write while employed by the company belongs to the company." In your spare time you write a spam filter. Who owns it? You do. A court would find that the actual fact was that accounting software was the scope of your employment. The only software that's work made for hire (whose copyrights vest in the employer) is the software written within the scope of your employment. And, as previously mentioned, you can't assign copyrights for something you havn't written yet.

      What if you wrote the next Lotus 123? Then the company would own it. A spreadsheet is reasonably accounting software which was within your actual scope of employment.

      Here's a trickier one:

      You work (as an employee) for a company writing accounting software. You sign an employment contract which says, "I will assign rights to the company to all software I write while employed." In your spare time you write a spam filter. Who owns it? You do. That's right, you do. BUT, you have a valid contract with your company which compells you to write a document which says, "I assign the rights to this software to the company." If you fail to do so, you are in breach of contract.

      What about when the contract said, "All software I write while employed by the company belongs to the company?" Are you in breach of contract if you don't assign the rights? You are not. There was no requirement to assign the rights, on an element stating that the rights belong to the company. That element in the contract is contrary to the governing law. If your contract allows it (most do), that element would be severed from the contract. Otherwise, the entire contract would be voided.
    • Re:Copyright (Score:3, Informative)

      by Alan Cox (27532)
      It depends on the country and even in the USA the state. Its always best to have this on paper.

      My old one with I2IT. Sonix and 3Com basically said

      "If you are doing it on your own time and equipment, it doesn't interfere with work and it doesn't involve or relate to company trade secrets or business then fine"

      Which meant I had to keep out of Linux ISDN and bridging but that was IMHO fine. I2IT and Sonix were thankfully both companies that understood that they were making a net win out of the whole thing a
  • by autopr0n (534291) on Thursday June 05, 2003 @12:58PM (#6124957) Homepage Journal
    keep in mind the GPL allows for internal use of modified software without releasing the source code.
    • by dubious9 (580994) on Thursday June 05, 2003 @01:11PM (#6125086) Journal
      Yes, but its in your best interest to release your changes back to the communtiy so you won't have to manually merge code in later versions.

      When our company needed to use some open source, we had a meeting with the legal department. Basically what they said is that if it didn't contain any proprietary information relating to our line of business then we could release it. Since the project just converted xsl to rtf [jfor.org] then we didn't have to worry about it and got a green light.

      Since we've put it into production and release the changes we made back to the community there have been 3 releases that we don't have to maintain ourselves. The whole thing probably saved us about a man year.
      • Yes, but its in your best interest to release your changes back to the communtiy so you won't have to manually merge code in later versions.

        In fact, I believe you have the strongest argument for releasing deltas back to the community. Basically, the benefits of open source are generally the greatest with code that serves a widely used general purpose. Individual developers will do the porting work to new platforms or add specific new features. But everyone gets to leverage the larger body of code.

        Y

  • love? (Score:2, Interesting)

    by v(*_*)vvvv (233078)
    We have recently been doing more and more modification and customization of open source products, and we would love to give some of this back

    What does he mean by "love"? Does he have a choice?
    • Re:love? (Score:3, Informative)

      by finkployd (12902)
      Yes, if he is not distributing binaries, you do not have to distribute source code. You are allowed to modify GPL code for your own use without filtering the code back to the community.

      Finkployd
  • by stevew (4845) on Thursday June 05, 2003 @12:59PM (#6124966) Journal
    The first question that needs clarification in my mind is - Is your company distributing open-source code that they have modified?

    If that is the case - then if it is GPL'd code, you need to release it according to the license. If it is a BSDish license that isn't the case.

    Probably the best piece of advice - get your company to emit a policy on the subject. You may not like the results, but at least it will be a definitive answer.
    • The first question that needs clarification in my mind is - Is your company distributing open-source code that they have modified?

      If that is the case - then if it is GPL'd code, you need to release it according to the license.


      and let's finish that sentence...

      To the people you distributed the GPL code based item to. you do NOT have to give it to the world freely and willy nilly.. just to whom you distributed the binaries to... oh and hope they dont post it all on usenet, because you cant tell them not
      • Note: if you're "releasing" to entities within the same corporation (subdivisions and the like) you don't have to release any sources.
        • That's an interesting point. Are you at that point really safe from having to release the sources. I haven't read the GPL in a while. What's the definition of distributing, what constitutes a party involved in a distribution transaction?


          Obviously it's silly to think that distributing a modified OSS package to an employee entitles them to all the rights granted under the GPL, but it may be a loophole.

    • by wbattestilli (218782) on Thursday June 05, 2003 @01:16PM (#6125132)
      This is not actually true of the GPL.

      If they are making programs for internal use then they are obligated to release nothing.

      If they are distributing the code to another party, then they have to make the source available to that party.

      They GPL never says that they have to release the code to the public, however; the party receiving the above mentioned code would have the right to release it to the public under the GPL.

    • by Zathrus (232140) on Thursday June 05, 2003 @01:19PM (#6125156) Homepage
      If it's true GPL code and they're distributing it to outside customers, well, they're idiots. Because they now either have to remove the GPL code entirely or release the entire application under the GPL.

      If it's LGPL then they need only release any modifications to the library or other LGPL'd code they did. Or, again, remove the LGPL code -- presuming they're distributing it at all.

      If it's BSD or similar it's irrelevant, as you said, as long as they keep the copyright notices, etc. in tact.

      Essentially, check the license before you use the code and know what it means. We use a great deal of LGPL, BSD, and public domain code in our products. We stay away from GPL though -- we don't have any intentions of distributing at this point, but if we did we'd rather not have that problem.

      As far as remitting work back to the community - talk to your managers. If your managers are decent then they'll understand the issues involved. It may take some time, but most likely you'll be given the OK. After all, think about what you've modified in the code -- does it give any advantage to your competitors? Does it reduce the value of your product to your customers? Are the changes bugfixes or new logic that's only applicable to your company?

      Actually, we do have one GPL program that we've modified... vsftpd. Again, no plans on redistributing it, but if we did it'd be no problem submitting the changes. They're deeply specific to our company and our usage and would utterly screw up anyone else who used them (things like automatically assuming paths on puts and gets so our customers don't have to do cd, and automatically moving files on completion of transfers (which might be useful)).

      Do not work on OSS during company time though, not without explicit written consent. And many companies are now claiming anything you work on, even outside of work, to be their IP (which is on somewhat shaky grounds)... so if you want to work on OSS outside of work, check your contract and get a release from management if needed. Don't just do it -- in the worst case you're really, utterly screwing the project to the point where it may have to be removed from the net (at least officially). Most companies won't give a crap, as long as you're not doing it on company time and it's not competing with them.
  • Justin Frankel (Score:5, Insightful)

    by Transient0 (175617) on Thursday June 05, 2003 @01:00PM (#6124971) Homepage
    I think Justin Frankel [slashdot.org] would tell you that you can't ever be sure that you have any creative control over what you are doing on company time.

    The only ways to remain certain that you have complete control are to either work on your own or with a small group in a small company and then leave as soon as they get bought out by the big guys.
  • Charge for it. (Score:5, Informative)

    by Zaphod B (94313) on Thursday June 05, 2003 @01:00PM (#6124972) Journal
    Remember that open-source is not necessarily free-as-in-beer. Your company can charge for the source code and the binaries if it wants, it just needs to use an open-source license (insert heavily-compressed flamewar here).

    Also you can make quite clear that you will only support YOUR version of the product and that if they choose to modify the source they're on their own.

    If you're just talking about donating code snippets, well, then you need someone with more experience in that than I.
    • Remember that open-source is not necessarily free-as-in-beer. Your company can charge for the source code and the binaries if it wants...

      But the problem is that once your company releases the source to the buyer, that buyer can then redistribute it for free or for a minimal cost. So, in many ways, once the "cat is out of the bag", open-source is "free-as-in-beer".
  • by NoCoward (648971) on Thursday June 05, 2003 @01:00PM (#6124973) Homepage Journal
    Please read the following before committing your IP and company to Open Source:

    Open Source Doesn't Make Economic Sense For Most

    The open source organization has presented a few cases that supposedly explain why OS works economically. However, if you examine the cases objectively you will find that the cases are flimsy and non-specific and do not address any specific concerns. They attempt to bolster their case by pointing out a few "successes", among which Caldera and Red Hat are displayed as shining examples.

    The real economic question of the OS model is how is money made, and who is making the money. Who is being rewarded financially for the enormous development effort? The open source initiative claims that there are at least four different models that allow someone to reap rewards. Oddly, it is not mentioned that it is not necessarily the people who did the development work that gain financially.

    The four primary business cases mentioned by OS proponents are "Selling Support", "Loss Leader", "Widget Frosting" and "Accessorizing."

    The first case proposes that money can be made via selling support for the free software product. This is by far the strongest case and is proven to work, for a few small companies. The two companies that are shown as positive examples of this business model are Red Hat and Caldera, who distribute and support the Linux operating system. What is never mentioned is that neither of these two companies has contributed significantly in relative terms to the Linux development process. Its important to note that using this business model, the people that make the money are usually not the ones who have invested in the development process. So much for the strongest case.

    The second case is based on the idea that you give away a product as open source so you can make money selling a closed source program. This also can work, but it should be noted that the money is being made off the closed source product and not off of the open source. An example of this model would be Netscape, who gives away the source code of their client browser so the OS community can do development, but keeps their "cash cow" products completely closed. Obviously, this case may only work if you have a software product that lends itself to this sort of "give away the razor and make money on the blades" system. The truth is that the vast majority of software is monolithic. So much for the loss leader case.

    The third case, "Widget Frosting", sounds completely practical. The premise that hardware makers produce open source software so that the OS development community will work for free to produce better drivers and interface tools for their hardware products. It sounds great on the surface, especially for the company that produces the hardware: they get free drivers and do not have to pay for expensive developers. The OS community wins by getting presumably stable drivers and tools. What is not mentioned is the reason hardware makers usually don?t do this is because they do not want to reveal trade secrets regarding their hardware design. Production of efficient drivers requires an intimate knowledge of the hardware the driver is for. It is almost always the case that it is in the hardware developers? best interest to keep their hardware secrets close to home. This also brings up the question of why isn?t hardware "open"? So much for the frosting case.

    The final case, "Accessorizing", is similar to the first, but throws in the idea of selling books and complete systems with the open source software, and other accessories as well. It is obvious that selling books qualifies as support, and that it really belongs in the first case. The idea of selling computer systems, T-Shirts, dolls, again begs the question: "Who is making the money?" As with the first case, it is not necessarily the people who have done the development work. Additionally, the question of how much money can be made selling books, t-shirts, mugs, etc, is never answered. O?Reilly Associates is frequent
    • This from a person who puts his home page as Netscape.com? Your home site (employer?) is the first commercial company (probably) to have released their product to the open source community.
    • by BrynM (217883) * on Thursday June 05, 2003 @01:11PM (#6125082) Homepage Journal
      THIS DOCUMENT CAN BE RECOPIED AND REDISTRIBUTED WITHOUT RESTRICTION, HOWEVER ADDITIONS/MODIFICATIONS/CORRECTIONS SHOULD BE LABELED AS SUCH WHERE THEY OCCUR.
      So are you saying that this document is Open Source/Public Domain? By your standards, I shouldn't have wasted my time reading it then and someone shouldn't have wasted their time writing it. Though it may have very important points, the stance of the document reeks of FUD.

      By the way, who is "The open source organization"?

    • Why did somebody mod this as offtopic? Just because you don't agree with it doesn't mean it's off topic. How can an article related to open source in the work place be off topic here?

      That said the article missed an important benefit: I call it open source framework. The idea is to use open source in your project wherever possible to save on man time then compartmentalize your proprietary code so that it isn't in violation of whatever license the open source used.

      Now you are getting free updates to a c
    • Repost (Score:5, Informative)

      by Anonymous Coward on Thursday June 05, 2003 @01:25PM (#6125204)
      It seems [slashdot.org] you've posted [slashdot.org] this article (from 1998 [felter.org], not 1999) a few times already.

      Do you work for Microsoft [slashdot.org]?

    • by ThogScully (589935) <neilsd@neilschelly.com> on Thursday June 05, 2003 @01:35PM (#6125280) Homepage
      I feel like a fish catching a hook, but I'll reply for a bit. First off, this is off-topic. This story is about someone using opensource software in business services and wondering how to contribute changes/improvements back to the community while keeping his company's IP separated.

      Second, open source models for profit are not based on the sale of the software, so since opensource companies don't sell their software, don't assume they aren't profitable. You don't credit Red Hat and Caldera with any development, but they most certainly do contribute and make their money off of both support and the package they sell their OS in. They prepare everything for a user to have a complete OS and that requires many tweaks to everything for uniformity and integration. They also develop and maintain OS updates as patches become available so their users can update their systems.

      Your discussion against why opensource software is not better than commercial is only in talking about how gcc is not up to par with commercial compilers, but you haven't proven that point. As a cross-compiler, I'll bet gcc is probably one of, if not the, best out there. I guess it won't compile as well for a P4 as an Intel designed P4 compiler, but those details are tough to notice and not so applicable. Then your argument here trails into how there aren't enough qualified contributors in the opensource world to make competitive software, while I would suggest that there is more qualification in the opensource world. Since you didn't support your argument, I won't support this to save space and at least match the convincing-ness of your argument.

      You say that opensource software was not responsible for the internet's success, but open protocols were. The first step was open protocols with clear definitions. The next was software to implement them, which is still largely opensource. Apache, BIND, sendmail are always at the top of the list and I promise if you turned off every Apache, BIND, and sendmail server right now, you wouldn't bother trying to use what's left of the internet.

      By the way, how does Netscape's contributions to opensource help them make a profit? I've never felt inclined to buy Netscape's enterprise servers simply because I use Mozilla.

      And this document won't be recopied or redistributed by me, as I'm not as willing to make a fool of myself like you have. But then again, I did bother to write this long reply.... oh well.
      -N
    • Plus, it gives you piles, cirrohsis of the liver, bad breath, ring-around-the-collar, and worms.

      Stick with raw greed as your motivator. Greed makes you taller, cleaner, healthier and more sexually attractive!

      In the "unlimited greed" model, it doesn't matter if contributing to OSS makes your world better, because you must NEVER EVER EVER give anything away -- even if you don't need it, and can't profit from it -- because charity by definition is bad!

      SO, to be truly greedy, don't help OSS projects make be
    • It is easy to see that the foundation of the Internet was built on open protocols.

      Factually inaccurate.

      Yes, IP, TCP, and UDP are open protocols, as are most of the protocols built on top of them (telnet, ftp, dns, etc).

      But the single most prevalent TCP/IP stack, from which virtually every existing TCP/IP stack is inherited, comes from BSD, which is open source. In fact, the litmus test for being able to connect to the Internet was whether or not you could communicate with a BSD stack system, not whether
    • "The four primary business cases mentioned by OS proponents are "Selling Support", "Loss Leader", "Widget Frosting" and "Accessorizing.""

      You forgot a couple:

      1. Making sure of a good supply of poker chips. A healthy OSS movement is a good bargaining tool in contract negotiations with proprietary vendors.

      2. Never having to start from scratch ... it's easier/cheaper/faster to take an OSS program that is almost what you need and customize it then to start from scratch and write virginal proprietary code.

  • by Anonymous Coward on Thursday June 05, 2003 @01:01PM (#6124979)
    • Don't ask for permission. What they don't know, can't hurt them!
    • Be like Nike; Just Do It! Need to write a routine for the internal process? Just slap the GPL on top and release it on Sourceforge.
    • Make use of the resources available. Do you not have enough time to work on your own projects? Just circumvent the firewall and telnet to your home machine. The office is more comfortable, anyway.
    • It works the other way you know. Need a routine for an internal project? Just use it and release the changes.
    • If all else fails; lie. Claim it wasn't you. Cover your tracks. Call the BSA if you need a diversion in a hurry.

    Thats what I did when I was at SCO, anyway!
  • by Anonymous Coward on Thursday June 05, 2003 @01:03PM (#6124999)
    ...How to run an ebay business selling your company's items
    • ...How to run an ebay business selling your company's items
      Oh come on, who would do that? [ebay.com]

      --
    • It's too bad that the parent is so funny becuase it is the most insightful comment I've read so far. Although the problem has been obfuscated by talking about things like open source and developers and IP what's really being asked is quite simple (as displayed by parent). If I worked on someone elses farm I might have a very strong urge to box up a bunch of food and send it off to starving children in 3rd world countries. This desire is certainly altruistic. And I might have even tilled the fields and p
  • Well (Score:5, Insightful)

    by drinkypoo (153816) <martin.espinoza@gmail.com> on Thursday June 05, 2003 @01:04PM (#6125020) Homepage Journal
    IANAD (Developer) but it seems to me that you need to have a contractual agreement with your employer to allow you to contribute code written on company time back to the particular projects on a case by case basis. You are most likely to succeed if you go to them and say, "I have been downloading, customizing, and using these GPL packages, these are the nature of my customizations (...) and I would like to contribute the code back so that it can be reviewed and improved upon by others rather than by me."

    Ultimately, anything you've done on company time is owned by the company, and you have no rights to it whatsoever, NDA or no. Your contract may grant or revoke various rights, of course, where not prohibited by law. But I would definitely go in assuming that all that code belongs to the company and you have no right to distribute it without formal written permission.

    • I think the argument to make to your managers or to the legal department is "this code we worked on provides a useful component of some project or projects but A) It doesn't represent intellectual property that's core to our business itself and B) If we don't contribute the changes back to the community, we incur substantial additional costs of merging and maintaining our own separate code base for our version of the product." Point B is most likely of interest to your manager, and Point A is most likely o
  • This question... (Score:5, Informative)

    by jmu1 (183541) <{ude.uosag} {ta} {namllumj}> on Thursday June 05, 2003 @01:05PM (#6125024) Journal
    gets asked a lot around here. And the answer is always the same: Talk to your legal department. There isn't anything else you can do.
  • by DeRobeHer (76234) on Thursday June 05, 2003 @01:05PM (#6125029) Homepage
    When we're modifying open source programs for use in our environment, we try to come up with two different types of patches; patches that enhance the package wether they be with new features or bug fixes, and patches that are only there to support local conventions and tools. We rarely submit the local patches back to the development team of the package, but if we feel that the enhancement types of patches will help out the project, we'll submit them back.
  • by Anonymous Coward on Thursday June 05, 2003 @01:07PM (#6125046)
    the company i work for has a term of employment agreement that i had to sign upon hire. it specifies that the employee is forbidden (except by written arrangement) from participating in activities that conflict or compete with the company's business. Example would be contributing to open source software that competes with your company's product.

    these kinds of agreements is probably common practice.

    if in doubt, you can ask for permission. if you aren't granted permission, then you have a decision to make.
  • "I would like to suggest a policy to my superiors, and could use a few good suggestions."

    You do this: YOU DON'T!

    You're sitting in your cube hammering out some code for whatever company project you're working on and suddenly you realize that the code you just slapped together would be perfect to help [insert OS app here].

    What do you do?

    Do you take the (now) IP of a company project and give it to GNU and do it over the company wire? Do you do the (technically) "Right Thing" and not contribute th
  • by Dr. Zowie (109983) <slashdot@defore[ ]org ['st.' in gap]> on Thursday June 05, 2003 @01:11PM (#6125087)
    The work I do is mostly funded by NASA, under scientific grants. Every grant proposal I submit contains the words "All software and intermediate data products will be freely released to the general public" (or minor variations on that sentence). That way I'm actually required to release stuff, and the most restrictive license I can put on it is something like GPL (public domain would also work, of course). Haven't had any problems with management over it.
    • the most restrictive license I can put on it is something like GPL

      No you can't. GPL is based on copyright laws and as an employee of the US Government none of your works for it are eligible for copyright protection.

      The same is not necessarily true for 3rd parties or sub-contractors working for the US Government, but that depends on the contract.

      Public domain isn't a license... it's a state. Something is either copyrighted (in which case you can have a license) or public domain (in which case you can't,
      • Actually, I'm not an employee of the U.S. Government, I'm an employee of Southwest Research Institute. What we do is produce scientific results under contract to NASA (and elsewhere). The actual results that we produce are (I believe, but IANAL) required to be in the public domain, but the software tools and intermediate data products are certainly not: in fact, much of NASA's scientific work is done using proprietary, closed-source software, something I'm actively combating within my community.

        So, the

    • Not attempting a flame war over GPL, this is a general question about public funded software dev.

      I wonder, if the work funded by NASA must be released to the public, can it be released under GPL (or any other license) which adds its own restrictions?

      In other words, should it instead be released with no restrictive license at all instead of one that prevents some uses or business models?
  • by Saucepan (12098) on Thursday June 05, 2003 @01:12PM (#6125089)
    From past experience I've found that asking upper management for permission to contribute code results in them hemming and hawing, thinking about it for six months, and eventually just saying "No" when pressured for an answer.

    This makes sense when you think about it from their risk-averse perspective: releasing even small pieces of otherwise-useless specialized code is all downside and no upside.

    On the plus side you might might improve goodwill with a small number of open source developers. But on the minus side you might be exposing the company to liability, accidentally revealing sensitive information, or inadvertantly helping your competitors. Plus, management always has to worry about shareholders second-guessing them -- possibly resulting in a shareholder lawsuit -- if the IP you give away is later perceived to have been very valuable.

    Given all this, a dangerous but more pragmatic idea might be to just go ahead and contribute at least the small stuff like your patches and bugfixes. As long as you have no official policy forbidding this you can point out that it's just the standard way things are done when working with open source tools.

    Let me be clear that I am not actually advising anyone to do this. More just.. thinking aloud.

  • Lawyers (Score:3, Insightful)

    by truthsearch (249536) on Thursday June 05, 2003 @01:12PM (#6125092) Homepage Journal
    Considering it's a software company, hire a lawyer. Developers alone should not be making these decisions where a company's fate is at stake. Hire a law firm who specializes in software and/or copyright, go over everything with them, and then make up policy. It's not smart to not consult a lawyer in this case.
  • What! (Score:5, Funny)

    by PS-SCUD (601089) <peternormanscott@y a h o o.com> on Thursday June 05, 2003 @01:12PM (#6125094) Journal
    I'd never do something so dishonest as to develop OSS on company time. I just look at pr0n and DL some music on Kazaa ;-)
  • Empirical evidence suggests that, if a safe way to release work-produced code exists at all, it's to get an ironclad release statement written in blood and signed by the CEO and the company's legal department.

    In short, I wouldn't try it. Convince management to do it, and make sure there's a paper trail.
  • A cautionary tale (Score:5, Interesting)

    by Anonymous Coward on Thursday June 05, 2003 @01:13PM (#6125105)
    I'm posting AC for my own safety. I made changes to an open source package for my employer. Since the changes were for an internal package (we didn't release binaries to the public) I was told by my boss that submitting the changes to the package maintainer would be a violation of my NDA. I discovered after I left the company that my changes were eventually submitted to the package maintainer, and that my boss had taken credit for them.

    The moral of the story: get the company policies in writing before you start making changes to an open source package.
  • Do the Right Thing (Score:5, Interesting)

    by hobbs (82453) on Thursday June 05, 2003 @01:16PM (#6125134)
    Of course, defining the Right Thing will in the end be up to your managers, but influencing their opinion is important.

    First off, do they realize what value they are already getting from open source, or was that snuck in the door? The former would make life easier (for everyone, since more PHBs will realize the value of OSS).

    One thing you don't want to do is to sneak behind your boss' backs and contribute what is unarguably company IP back to OSS without their permission. This can cause headaches down the road that could have been avoided.

    Setting criteria for contributing back to OSS that you are enhancing is much easier than releasing OSS in the first place (IMO), and, yes, I have worked for enlightened companies that blended both well. It all depends on what your company does (industry focus) and where it values its IP. Generally though, if you have just enhanced OSS, returning those enhancements should be a no-brainer (and required by some OSS licenses). Again, that is really a no-brainer only if management knew you were using OSS in the first place.

    For major enhancements, try to value it from your company perspective. If you were (eg) a video codec software company and had just made changes to a BSD video codec that gets 10x compression improvement with no quality loss, is it really worth your while to release that back immediately? I know some will argue that all software must be free, but how many of them are gainfully employed based solely on the free software that they develop (read: I don't think the model for just selling support sustains itself). IOW this isn't intended to start religious wars, just to make you think about what IP really has value to your company, and what you should be more readily willing to share.

    Completely new software that you might want to release under and OSS license is similar to the above. First off, if you company isn't OSS aware, make them. Then discuss what things you don't want to release for core IP reasons, and what is good to release.

    Remember that just releasing code doesn't raise the jollies of most corporate types. It usually has to have a purpose, and company brand awareness is a large part of that. Making or enhancing OSS software can be very good guerilla marketing for a company. It's perhaps not the same as dot.bomb hype levels, but it still has value for brand awareness, recruiting, etc.
  • Get it in writing! (Score:4, Informative)

    by tundog (445786) on Thursday June 05, 2003 @01:20PM (#6125166) Homepage
    We want to make sure we get clarification about what is or is not covered by our NDAs

    IANAL but here goes...

    This one is kind of obvious to me, but an NDA is an Agreement between two or more companies that basically says 'I'll show you mine if you show me yours' and legally binds each party not to tell anyone else about it. I try to avoid these because I'm always paranoid that the other company will tell me something I'm already working on and later try to stake a claim on what's mine.

    Simple answer to your question: Before you send ANY code into the public domain get your boss to sign off on EXACTLY what you are releasing. Otherwise, even if you get the OK you could be in hot water later if your boss backs out on you.

  • Merging (Score:5, Insightful)

    by EnglishTim (9662) on Thursday June 05, 2003 @01:20PM (#6125168)
    I would have thought the best approach is to suggest that you submit the patches so that you won't have to go through the pain of merging your changes in every time you want to get a new version of the software. If you phrase it as something that will help your productivity, I'd have thought they'd be much more likely to agree.
  • by Anonymous Coward
    Gates has already done that.

    If you and/or your company are using OpenSource/GPL software in a beneficial way and you make improvements to the GPL code it would be in your/your companys interest to release your improvements to the community. After all, if you grazed your cattle on the commons would you sell the fertilizer back to the community that gave you free grazing priviliges or would you leave it on the commons to fertilize the grass so other cattle have grass to graze? Gates would collect it as "IP
  • Read the license of the code you are modifying. Simply put, the modifications may not "belong" to your company. If the company accepted source code to modify and that source's availability was conditioned on the publication of modifications, then there is an obligation imposed by the license to release the modifications.

    Call this a self-serving statement by one of those fscking IP lawyers, but your company should consult with a lawyer who knows software licensing, knows source code issues, and can advise

  • I work for a web hosting company (www.hagenhosting.com) and we use basically all open source software to manage our systems. We recently started using an open source web mail client that works very well with our mail setup and in the process have made many changes to it (though I am still not done with all my changes). Once I get all the changes done and am happy with the quality of the code I changed I will be returning the code back to the original author. This is the first time that we have modified o
  • Can't you just use (Score:2, Insightful)

    by vasqzr (619165)

    Can't you just use a psuedonym? I mentioned this in another post.

    If the patch or software is released by "Thor the C Coder", who's the wiser?
  • I'm not a legal expert, but I assume that all changes are made while you are working at the company. This means the copyright of the code belongs to the company. If you want to publish your patches, you need a formal decision by the company management for doing this. Notify that if you modify code under the GPL and distribute that code to a third party, you are required to publish it with the complete source. Please make sure, that every decision is documented and signed by the legal responsible persons. K
  • by Medievalist (16032) on Thursday June 05, 2003 @01:34PM (#6125269)
    Alan Robertson [linuxjournal.com], who maintains the heartbeat [linux-ha.org] package and works for IBM [ibm.com], recently posted to the ha-linux [linux-ha.org] list [progressive-comp.com] on this subject.

    Alan does not accept patches to the heartbeat code that were developed on company time unless he receives a disclaimer [theaimsgroup.com] from somebody at the company.

    This is obviously spoofable, but it's probably a good way to legally protect the code -- Alan can honestly say he received it in good faith, which keeps IBM's lawyers' from breathing down his neck. It's kind of weird for me, though, I have to send a disclaimer giving myself permission to send in a patch....

    So, to answer your question: explain to your CEO why helping the OSS community helps you to help your company, and get her/him to sign off on a policy that allows you to do so. Ask for legal authority to be delegated to yourself (or your boss) to license or assign corporate intellectual property to open-source projects. Then have HR propagate the policy to your co-workers.
  • Careful! (Score:3, Interesting)

    by Austerity Empowers (669817) on Thursday June 05, 2003 @01:45PM (#6125372)
    When I joined my present employer [bell-labs.com] I had to sign a big page of legal nonsense about not joining competing companies for 3 years after I quit/get-fired. I also had to sign away that every single thing I do (including this post) while employed here is company property. At work, at home, all times of the day... To legally release open source code I would have to write it, convince our legal department that it's useless to the company [lucent.com]. After about a year or so of fighting very unintelligent executives I may be given permission to own my work, and thus release clean, GPL code.

    So if anyone wonders why nothing good ever gets done from our company, this is why.

  • by Samrobb (12731) on Thursday June 05, 2003 @01:45PM (#6125373) Homepage Journal

    Where I'm working right now (TimeSys [timesys.com]), I've been involved in contributions to Eclipse [eclipse.org] and Cygwin [cygwin.com]. Here's some advice:

    ASSUME THAT YOU ARE NOT ALLOWED TO RELEASE ANYTHING WITHOUT PERMISSION.

    If there's no clear policy already in place, ask. You probably don't have the authority to act as an agent of the company with regard to making decisions about IP. (If you don't know for sure whether you have that authority or not, you should assume not until someone tells you otherwise.) Keep pushing the suggestions/requests up the chain of command until you reach someone who has the authority to say "yea". They may still tell you "nay", but at least you'll be getting a decision on the matter instead of an "I can't make this decision, I don't want to bother my boss, so I'll just say no" response.

    START WITH SOMETHING SMALL.

    In my case, it was getting permission to submit patches to correct bugs - very small, very simple, very non-threatening things. The argument was that we could submit the patches, or go through the pain of developing the same patches again with each new release of the software we were using. That's a good way to get the foot in the door: show that there's a benefit to submitting patches that outweighs any perceived risk. If you can show that you spend X days out of every release cycle generating the same ol' patches again and again, it's an even more convincing argument.

    DON'T PUSH TOO HARD.

    For some companies, this is a big step to take. Let the folks who make the decisions think about the idea, answer their questions honestly, and be persistent without harassing them every day about the issue. You don't want to have them tell you "no" just so you'll quit bugging them.

    BE HAPPY WITH WHAT YOU GET.

    I don't mean that when you get the first "no", you should give up. You need to be reasonable in your expectations - IMHO, submitting patches for bug fixes is fairly minor, and the reaction to that request should give you an idea of how receptive your maangement might be towards the idea of more substantial work & contributions.

    My employer lets us submit bug fix patches freely for one project, at the developer's discretion. Minor feature additions in the same project require approval, which is generally easy to get. Other projects require management approval for all patches, no matter waht. Some projects that require copyright assignments are still in the "we're considering it" phase, and may never be approved. We've contributed at least one large chunk of original code to a project, and are considering doing it for a couple of others, as well, because while we want the software to have feature X, we don't want to have to maintain feature X. That's a pretty good argument to try if you're trying to get approval to submit a patch that adds a feature or functionality to an existing project :-)

  • Get it in writing (Score:3, Interesting)

    by kjs3 (601225) on Thursday June 05, 2003 @02:31PM (#6125757)
    Having spent lots of money with lawyers over this sort of thing...


    First let me say that there is a distinction between "what is right" and "what is legal". Many things that are not legal are right, and vice versa. I'm not interested in getting into a lot of "but that's not right!" arguments; I'm simply relating what the legal realities are as I understand them.


    The only way to really be safe is to write down exactly what it is that you intend to contribute and get an officer of your company (or other superior who clearly has the authority to commit the company) to sign off acknowledging that the company will make no claims against your contribution. Stick to what has been agreed to, and get written addendums if there is "scope creep" on your open source project.


    If they won't sign off in writing, you can assume that they will take action of some kind against you if you decide to do it anyway. As my lawyer used to say "contracts aren't for when people are happy with one another". Might be a good idea to look at other options (of employment, if you're committed is to your OSS project).


    I would also note that unlike some wildly misguided people I've heard recently, you cannot simply take something you don't own (in the legal sense), release it with a GPL notice on top, and be free and clear legally. Sure, that code can't be "called back", but you (and people who use your code assuming you had the right to apply the GPL to that work) might very well find yourself in court. Ownership of the code (and thus who has the right to determine the license) is determined by the contract you entered into, and the courts will decide your fate based on that.


    Be aware that some employment contracts state things to the effect that anything you do "in the field" can be claimed by your employer. Thus, just because your contribution is done on your own time with your own equipment, you still could be liable for action. Know exactly what your employment contract says (hopefully you did that before you signed it). Have a laywer (your own laywer) explain it to you if you aren't very familiar with contract language.


    Also note that simply not signing an IP agreement does not automatically absolve you of its terms. Look for other employment paperwork that says things like "by accepting employment you implicitly agree to all our required employment contracts". I've definately seen people bit hard by this. If your employer has an IP agreement, then negotiate the terms you want and sign that so that all is tidy and legal. Again, consult your own lawyer to know exactly where you stand.


    Know your rights under state law. Different states have wildly different interpretations of the strength of employment agreements. Contract language which would bind you up in one state might very well be tossed out as onerous in another. Consult a lawyer.


    You do not want to litigate over this; you want to avoid putting yourself in that position. Even if you win, it's generally very expensive, annoying, frustrating and you'll often as not loose the job as a result. Don't sue "on principle" unless you know you have enough money, time, etc., to survive the process (including the possibility of loosing...no matter how strong you think your case is, the legal world is bizzarro world, and outcomes are not always deterministic). Special Fact - generally, if you sue your company (e.g. to claim ownership), and they decide to countersue you (say, for breach of contract), you won't be able to drop your suit (even if you run out of money), unless the other party agrees to it. Hint - they won't unless you back down.


    Lastly...do not simply take your managers verbal word that there will be no problems. Get it in writing. There is a doctrine of "verbal contracts" (I suppose "implied authority" also plays here) under the law, but they are difficult to make stick, especially if the other side is determined to invalidate it. OTOH, "Paper has a perfect memory", as one of my old biz partners used to say.


    N.B. - I can speak only for the U.S. There are different subtleties elsewhere...

    N.N.B. - IANAL, nor do I want to be...

  • by sir_cello (634395) on Thursday June 05, 2003 @02:39PM (#6125810)

    * you mention that you are currently customising open source software, does this mean that you are legitimately honouring the licenses associated with that software ? if not, then that should be your first step. the choice here is simple: either honour the license, or don't use the software. this may require you to make available your modifications.

    * you really need to write up a business case: why is in the companies interest to do this ? will it be "pr" ? will it cost ? will it cause legal (liability) issues ? will others run with the software and turn it into something better (free labour for you) ? does the work required (to package, make available, etc) outweigh the costs ?

    You need to answer these questions in an intelligent and reasoned way before someone else (i.e. your engineering manager / etc) is going to allow this to occur.
  • Similar situation (Score:3, Informative)

    by thelenm (213782) <mthelen.gmail@com> on Thursday June 05, 2003 @03:00PM (#6126014) Homepage Journal
    There was an interesting PerlMonks discussion [perlmonks.org] about a very similar question not too long ago that you might be interested in reading.
  • by Jboy_24 (88864) on Thursday June 05, 2003 @03:44PM (#6126457) Homepage
    With the current SCO hub-bub, I think every developer who thinks about submitting code developed at work and every developer accepting new code from outside developers realize that the code you are submitting is the property of the company you work for!

    Ultimately its there decisicion, if you feel like doing it without permission to 'Help' the open source community you are actually hurting the project and community almost beyond repair.

    Unless you get writen signed off permission from someone who can give permission, 5-7 years from when you submitted the code, your company can still claim ownership to that data. Right now your boss may say "go for it!", 5 years from now, you and him are probably gone and forgotten, yet the company can still sue the project you submitted to because it contains their property.

    Please, please if your not sure, don't submit!
  • by chrysalis (50680) on Thursday June 05, 2003 @04:01PM (#6126602) Homepage
    Here's what _may_ work :

    Start the project at home, out of your working hours.

    Make it GPL'ed. As a public proof, you can release an initial public beta version.

    Back to your company, continue to work on the project. Any addition made to it must be GPL'ed as well, isn't it? So even though you are working on it while on company time, you can always release the product as free software.

  • by phliar (87116) on Thursday June 05, 2003 @04:03PM (#6126617) Homepage
    That's the gist of it. It's easier in a small company, of course -- if the hacker knows the CEO personally it's much easier to get the sign-off. You can actually make the case that it's an excellent marketing statement, and they're more likely to be able to hire the good hackers if they seem aware of hackers' sensibilities. In a large company it's a pain in the ass -- the legal dept. gets involved and they really don't like unfamiliar situations. In their view, the company gets nothing from it; why should they risk any liability, however small?

    Even code you write on your own time -- you don't want the company to later be able to claim that you used their "intellectual property" -- your general knowledge of projects at work -- while writing that code. Perhaps I'm just paranoid, but I make sure to either get my free software activities acknowledged in writing before I accept a job, or not work on free projects that may be related to the stuff I do for hire.

    But most important, don't do it without actual legally binding authorisation from your employer (not just your boss). It's critically important that all the free software out there really is safe for everyone to use.

  • by raw-sewage (679226) on Thursday June 05, 2003 @04:20PM (#6126770)
    This is slightly off-topic, yet somewhat related... What about contributing ideas or concepts to open source that were developed at your place of work?

    A co-worker and I were having this discussion with regards to the SCO vs IBM case: say I'm developing some technology at work, a state-of-the-art journaling filesystem for example. Now I go home at night and work on an open source journaling filesystem. All the code between work and open source projects is separate (i.e. absolutely no code sharing). However, there are certain concepts and ideas that I will inevitably borrow from my work project and put in the open source project.

    Now we have a potential SCO vs IBM situation on hand: my company finds out that there is some open source using very similar technology (to their own patented or copyrighted work). My company is going to want royalties for this!

    Although a lot of us open sourcers are taking the SCO vs. IBM situation lightly, if it does happen to go in SCO's favor (either by court decision or settlement), it's sets a precedent for companies to go scouring all open source code for possible IP infringement. This will scare corporations away from open source in a heartbeat.

"Hello again, Peabody here..." -- Mister Peabody

Working...