> 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. > - 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). > 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. > - 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. > - 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. Correct, I tried to rephrase it to see if this is what you proposed. > No other changes to the call. > As to: > > > -1 because there isn't a text explaining what is offered > to 3rd > parties when the cvs is open. > > I still so not fully understand what that has to do with the > vote itself. Writing such a tekst is obviously something that > should take place, as is creating those needed facilities > (i.e. a webpage for information and/or documentation). > However the latter takes some time. > Note that I did include some text: I want a text to clarify to a potential third party what the vote is all about. I am confident that every committer wants the same thing as you want. It is quiet clear for us what we want, but an outsiders will still have lots of unanswered questions after your vote. The vote is targeted to us. The text should describe our opinions and should be targeted at third parties. Hopefully, third parties will follow our mindset after reading the text. I like the text to be present at the vote so we know what we are communicating to third parties. Nico _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
