Reply to comment

As the story of open source licensing being upheld by copyright law bounces around the Internet, there's been quite a bit of commentary on it. Today, I came across yet another article which made a very important distinction. From How not to get sued by open source coders:

...Specifically, those policies should include a list of open source technologies in-house developers can use, a procedure for obtaining appropriate approvals for usage, and most importantly, a process for tracking the code. The latter – tracking how the code is used and modified – is often the root of the issue, said Abe, when a business wants to start selling its products.

But at the core of the court ruling, is the fact that the business had infringement on copyright – not just in breach of the license contract – by not following conditions imposed by the license agreement, like crediting the author, reference to copied files, a description of modifications to the original source, and where to find the original source...

I suppose that I've been using, writing and writing about Open Source and Free Software that I think that this is a no-brainer. That being said, it seems that at least a few organizations and companies are using open source code as Commercial Off The Shelf Software (COTS). And COTS is something that a lot of companies decide to use based on development and process tracking costs: if, for example, a company is trying to maintain a SEI level of 3 or better and they want to avoid having to track a project, they may plug in some COTS.

But Open Source/Free Software isn't COTS in the traditional sense. When a lot of software process terminology was started, open source and free software simply did not have as much visibility as it does now. And Free Software/Open Source, aside from the attributions and copyright, can be used as COTS until it is modified. In essence, the second code is changed in an open source project to meet the needs of the organization, it cannot be treated as COTS anymore: it becomes a project which should follow a software process. In fact, all code should follow a software process and Open Source/Free Software is no different.

The easiest and most sensible way to manage an Open Source/Free Software package is through the same mechanism that the developers use. A typical open source project already has a CVS repository, and useful changes are typically welcome. Not all changes a company makes will be, but at that point the code can fork and a separate copy can be maintained in a CVS - privately - until such time as the code is sold to others. Once that code is sold to others, they must have access to the code - unless the original license is a BSD-like license.

It really isn't that difficult to follow a free software/open source license. If people can follow Microsoft's EULA, any open source license is much simpler. But because it is open source doesn't mean it is Public Domain - someone holds the copyright.

The whole thing boils down to proactive communication with developers, internally and externally.