On 7/23/07, Scott Balmos <[EMAIL PROTECTED]> wrote: > So much for attending either meeting. Weekend schedules have that way of > changing on a dime...
Yeah the second meeting didnt turn out... > 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. So I'd assume we're talking about offering a proprietary-friendly license to those who can't use GPL/LGPL ala mono, as opposed to just releasing it with an option of two licenses? > > 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. I agree. I think anything that provides interfaces for pluggable code should be LGPL, and GPL for tools, the kernel core, etc > 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. True... although LGPL does not have any requirements for those who create modules that link to the original code. > 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). I agree. > > 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. Here's a sticking point, because we don't have a SharpOS organization-- is assignment viable before we even have an organization to stand for the code? Right now all the code in the trunk is (C) SharpOS, which is a non-existent organization. We did include the author names in the right places so we know who actually wrote what code. > 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. Right, which is why I brought it up :) > 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. Of course. We've got a great method of forcing clean room implementation-- as long as no one gets a hold of the Singularity code :-P > 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 > -- 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
