This may seem obvious to the average software developer, but I have some difficulties with Larry Lessig's proposal about escrowing software from the point of view of the mechanics. How do you cover
- patches and minor releases - companies with successful software products generate patches at a furious rate (e.g. typically at least once every six weeks). In some cases, they make different patches for different companies. Every successful software product that I've known about has that property of having many, many different versions. Are each one of these reissued at the source level with a new copyright.
- web applications - Does this apply to E-TRADE's web site (all of it, part of it, what)? There are aspects of it that might be copyrightable. Is it the look and feel, the back-end.
- third party components - no software product or web application that I know about is built without third party components. In some cases, these are special purpose versions from other vendors. These may be integral to the workings of the code. I certainly can't redistribute their source code.
- Multiple levels of specification - many products have pieces that are described by a given level of specification and then another generator program is run over that specifcation to produce 'source' that can be fed to a compiler or assembler. Which part counts as the source code. The source that is fed to the compiler is totally useless and the higher level specification is useless without documentation of that specification and the translator program.
If the intent of the proposal is that I should be able to build and execute the software from the escrowed source, it puts a significant expense on software authors. The degree of version control and build management that would need to exist to do this is a difficult art that is not done very formally at many independent vendors, and to varying degrees of success at larger vendors (Do I have to escrow the compilers and operatings systems where the system is built). Making this a requirement definitely favors larger corporations.
If the intent of the proposal is simply that it is available for reading, I think that the density of most source and its chaotic nature (one small change can render the entire program useless) renders it almost impossible to disentangle an accurate design from the implementation without some guidance by the authors (e.g. comments, models, design documents, etc.) by the developers. The code is technically a specification, but since it is also an executable specification, it is not very similar to a specification in a musical score or a blueprint in a patent document. It's a lower degree of specification.
Finally, as a person who has used numerous third party software in building products and required other companies to put their source code into escrow, I don't think I've ever seen that fact used successfully in the case that a company disappears. The most important thing is the sanctity and standardness of the interfaces that are used from my software to the other 3rd party vendors. To the extent that I can do that successfully, I can use different app vendors for J2EE compliant app servers, different ODBC or JDBC drivers for connecting to databases. Different SQL database vendors. In none of these cases am I dependent on the source code.
That is not to say that source code doesn't have value. Many of us grew up reading the Unix sources as an inspiration for writing C programs, and that should continue. It simply is the case that the source code is not exactly like the words in a book, and it is not like a musical score (which can be copyrighted in its own right).
9:21:32 PM 
|
|
