I apologize... I picked the one item on our agenda which needed the most public visibility to forget. We also have a proposal to create a private board IRC channel which can be used for private/sensitive board discussion (which is logged, but the logs are kept privately). The proposal also outlines an accountability policy for the board which makes it possible to force the board to release log information from that channel (and in fact, any sensitive information it may have in trust, that doesn't open us to legal liability). The proposal has not been brought to vote yet.
On 9/3/07, William Lahti <[EMAIL PROTECTED]> wrote: > It's been only a bit more than a day since we officially created the > SharpOS Provisional Governance Board, but we've been very busy. > > The board voted in a proposal to adopt the initial policy that I > wrote, which was the first piece of official policy for the SharpOS > project. The policy recognizes the powers of the board, outlines > procedure for adding new members, and discussion/voting. Six out of > seven votes were cast, and the decision to adopt it was unanimous. > > We adopted a proposal that outlines time frames for completing > motions. A motion only lasts as long as less than half of the board > has voted on it. Normally motions have 30 days before they expire (and > are acted upon), but they may also be marked as "Express" or "ASAP" > motions. Express motions have a time limit of 7 days, and ASAP motions > have a limit of 3 days. Five votes were counted, unanimously adopting > the proposal. > > One board member (Michael Schurter) relinquished his seat on the > SharpOS board. He did so by unsubscribing to the list, I believe as a > response to the reminder email I sent to the inactive board members. > We've also acted on the first request to join the board, from Chad Z > Hower. The board denied the request, with five votes counted, > unanimous. > > There are still a few proposals pending right now. One requests the > use of parliamentary procedure to speed things up and make sure things > get edited before voting. > > A discussion is currently happening about creating a preliminary > position for new members of the board, where membership has either a > limit or is more susceptible to revocation. > > Beyond completing the remaining membership requests, there is still > more work to be done: > - We should define positions on the board such as secretary (for > tracking accountability, keeping records, and maintaining the display > of board information on the website) and chairman (for breaking ties, > summing completed motions, and as a central point for contacting the > board / PR), > - We should round out the SharpOS policy related to the board and > adopt the policy as the bylaws which govern us (input from the > community is needed a lot here on what is deemed most important). The > bylaws part itself is not strictly necessary, but it would reason > spreading the affected policies into a new BoardBylaws wiki, help > discussion by letting us just refer to it as "the bylaws" instead of > "the official policy regarding the board" or so. > > This is just my personal list, but I think we'll be at a point where > we can begin working on licensing, which is one of the biggest reasons > we did it. I believe all of the people who hold copyrights to the > SharpOS code are on the provisional board, which will speed up the > process significantly. But I want the heart of the matter (what > license do we pick?) to be talked about _here_ and not on the board > list. The decision deeply affects anyone who wants to contribute code. > In previous discussions I think the MPL license looked to be the > smoothest choice among the people involved. Does this really hold > true? Do you think the MPL is a good choice for licensing SharpOS? > There was also talk about adding an attribution clause alongside the > MPL license if we choose it (and call the licensing combo MPL with > Attribution). > > Dual licensing: we've typically talked about dual licensing on 2 very > different licenses, such as GPL and BSD or a similar permissive > license. This is only one case, and I'd like to remind the group about > doing combinations of _similar_ licenses, which makes things much > easier when trying to combine two pieces of code with similar but not > equal licensing. For instance, MPL/GPL dual licensing would allow the > code to be used in the more permissive, weak copyleft manner, and also > allow developers of GPL projects to use our code. This doesn't mean > that the code is locked under the GPL (quite the opposite), nor does > it mean that GPL licensed code can be added to SharpOS, but it does > mean that more open source projects can make use of our code while not > sacrificing commercial developers and interest. > > Please discuss, comment, and flame :) > > -- > fury > > long name: William Lahti > handle :: fury > freenode :: xfury > blog :: http://xfurious.blogspot.com/ > -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
