Subject: How about an official community branch in AOSP?
Date: Sunday 27th September 2009 17:01:09 UTC (over 8 years ago)
Summary: should we create "community" branches in AOSP? So far, the Android Open-Source Project has been set up such that contributions were being considered primarily for their appropriateness in Google-Experience devices (those are the devices where Google gets the most involved), secondarily for their usefulness in the ecosystem as a whole. There are some positive aspects in that setup: -it guarantees that the vast majority of contributions accepted into the Android Open-Source Project master branch eventually make it into Google-Experience devices, and from there into official tagged release branches of the Android Open-Source Project. Google's internal eclair branch incorporates about 9 months worth of accepted contributions. -it helps control the drift between the master branch and the official tagged releases. There's one big negative aspect in that setup: -it can't deal with changes that are valuable in home-brewed builds but not in Google-Experience devices. I'd like to find a way to resolve the negative aspect without damaging the positive ones. I'm thinking that creating a community branch in the Android Open-Source Project could solve that: the master branch would still hold its current properties, but the community branch would be able to take in some of the more "bleeding-edge" changes (and even host additional modules that don't make sense at all for Google-Experience devices). License-wise, this is my opinion of how it'd have to be set up: -the licenses on the existing modules aren't changed, so that the changes done in the community branch for those modules can be brought back into the master branch (and from there into official releases). -new modules that are brought in from existing open-source projects keep their license (see below about GPLv3), so that changes can be contributed upstream into those projects. -new modules created from scratch should be under ASLv2 if they could potentially be integrated into the master branch, ASLv2 or (L)GPLv2 if they're fundamentally replacements for Google apps. BSD-like could be considered for special cases where it's more appropriate than ASLv2. -(L)GPLv3 is out of the question in all circumstances - it scares the phone industry so much that we'd be hurting the entire Android ecosystem if such code made it anywhere into the Android Open-Source Project. JBQ -- Jean-Baptiste M. "JBQ" Queru Software Engineer, Android Open-Source Project, Google. Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-platform" group. To post to this group, send email to android-platform-/[email protected] To unsubscribe from this group, send email to android-platform+unsubscribe-/[email protected] For more options, visit this group at http://groups.google.com/group/android-platform?hl=en -~----------~----~----~----~------~----~------~--~---