So much for attending either meeting. Weekend schedules have that way of changing on a dime...
As I was talking with William last week (I like using real names rather than IRC nicks. You get to know people faster that way), I would advocate a dual license between LGPL (maybe GPL v2, but I'll get that in a moment) and a commercial license. This gives us the best flexibility for potential commercial options down the road, while maintaining the openness that the project wants. I would say LGPL over GPL because of the intended modularity that we *will* have in the system. For the sake of avoiding confusion, I refer to the "kernel" as the whole system (JIT compiler, VFS, scheduler, memory, everything, including the other system-level microkernel servers). By using LGPL for the whole kernel and system, rather than just the CLR userspace libraries (the BCL from the CLR spec, corlib, etc), this allows us to develop "premium" kernel modules that may be under a different license, or even closed-source. For example, to stem off another discussion, we could have a standard GC in the open version of the system, but sell a high-performance or embedded device / low memory GC module that is closed source. This wouldn't be possible if the kernel was purely GPL. Further, using LGPL will alleviate grumbling on the part of device manufacturers writing their own closed drivers. We must accept the reality that they will want to keep their drivers closed-source. Even though this doesn't mean much in the CLR bytecode world, where someone could rather easily reverse-engineer the bytecode. But like Apple DRM, with a nod and a wink more or less, it's the thought and flexibility that counts. Now, for purely commercial interests, like MySQL and others, we can dual license under a commercial license for those companies who don't want LGPL at all. This would make most sense in the case of an embedded device manufacturer who wants to embed a customized version of SharpOS (some futuristic cable set top box / home media server comes to mind). Or we could require commercial licensing for general computer manufacturers who want to load and brand SharpOS on their systems (e.g. Dell). The big requirement for doing this dual-licensing is that anyone who contributes to SharpOS must have on file some type of copyright assignment. MySQL, Trolltech, and others require this, because of their commercial licensing. If people don't want to sign the assignment, then we would have to maintain another fork of the OS. Then someone would have to go back and clean-room reimplement that open code in the commercial branch. I'd be happy to write up a sample assignment paper, as I'm used to it. But it's important that we get such a large decision out of the way now, before we get a huge number of commiters. Finally, don't quote me on this because I'm not a lawyer (duh), but remember that copyrights only cover the specific implementation, not the idea. Thus, and while I'm not directly recommending we do this, you can look at Linux, BSD, etc code, get the *idea* of what it does (especially drivers for hard-to-document devices), and then write our own code. We just can't directly copy and paste. And in reality, we couldn't copy and paste anyway, since we're using a completely different language / environment. Okay, long email number one down... :D I'll let everyone discuss this before I go on to write the next one. ------------------------------------------------------------------------- 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
