Thanks for taking a critical but honest look at the licenses. I agree that they're really short and easy to read, and I personally found that refreshing and a big step in the right direction.
I think it's important to understand that the "limited" licenses will allow for Microsoft to release source code that might otherwise not be able to be released at all (political reasons, etc.)
Also recognize that there are two true "free" licenses here - the Ms-PL and Ms-CL should indeed be qualify as free software licenses; I'm interested to hear commentary from the FSF on this.
The other three are more limited - the Ms-RL "reference license" could be used to allow people to trace into our source code, so they can have a better debugging experience. That's how I see this license being used, and for this reason it serves its purpose.
The other ones, the Ms-LCL and Ms-LPL do have a platform limitation. I will expect that they'll be used when an internal Microsoft group is in a situation where they can't get approval for the "free" licenses and they need to settle for a partial victory. In my opinion, a partial victory is better than nothing.
Um, we've always had ReiserFS. You forgot to enable "experimental features" in your kernel config... and, um, this was actually covered in the documentation:)
You'll notice that 3Com says that two techniques are used to turn this 12-bit screen into a pseudo-16-bit screen. The first of these techniques is "frame rate techniques," in which pixels are changed quickly between two colors in order to simulate a third color -- now, *if* this is being done *in hardware*, then I think it's fair for them to say that they have "x *effective* colors," where x > 4096.
What gets me is when they have to fall back on mentioning dithering -- the process of using *multiple* pixels to simulate an intermediate color. I hope they are doing this in hardware and not relying on Palm developers to do it for them.:) Even so, unlike "frame rate techniques", I don't see "dithering" (even when done in hardware) as a means to boost their claim of the number of colors that their panel can display, because even hardware-based dithering will degrade the effective screen resolution.
I think that people are interested in "bits per *pixel*." If 3Com wants to say "5 *effective* bits per pixel," (because they're using hardware-based pixel-flipping techniques) then I think that's acceptable. But if you're going to avoid mentioning pixels and start talking about "color combinations," then I think they've crossed the line of common sense and are trying to be deceptive. We don't care about how many possible colors we can display using 4 pixels -- we want to know how many we can display using *1 pixel*!
Actually, Linux PPC kernel developers are taking this issue very seriously since it *could* potentially affect PPC systems too. No confirmation, and probably *not*, but a long conversation ensued over the PPC's "BAT" on LKML....
Slashdot Mirror
Thanks for taking a critical but honest look at the licenses. I agree that they're really short and easy to read, and I personally found that refreshing and a big step in the right direction.
The Ms-PL does *not* have a platform restriction. See: http://www.microsoft.com/resources/sharedsource/li censingbasics/permissivelicense.mspx
i censingbasics/limitedpermissivelicense.mspx
The Ms-LPL *does* have a platform restriction. See: http://www.microsoft.com/resources/sharedsource/l
Your comments seem to confuse the Ms-PL and Ms-LPL. "L" means "Limited," ie. platform restriction.
The Ms-LPL is the Ms-PL with the addition of a Microsoft platform restriction. The Ms-PL doesn't have any such restriction.
I think it's important to understand that the "limited" licenses will allow for Microsoft to release source code that might otherwise not be able to be released at all (political reasons, etc.)
Also recognize that there are two true "free" licenses here - the Ms-PL and Ms-CL should indeed be qualify as free software licenses; I'm interested to hear commentary from the FSF on this.
The other three are more limited - the Ms-RL "reference license" could be used to allow people to trace into our source code, so they can have a better debugging experience. That's how I see this license being used, and for this reason it serves its purpose.
The other ones, the Ms-LCL and Ms-LPL do have a platform limitation. I will expect that they'll be used when an internal Microsoft group is in a situation where they can't get approval for the "free" licenses and they need to settle for a partial victory. In my opinion, a partial victory is better than nothing.
Personal thoughts from...
Um, we've always had ReiserFS. You forgot to enable "experimental features" in your kernel config... and, um, this was actually covered in the documentation :)
You'll notice that 3Com says that two techniques are used to turn this 12-bit screen into a pseudo-16-bit screen. The first of these techniques is "frame rate techniques," in which pixels are changed quickly between two colors in order to simulate a third color -- now, *if* this is being done *in hardware*, then I think it's fair for them to say that they have "x *effective* colors," where x > 4096.
:) Even so, unlike "frame rate techniques", I don't see "dithering" (even when done in hardware) as a means to boost their claim of the number of colors that their panel can display, because even hardware-based dithering will degrade the effective screen resolution.
What gets me is when they have to fall back on mentioning dithering -- the process of using *multiple* pixels to simulate an intermediate color. I hope they are doing this in hardware and not relying on Palm developers to do it for them.
I think that people are interested in "bits per *pixel*." If 3Com wants to say "5 *effective* bits per pixel," (because they're using hardware-based pixel-flipping techniques) then I think that's acceptable. But if you're going to avoid mentioning pixels and start talking about "color combinations," then I think they've crossed the line of common sense and are trying to be deceptive. We don't care about how many possible colors we can display using 4 pixels -- we want to know how many we can display using *1 pixel*!
Actually, Linux PPC kernel developers are taking this issue very seriously since it *could* potentially affect PPC systems too. No confirmation, and probably *not*, but a long conversation ensued over the PPC's "BAT" on LKML....
Best Regards,
Daniel Robbins