The Risks of OSS Utilisation in the Context of a Commercial Business.
A couple of months ago a Client had asked me for an opinion concerning legal risks of including some Open Source Software (OSS) into a proprietary product. After inspection of the relevant software packages (some mathematical libraries) in depth it turned out that they all were licensed under some kind of BSD-style license which should not bar any commercial utilisation.
However, what indeed surprised me a little bit was a flavour of sloppiness of the legal documentation attached to the source code files. One of the OSS projects concerned was shipped with different license texts in the module headers. Which of the variants should be considered as legally binding? Another point was that in view of another OSS project there were prima facie problems with the list of contributors. In the headers of the source code modules only one person was named. However, on sourceforge a list of developers was named. Something seems to be wrong. Most probably the list of developers on sourceforge was more or less up-to-date but the headers of the source code modules had not been updated since those time when the original founder of the project had started with coding. In a third case a University was named in the Copyright list. It was quite unclear what role this institution actually had played in the context of software development and whether or not the OSS licensing had been approved by any competent person acting on behalf of said University.
Regardless of whether OSS is distributed under the GNU GPL or (like the case discussed above) under some BSD style license, it should be strived by all persons involved for keeping the legal documentation up to date at any time. Under all circumstances the documentation should state the correct license text as well as a correct list of contributors as well as the extent of the particular contribution of each contributor.
I would like to guess that with regard to the SCO lawsuits all high-profile OSS projects like the Linux kernel development have reconsidered their documentation practice. However, there are many smaller and less prominent projects out there where substantial problems might exist in this respect.
A risk for any business using OSS might, for example, be that later on some person shows up, explaining that he or she is also a contributor to the source code but never has agreed to the dissemination under an OSS license. Such scenarios might theoretically also be utilised as a tool for attacking OSS projects by deliberately causing legal problems by improperly injecting code into the codebase.
I do not want to be misunderstood. I do not want to say that this risk is not manageable and that therefore businesses should refrain from using OSS. But I would like to point out that some parts of the ongoing discussion on legal risks of the utilisation of OSS might miss the point. Some main problems appearing during the coming years might perhaps not arise from particular problems of the license texts as such but from more factual problems, in particular the determination of who actually has contributed to the source code and under which conditions.
Hence, maintainers of OSS projects might wish to ensure that so far the project documentation is up-to-date at any time.
Wrong, you don't really seem to know what you're talking about. You write: > A risk for any business using OSS might, for example, be that later on some person shows up, explaining that he or she is also a contributor to the source code but never has agreed to the dissemination under an OSS license. Such scenarios might theoretically also be utilised as a tool for attacking OSS projects by deliberately causing legal problems by improperly injecting code into the codebase.
This is plain wrong, because any contributor, by adding or changing code and publishing these modifications in any form (generally, by sending these to the project), is agreeing to the project license - otherwise he would be violating the copyrights of all other contributors. Again: He can't attack anyone for using his contribution, because he's the one who had to accept the license in the first place.
Mixing code from different parties is what open-source licenses are for in the first place. You don't seem to have understood anything beyond one-way licenses.
Well, I'll refrain from entering into a discussion on whether or not Mr./Ms. Tobu knows what he/she is talking about. A scenario which I have thought of might e.g. be:
A university teacher X offers a theme for a student research project paper to be delivered by one of his students concerning efficiency problems in performing a certain class of numerical calculations. Teacher X had vaguely indicated that he is actively developing an OSS math library Z, and in the course of that voluntary work done during his spare time he had stumbled over the problem which is the core of the theme offered. Student Y accepts to tackle that subject and develops some code for solving a certain numerical problem more efficient. The project paper delivered by the student Y is a hardcopy printout with a lot of mathematical discussions and with an appendix exhibiting some code developed by him. Attached to the paper hardcopy is a floppy disc or CD-ROM with a machine-readable version of the code as included in the text of the paper.
Let us assume this scenario happens in a country where applicable law says that the student maintains the benefits of the copyright of his works so that no rights are automatically transferred to the university etc. pp.
Then, without explicitly negotiating (orally or in writing) some kind of contribution agreement with student Y, the university teacher takes portions of the code developed by Y and includes the same into some modules of the OSS project library. Maybe he adds the student's name to the list of contributors, or he even omits to do so. Maybe that he (the university teacher X) in good faith thinks that he had talked to the student concerning a distribution, or maybe he is acting carelessly or even fraudulent. Anyway, the student Y is not aware to have given away any rights.
Let us now assume the scope of application of the said OSS library is boosted because of the code taken from Y's project paper does a lot of tricky stuff much faster and in a superior way than previous solutions did. Years later, company A uses the OSS library in the context of some commercial project.
Again some time later, student Y gets aware of the excellent fame of the said OSS software and learns that company A uses the OSS code commercially. He is still interested in the mathematical subject-matter and just curious to see how it works. Very astonished he has to take notice that either his code is used and his name is mentioned with the code or that his code is used even without his name being attributed. He vaguely remembers that his university teacher had said something about a certain OSS library but at the best of his knowledge he does not remember ever to have agreed to the dissemination of his code as a part of that OSS library.
He decides to go to the court in order to get some money from A commercially exploiting the code.
From the perspective of A this looks like an 'OSS time bomb': They have, in good faith, decided to make use of the OSS library, and they have carefully checked the license text attached thereto. But they were not aware of the fact that there might be a problem with an improper contribution. To blame is university teacher X and, perhaps, some code maintainer W, who was somewhat negligent when overlooking that there was no proper documentation of the origin of some of the code modules. But from the perspective of A, the prospect of being taken to court by Y looks like a 'risk'.
This scenario has nothing to do with properly licensing some code under (multiple) different licenses or something like that. It has to do with sloppiness, malpractice and fraud. Sometimes such things form the stuff from which lawsuits are made.
There is are other possibilities, which I will describe as your failure to consider them perhaps stems from a possible misunderstanding on your part of copyright law. I note you describe yourself as dealing with patent and trademark, so perhaps this is forgivable... once.
(1) Aggregate works:
Software, as a literary work (and it is a literary work, by international treaty and plain common sense (I sit down and write software), patent lawyer and corpie fantasies of 20-year monopoly taxes on trivialities notwithstanding), is protected by copyright, and copyright law has long been applied to anthologies.
Just as the copyright to an individual short story in a science fiction anthology might rest solely with the author of that short story, so an individual author might hold sole copyright to a module in a larger software project. There is established legal precedent for this in both the book-publishing and software world. Therefore - and this has long been standard practice in the industry - only those authors who have modified the file in question claim copyright at the top of that file (UNLESS (2) below, in which case it is usually the party to which copyright has been transferred), copyright to the work as a whole is claimed in a LICENSE file.
To possibly clarify this point (or muddy it...) - say someone had a patent on a particular kind of bolt. That wouldn't stop someone having a patent on a device that used that bolt as a subassembly.
That's why linux distros as an aggregate work can be GPLed, while containing components under different licenses, WITHOUT those components magically becoming GPLed. Or why microsoft can have a license agreement for their windows OS distribution as a whole, and separate licenses for components in the aggregate work.
While there is no doubt in my mind that some OSS projects have shoddy copryight attribution tracing, most don't - we tend to take it very seriously, due to long years of harrassment by laws written to favour special interests.
(2) Transfer of copyright.
While some of us would rather that copyright was non-transferrable, that is not the case today. It is the norm among many larger OSS projects to copyright transfer to the holder of the official tree. This is done so that a unified front can be presented in the face of legal attack - the FSF requires transfer of copyright to it for contributions to its official trees for various GNU tools.
(3) Credit/citation lists vs. legal rightsholder lists.
Software authors will often "give kudos" or "shouts" to those who inspired them, offered tips, etc. - these things often are too ephermal to claim definite legal rights to, but citing someone as inspiration or "help" in a list of contributors does not mean the contributor ever had legal copyright to any part of the work. You cannot "own" ideas themselves (even if some greedy themselves-nearly-idea-less-MBA-cretins would wish it were so), so it is often the case that a CREDITS list differs from a LICENSE list.
I think most of your confusion stems from the fact you're a patent lawyer trying to break into a field that has been satisfactorily regulated by copyright law for several decades.
If, in my fictitious example, student Y never had agreed his code being aggregated into a bigger OSS library, referring to the law of aggregate works doesn't help.
And, yes, even in Europe the rights to use (including right to create derivative works etc. pp.) are transferable, but again that doesn't help if Y actually never has transferred any such rights to use.
And, of course, a proper legal documentation as such does not provide any rights to third parties. But such a well-conducted documentation makes it prima facie more plausible that all necessary rights have actually been transferred properly.
> While there is no doubt in my mind that some OSS > projects have shoddy copyright attribution tracing, > most don't - we tend to take it very seriously, due > to long years of harassment by laws written to > favour special interests.
I think that the motivation for properly documenting copyright transfers and attributions should not be merely "long years of harassment by laws written to favour special interests". Without such a documentation, OSS risks to lose reputation in a critical sense. It would, for example, be a real disaster for all commercial OSS usage if SCO in fact would be able to prove that some parts of the code of the Linux kernel were improperly attributed and/or licensed (I do not say that this is the fact, I only mention the gravity of the consequences if such findings were the outcome).
The time of "rough consensus and running code" is bygone, like it or not. "Running code and conformity with legal requirements" would more accurately describe the current situation.
If, in my fictitious example, student Y never had agreed his code being aggregated into a bigger OSS library, referring to the law of aggregate works doesn't help.Uh, I don't deny that. But it's irrelevant. I was dealing with why your claimed "examination of an open source project on sourceforge" may be invalid as there are legitimate reasons for the difference you note, and certainly not trying to refute your hypothetical (and not very worthwhile) example. You hypothetical example applies trivially to closed source too and is therefore not an argument against (but may be a weak one for) OSS - if student Y had never agreed to his code been aggregated into a bigger closed source library, it wouldn't help either! - the major difference being that closed source makes such cases somewhat harder to detect (but less hard than the layman might think). That's hardly a valid argument - use closed source, because open source makes it easier to prove I"P" violations??? If anything, you should Open Source so that any potential problems would be clearly visible to everyone and resolved as early as possible, and with no intent to hide evidence on your part.
The time of "rough consensus and running code" is bygone, like it or not. "Running code and conformity with legal requirements" would more accurately describe the current situation. Conformity with legal requirements is a red herring when the law itself is wrong. Just because it was once legal to own slaves doesn't mean it was wrong to wage war against slavers. Just because it is legal in the US and powerful forces are trying to make it legal in the EU to "own" the rights to particular ideas in the software field (and don't give me crap about patents not covering ideas - empirically, they have been shown to effectively do so, particularly in the software realm) doesn't mean it is wrong to wage war against the infofascists.
That's what I don't think you people understand - in the end, all the economic arguments for patenting in the world won't sway us (just as an argument for slavery that slavery would be profitable for some segment of the population are silly): we regard patenting as an infringement on our civil liberty, and will, if necessary fight to the death using every means available to us (remember, we're the ones who design and build and write the software to control machines, in the end you just push paper about) to defeat patenters. We don't _care_ if the poor starving multinationals, or the apocryphal "lone inventor" would make less profits without patent law (even though several economic studies suggest that is itself not true, and that patents are really a tax on innovation) - You are trying to curtail our freedom for your profit, and we will not allow it!
You might cry "Zealotry!" to that: but sometimes zeal is justified, like when fighting tyrannical corporate oppression facilitated by self-serving patent lawyers.
And it's not like most of us don't comply with the letter of copyright law for the most part anyway, it strikes a reasonable compromise between our "no restrictions" viewpoint (copyrights are a restriction, as are patents) and the wishes of others to have restrictions, for whatever sick reason. Corpies should beware pushing to hard for patents, or we might start pushing harder (and we can push MUCH harder) the other way, and they'll find themselves without copyright OR patent.
Feel free to contact PA Axel H Horns via e-mail
horns@ipjur.com. BEWARE: DO NOT SEND CONFIDENTIAL INFORMATION UNENCRYPTED VIA E-MAIL. USE OF ENCRYPTION SOFTWARE IS HIGHLY RECOMMENDED. PA AXEL H HORNS IS PROVIDING SUPPORT FOR ENCRYPTED E-MAIL MESSAGES USING PGP OR PGP COMPATIBLE FORMATS. THE PGP PUBLIC KEY FOR PA AXEL H HORNS IS AVAILABLE
HERE. THE GnuPG PUBLIC KEY FOR PA AXEL H HORNS IS AVAILABLE
HERE.
Dipl.-Phys. Axel H Horns is Patentanwalt (German Patent Attorney),
European Patent Attorney as well as European Trade Mark Attorney. In particular, he is Member of: