Linked by Thom Holwerda on Thu 17th Feb 2011 20:33 UTC, submitted by Radio
Permalink for comment 463022
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
More News »
Sponsored Links



Member since:
2005-06-29
Microsoft could accept the source code from the upstream provider, check that it compiles & runs properly, put the source code on a separate server and the binary DRM'd installable app in the app store (thereby being fuuly compliant with the GPLv3 license requirements), and provide their WP7 users with more free choice for almost no cost to Microsoft.
This is a lot easier than a commercial third party app, where Microsoft has to work out revenue sharing with the provider.
Revenue sharing decisions are made by non-engineers, and in most cases will be boiler-plate.
This would add:
1) The need to identify which products required/offered source code to be publicly available.
2) Creating a process for uploading, backing up, and downloading the source code.
3) If there were a step to verify that the source matched the binaries, engineers would be required to obtain the tool chain and libraries needed to re-create the environment in which the original binaries were created.
This is effort. This requires that distributors adapt their processes to the provider, rather than set terms that the provider must meet. This is a cost to the distributor, one which a distributor can reasonably object to taking on.