Next post, concerning the future position of the SharpOS Board as a legal entity...
Again, the way I envision it is a hybrid between the FreeBSD Foundation's relation to FreeBSD itself, and Canonical's relation to Ubuntu. Neither the FreeBSD Foundation or Canonical directly own the copyright to any part of the code base. What they do is own the trademarks, logos, etc to the projects, along with providing official support and engineering assistance. This is where we, in the future, will probably get into SharpOS the project, and then the SharpOS Board / Foundation owns the logos and trademarks, and gets to say "This is The Real SharpOS [tm]". One interesting twist to this is that the FreeBSD Foundation acts as the legal entity concerning the project when a legal entity is required. I am not sure how they do this without having copyright assignment waivers on file for anyone who contributes to FreeBSD. Obviously, if I contribute to FreeBSD, I don't have to assign my copyright over to the foundation. But I have written an email to their board, asking how they dealt with this, what situations they specifically mean when they say "when a legal entity for the project is required", etc. I will post that response if / when I get it. As a future note, I do have experience in incorporating, setting up the proper legal entity structure for geographically-distributed groups like us, etc. I had to do it for SimuNex back in 2004 for one reason or another, even though I've never spent a dime or received a dime for that company yet. :) It's a little harder for non-profits, because of the obvious checks and balances needed to maintain non-profit status. But it's not *that* hard. For those curious, MySQL and others require copyright waivers for contributions to their mainline codebases because they are dual-licensed under both a community and closed-source commercial license. This is what lets MySQL outright sell closed versions of their database, and also why they have a separate community edition. Based on my previous post about MPL vs LGPL, this is not necessary. SharpOS, architecturally, is a large number of modules all communicating between each other. If a commercial-type module is necessary, then the SharpOS Foundation (or whatever future legal entity) can provide the necessary engineering support for that, and license accordingly in something other than LGPL / MPL / whatever we pick. Since the Foundation's engineers would be writing a new module that simply links to the existing codebase, and doesn't outright extend it, that's how we can get away with licensing in a different license without needing copyright ownership of the existing codebase. To the MPL / LGPL, we are a 3rd party creating a closed-license module that links back against the existing modules. Hope this post also made sense. :) Basically, for our envisioned purposes (even the commercial ones), we don't have to worry about having contributors assign copyrights to a non-existent future legal entity. --Scott ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
