Participating in an Open Source Project
One of the great things about an open-source project is that it enables
developers and users to co-operate to help the product fulfil its
potential. You develop a plug-in module, or you enhance the functionality
of a class, and by sharing it with other users you increase the general
usefulness of Wonka. Then other people try to use your stuff, and they
find bugs or they suggest improvements or new uses for your code: so you
end up getting more out of your code than you would have done by keeping
it to yourself.
So it goes without saying that contributions are always welcome, be they bug fixes or enhancements or documentation. However, we need to set some ground rules to protect the project from abuse, legal problems, and excess of entropy.
Approval of Changes
To deal with the last point first: simply allowing everybody
to make changes to any file is probably not a good idea;
problems would arise when two people started making incompatible
changes to the same code, or if someone were to ``optimise'' code which
was written the way it was for a very good reason.
Worse, it would make it impossible to keep our legal house in order,
and would open up possibilities for sabotage.
The project is therefore controlled by a ``core group'', to whom all contributions should be sent in the form of patches. Core will then review them and, if approved, will incorporate the patches into the source tree. Initially the core group is drawn from the original development group at ACUNIA, but it will co-opt members from outside as the project progresses.
If this system proves to be a bottleneck, then we will find ways
to automate or to streamline it. It should evolve with the project.
Clean-Room Conditions
Wonka has been developed completely independently from Sun's JDK. We intend to keep it that way. To start with the bad news, we cannot accept any code from you if you have signed any kind of Non-Disclosure Agreement with Sun or another JVM vendor.
Ideally, if you have Sun's JDK installed on a computer then you should delete all the source and keep only the Runtime Environment. Even if you don't do that, you certainly shouldn't refer to it when doing work on Wonka, not even to get an ``overview''.
These conditions aren't dictated by us, they are implied by the licence you have from Sun to use their code. We mention them here because by doing the Wrong Thing you would be getting both yourself and the project into a lot of unnecessary bother.
Similar considerations apply if you have access to source code from some other commercial Java such as those from IBM, HP, or NewTronics. Your agreement with them probably doesn't allow you to use their sources to help develop another product, so don't do it.
The situation with other open-source projects is a little different. Simply cutting-and-pasting of code from the other project to Wonka is only possible if the licence used by the other project permits it (the GPL and its close relatives certainly do not), and if you comply with all relevant copyright requirements. On the other hand reading the code of another open source project for information and ideas should not create a problem: one of the fundamental ideas behind the open source movement is that programmers should be able to study each other's work and learn from it.
Copyright Questions
Code needs to belong to someone. In fact under the Berne convention, anything written today is copyright © someone or other, even if they don't know it.
Things get interesting (from a lawyer's point of view) if a single work
contains parts which are copyright © lots of different people.
Even defending the copyright becomes difficult, as there is no single
party to take an infringer to court. (This is not purely theoretical:
some Open Source projects have gotten themselves into a mess this way).
If you contribute more than a very small amount of code to the core project then we will ask you to formally assign the copyright to us. This helps keep the ownership from becoming fragmented, and also protects us (and therefore ultimately you) against some Mean Tricks.
(Imagine for example that a company were to contribute code but retain the copyright in its contribution. Years later, when you are using Wonka in your best-selling MP3 toaster, they could change their mind and announce that anyone who wanted to continue to use their contributed code would have to pay them a licensing fee. Instant crisis. The only way we can prevent someone else from doing that to you is by making it impossible for you to do the same to anyone else.)
If you design a self-contained add-on for Wonka, then you can licence it any way you want: however for the sake of clarity we will only host on our website and its mirrors code which actually belongs to us. Third-party code will be pointed to by a link with an accompanying note which makes it clear that ACUNIA is not the owner of the code.
If however you make changes to Wonka, Rudolph or OSwald themselves, or add new code which you want to become part of the distribution, then we need to ensure that this does not result in a copyright muddle.
Small changes:
ACUNIA NV hereby grants you the non-exclusive, worldwide right to make bugfixes and other such small changes to the initial and/or present version of the source code of Wonka in order to improve and extend the initial and/or present version of the code. These changes shall be considered derivative works and therefore you explicitly agree and acknowledge that all title, rights and interest in and to the initial and/or present version of the source code and these changes shall vest in and remain with ACUNIA NV. If you do not or cannot agree to the vesting of ownership rights in ACUNIA NV, do not contribute your changes.
Larger changes:
If you provide large changes or large amounts of software code to the initial and/or present version of the source code of Wonka, you will be asked to assign all your pecuniary and moral rights to the contributed software, in object and source code form, to ACUNIA NV to the maximum extent permitted by applicable law.
If assignment of copyright in the software code that you provided is not possible, we may be able to negotiate some alternatives which can satisfy all parties.
By the way assigning copyright to ACUNIA does not mean that we will not acknowledge your contribution: on the contrary you will be listed as a contributor both in the source code and on the website (there will be a Contributors page as soon as we have some contributors to put there).
Coding rules
There are some standards which we have tried to stick to, and we ask you to stick to them too. You probably won't agree with all of them; no software developer ever agreed completely with coding rules he didn't write himself (and maybe not even then). By sticking to the rules, you are helping to produce a body of code which forms a logical, cohesive whole.
Tip: try to resist the urge to re-format code to your preferred style before you start work on it (even if you intend to put it back in the original format later). When you do that you make it harder for yourself to produce a patch (see below) which we can review and apply.
Submitting a Patch
If your patch solves a problem in Wonka, write a brief description of the problem and how your patch solves it and generate a patch listing using diff -u oldfile newefile. Mail both to wonka-bugs@acunia.com.
If you have ideas about improving the performance or functionality of Wonka, OSwald or Rudolph then you should mention this on the wonka-developers@acunia.com list. One of the core group will then contact you to make arrangements.
In both cases we will need confirmation from you that you agree
to the copyright rules mentioned above.