December 8, 2009, 12:16 pm
On 1st December Olswang held their third and final Open Source Summit in London. For one reason or another I’d been unable to attend the 2007 and 2008 events and was glad to last week be finally able to make it along. Olswang are a law firm and so as you would expect the summit focused on open source legal matters. We were treated to a keynote from Bruce Perens and the overall quality of the event was very high. Numerous topics were covered over the course of the morning and a few notes follow.
Due diligence
It was suggested that IP management and due diligence must be built into the development process and that these considerations cannot be left until the end of the development cycle – licensing meta-data must not be kept separate to the code, e.g. licence use documentation with Legal and source code in subversion.
Similarly, code scans and licensing due diligence should not be carried out at the time of M&A discussions. This is the worst possible time to be attempting to locate all the various source code repositories, determine what should be audited (releases only? betas too? development prototypes? 3rd party/supply chain code?) and seek access etc and all without alerting staff. There may well be licence compliance issues, you cannot pay off the F/OSS community and re-engineering takes time. The potential acquirer will use any discrepencies to mark down your value, e.g. “is all your code this bad?” Policy must be defined in advance and process made business as usual – see previous point!
Licensing and Community
It was suggested that in M&A situations code assets should be rated at zero value if they are made available under a “giftware” license, i.e. a permissive licence such as BSD. Thus it follows that if the code is deemed a core asset that the investment made should be protected from proprietisation, such as through use of copyleft licensing. This does not include things such as an SDK , where it may serve as an on-ramp to other products or services and adoption is the principle concern.
With MySQL it was suggested that there has been “no significant community development of core product during the tenure of MySQL AG”. Furthermore, that many companies are doing just fine using MySQL and without paying for support.
Conclusions
Due diligence must become strategic, employers will need to educate their developers and best practice is needed. The obligations are clear, as are the potential ramifications of leaving things until the last minute.
Permissive licensing and the absence of any guaranteed return (cash or code) may make it harder to value code as a company asset with a cash value attached.
It may be that with MySQL the incentive to contribute was greatly reduced due to MySQL AG requiring ownership of all copyright (in order to support dual licensing). Or there may have been other reasons for the lack of community contribution to core… However, it should be considered that dual licensing may sometimes discourage community contribution whilst not securing payment, and thus may actually offer least value.
