Software Intellectual Property Management

It goes without saying that every software project manager should manage intellectual property as he manages other property and assets. He must maintain a software asset registry of owned software (copyrights), and leased software (copyrights and licenses) for every IP artifact (files). He must ensure compliance with all licenses, and have a process in place to manage change with respect to softwareIP. Yada, yada, yada. As if!

Most software project leaders barely give lip service to software IP issues at the outset. Why bother? There are so many other pressing concerns for the project, such as delivering a quality product on time that delights the customers. My experience was no different. We used broad stroke analysis of our imported software components. The server side was mostly paid-up Microsoft software along with our own software, and the client side was a mix of Microsoft software, open source software (including public domain software), and proprietary software and data with acceptable licenses. We analyzed licenses of components as they were brought in, but we didn't do any more than that.

After a while, one of a few things happens to a new product:

1. The product fails to attract customers and revenue. Nobody really cares if you are violating licenses or not because it costs them more to sue you than they would ever get from you in damages.
2. The product fails initially to attract enough customers and revenues to grow the business in a limited market window, but convinces wealthy investors of a high business potential in the future.VC financiers are the typical investors.
3. The product succeeds at attracting large channel partners who feel that they can make money distributing the software or derivative works. A big reseller or VAR want to cut a deal with you.
4. The product succeeds at attracting large customers who are great targets for IP lawsuits because they are rolling in cash. A large customer wants to buy your product.
5. The product succeeds at attracting a large customer to buy the product business. A large company wants to acquire you (M&A).
6. The product succeeds at attracting enough customers and revenues to convince the general public that this business is a viable, sustainable, and profitable. This is when an initial public offering (IPO) happens.
7. The product attracts enough customers and revenue to sustain the initial team and grow slowly and unpredictably, but not enough to attract other investors, channel partners, or big rich customers. This is a typical independent business.

The first scenario and the last scenario represent the fate of probably 80-90% of all new products. Software IP management is irrelevant because nobody who can be sued for a lot of money is wants to be vested in the business.

For the fortunate 10-20% of companies that actually do business with a vested interest worth suing (examples 2-6), software IP management becomes important because the large vested interest wants to ensure that the software intellectual property liabilities of the new product are all known, bounded, manageable, and don't impede further business.

My experience was no different. Our company first attracted financing, and was eventually acquired by a large Software-As-A-Service company. The first step of the acquisition process was that the software team had to produce copyrights and licenses for all 3rd party components in the system. We relied on our memories first. Then we scoured the source-code tree for more licenses. It was a tedious experience because we had to gather the software licenses of all of the software components, and provide a registry of all 3rd party components. We were fortunate. We had used SQLite as the client side database, and SQL Server and .Net on the server side, and the first one was public domain, while the second one was proprietary and paid up. We had used gSOAP and OpenSSLfor our client-server communication, and since it was dual-licensed, we had to carefully ensure that we complied. We had other 3rd party software under proprietary licenses which were provably paid up. We were very fortunate in that we had no violations of licenses, nor any unbounded or unmanageable liabilities. Our software IP profile did not cause the acquisition process to stop, and the acquisition eventually closed without any reductions in price due to software IP issues.

Overall, my experience was straightforward in that we did not knowingly infringe copyrights or violate licenses, and we were able to prove it to the acquirers. Nevertheless, it highlighted the need to properly manage software intellectual property. We were fortunate not to have any IP issues, as I know that unbounded IP liabilities have killed deals or reduced the value of an acquired company to the tune of tens of millions of dollars.

The word itself tells the story. Here is a bit more.

1. Copyright is the exclusive right to copy a work. Copying can take various forms such as producing digital copies, or copies on a physical medium such as paper, as well as to make multiple remote and local copies of the work.
2. Copyright is the exclusive right to distribute a work, for free or for compensation, either by a physical medium or by digital such as tape, hard disk, or DVD, or by transmission over an electronic network such as broadcast TV, radio, and the internet.
3. It is also a right to create derivative works based on the original work.
4. You also get the right to perform the work live or live over a digital network.
5. Copyright is also the right license the copyright to others under terms of your choice, or to assign the copyright outright.

What kind of a work? Literary, software, music, audio, video, drama, art, architectural works. Chances are that if you can copy it, it probably has a copyright.

Copyright is implicitly granted to the author of the work in many jurisdictions. Other jurisdictions require you to register the work and the copyright with a government agency. Many authors assign their copyrights to their employers or publishers, thus granting them the exclusive right to copy the work (implying that the author forfeits his copyright).

There are exceptions to copyright exclusive rights. For example "fair use" allows "limited" or "small" portions of a work to be used in another work that talks about it or helps to find it. For example movie reviews and Google. It also allows works to be created to parody other works. e.g. Weird Al Yankovic or MAD Magazine.

In some cases, assigned copyrights can revert to the author after 35 years, but in general, copyrights will last for a lifetime after the author dies.

When managing your software intellectual property, you need to be able to know the copyright ownership for every single file that you use, modify, and distribute. This is where a good IP lawyer can help. I recommend BF Lippett if you need an experienced hand at this.

See Wikipedia for details.

A software license is a contract between the copyright owner and the consumer of the software. Although the wording of the contract is usually cluttered with paragraphs of legalese, a licence usually boils down to these things:

1. Replication of some of the exclusive rights of a copyright holder non-exclusively to a user. Examples of these rights are right to copy, right to distribute, right to make derivative works, right to distribute derivative works, ownership of copies, ownership of derivative works, and the right to sublicense derivative works or the original work.
2. This limited assignment of rights is usually limited by time or by other terms. Terms may include payment for the licence, ongoing subscription payments for the license, agreeing to the limitation of liability of the copyright holder, and penalties for violating unassigned rights.
3. Licenses often come with warranties, IP indemnification of licensee, etc.
4. Licenses also come with termination clauses such as agreeing to destroy copies of the software.

Licenses come in two flavours:

1. Open source licenses are intended to either liberate the source code and the software (e.g. GNU GPL), or to liberate businesses to use the software in proprietary derivative works (e.g. MIT or New BSD). Some licenses are hybrids of the two (e.g. Eclipse Public License or Mozilla Public License). Some licenses add the waiving of patent rights of the copyright holder to the copyright rights granted in the license (e.g. Apache, GPLv3, Sun CDDL).
2. Closed source licenses are intended to let licensees gain benefit of the software while keeping most of the copyright rights of the source code with the copyright owner. The terms of the license are much more restricted, but most closed source software comes with solid technical support, professional support and IP indemnification.

When managing your software intellectual property, you need to be able to know what licenses you have, your obligations, and your liabilities. That goes for every single file that you use, modify, and distribute. This is where a good IP lawyer can help. I recommend BF Lippett if you need an experienced hand at this.

See Wikipedia for more details.

Copyright has a long history. As art and literature have gotten cheaper and cheaper to copy, governments have brought in copyright protections for purposes such as censorship, promotion of knowledge, and enshrining the intellectual property rights of authors.

This brief slide show at
http://www.loc.gov/teachers/copyrightmystery/#/files/ shows the history.

The SFLC published a great guide on legal issues on open source and free software projects. It was written by well-known legal eagles such as Eben Moglen. The guide is located at the Software Freedom Law Center Web Site. It describes copyrights, licensing, patents, and trademarks as they apply to open source software. It also addresses how to organize legally to "house" an open source project (e.g. The Apache Foundation). It is fairly short (about 40 pages) for what it covers, so it is well worth the time.

Here is the table of contents:

Foreword
1 Introduction
2 Common Copyright Questions
2.1 Copyleft
2.2 Choosing A FOSS License
2.2.1 The GNU General Public License
2.2.2 BSD-Style or Permissive Licenses
2.2.3 The GNU Lesser General Public License
2.2.4 The GNU Affero General Public License
2.3 Copyright Assignment and Unification
2.4 Copyright for Documentation, Websites and Supporting Material
2.5 Copyright Enforcement
2.5.1 Gather the facts
2.5.2 Familiarize yourself with the license
2.5.3 Contact other copyright holders
2.5.4 Ask the violator to fix the problem
2.6 Copyright Registration
3 Common Organizational Issues
3.1 Corporate Form
3.1.1 Unincorporated Associations
3.1.2 Nonprofit Corporations
3.1.3 Umbrella Organizations and Fiscal Sponsors
3.2 Incorporation
3.2.1 Where to Incorporate
3.2.2 Choosing a Name
3.2.3 Formation Documents
3.3 Governance
3.4 Bookkeeping
3.5 Tax Exemption Recognition
3.5.1 Restricted Activities
3.5.2 Public Support Test
3.5.3 Related and Unrelated Business Income
3.6 Filings
4 Patent Defenses for FOSS Developers
4.1 Structure of a Patent
4.1.1 Claims
4.1.2 File Wrapper
4.2 Patent Infringement
4.3 Becoming Aware of a Patent
4.4 Understanding the Claims
4.5 Building Defenses
4.5.1 License
4.5.2 Noninfringement
4.5.3 Invalidity
4.5.4 Noninfringement and Invalidity Opinions
4.5.5 Unenforceability
4.6 Other Measures
4.6.1 Designing Around
4.6.2 Re-examinations
4.7 Should FOSS Developers Apply for Patents?
5 Common Trademark Issues
5.1 Choosing a Mark
5.2 Registered v. Unregistered Marks
5.3 The Federal Registration Process
5.4 Using Your Mark
5.4.1 Proper Use of Your Own Mark
5.4.2 Others' Use of Your Mark
5.5 An example: Project Foo and FooNews
5.5.1 Is permission needed?
5.5.2 When to allow use
5.6 Trademark Policy
5.7 Forking a Project
5.8 Responding to Cease-And-Desist Letters

HP published a guide for software IP governance called FOSS Governance Fundamentals. It is a great way to get started with putting together a process to manage all software IP assets, software IP functions, and software IP processes.

It is a free document from HP, and it outlines the best practices for IP governance. It gives a simple and straightoforward way to manage the entrance of FOSS software into an enterprise, a framework to document and evaluate the benefits as well as the liabilities of FOSS software, and a brief section on one compliance tool.

At the end of the day, no IP process consultant, document, or vendor of all-singing, all-dancing software tools can manage your software IP for you, but they can help you execute your processes and policies that you define. This document can help you do it effectively and inexpensively.

Bill Snyder from Infoworld wrote a great article called
What to do when developers take code snippets with them. He described how code snippets carried by developers from gig to gig could cause IP pollution and unbounded IP liabilities.

Good article Bill. Software IP is definitely on the radar of large enterprises that can be sued for software IP violations. However, code snippets are not really a concern. Most code snippets are too small to detect. Even if you could detect them it is very conceivable that the developer rolled them on his own. Also, small snippets represent a very small part of the value of a project. It is also hard to build a case to go after people for code snippets.

That leaves only large software subsystems for you to worry about (e.g. PostgreSQL, Linux, Boost libraries, Log4J, etc). For these subsystems, the project leader has to make a conscious decision to bring the software into the project. For such systems, the IP databases of companies such as Black Duck can help, as can the free Fossology tool from HP. However, Black Duck's Code Center offering seems to be the best product that lines up with making conscious decisions to import OSS software into a product.

The value of Black Duck's database is not as high as it appears. For example the Flossmole project (http://ossmole.sourceforge.net/) in Sourceforge compiles such a database monthly with reports of the IP terms & conditions of a large number of OSS software projects.

Also keep in mind that most IP lawsuits are triggered when developers obviously expose open source functionality by doing things like leaving OSS strings and log messages in the software. This is hard to detect unless the developers were really dumb and left the strings and logs in the OSS code that they derived from.

Finally, the only worrisome open source licenses are the GPL variants, and they are only worrisome to people who create AND distribute/sell derivative works, AND would make a good target for a lawsuit. Most software development houses simply do not meet these criteria. Why?

1. Web site software operators don't have to worry about OSS software (except AGPL) because they do not distribute the software. (You don't see Google open-sourcing GFS even if it is derived from Linux).


2. Many software shops use OSS but use the software internally, thus freeing them from GPL liability.


3. Most software companies are too small to sue. They only have to worry if they actually get big enough to acquire or get equity financing.

Who does that leave? Large profitable software distributors (including computing equipment distributors). Compared to all of the software development shops, large software distributors are a surprisingly small percentage. They typically start out by buying software components from large software distributors such as Microsoft, IBM, Oracle etc, and don't use a lot of OSS, so a lot of them don't have to worry either.

Distributing open source software with licenses in the BSD/MIT family or the Apache 2.0 family is the safest bet if you are going to use OSS, and there is plenty of that available. A lot of large software distributors do just that if they are going to incorporate OSS into their software distributions.

If you want to be safe, use the best practices described at FOSS Bazaar (https://fossbazaar.org/), use Fossology to keep good IP records, and use the Flossmole database to cross reference. That should suffice for most folks. If not, then bring in the commercial products such as Black Duck.

Phil Robb from FOSSBazaar.org raised a provocative question at FOSSBazaar.org where he asked if any contractors working on an internal software application that was a derivative work of a GPL application were entitled to take the entire software distribution and distribute under the GPL. My answer follows:


GPL software that is used and modified internally within an enterprise is obviously not a distribution, so the enterprise does not have to give up the files of the derivative work because it was not distributed to anybody.

Internal contract access is a different story. The internal contractor signs his copyrights away to the contract company who shopped him out to the enterprise. That company signs away the copyrights to the hiring enterprise. I will argue that it is still not a distribution. According to common law and copyright law, the copyright of the derivative work belongs to the enterprise, and one of their rights under copyright law is to distribute the software. With GPL software, the big caveat is that you may produce derivative works only if the distribution license is also GPL. Distribution requires a conscious act of distributing the software or making it freely and easily available for distribution. Although it is true that internal contractors have access to the distribution, having and using unauthorized access and being given a distribution are two very different things, (not unlike the difference between sexual assault and consensual sex). Since the copyright of the derivative work belongs to the enterprise (as per copyright law and common law), they may choose to exercise their rights under copyright law, one right being the right to copy and distribute the software. Enterprises that want to keep a derivative work internal will not want to distribute it to anybody, including an internal contractor whether or not they have access.

External contractors are a bit trickier because the enterprise must distribute the GPL software to the external contractor, so it appears that the external contractor is also entitled to the entire derivative work to distribute under the same terms. However, most contractors, internal or external, sign away the copyrights of the derivative work to the enterprise, and in doing so become tightly bound proxies of the enterprise with respect to copyright ownership of derivative works, thus making them the same as internal contractors.

Google recently removed the Mozilla Public License (MPL) as an option for new projects hosted at Google Code. The full article is at The Register.

How and why does that make sense? I think that it makes perfect sense for Google. There are 3 main families of licenses in open-source.

• Producer-friendly licenses such as Apache 2.0, MIT, and BSD allow software producers to link open-source code into closed-source products without having to distribute the proprietary source code of the producer.


• User-friendly licenses such as GPLv2, GPLv3, force software producers to distribute source code of any software that links to or derives from other user-friendly licenses, including code written by the producer in that software product.


• Reciprocal licenses such as MPL, CDDL, and EPL require producers to feed back improvements to the originators and to license derivative works under the same licenses.

By getting rid of MPL, Google Code hosting has gotten rid of the reciprocal licenses. I believe that this is a good idea because it removes the administrative obligation of both the software producer and Google Code Hosting to propagate improvements back to the originators. Another nice side effect is that it removes any threat (from originator and producer of derivative work) of an audit to see if the improvements were propagated back. In my opinion, those administrative burdens throttle the free flow of ideas and software, and therefore reciprocal licenses should not be used if the goal is to spread software and ideas as fast as possible. Google did the right thing for open-source software.

GPL as a license was made to free software and keep it free. GPLv3 improves on it by addressing and counteracting threats to that freedom, such as software patents, patent side deals, Tivoization, digital rights management (DRM), and other features. Read the full article at The Free Software Foundation.

Linux Watch has published a great paper on the differences between GPL v2 and GPL v3. Check it out! The explicit patent license of GPL v3 is the only major difference that I saw...

If you are reading here, you have decided that you want to get a handle on external or open-source code in your code base, but don't want to do it by hand. How should you choose a tool? Here are a few questions to ask.

1. Does the tool install on all relevant workstations and servers in your environment? If not, it does not work for you. Often, tools install on a client, but not a server, or vice versa.


2. Does the tool work with all of the programming languages in your environment, including the scripting languages, data manipulation languages, and rule-based languages used to build the system?


3. Is the tool robust enough to detect imported IP in the face of obvious tricks such as stripping out copyrights & licenses of imported code, or by adding custom code to an imported file? Few do this, but the US patent database suggests that Black Duck Software has the technology to do this.


4. Does the tool work with your version control system? This one is very important.


5. Does the tool require a particular integrated development environment (IDE), or a particular version of an IDE, and if so, do you use it? If not, you may need to switch IDEs to make it work.


6. Does the tool require plugging into your IDE, or can it run stand-alone? This is a subtlety, but it makes sense. For example, if the tool runs as a Visual Studio.Net plug-in, but somebody introduces files into the system using command lines, a simple text editor, and manually tweaking build-files, will the tool work?


7. Does the tool require you to transmit information to an internet-hosted service, or can the hosted database be installed in-house? If so, do you and your CIO know what is transmitted? Is it accessible to you? Answer this one well because your CIO will be all over it.


8. For tools that have an internet-hosted service, is the service in a reputable and secure data centre with firewalls and security good enough for your CIO?


9. Will the reports generated by this tool document the copyright owners and licenses of each piece of 3rd party/FOSS software?


10. Will the reports flag imported 3rd party software that violates the policies of your organization? Can the tool be configured to even do that?


11. Will the tool work with your internal processes for software IP governance?


12. Does the tool vendor offer professional services such as M&A Audits, Enterprise Audits, and Software Development Lifecycle IP Management Services, or are you left on your own? For enterprise due diligence for M&A and Enterprise Audits, has the tool vendor succesfully helped other companies navigate the software portion of the due-diligence? Check out the professional service offerings from Hewlett-Packard, Palamida or Black Duck Software for the kinds of services you might need.
    

Ask these questions of any tool vendor that claims to be able to provide a robust software management solution, and ensure that you know what is missing so that you can design your software IP governance processes around the deficiencies.

In general, a tool only will help you with the gathering of the records gathered by the tool. This is far beyond what most software teams do for IP management. However, a a tool with professional services will help you with gathering all relevant IP records, analysing compatibilities between licenses and copyrights of different files, analysing overall IP liabilities, and delivering an auditable governance process to ensure that you did the job right.

Recently Koders.com was bought by Black Duck Software. Black Duck, of course is well-known as the leader in intellectual property assurance for external software.

Koders.com is a code search engine used by 30000+ coders to find code on the 'net.

Now that the two companies have teamed up, there is a real opportunity to get some good IP information.

First of all, install the Koders search engine plugin into your Firefox browser. Then search for code.

As an exercise, suppose somebody hands you a file called thttpd.c that deals with HTTP, and has the routines (written in C) handle_newconnect and handle_read in it, but you don't know the copyright (perhaps stripped out to protect the guilty).

Just search the koders engine with "thttpd.c" as the search term, and check your result. See if the file matches. Koders also provides "http handle_connect handle_read" as the search terms, and it also provides the license, copyright owner, and location of the master code base.

You can use this information to help ensure that any open-source code that you bring into your system (or code that somebody hands you) has copyright and license terms acceptable to your company.

Since Koders is owned by Black Duck, you know that they will, whether they like it or not, have to stand behind the license claims on Koders. It is actually believable because Koders usually points to the actual site where the master code is stored.

UPDATE - July 21, 2008 Black Duck has added a ton of C/C++ code to the search engine to make it even more useful. This means that the copyright and license data should be of the same great quality as Black Duck. Check out the article at Open Source Enterprise Magazine.

Palamida Software which focuses on application security and vulnerability audit software has a module for software IP compliance.
This module enables you to get copyright and licensing information for open source software in your software product from Palamida's metadata repository (composed of nearly a million OSS projects). It can also search for code and binary matches.

They also have alerts for IP policy violations, which enable software production leaders to act immediately when non-compliant software is introduced.

Palamida's product is nice also because its complementary product manages and alerts you about security vulnerabilities for open source software. For example, if you are using a MySQL derivative in your application, it will not only get you copyright and licensing information, but if there are security fixes etc, it will ensure that you know about them to keep as up-to-date as possible before you ship.

Palamida also has professional services for IP management to complement their products.

This product is worth a look if you don't have a software assurance vendor (e.g. RedHat) for your open-source software.

I just discovered a new tool called OSSDiscovery which can be found at www.ossdiscovery.org.

This tool is an open-source Ruby script that can be installed on a Windows or Unix computer by anybody and run. The tool has the same privileges as the user. The tool will scan and sign your code based on file names, signatures and other information, and produce anonymous reports for each computer. A public fingerprints database is available to benchmark OSS usage at www.osscensus.org.

The tool currently has fingerprints for about 1100 software packages, but anybody can add a rule to increase coverage. The rules can be found at http://ossdiscovery.opensource.collab.net/servlets/ProjectProcess?pageID=cf1nMc.

This tool also comes with optional professional services from OpenLogic .

This tool has some great potential to help enterprises manage open-source usage and manage their intellectual property liabilities.

Google Code Hosting has always had a way to assign licenses to the code that is stored there. They have now added a feature that lets you add licenses for the content (such as pictures, videos, etc). See the Google Code Blog for details.

This is a great way to ensure that code and content is properly licensed in a software product or software distribution. Not licensing content can unintentionally get people in trouble. Licensing content (as well as code) is a good practice in software intellectual property management.

In this podcast at Twit.tv, Chris di Bona and Leo Laport interview Eben Moglen, one of the principal authors of GPL verson 3.

This podcast is dated in September 2006, so it should give you an idea of what they were thinking as they drafted GPL v3.

Enjoy.

Check out this story at Marketwatch . California Healthcare Foundation has open-sourced their software to allow others to build on it. You can find it openhie.projects.openhealthtools.org.

One of the risks faced by companies taking open source code and customizing it is that they don't know who owns the copyrights, licences, and patents on the software that they are extending or customizing. Palamida helped out here by providing an analysis of the IP ownership of the software. If a company wants to take this software and extend it, they know the pedigree from which it started, and that can help them safely manage any IP liabilities related to using that software.

Kudos to Palamida.

In November 2007, IBM published a paper at IBM Systems Journal on a tool called Ariadne that monitors software files as they are developed.

It basically provides an Eclipse plug-in that tracks the evolution of a software file as it evolves over the course of a project. The contributions of all contributors are encrypted logged in an adjunct metadata file, along with the copyrights and licenses of each. Presumably this metadata is auditable on the final product.

This is an interesting approach because the log file of a file built from scratch will look very different from the log file of a file that was cut & pasted into the project from elsewhere. Furthermore, if an entire software subsystem was imported at the same time, then the metadata files of the entire subsystem would have the same time stamp.

Assuming that the Eclipse plug-in could capture all file alterations possible in a project, this approach provides an airtight history of every file. Derivative works will be very easy to spot with this approach.

However, is this approach relevant in providing comparatively superior copyright and licensing information? I argue that this approach is not relevant. First of all, any project that imports a large subsystem into its code base will presumably have a support and indemnification contract for the imported subsystem, and the conditions of those often mean that support and indemnification is limited if the project's developers change the source files significantly. i.e. This is relatively unlikely. In that case, the approach of Fossology is probably sufficient to record the IP ownership of the original work and the derivative work. Even for software projects that don't have a support or indemnification contracts, significantly changing imported software usually presents an unbounded quality risk that is hard to justify independent of the IP risks. i.e. It is not likely.

Software projects that choose to import software into the project while violating copyrights and/or licenses are also hard to catch. It doesn't take much to obfuscate code to thwart typical code plagiarism tools. Most software distributors that are sued for copyright violations for imported subsystems are usually caught because they made obvious blunders such as not changing symbol names, not suppressing or changing logs, etc from the original software.

This implies, also that most software copyright violations for imported subsystems are inadvertent, and not malicious. Although Ariadne could help, organizations that are that concerned with software IP governance will actually implement a good software governance process such as those that come with the Black Duck Code Center product, or those advocated by Fossbazaar. A good software governance process would be much more useful in catching software copyright and license violations early, and that would render Ariadne relatively useless.

In another scenario, a developer gets code snippets from the Internet. That would be pretty easy to spot with Ariadne, but it wouldn't be relevant because it is hard to track ownership of small code snippets, harder still to get developers to import copyright and license information accurately, and even harder to enforce legal action on a small violation caused by importing a small code snippet. Again, Ariadne is not relevant to tracking copyright and licensing information for original and derivative works.

Overall, Ariadne is an unusual approach to solving the problem of determining copyrights and licenses for original and derivative files used to build a software product. I don't think the approach is relevant in the context of the overall business processes related to software IP governance. Time will tell if IBM feels that way too or actually goes ahead and develops Ariadne into a product.

(March 2, 2009) - Protecode just announced the launch of Software Intellectual Property Audit Services. According to the press release at marketwire.com, Protecode's "Enterprise IP Analyzer" is a "..software solution that analyzes and identifies all code in any directory, producing customizable reports on the licensing and copyright obligations as well as other attributes of the binary or source code".

If you work for or run a financially successful company that distributes software through application sales, source code licensing, or open source, this is great news. For years, the only viable players in this space were Black Duck Software and Palamida. With a dynamic agile startup like Protecode in the mix, there is now some real competition to provide software distributors with increasing value innovation and/or price competition for managing their software intellectual property.

The Software Freedom Law Center has published an excellent guide called A Practical Guide to GPL Compliance that shows simple steps on how companies can comply with the GPL without getting their fingers burned. The big steps are fairly straighforward.

• Evaluate License Applicability - Know up front if software from various copyright holders and licenses will mix.


• Monitor Software Acquisition - Track the copyrights and licenses of all pre-made software you bring into your system.


• Track Your Changes and Releases - Track and be able to produce reports of what you changed, especially with 3rd party software.


• Avoid the "Build Guru" - Under GPL, you must provide repeatable and/or automated ways to build your software. Include any open source tools as wells as accurate and exact pointers to proprietary tools used to build the software.


• Pick Your Distribution Mechanism - Different OSS licenses have different requirements, whether it is including source with the binaries, having source on a separate CD, distributing source over the internet or P2P networks etc.

There's more in the guide. It will help you along the way to ensuring that your software complies with the GPL.

Opscode released Chef under the Apache 2.0 License. Here are the reasons.

They make a plausible and well-reasoned case why they chose Apache 2.0. Studying this rationale educated me a lot about what business must consider when releasing open-source code.

Guy Kawasaki and Bill Meade wrote a great article on restarting an intellectual property program.

This article has some great tips to help companies consciously manage their intellectual property portfolio.

Seth Godin has an interesting approach for IP management on his blog.

The long & the short? Don't protect your ideas. Spread them. He kind of makes sense. These days, there is no shortage of really good inventions, nor is there any shortage of inventors who will invent around an idea that has been patented, an expression of an idea that has been copyrighted, and a trademark that has been registered. His main push is that in an age where there are more great ideas than people being able to use them, getting people's attention and trust is far more valuable than restricting others' use of your ideas.

Interesting...

Openlogic.com has released a beta tool that lets you audit your open source software. They scan for over 130000 known OSS packages. The software can be downloaded here for Windows, Solaris, Linux, Mac, and FreeBSD.

This is another great and free way to find OSS software in your software assets so that you can be sure you are only using OSS software that is acceptable to your company.