Slashdot Mirror


Explaining Open Source Software

scubacuda writes "Mark Webbink, Red Hat's general counsel, has written an informative article explaining free and open source software. Geared towards attorneys, he explains the various licenses and addresses several myths about OSS." One to bookmark.

12 of 182 comments (clear)

  1. Great overview! by linux_user_31337 · · Score: 4, Interesting

    This article is exactly what I need to explain open source to my dad, a lawyer. It's especially difficult getting the concepts behind open source across to him now that I'm writing open source code (BSD license, no less) for a *living*.

    Thanks again, Groklaw. It's so wonderful having some lawyers on *our* side!

  2. Eh? by Film11 · · Score: 1, Interesting

    I really don't see whats so hard to understand about OSS. It's free and its meant to be distributed and you can edit it, but you've got to give credit to whoever made the orginial version. It's that simple. Well probably NOT that simple, I'm no OSS guru, but I think it's like that...

    --
    ):
    1. Re:Eh? by cubicledrone · · Score: 4, Interesting

      Water is free.

      Water is a $5 billion industry.

      Seems simple enough.

      --
      Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
    2. Re:Eh? by Anonymous Coward · · Score: 1, Interesting

      Poor analogy. Water is an industry because it requires purification. Purified water cannot be "copied" ad infinitum.

      Open Source, on the other hand, can be. A "purified" Open Source program not only can be copied, but under the guidelines of licenses like the GPL must be made copyable for free. After the purification of the product it may be distributed at will by anybody who gets their hands on it.

      A business model derived from profiting from an Open Source product is flawed. While the originating entity can sell the first copy that copy may be copied and distributed freely. The Open Source business model depends entirely on three things: donations (in the form of actual money or in the sale of tangable novelties like plush penguins), services (such as the sale of support or custom development to businesses) or hardware (such as a router or total solution server where the real product is something tangable that cannot be copied and the Open Source accompanyment is simply a nicety.)

      Anyone who claims that there is money to made selling Open Source software is daft. There is money to be made, but it lies elsewhere.

    3. Re:Eh? by fozwinkel · · Score: 2, Interesting

      FSF claims, in their FAQ and the preamble to the LGPL, that any linking to a GPL library makes the whole program derived. However, they do not give reference to any statute or judicial interpretation that supports their statement. IMHO, linking does not necessarily make a derived work.

      I decided to distribute my library (tkgeomap.sourceforge.net) under the GPL with some trepidation. It is a library, and I worried that FSF's statements about linking would scare away proprietary developers, who have helped me in the past. Then I noticed the GPL does not contain the word "link" anywhere in the license (just do a search). In my view, if your program falls on its face without my library, then it's a derived work. If your program is still functional without my library, and my stuff just adds some optional features, then your program is independent. For example, if you have a big database program that occassionally spits out latitudes and longitudes, and you add link in my library to draw some maps with them (that's its job), but your database program works fine without maps, then the database program is independent, and exempt from my distribution requirements. I would still require you to GPL any modifications TO MY WORK needed to enable the link, if any, but the main program is all yours. I would objectively say that if you can load and unload my library during runtime, you are independent. If the linking is static or startup-dynamic, there will be gray areas.

      That's my opinion, which isn't backed up by statutes or precedents, either. All I can do is indicate circumstances under which I might make a complaint, which is how most legal boundaries are set, anyway. I hope open source does not become a bonanza for lawyers. Hopefully, developers who use other licenses and end up in the gray area will contact me, and if need be, I'll issue a license amendment to the effect of "Copyright holder of library A accepts that program B uses the library but is otherwise independent, and therefore exempt from the distribution terms of library A." Court is the last resort.

  3. More ways to prevent people from doing their job by Brahmastra · · Score: 4, Interesting
    Here's one of the guidelines from the article:
    1. Do not permit the uncontrolled importation of software onto company computers. Do not permit employees to download freeware, shareware, or Open Source software onto company computers without first clearing the license terms with the legal department. At the same time, bar the use of proprietary software except to the extent that the company can account for the permitted licenses. In other words, know what you are putting on your machines--to do otherwise exposes your company to risk.
    At least for me, this would severly hamper my ability to do work. For example, I sometimes use perl to parse through MAP files. So, if I wanted to download a FREE version of perl and run it, I have to go to some lawyer to explain why I want to use it? I can think of a hundred other reasons this would be a bloody pain, and result in a lot of bureaucratic hassle for engineers.
  4. Excellent article, but long... by bc90021 · · Score: 3, Interesting

    ...and I think that any CXO of a "mainstream" company would have his eyes glazed over by the "Fundamentals of Copyright Law" section.

    I suggest excerpting the article, to start with the "Myths of Open Source Section", as that looks short enough for most CXOs to handle, and then go with the rest if the CXO expresses further interest.

  5. We need translation to and from legalese. by dexterpexter · · Score: 5, Interesting

    It should be obligatory that any person involved in deciding this case should have to read a writeup such as this one. All too often those making the decisions are as tech savvy as dung beetles. It has been successfully argued in court that a certain hacker (in the misused sense of the term) could not have possibly been responsible for a breakin because the end IP was not the same as his home one and that "IP addresses are like DNA. Identifiers that cannot be changed." When we have the technologically unsavvy making rulings on technology issues, how can we expect any differently? If this SCO case is won, it will probably be on the backs of people who can't figure out how to attach files to their emails.

    This has been long-needed. We demand that legalese be put into "plain English," should we not expect attorneys to require the same?

    We need Open Source and related licenses explained for dummies (pehaps a book, anyone? Open Source For Dummies), for the those of us knee-deep in all of this who have a grasp of what is going on, and for the legal entities who will ultimately decide the case.

    This case will never be won so long as people believe that SCO can claim .h files, error number listings, and parts of the C standard library because "they look the same as that 'er Linus thingy code", and as long as people continue to equate open source royalty-free software with an attack on capitalism. Perhaps in addition to an Open Source for Dummies, the courts need a Basic Programming for Dummies as well.

    Yes, we need more articles like this one.

    --

    *-*-*-*-*-*-*-*
    "We are Linux. Resistance is measured in Ohms."
  6. Re:More ways to prevent people from doing their jo by jeffkjo1 · · Score: 2, Interesting

    Clearly we all recognize the hassles that result from having to clear software with a 'legal' department, however, I think we've seen enough BSA attacks on businesses to know that it's necessary.

  7. beauty of the GPL by Anonymous Coward · · Score: 3, Interesting

    But which is riskier, licensing practices that are constantly being challenged or those that, in their simplicity and effectiveness, have avoided challenge.

    This is why the GPL, BSD, etc licenses are so wonderful. They are aligned with the user's needs. It's really tough to violate them as an end-user. You just download the software, use it, and you never even have to *accept* the license at all!

    Just like anything else in life.. you buy a car, the car company doesn't really care what you do with it. Now, if you take it apart, learn how it works, and start selling copies for half price, they might want to chat with you.. but only a very small percentage of car drivers would do that. Even the ones that do work on their cars do it for their own personal enjoyment. Same with the GPL.. hack as much as you want, just keep your eye on the terms when you start re-distributing.

    Once legal departments start to figure this out, free software will make bigger and bigger inroads. "Wait, you mean with FreeBSD we never have to worry about being targeted by the BSA? Whoa.. *mind blown*".

  8. Re:You missed the point ... by Fnkmaster · · Score: 3, Interesting
    And you need to talk to the legal department to figure out if you've properly purchased a copy of WinZip for your developers? Or whether emacs needs to be purchased before it's used? If issues that trivial can't be solved by a 10 second conversation between a developer and their manager, then your company is broken. Don't expect to be putting out product any time soon.


    There are certainly issues that do require discussion with a lawyer and conference with a legal department or outside counsel. If you plan on incorporating or using a piece of Open Source software as part of a product for customer delivery, your plan should definitely be vetted by legal, or if you are going to use a commercial enterprise software product with complicated license terms (think: Oracle, at least the way they used to do RDBMS licenses - they would sometimes lead small companies in to using their software than come back later and tell them they had misinterpreted their licensing terms and hit them with a $100k bill).


    So yes, unlicensed or improperly licensed software can be a problem in certain circumstances, but generally buying or using a general piece of software, open source or commercial, like a text editor, IDE, or other general purpose desktop tool should not require intervention of a legal department. I didn't say there shouldn't be an approval process to buy such things with company dollars, just that the approval process shouldn't require the legal department's intervention.

  9. Sorry, it's your misinterpretation. by Kjella · · Score: 2, Interesting

    "(1) those that apply no restrictions on the distribution of derivative works (...) and (2) those that do (...) ensure that the code will always remain open/free)."

    He's talking about derivative works. And derivative works of BSD code can be neither open nor free. This is the core difference between the BSD and GPL "class" of licences, and I find the classification good and the statement accurate.

    Like it or not, this is very very important to corporations. You might not care that someone else is profiting (as in $$$) off your work, that your code doesn't "disappear" through use, but companies do. They're all about making profit for them, not for anyone else. If someone else is going to make money off it, they want their cut.

    Alternately, they'd like to get compensated in another way - in form of the modifications others have made. The GPL licence is giving them a reason to release the code, the BSD licence does not. With the BSD licence, you're not guaranteed to get anything back - anything at all.

    Kjella

    --
    Live today, because you never know what tomorrow brings