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.
Lawyers on both sides! Thats how the world was meant to work!
Trying to use sarcasm in text-based forums does not work.
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!
Lawyer: You mean you *want* it to be free?
If my answers frighten you, stop asking scary questions.
On the subject of using volunteers versus paid programmers:
"Remember, amateurs built the Ark. Professionals built the Titanic."
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.
...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.
libertarianswag.com
I see your point, but free stuff makes people like the product, unless the said product is crap, in which case he will know this and just give up. However, if the product is good and useful, people will donate. Its a fact of life, you see it everywhere like here and here. Both those sites give something for nothing, and they manage to make a living perfectly well.
):
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.
.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.
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
Yes, we need more articles like this one.
*-*-*-*-*-*-*-*
"We are Linux. Resistance is measured in Ohms."
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.
And remember, once the GPL, MPL, Artistic License, etc, have been cleared through legal, anything under those licenses is no longer barred from downloading.
Best Slashdot Co
Actually the quote says "...without first clearing the license terms with the legal department."
So for example, don't let your employees use GPL software until you understand what the GPL is. Fair enough. After you approve the GPL license terms, people are free to use GPL software.
Did you interpret this to mean that you would need approval for each piece of open source software? Because yes, that would be a huge pain! I don't think that is what the guideline meant. Getting an open source license approved once isn't a big deal.
----- rL
a lot of bureaucratic hassle for engineers.
This is the entirety of justficiation for the existence of most "corporate" "departments." It's also a very efficient way to ensure universal mediocrity.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
Yes, that is definitely idiotic big-company-think. I think a manager should be responsible for informally overseeing or okaying use of random new tools. Using a tool is very different from incorporating source code, copy-and-pasting material, and doing something that creates a potential legal issue. As a manager, if somebody says they need Winzip, emacs, bash or whatever to feel comfortable and get work done, then more power to them. It should be made completely clear to them that they can't download source code or software from any source on the internet for use as a part of a product, runtime component or anything like that without approval from a manager and legal. Beyond that, there's nothing you can do but trust your employees, make the potential consequences really clear, and conduct regular code reviews to spot anything potentially suspect (primarily just to spot shitty, lazy code, but if somebody really cut and pasted a bunch of code, it would probably be obvious if you knew their coding style, your company's coding standards, and so on).
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.
It is a bureaucratic hassle, but it is a necessary one. Let's look it in a slightly different way: the lawyer has to support and defend the company's software use in court. This is basically a sysadmin type job: the network sysadmin defends the company's network from technical threats, and insures the smooth running of the network. To do this he needs to know what software is in use. The company's lawyer needs to defend the company from legal threats and insure the smooth handling of legal matters. To do this he needs to know what legal agreements the company is a part of.
Now, Perl should be a perfunctory check: can we use GPL software for development purposes? Yes, but make sure you don't use the code. Simple. Just like the IT department will want to know you are using a programming package, and have agreed to not write a virus to destroy the network. Why? Because they will get the calls when it breaks something, and they need the info to effectively do their job.
Help the lawyer do their job. It is as necessary in today's world as yours. Hampering them will just make them angry, and likely to want to retaliate by hampering you.
'Sensible' is a curse word.
(I have no idea what MS Windows is written in)
Windows is written in the lowest pits of hell!
; )
You can't take the sky from me...
The trickiest part of GPL-like OSS licenses to me is figuring out where the line on "derivative works" ends.
This is really a problem of copyright law in general and companies that collaborate (source only open to the parties involved) can get into trouble deciding who owns the resultant work, but most closed-source licenses are pretty simple: I can distribute object form only of the Metaware libraries, I can do anything with the input or output of their compiler (my code) and my work which uses their libraries is not considered a derived work (even though they're statically linked).
Linus has clarified where he stands on userland use of the kernel, but lately has made some odd statements about kernel modules distributed in binary form. There's also issues with libraries distributed as GPL instead of LGPL (e.g. the MAD mp3 decoder). If MAD is dynamically linked to my app, but both are contained in a ROM and the "dynamic" loader uses the simplified BFLT format, is my app still independent & not derived (so I can release source to MAD but not my app)? Does statically linking my app mean I must release its source???
How about an explanation that works for suits?
Something like this:
- Open source and free software is like disk space. You used to pay $1000 for 1GB, today you get 1Gb for $1.
- This is possible because the Internet has made communications so cheap that the traditional huge costs of making software - design, management and infrastructure - have been largely eliminated.
- "Closed software" businesses like Microsoft would very much like you to continue paying 1970's prices for software.
- But the fact is that your competitors are benefiting from high-quality free packages like OpenOffice, Apache, PHP, Linux, and MySQL.
- You should really be switching your IT budgets from paying for software licenses to paying for support and custom development: this is the best way to keep an edge in the market.
Every dollar spent on buying overblown commercial software that has a free equivalent is a dollar wasted. Are you sure you want to waste your money?
Ceci n'est pas une signature
Lighten up - This is the first I've heard of this article (Okay, I saw it last week on Groklaw too) and it's extremely relevant to the issues facing OSS in the coprorate world, especially with S.C.U.M. lurking about. (That's SCO Corporation's Underhanded Management, BTW). Putting this on the Slashdot front page makes sure that "many eyes" we talk about so often have actually seen it. Getting the word out about good, relevant, useful tools (well, once in a while) is one of the reasons I still come here.
Soko
"Depression is merely anger without enthusiasm." - Anonymous
"Remember, amateurs built the Ark. Professionals built the Titanic."
...
Mild humor value aside
How many icebergs did the Ark bounce off of? And if we are accepting the Ark and Flood we have to also accept that God was piloting the Ark, have to take the entire story or none at all , and piloting was the problem with Titanic not construction. That is we are being fair and objective.
Personally if the pro Open Source lawyer is making statements like the above the document's credibility comes into question. Where there is one piece of spin and misdirection there may be more. I would prefer a objective unbiased legal analysis. The author should hold the jokes for the conference presentations.
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*".
-----
Free P2P Backup, Windows & Linux
You missed the point, there are two problems. One is source code, the second is unlicensed software. Having an unlicensed copy of a piece of software can be a huge legal issue. Not having a policy where software have to be approved in some formal way only makes the legal issue worse. "Big company think" is not universally wrong, occasionally they do the right thing. Whether the rare right choice being made was accidental or not I leave to a different discussion.
I wish. Unfortunately the lawyer resorts to the same GPL FUD I see all the time:
BZZZT, wrong Lawyer-man. Pointing out that "Protective LicensesSo if "Protective" licenses offer no additional protection for my code than "Non-Protective" licenses, the question is what is the difference and why is Lawyer-man lying about it?
I know the answer, do you?
Serve Gonk.
Poor analogy. Water is an industry because it requires purification.
Perfect analogy. Rainwater is about as pure as water gets. Water is an industry because it's more convenient to pay for water than it is to set up basins on the patio.
Purified water cannot be "copied" ad infinitum.
As a matter of fact, there is so much water available that "copying" it is a non-issue. In fact, it's a red herring.
Anyone who claims that there is money to made selling Open Source software is daft.
Red Hat's market cap closed at $3.17 billion on Friday, up 304% for the year.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
"How can he put Linux as an example of GNU software!? which is under the GPL license just for histerical reasons, and is not part of the GNU Project!."
I think you mean hysterical.
Calm down. The GPL is a GNU project licence, i.e. it was created as part of the GNU project. So the Linux kernel uses a GNU licence. That is all...
It seems to me as though he is referring to derivative works when he says "code" in the last sentence of the quote. I do not profess to have a complete understanding of these licensing issues, but with what I do know it seems as though the quote is fundamentally accurate if this interpretation is used.
"(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
Who says you have to give it away for free?
Not everything has to be free as in speech and beer, otherwise how would Red Hat/Suse/whoever be able to charge money for their Linux distributions (among all the completely free distro's out there) and not immediately fold?
Customer support is a part of that, but so is offering the package in an easily installable, usable and maintainable set. Look at some of the really Newbie-Friendly distros (xandros and Lindows), both offer easy-to-use versions of Debian (available for $0) and can charge upwards of $100 American for it?
Yeah, that's just for Linux, but still, there's nothing saying that Johnny FooBar _must_ give away his work for nothing, hoping that people will donate money to pay for his costs (or he has to work a day job to pay his bills). If he chooses to do so, that's up to him, but it's not a requirement of OSS.
This has happened before. What happens is that the GPL'd copies are still GPL'd and therefore not in violation of any license. Once you distribute something under the GPL, it is GPL'd period.
There is nothing which stops you from no longer providing licenses under the GPL (in which your case your development from that point for wouldn't be open to all), nor is there anything preventing someone else from taking what you had released up to that point and forking it, providing updates to it as well since the GPL license you distributed to them continues. The GPL can't be revoked short of a violation of it's terms.
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.