Microsoft Ponders Shared-Sourcing SQL Server

i_frame writes "C|net is reporting in an interview with Tom Rizo, director of product management in Microsoft's SQL server unit, that 'the company is thinking about including the forthcoming SQL Server 2005 in Microsoft's shared-source program for disclosing product source to customers'. Is Microsoft reinventing themselves, and are they ready to learn the benefits of open source?" From the article: "It's not finalized. It's not anything there, but if a lot of customers demand it, we'll definitely look at doing shared source with SQL Server..."

Comments

Share Source is not shared

[cyber_rigger]

It is look but do not touch

Re:Share Source is not shared

[Lxy]

IIRC, Shared Source is limited in several ways.

You do not get a complete copy of the source. You get large chunks... enough to examine the code, but not enough to compile a working product.

Modification is a no-no. Even sending code modifications to Microsoft is against the license. You may NOT modify code or write patches against the code.

You absolutely may NOT incorporated shared code into anything. If you've seen MS source code, you must wash your eyes and cleanse your brain as not to inadvertantly introduce MS code into other projects. Some would say it goes as far as not participating in GPL projects.

Shared source is to appease the customer who wants the ability to evaluate the code and audit its safety. It goes something like "purchase XXX licenses, and we'll show you the source code. Of course, if you don't like the poor quality of the code, you don't get a refund, just that sinking feeling that you're screwed.".

shared source is a trap

[idlake]

Once you look at someone else's source code, you run the risk that they claim that your own future work is "derived" from theirs. Some shared source agreements are quite explicit about that, while others are merely silent on the issue. Some shared source agreements also explicitly state that the code you are looking at is unpublished and contains trade secret information.

The only way to guard against those claims is not to look at other people's source code unless the license not only permits you to look but explicitly permits you to reuse. Open source licenses do that, shared source licenses don't.

Shared source isn't new. AT&T UNIX and DEC VMS were "shared source", for example. Companies hand out shared source licenses because they are too cheap to fix their own bugs and want to get bug reports with fixes from customers, because they want customers to be tied more closely to their product (making it harder to switch), because they want others to do their porting work for them, and/or because they actually want to lay traps for open source developers.

If you have looked at any shared source source code under a non-open source license, do not work on any related open source or proprietary project; you would be putting those projects in jeopardy. Do not be fooled by "shared source" that's downloadable with a click-through: it may look like open source at first glance, but whether it's downloadable or whether you have to go into a room with five lawyers and sign an elaborate agreement may make some difference if it came to a court case, but it doesn't change the principle. Furthermore, most of those cases won't get to court: your future employer or open source project will probably unceremoniously dump you if there is even a hint that you have looked at shared source.

In other words, before you look at some company's proprietary source code, think carefully whether you want that company to own a piece of your brain for the rest of your life, because that's what it comes down to.