Ok, looking at the changes between this one and the original vote:
Excellent.
- All code submitted must follow the MPL. This may change later, but we don't want a full discussion on licenses right now.
> - The recommended license for these kind of packages is the MPL or any > compatible
> (BSD-like) license.
You propose a slighty more relaxed license policy, which I persoanlly don't have issues with, but which is a discussion I didn't want to start yet. If nobody else objects I don't mind this chnage.
Actually, I copied this from the document Gerard wrote. I think Gerard is the best person to decide which version should be in the vote. I like your reasoning to only allow MPL for the moment.
Maybe it's better for the time being to stick to the MPL (1.0 or 1.1), but I think 3rd party apps can use every compatible (bsd-like) license in the future.
- All code must follow MMBase code conventions and have documentation (or aim to fulfill these requirements as soon as possible).
Was dropped. As I wrote earlier, this is not really an 'extra' rule, it is applies already. So even if I drop it in the vote, it still applies in general. In the end though code conventions are mostly guidelines.
It is third party code and that shouldn't have to follow our code conventions. When it want to become a community package then it has to comply. And like you write it are guidelines (best practices).
I think it doesn't have to follow our code conventions, but it's preferable they do.
One thing that I do think important is that projects use the same build process (where appicable). If a package doesn't, there is no way to distribute that package, except when people build it themselves in cvs using their own tools.
Note that I don't mind 'maven' for this (even though I don't know how to use it), but as currently the ant builds work, I would suggest that if soemone desires this it be done by a project (a Distro II project perhaps), and therefor it is not part of the vote.
It is third party and the maintainer is responsible for it. If it can't be build in the way we build then it is his/her problem. If we have a build process that is suitable for most cases then others will likely use it.
It must be made clear if a 3rd party app wants to make a change of getting into the default distro, they must follow the standard build process.
- The application/component must be generic, useful, and applicable with a broad enough systems and configurations of MMBase (i.o.w., no vendor-locking).
Was dropped. I think though that this (or something smilar) should be included as it allows people to judge packages for inclusion, and re-affirms that they can use their own judgement.
Defining which type of packages we have and explaining why we are offering a
third party infrastructure should be enough. Maybe this should be added, but then with a less forcing tone. It shouldn't
be a rule, but a guideline.
People who want to make things open source should answer the question: why do I want to make it open source? Personnally, I would never open source WIAB, LeoCMS or Surfnet. Not because they aren't great sources to learn from, but they are too specific for a customer and there is too much functionality in there everyone don't want. Everyone who wants to see the sources already plans how to strip the application to make it more usable.
I would prefer reusable components in the 3rd party repository and projects like wiab/leocms/etc must have their own cvs-repository (maybe on mmbase.org, maybe not).
- A committor (not necessarily the same person who amde the vote) needs to maintain the code. It is possible to make someone a committor for the express purpose of maintaining 3rd-party code (with the expected limitations on such a committor's rights to change code), but an existing committor should [still call the vote].
(note: last bit got dropped in the original vote mail for some reason) This is bacically left the same but formulated in a different way.
Most import: an existing commitor must 'sponsor' the new to be added 3rd party app and people can be made commitor for one project.
You removed the part of the MMBase-commons from the document I wrote, but I think that's maybe a seperate discussion. I still find it a good idea to have a commons-sandbox (the present speeltuin) and a commons-main.
Gerard _______________________________________________ Developers mailing list Developers@lists.mmbase.org http://lists.mmbase.org/mailman/listinfo/developers
