On 13/05/10 20:26, Geoffrey Broadwell wrote:
As a matter of copyright management we can't just import code from other projects without a copyright notice (and probably a link to the original project). As a matter of supportability it's important to keep in touch with the upstream project regarding bugfixes and the like. And as a matter of good manners, it's nice to at least talk to the original project before copying the code. At the very least they may suggest how they'd prefer it be done, or in fact already have a process for working with downstream projects harmoniously. Does PaFo have an official policy on copying external code? (Assuming the license is already compatible, of course.)
Thanks for bringing this to the mailing list, Geoff. I saw those commits going by, but I assumed the external project developers had made them.
All three ways work, but the meaning is a little different for each, so it's worth putting up a wiki page explaining the difference.
1) If you keep your code in an external repository and distribute it as a separate module, there's no connection to the copyright, license, or support infrastructure of Parrot. For the most part, I expect most external modules to go this way, especially once Plumage flies.
2) If you keep a copy of (parts of) your external code in the ext/ directory in the Parrot repository, there's also no connection to the copyright of Parrot, and the license can be any open source license that allows aggregation. The Parrot project does not give support for these external projects, so any bug reports related to them go up to the original project. Some projects (e.g. NQP-rx) ship in ext/ for easier distribution or better visibility.
3) If you put a copy of (parts of) your external code in the Parrot repository outside ext/, it works like an ordinary code contribution. That means you still own your original copyright, but also grant Parrot Foundation a license to distribute that code as part of the larger Parrot copyright. In that case, we strip off copyright notices other than Parrot's, because the "umbrella" copyright is the only one users need to think about. In this case, you should make sure you have a Parrot CLA from the committers to your external repository, so Parrot Foundation can grant all users the same rights that they grant for other parts of the repository. By including the code in the main repository, the Parrot team is agreeing to provide support for the code, and accept bug reports related to it (some bugs may be forwarded on to the original project, if that's a more useful place to deal with the bug).
Note that I'm talking about the external developer's choice of whether to include the code in the repository. The external developer or developers own the copyright to the code, and we cannot make that decision for them. In cases where we haven't talked to the external developer, we should restrict any inclusions to the ext/ directory, where the full original copyright and license notice remains intact. This includes not only external modules, but any low-level (C) libraries. It's not legally required to talk to the developer before adding code to ext/ (i.e. if we're using some random C library off the web that's open source licensed, the developer has already given permission in the license), but if it's developed by a Parrot developer, we really should talk to them first.
For now, I recommend removing the Plumage and Tapir code that was included in Parrot and let the developers decide what they want to do.
There are some build process considerations here too. If we get a large amount of external code in ext/ to the point where it's causing build dependency difficulties, we may need to start building in a temporary build/ directory, where we can merge internal and external code before or during the build. (We've talked about doing this anyway, to make installation simpler.)
Allison _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
