Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Jean-Baptiste Queru <jbq-z5hGa2qSFaRBDgjK7y7TUQ <at> public.gmane.org>
Subject: How about an official community branch in AOSP?
Newsgroups: gmane.comp.handhelds.android.platform
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
-~----------~----~----~----~------~----~------~--~---
 
CD: 3ms