Slashdot Mirror
OSI Launches Certification Program With Logo
Lao-Tzu writes "The Open Source Initiative has launched an OSI certification program. The OSI has trademarked a logo looking like a keyhole for their use as a graphical certification mark. Python.org is the first website to carry the new OSI logo." One might ask what took so long.
Gene Kan dead at 25
iron sights on a rifle to me... billg watch out!
Looks pretty sexually explicit to me!
One might ask who the hell cares.
Look up http://singlegoal.com and http://eternalambition.com . Then
look at the only purpose anybody can have--as follows.
MEANING
The meaning of all conscious beings is to pursue one of two
goals--love or power.
All subgoals except L2 are unachievable.
A conscious being...
-Common subgoals:
C1. controls reality.
C2. knows reality.
C3. has mastery of potential reality.
C4. has mastery of the abstract plane.
-Love subgoals:
L1. and one other are the only conscious beings to exist for all time
and space.
L2. is bound by a seed of love to the other conscious being.
-Power subgoals:
P1. is the only conscious being to exist for all time and space.
What Open Source Zealots Don't Get
.doc file. I'm continually annoyed myself by people who send HTML mail, never mind the lunatics who use Microsoft Word as their text editor in Microsoft Outlook. Email is much more efficient as plain text. If Stallman had positioned his screed as "use the right tool for the right audience in the right medium" I would have been totally on board with him.
.doc format. It's a lofty and valuable goal. But until the day when Stallman or someone else can figure out a way to get open source developers to scratch someone else's itch with the same fervor and quality with which they scratch their own, it's just not a realistic goal.
The News Forge editorial, We can put an end to Word attachments [link via Camworld], by Richard Stallman of the Free Software Foundation, illustrates perfectly why the free software/open source movement is never going to penetrate the mainstream consumer consciousness.
Caveat: I like open source software. I like the concept and I support it. What I dislike is the zealotry of hardcore open source/free software advocates, like Stallman, and their total disregard for how consumers view and use software. These zealots are stuck in a dogma that is constructed from the viewpoint of someone who develops software, not from the viewpoint of consumers who use software for reasons other than developing more software (which constitute the vast majority). The zealots of open source/free software present the movesment as serving manking, but in fact they have an overwhelming tendency to ignore the needs of any user not like themselves. This essay isn't an anti-open source rant, nor is it flag-waving support of Microsoft's monopolistic practices. It is intended to be a pragmatic look at why open source hasn't lived up to the hype.
Stallman's point in his editorial is that people shouldn't send Word attachments via email. Much of Stallman's rhetoric is justifiable. In fact, I think it's not only counter-productive, but rude, to send Word attachments to people who use open source software incapable of reading a
However, much of Stallman's rhetoric is the usual open source/free software wheel-spinning that shows little consideration for or understanding of the vast majority of computer users. This part of the second paragraph sticks out:
Most computer users use Microsoft Word. That is unfortunate for them, because Word is proprietary software, denying its users the freedom to study, change, copy, and redistribute it.
There are all kinds of problems with Stallman's rhetoric, but this is the most glaring and is the ultimate of example of What "Open Source Zealots Don't Get." Here's the underlying concept that the open source movement has continually failed to understand. Ready? Here it is:
Most computer users don't give a crap about studying or changing software.
Get it? 99.985% of Microsoft Word users have absolutely no desire to view -- never mind modify -- the source code of Word. Why would they? They don't know how to code! Nor do they want to learn! It's like asking them to re-design the shovel to make it more appropriate to their needs. Hey, sure maybe 0.015% of shovel-users customize their shovels, but most people use the tool off-the-shelf, as is.
Stallman is right that people would like to freely copy and distribute software, but this is where we run up against the dirty secret of open source: open source developers like to scratch their own itch. And, unfortunately, that attitude doesn't jive with creating consumer applications, so those consumer needs get left up to businesses that need to make money off their product to exist.
Open source developers tend to work on projects that solve their own problems (which usually revolve around building software and working with others who build software). That's why we have great open source operating systems, web servers, compilers, etc., but are severely lacking in open source office suites, graphics and design tools, games, etc. Independent open source developers don't come together to develop those kind of applications like they do to develop web servers, compilers, and databases because developers typically don't have a desperate need for those kinds of apps. No itch, so why scratch?
Yes, I know there are some alternatives out there (primarily because the zealots have this mistaken idea that Linux will compete with Windows and Macintosh for the consumer desktop). I know about KOffice, AbiWord, GNOME Office, OpenOffice, and Sun Microsystems StarOffice.The only competitive contender on that list is StarOffice, which, of course, started as a proprietary application. Sun Microsystem's CEO, Steve McNeally, acquired StarOffice and open sourced it purely to attempt to spite Microsoft; Bill Gates just laughed. The Gimp is a fine graphics program, but it doesn't measure up (especially running under Windows) to Adobe Photoshop, or even Jasc Paint Shop Pro. And where are the competitive open source competitors for Adobe's Illustrator, ImageReady, PageMaker, InDesign, Premier, AfterEffects, etc.? What open source app would professionals choose over Macromedia Dreamweaver, Fireworks, Freehand, Flash, Shockwave, Director, Authorware, etc? Answer: they don't exist.
Open source developers don't care enough about those applications to develop them, and they sure don't care enough to develop them for the non-open source platforms (e.g. Windows, Mac) that most of the world uses. The bottom line is...well, the bottom line. If consumers want these kinds of tools that are of interest to consumers, but not of use to the geeks who know programming languages, then the consumers are either going to have to learn to code themselves (ain't gonna happen; we all have other careers) or the consumer will need to pay to have someone else develop them.
The demands for these consumer apps gets filled by corporations who exercise proprietary control over their intellectual property in order to recoup the development costs, because the companies have to hire developers to scratch someone else's itch. And that proprietary control means patents and copyrights1, because to make money off a product you must, repeat MUST, control reproduction and redistribution. And businesses are about making money.
If anyone had been able to demonstrate a competitive, scalable business model for a company that develops open source software, then I might get on board. But even RedHat, the open source developer with probably the most solid foundation and best shot, is still hemorrhaging money. Developing open source software works as a hobby; so far no one has been able to make developing open source software work as a business.
A bunch of developers might come together to develop a super open source web server like Apache to solve their own problems, but they don't get the same personal satisfaction from developing, for example, an open source consumer desktop publishing application or a GUI desktop -- witness the struggle to get KDE and GNOME to some usable point, and remember that Eazel tanked. Problems like those that have plagued the attempt to put an open source GUI on the Linux operating system illustrate another problem with open source: too many cooks in the kitchen screw up the menus. (Oooh. Pun!)
Choice is sometimes counterproductive to usefulness, and usefulness is paramount for a consumer application. This is where "network externalities" -- the economy of increasing returns -- comes into play. If ACME Industries makes ACME WonderSoap, the soap doesn't become more useful to the consumer (e.g. it doesn't clean your armpits better) if more people use it. That might be better for ACME, but my armpit gets just as fresh whether ten thousand or ten million people use ACME WonderSoap. Not so with software. If ACME industries makes a word processor, ACME WonderWord, then ACME WonderWord is much more valuable to me if ten million people use it as opposed to ten thousand, because we're all using the same tool. The best illustration of the concept of an economy of increasing returns is the Microsoft monopoly. People won't switch to Linux and StarOffice, because everyone else in their workplace or community is using Microsoft Windows and Microsoft Office. In a networked environment where you have to share your output and input, life is more difficult if you're not using the same tool. This is where the open source approach shoots itself in the knew -- every Microsoft Windows XP desktop works the same, but if I want to get my officemate to help me with something, and I'm running GNOME and StarOffice and he's using KDE and KOffice, then we might as well be working on Windows and Macintosh. There's no increasing returns, when there's no consistency.
The open source response to that is "it's not the tool, it's the standard." If every tool adhered to an open standard, then they'd all work together. Which is basically Stallman's point -- use text or HTML instead of the proprietary Word
1I think copyright is an idea that has run it's course, but we're not at the point yet where it can be tossed out the window. And the little known fact is that Stallman has to support copyright, even if he won't announce it very loudly, because the GNU General Public License is founded on copyright. Putting software in the public domain doesn't satisfy Stallman's zealotry because someone can still use public domain software as the foundation or part of proprietary software. Instead, Stallman advocates copyleft, whereby instead of relinquishing copyright, the software developer retains copyright and licenses the software and source code under the condition that any changes or modifications also be licensed under the same restrictions. It's admirably clever, but I think Stallman ought to be as concerned as the RIAA about copyright. If copyright unravels, so does the GPL. [back]
Within the software industry, the recent clash of source-code licensing philosophies has proponents of commercial software and open-source advocates frequently at loggerheads. Both commercial and open-source software models, however, have demonstrated value for various sectors of the software market, which has determined that multiple licensing and distribution models should coexist in healthy competition. The market, in fact, is driving both camps toward a middle ground where the most beneficial aspects of both philosophies are embraced.
In May 2001, Microsoft® responded with a Shared Source Initiative (SSI) to provide source access to a broad range of customers, partners, independent developers, researchers and other interested individuals, while preserving the intellectual property rights that have sustained innovation throughout the industry over the past quarter-century. The SSI framework supports a spectrum of licensing programs, each tailored to the source-access needs of a specific constituent community. Meanwhile, prominent open-source developers began to adopt certain commercial distribution methods in their own pragmatic migration toward the middle. These developers commonly rely on open-source licenses, like those based on the Berkeley Software Distribution (BSD) license, that place few if any restrictions on licensees' subsequent use of licensed source code, including its use in commercial software development.
Free software distributors, by contrast, use the highly restrictive GPL, which was created by the Free Software Foundation (FSF) in furtherance of its philosophy that software should not be subject to ownership, and thus that commercial software is inherently immoral. The GPL governs distribution of some popular free software, including Linux. The GPL may be beneficial to noncommercial developers and certain licensees in other contexts, but several of the license's terms and uncertainties should raise red flags for commercial developers considering its use.
Because many businesses may not understand the GPL and its potential implications, Microsoft offers this document as a checklist and to provide important background information. Most or all of the following questions will be familiar to those who have examined the GPL. Many of them have generated considerable debate even among open-source and free-software advocates. Comments in this document are based on GPL Version 2, Lesser General Public License (LGPL) Version 2.1 and the GNU GPL FAQ page (www.gnu.org/copyleft/gpl-faq.html).
The GPL is a complicated agreement. To understand your potential rights and obligations, you must interpret the various provisions of the license and apply them to your particular circumstances. Microsoft recommends that you obtain legal counsel as appropriate. This document does not and cannot offer legal advice.
1. Have your lawyers read the GPL (and the LGPL)? Because the GPL is so frequently misunderstood and because it attempts, under certain circumstances, to impose significant obligations on licensees and their intellectual property rights, no responsible business should use GPL software without ensuring that its lawyers have read the license and explained the business' rights and obligations. They should also review and explain the Lesser General Public License, or LGPL, a related license that is sometimes used with open source libraries.
2. How are you using GPL software and what obligations does it impose? The obligations associated with the GPL vary substantially depending upon the way in which GPL code is used. Even limited or relatively obscure uses (e.g., including a few lines of GPL code in a commercial product or linking directly or indirectly to a GPL library) may have a dramatic effect on your legal rights and obligations. To understand the potential implications of the GPL, you need to have a detailed understanding of your use of GPL code. Basing any analysis upon a superficial understanding may present serious risks.
3. How does your use of GPL software affect your intellectual property rights? One of the most significant impacts of the GPL is its potential effect on your intellectual property rights. The GPL is widely referred to as 'viral' because it attempts to subject independently-created code (and associated intellectual property) to the terms of the GPL if it is used in certain ways together with GPL code (see Sections 2 and 3 of the GPL). For example, a business that combines and distributes GPL code with its own proprietary code may be obligated to share with the rest of the world valuable intellectual property (including patent) rights in both code bases on a royalty free basis. Other uses of GPL code may also create obligations for the user. It is important to perform a careful legal and technical review of this issue before using GPL software.
4. What if you are simply a customer, acquiring GPL software from other businesses? Does the GPL have any effect on your rights and obligations? Section 0 of the GPL says "[a]ctivities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted." So, a customer who only runs the Program should have no obligations to the author of the code under the GPL. As discussed below, however, such a customer also has no rights from the author (e.g., no assurance that the code is even free from "known" copyright infringement problems) and may have liabilities to third parties. If, on the other hand, the customer's use of GPL code involves even limited modification, copying or distribution of the code, the GPL arguably does impose obligations to the author, discussed above and below. In assessing this possibility, customers should carefully consider what the GPL means by "copying, modifying and distribution."
5. Can you develop applications for a GPL program, like Linux, without subjecting those applications to the GPL? This is a particularly important question. The answer will almost certainly depend upon a detailed analysis of the way in which the application was developed and distributed and will be subject to caveats regarding the interpretation and enforceability of the GPL. For example, the analysis will presumably involve a careful review of your development team's exposure to and use of GPL code during the development process, especially whether the application incorporated any such code or was otherwise derived from it. The analysis would also likely consider what libraries are used; how are they used (e.g., statically linked or dynamically linked); whether they, in turn, link to other libraries; and which licenses (GPL or LGPL) govern all of these various libraries. Similarly, the analysis would probably consider what header files are used; whether they, in turn, include other headers; and which licenses govern these various headers. In addition, the analysis would presumably consider whether the application is distributed with GPL code and, if so, how it is distributed and by whom.
6. Can distribution of your code with GPL code require you to license your code under the GPL? Have you combined your own code with code licensed under the GPL? The GPL attempts to address these questions directly. Section 2 of the GPL says that identifiable sections of a work that are not derived from a GPL program and that "can be reasonably considered independent and separate" are not subject to the GPL when distributed as separate works. But if these separate sections are distributed "as part of a whole which is a work based on" a GPL program, then this distribution of the "work as a whole" is subject to the GPL. Section 2 also says that a "mere aggregation of another work not based on the [GPL] Program on a volume of a storage or distribution medium does not bring the other work under the scope of this License." A licensee is left with the difficult task of deciding whether a particular combination is a "work as a whole" (GPL infection apparently intended) or a "mere aggregation" (GPL infection disclaimed).
7. If your software becomes "infected" by the GPL, do you have to give it away for free? Section 3 of the GPL says that you can copy and distribute a GPL program (or a work based on such a program) in object code or executable form, subject to several restrictions. You are supposed to make the corresponding source code available, for example, by including the source code with the object code or offering to distribute it to any third party (Section 3). Section 1 says that you "may charge a fee for the physical act of transferring a copy," but Section 2 says that you "must cause any work that you distribute or publish, that in whole or in part contains or is derived from [a GPL] Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." The net effect is, apparently, that you are able to charge a fee for your software, but that right is significantly undercut by your obligation to give others (including your competitors) the right to distribute your software for free.
8. Are your obligations under the GPL "flexible" or "proportional" to your use of GPL code? Suppose Business A uses a few hundred lines of GPL code in its existing 500,000-line proprietary program and makes copies for its own employees or distributes ten copies of the modified program as a collective work. Suppose Business B combines 500,000 lines of GPL code with an existing 1000-line proprietary program and distributes 500,000 copies of the modified program as a collective work. The GPL may be read as to require both businesses to share the source code for their modified programs (including their existing commercial programs) and allow royalty-free redistribution of those programs. This is true despite the potentially dramatic differences in the volume, value and copies of the GPL code used.
9. Do you have all of the rights required to use GPL code? Could your use of GPL code cause you to infringe on the intellectual property rights associated with code you have licensed from others? The seemingly obvious answer to the first question is yes because those rights are provided under the GPL. The correct answer, however, may require more careful analysis. If, for example, you plan to combine and distribute GPL code with pre-existing code, the "viral" nature of the GPL may require you to provide source code for the pre-existing code to all third parties and license others to use it on a royalty-free basis (see Section 2). Unfortunately, if you licensed some of the pre-existing code from a third party, you may not even have access to the source code, much less the right to license it to the rest of the world on a royalty-free basis under the terms of the GPL.
10. Do you have any existing obligations that might preclude your use of GPL software? Could your use of GPL code put you in breach of existing contractual obligations? As noted above, the use of GPL code with code licensed from another party could, under certain circumstances, arguably obligate you to sublicense the other party's code under the GPL. If you expressly agreed not to attempt to sublicense the other party's code, you should consider whether your use of the GPL code presents a risk that breaches your earlier contract. Even if no breach occurs, the GPL includes provisions that may make it impossible for licensees to retain both their GPL rights and rights under other agreements. For example, Section 7 of the GPL says that if "conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this license, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all." Suppose Business A has developed a program using trade secret rights that were licensed from Business B under an agreement that prohibited their disclosure. Now assume that A uses GPL code in a way that "infects" its program. Section 7 apparently says that use of GPL code in such a program is impermissible. This places A in an untenable situation: unless it persuades B to divulge its trade secrets to the world, A must cease distribution of its program. This may be true even if A's use of GPL code is minimal.
11. Have you considered the risk that GPL code might infringe on third party intellectual property rights? Although it is always difficult for a business to ensure that acquired products do not infringe on third-party intellectual property rights, the risks associated with the use of GPL software may be substantially higher than those associated with commercial software. For example, given the distributed nature of open source development, you should understand what controls, if any, you have in place to screen unlicensed code or trade secret information from inclusion in the GPL program. This view is perhaps reinforced by the fact that Section 11 of the GPL expressly disclaims any warranties, including presumably a warranty that the program is free from infringements of third-party copyrights or trade secrets known to the contributor. You should also ask yourself if GPL developers may conclude that this disclaimer makes it okay to distribute code under the GPL when they know they don't have the rights required to do so. Developers of commercial software, in contrast, typically have procedures, contractual obligations, and a substantial financial stake in minimizing potential infringements.
12. What happens if an intellectual property owner, who claims that your use of GPL code infringes its intellectual property rights, sues you? As noted above, Section 11 suggests that you are "on your own" with respect to defense of the suit and payment for damages.
13. What is the extent of your liability for GPL-related infringements? Several provisions of the GPL may be read as requiring a GPL licensee to effectively sublicense its rights to the rest of the world (e.g., Section 2, relating to the modification and distribution of GPL works). GPL licensees should ask themselves whether, and to what extent, they might be responsible for the actions of their sub-licensees. For example, suppose Business A distributes a modified copy of GPL code to Businesses B, C, and D, and each of them further distributes 1000 copies. If Business A is sued for patent infringement relating to its use of GPL software, the patent owner might claim that the business is liable for direct infringement based upon the three copies distributed to Businesses B, C, and D and is further liable for direct, contributory, or induced infringement by the 3000 additional copies distributed by these businesses (and, of course, any and all later distributions by such businesses and their downstream sub-licensees). While actual liability would depend upon a host of factual issues, if Business A has deeper pockets than the other businesses, it should not be surprised to find plaintiff's counsel pursuing such an approach and claiming theoretically unlimited damages caused by Business A's limited initial distribution.
14. Can the author of a GPL program 'unilaterally' withdraw your right to distribute the program? Section 8 of the GPL gives "the original copyright holder who places the Program under this License" the right to preclude distribution in certain countries based on patents or interface copyrights. It is not clear that a licensee has any right to object to this restriction, which may be solely within the discretion of the original copyright holder. It is also not clear whether this restriction can be imposed retroactively, although Section 8 does say, "this License incorporates the limitation as if written in the body of this License." Companies relying on GPL code should carefully consider the potential impact such a geographical restriction could have on their business.
15. Can you use GPL tools in the development of your own software without subjecting your software to the GPL? As noted above, the GPL is sometimes referred to as being 'viral' because it attempts to subject related third-party code and intellectual property to the GPL. People concerned about this aspect of the GPL are probably careful about modifying GPL programs or combining their code with GPL code, but they may assume that their use of GPL tools cannot 'infect' the software they are developing. While this is probably true in many cases, it is not necessarily a safe assumption. For example, the 'Bison' parser developed by Richard Stallman, Robert Corbett and Wilfred Hansen was licensed under the GPL for some time before users realized that the software they were developing with the tool was arguably subject to the GPL. The potential exposure resulted from the parser's inclusion of incidental GPL material in the tool's output. In response to this problem, Bison version 1.24 and later was distributed with a 'special exception' regarding output files. The implication is that businesses concerned about the possible infection of their software by the GPL should make sure they consider: what, if any, GPL tools are being used by their developers; how those tools are used; and the possibility that such uses might subject their own code to the GPL.
16. If the GPL requires you to 'contribute' your modifications to GPL code to 'the community,' are you sure that your competitors are doing the same? Assuming that two competitors are making similar use of GPL code, their obligations under the GPL should be the same. There are, however, a number of scenarios to consider. Some competitors may not understand their obligations under the GPL and, for that reason, might not share their improvements with competitors. Other competitors' interpretation of the GPL might lead them to conclude that they have no obligation because they might believe the GPL is unenforceable in its entirety. Some competitors may intentionally ignore their obligations under the GPL to obtain a competitive advantage, relying on a variety of factors to avoid compliance. These factors might include obscuring object code to hide use of GPL code and the strength and enforcement of intellectual property laws in the country where they are doing business.
17. Does the GPL present any special challenges for businesses developing or distributing products with embedded software? The GPL does not expressly impose any 'special' obligations on embedded software businesses, but embedded businesses should consider whether the GPL presents any unique risks based upon scenarios common to the embedded product space. For example, the manufacturer of a hardware system that includes some embedded GPL software and some of the manufacturer's own proprietary software may find it particularly important to carefully assess whether the GPL and proprietary software form a 'mere aggregation' (GPL infection disclaimed under Section 2); a 'collective work' (GPL infection apparently intended); or something else altogether. Some embedded software developers, such as Caldera and Wind River, have publicly expressed concerns about the risks associated with the GPL.
18. Are your software developers aware of the many development-related issues that may affect GPL risks and obligations? Are you asking (or allowing) them to act as your legal counsel and are you willing to accept that risk? Are you 'betting your business' on informal or anonymous interpretations of the GPL posted on the Internet? As noted by the Free Software Foundation (FSF), the potential implications of the GPL on software development ultimately depend on the way in which judges will interpret provisions of the GPL. A host of relatively detailed, development-related questions are also likely to be critical. You should probably make sure your developers are asking themselves a number of questions, including: Given the subtle nature of some of the legal issues presented by the GPL, you should also make sure your developers know when to consult legal counsel regarding any potential risks presented by a particular development activity. All businesses would be well advised to avoid taking actions based upon general 'understandings' of the GPL that are not based on a careful reading of the agreement itself.
19. Who can you go to if you have a question regarding the GPL's interpretation, want to clarify your risks under the GPL, or amend your obligations? The GPL was developed under the auspices of the FSF. The FSF is not, however, necessarily the owner of any and all intellectual property rights embodied in particular programs licensed under the GPL. Section 10 recognizes this by suggesting that a GPL licensee could write to a program's author (or authors) for permission to distribute the program under different terms. In some cases, no single person or entity may own all of these property rights. As a result, a prospective (or existing) GPL licensee may find it impractical, if not impossible, to negotiate a desired change in its rights and obligations or even obtain a clarification of those rights and obligations. Even if a licensee were somehow able to identify key contributors and reach agreement with all of them regarding a desired change or clarification, presumably those contributors would be unwilling or unable to represent and warrant that they had the entire right and title required to do so.
20. Are you using any software governed by the Lesser General Public License (LGPL) and, if so, how does that license affect your rights and obligations? The LGPL was developed by the FSF to give library developers an alternative to the GPL. Specifically, although the FSF generally discourages use of the LGPL, it notes that "using the Library GPL permits use of the library in commercial programs." The LGPL retains the 'viral' provisions of the GPL in the context of modifications to an LGPL library (Section 2). But a different set of obligations are imposed when code is linked to an LGPL library (Sections 5 and 6). If you are developing programs that link to LGPL libraries you should review and understand these obligations. You should also check whether the LGPL libraries used, in turn, link to other libraries and especially consider the implications if the LGPL library links to a GPL library.
21. Does the use of GPL software reduce the acquisition value of your company (as a start-up) or a particular business unit (as a spin-off)? As noted above, the GPL attempts, under certain circumstances, to subject licensees' code and related intellectual property to the terms of the GPL (see, e.g., Section 3). Once your software is 'infected' by the GPL, it is not clear whether and how this process can be reversed. So, while GPL code may seem like an inexpensive, convenient and useful way for a start-up to develop a new product quickly, it may also have costly and long-term consequences for the start-up. Parties interested in acquiring the business are likely to conclude, as a part of any acquisition due diligence, that the business has already effectively given away most of the commercial value in its code.
22. Does your use of GPL code present any issues re shareholder value and exposure to suit? In the context of initial public offerings, at least some businesses based upon GPL software have concluded that such software introduces risks that should be disclosed as part of the offering. These risks include: the companies 'inability' to offer warranties and indemnities because the code is developed by independent parties over whom the offering business has no control or supervision; the uncertain future of the code base (will further development occur and, if so, in what direction); the availability of the same code from other sources for free; and concerns about negative reactions from the open source community. (These issues are discussed in the '10Ks' of several of the publicly traded companies that distribute GPL programs). If you are beginning to use GPL code, you should ask whether this presents similar risks to your business.
23. Do you have a process for reviewing and approving prospective uses of GPL software? Are you willing to use precious developer resources required to assess the impact of prospective uses of GPL code that you will depend on? Most businesses that are engaged in software development establish procedures to avoid tainting their development process with software that is subject to other people's intellectual property rights. Although GPL code is often described as 'free,' as noted above it may impose severe obligations on users and is perhaps even more deserving of a company-wide process regarding review and approval before use.
24. Do you have or need any special procedures regarding potential GPL issues created by your licensing of third-party software and or acquisitions of software? Given the potential effect that the GPL may have on code and intellectual property acquired by (or licensed into) a company, it may make sense for businesses to develop procedures to ensure that such acquisitions and licenses are reviewed for GPL issues. For example, many companies have established 'due diligence' procedures to help them identify and evaluate potential issues associated with the acquisition of businesses, product lines, and intellectual property rights. Companies pursuing software-related acquisitions or investments should probably consider whether their due diligence procedures should be updated to specifically address GPL-related issues.