There's been some discussion about re-packaging 3rd party FOS code with Moin (see here and here).
I feel I don't know enough about what are the exact steps required to do the re-packaging, and the practical implications of it.
- Does re-packaging mean simply including the 3rd-party code as-is in Moin's tarball? Or does it imply code modifications?
- What about accompanying non-code ressources (like images)? If there license is "compatible" with, say, the Apache License, but not with GPL2?
- What about 4rth party code on which the 3rd party code may be based?
- What about copyright ownership (copyright holder)? Any immediate or future implications?
I'd be grateful for hints and/or references on this.
Thanks a lot -- ZoranIsailovski 2007-11-10 10:20:49
Zoran - I'm not a lawyer, so I may not give you legal advise. However, just keep in mind that:
By law any author holds on any work he created the full copyright. Any other person than the author may use his work only in cases explicitly allowed by applicable law (which will depend on the country in that this person uses the work), or in the cases allowed by the copyright holder (the author) by contract. This contract is called "license". It typically allows the licensee to use the work in other (more) cases than those permitted by law anyway. Typically the term "use" may refer to publishing (distribution) and/or modification of the work, as these actions are not allowed by law.
So we have here 3 "spheres": 1st the author who may do or not do anything with his own work. 2nd other persons that may do things with the work only if explicitly allowed to do so. They may obtain this permit either 2a) by applicable law, or 2b) by a contract with the copyright holder (author). In most countries, the publishing (copying) and modification of a work is not allowed by copyright (!) law, so only the author himself may publish, copy, or modify his work. But the copyright holder (author) may give other parties the right to do so, provided that they pay a fee, or meet a certain condition or whatever the contract (license) says.
So the essential questions are: what is a "work" and what does the "license" say. In case of FOSS software, every single contribution (code, documentation, art work) is a "work", but if it's merged with other works, they may become together in the whole a work of its own. This is a very common case, just think of a patch you submit to a FOSS project: you are the copyright holder for the patch itself, but it will become part of a larger software, of which you and any other contributor are co-authors, holding the copyright of their respective contributions. Certainly, this can work only if any single author licenses his code to all other co-authors and vice versa, else they would neither have the right to form a work based on an other work (modification, i.e. the patch), nor to re-publish this new work (the merged source code containing the patch). FOSS license models will extend this right not only to the co-authors or a company holding the copyright, but to the public, thus making virtually anybody a potential or future co-author.
In exchange, FOSS licenses often give this right only under certain conditions, like the liability to re-publish always the source code, or not to apply any other conditions to those of the license (which means not to change the license terms). You will have to meet these conditions if you need the right to do something with the work that is granted only with the license—if you are the copyright holder, you don't have to follow the license terms, because you don't need a license to so something with your own work, you are permitted to do so by law anyway. But others will probably need to invoke the license to legally copy, modify, or distribute the work. In case you accepted contributions to your code, you will have to handle at least that portion of code, if not the resulting work as a whole, according to the terms under that this contribution was licensed to you.
As the copyright holder, you don't have to license you work under certain conditions, as you don't have to license it anyway. So also the choice of the license terms is up to you. But in the FOSS arena, you probably will choose an existing license model, as you probably won't reinvent the wheel; and in most cases you will choose a GNU license and/or the license used by the project to that you wish to contribute (e.g. LGPL for OpenOffice.org). That way, your work may become part of an other work, but also other works may become part of your work. It is even possible that a work based on your work (D) some day replaces your work (A) in the project to which you used to contribute (P): instead of A -> P and A -> D or A <-> D we than have A -> D (-> E -> F) -> P.
You see, this decision has to be made up very wisely. The GPL licenses have a very strong "copyleft", which means that if a GPL'ed work is merged with an other work, the resulting work must be licensed as a whole and exclusively under GPL. And while it is possible to re-license LGPL'ed works under GPL, there is no way back. Even more complicated, if a work is licensed "under GPL v.2 'or any later version'": in that case, the licensee has to decide first which license he invokes. If he opts of "any later version", e.g. GPL v.3, there is no way back, too.
You see how easy an imprudent license policy can result into a fork. That's why I don't think dual license models solve problems—the LGPL/GPL and GPL2/GPL3 problems are proof enough for this.
I hope this clarified some of copyright and license problems to you; but please remember that I'm was always talking of the situation in Germany.
-- MartinBayer 2007-11-10 14:41:10