How about an official community branch in AOSP?

[Jean-Baptiste Queru]

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.

[Fred Grott]

Seems like a plan..

[Disconnect]

Sounds reasonable from here. I think allowing the community to
contribute non-replacement apps under the [l]gpl license makes sense
too, but that is a decision that can wait until such apps appear and
become "standard"/popular on community builds.

[Jean-Baptiste Queru]

No contest from me as long as we're talking about (L)GPLv2. A number
of players in the industry (including in the Android ecosystem) have
been showing a certain reluctance toward open-source, to say the
least, and have set a certain bar that (L)GPLv2 seems to appropriately
respond to.

This brings a question, though: who should own the copyright on those files?

JBQ

[Fred Grott]

Good question...have several options:

1. New non profit org

2 Apache Software Foundation

and etc..

[Shane Isbell]

I can vouch that the Apache incubation process is really painful. Members have different opinions on what is even allowed and some guys just sit there all day blocking build releases if you miss a header on a unit test resource file or some other non-sense rule, which may be not even decided on by the general community.

--
Shane Isbell (Co-founder of SlideME - The Original Market for Android)
http://twitter.com/sisbell
http://twitter.com/slideme

[Fred Grott]

how fast could we form a new non profit?

[Mark Murphy]

Fred Grott wrote:
> how fast could we form a new non profit?

"Fast" isn't a criterion I would recommend if you want to create an NPO
from scratch. That's not the sort of thing you get a "do-over" for easily.

So long as the process does not drag out terribly long, copyright can be
fixed via (joint) copyright assignment at a later point. It really
becomes painful when you can no longer find the contributors (witness
the suffering Mozilla went through to switch from MPL to MPL/GPL/LGPL,
years after their initial license plan), but that's unlikely to happen
in the next few months.

We could consider the Software Freedom Conservancy
(http://conservancy.softwarefreedom.org/), an offshoot of the Software
Freedom Law Center (Eben Moglen, et. al.). Quoting from their Web site:

"One of the principal benefits of joining the Conservancy is that member
projects get all the protections of being a corporate entity without
actually having to form and maintain one."

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

_Android Programming Tutorials_ Version 1.0 Available!

[Fred Grott]

Sounds like a very good option..

[Jean-Baptiste Queru]

All right, I've floated the idea around at work (though not with
people who have final decision power on something like this). I've had
a positive response overall.

Here are the sticky points that came up:

-This would need to be set up in a way that would make it very clear
that changes in the community branch (which would probably need to be
called "experimental") aren't reviewed and approved by Google and
aren't meant to ship "as is" on consumer devices.

-Anything GPL-related is scary, even v2. Not all of the worry might be
justified. A big part of the concern is to make sure that having GPL
apps doesn't turn the entire system into GPL.

-Gerrit at the moment isn't designed to allow per-branch access rights
(only per-project), so that feature would need to be implemented first
before a community-maintained experimental branch would make sense.

-Contributors to the experimental branch would need to agree to the
standard AOSP CLA.

JBQ

[Al Sutton]

I'm not a fan of branching because it usually ends up with a split
community, work being redone for different branches, and sometimes
ends up with two different products using the same name (e.g. the
Community & the Google versions of Android each with different codec
support, different multi-touch support, etc., etc., etc.)

On point 2, why not make a tickbox on the submission process where the
submitted agrees to relicense any submission under the appropriate
license when used in an Android build?

Al.
--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

[Disconnect]

We are already in a branched environment - there is Android-that-works
(mostly closed, mostly google-experience builds) and Android-source
(AOSP). I think (if I remember correctly from yesterday) the idea is
that "Android-google" and "Android-community" both have roots in
Android-source. So if you are contributing to -community, you are
contributing to the "don't relicense" branch -- otherwise it would be
submitted to Android-source for use in both projects.. (And if you are
submitting to community, chances are you aqre replacing something that
already works in android-google and you don't want your submission to
become closed source.)

Or did I miss something?

[Jean-Baptiste Queru]

I explicitly don't want to think of a community/experimental branch as
"don't relicense". Rather, I'd like to think of it as a place to host
changes that are good enough for knowledgeable enthusiasts to use but
don't quite pass the bar to make it to consumer devices (think of
those changes that use the SD card in a few interesting ways but crash
or lock the system if the card is hot-pulled).

However, as time goes, some changes might evolve and grow into being
relevant for consumer devices as well. I'll take a real-world example:
FLAC support. There are some concerns left to take that code into
consumer devices right now, but there's no fundamental reason why it
would be "forever" unacceptable.

If anything, code in the experimental branch, even if it doesn't
change, can be considered to get better over time, by virtue of
getting tested more.

There will be areas which, by nature, will never be considered for
inclusion in Google-Experience devices (namely, explicit replacements
for Google's proprietary apps). However, if such efforts make the
community branch more appealing, they'll cause that branch (in its
entirety) to be used more, tested more, debugged more, and therefore
will indirectly increase the value of the parts that would be included
in Google-Experience devices. From that point of view, such efforts
could make sense within the community branch of the Android
Open-Source Project (within reasonable limits, of course).

JBQ

[Disconnect]

I guess I lost the thread somewhere - now the community branch is a
place for bleeding edge testing, not just a place to clean up the mess
of proprietary dependencies that google is forcing into the main
tree..? (And possibly add in non-google-approved items like yahoo
syncing or msn default search widgets or whatever..)

[Chad Fawcett]

Agreed, I don't think the licensing should be the determining factor for branches. One of the supposed major advantages of using something like git is making branching and merging easy, so there's no reason that a community/experimental branch should need to develop a sequestered/forked project anathema. My two cents are that if an experimental branch makes it easier for cutting edge/less google-cooked ideas to make it into the repository and get group vetting, while still allowing the parts that make sense for the long haul of the platform to get pulled into master and then eclair or gingerbread or strudel or whatever, while allowing cutting edge users of select devices use it immediately, legally, then great.

Taking Eric F's example scenario from the other thread..I want to scratch an itch and make a change and have it on my usable device within 24 hours. If it's a good itch to have been scratched, and it's legally on my fellow cutting-edgers' devices within 60 days, then the system is working for me. If it is able to end up on that stock motorola device my niece picks up at the verizon store a year later, then, for me (and probably the vendors and corporate sponsors) the system is working even better.

If you feel differently, that's fine..there are other projects and scenarios where I fully support (L)GPL, and others where I'm all for a closed source model.. But if your license ethos doesn't mesh with the apache-esque licenses here, ok, but I would strongly prefer that our politics are able to mesh enough that our contributions can be combined and that they not hinder my (the theoretical "my" that actually submitted a change) less-hard lined preferences and desire to contribute...

 -C

On Mon, Sep 28, 2009 at 12:28 PM, Jean-Baptiste Queru <j...@android.com> wrote:

[Jean-Baptiste Queru]

Cleaning up the dependency mess fixup should be done in the master
tree (and Google will gladly accept the those changes). Those changes
really *should* ship on consumer devices - I'd rather have OEMs focus
on doing interesting things on their devices than trying to figure out
how to make Calendar not exit right away.

JBQ

[Avtar Singh]

This brings a question, though: who should own the copyright on those files?

Can't the copyrights be owned by individual author or the organization to whom the author is affiliated?

In my view, having an "experimental branch" is good idea as it would be easier to keep it synchronized with latest from "master" and other way round. The negative point in this is that it may not always "build" successfully. But if the content in the branch is of good and sustainable interest, then the community would automatically fix that and keep it in "buildable condition".

I can contribute to maintain the branch in "buildable condition", if required, for a period of time and then someone can take over.

- AS

[Gergely Kis]

Hi,

I also think that it is a good idea to create the community branch or
even branches for different purposes (experimental, stable ...)

Do you have a specific process in mind? I.e. who would be in charge of
accepting changesets into the community branches?

One idea regarding experimental changesets: a slight improvement to
gerrit and repo would allow to create special local manifests that
include selected changesets, that were not yet merged.
These manifests could be created and published inside Gerrit, so
bleeding edge features would be very easy to test for even those who
are not developers, but are able to follow a simple set of
instructions.
If the legal distribution of device flashable images is worked out,
autobuild servers could produce these experimental builds, and lower
the bar further for testers.

This system would prevent the review bottleneck plus also keep even
the community / experimental branches relatively stable.

Regarding licensing: I think that the ultimate goal of AOSP should be
to deliver Android to as many devices as possible. And using a license
that is acceptable to OEMs is a very important component of this.

Best Regards,
Gergely

[Jean-Baptiste Queru]

I agree that there's got to be a pair of branches, one being
bleeding-edge while the other one is more stable. I'm getting some
push to call all the non-Google-reviewed branches "experimental", and
the established Android pattern for the stable branch is
"xyz-release", so I think that we're heading toward "experimental" and
"experimental-release".

As for the process, I'd like to move toward a process where some
recognized contributors are given verification/approval/submit powers
in the experimental branches (in addition to Google engineers). This
is not possible at the moment because Gerrit doesn't support
per-branch permissions, so there might be a period where all the
reviews need to go through Google engineers (but that's not meant to
be permanent).

With the way git works (and Gerrit on top of that), there might be
some difficulty being very fine-grained in picking individual changes
without writing additional tools.

JBQ

[lbcoder]

Has there been any update on this? It has been close to a month since
this relatively short (time) discussion. The idea sounds great.
Whatever the naming is, it would be very helpful to have "official"
unofficial branches in terms of focusing the community. The problem
right now is that the community is so fragmented that each small
developer keeps their own small amount of work on their own server(s)
and you end up with only developer A's build having feature A, and
only developer B's build having feature B when what you really need is
both A and B.

On Sep 29, 11:27 am, Jean-Baptiste Queru <j...@android.com> wrote:
> I agree that there's got to be a pair of branches, one being
> bleeding-edge while the other one is more stable. I'm getting some
> push to call all the non-Google-reviewed branches "experimental", and
> the established Android pattern for the stable branch is
> "xyz-release", so I think that we're heading toward "experimental" and
> "experimental-release".
>
> As for the process, I'd like to move toward a process where some
> recognized contributors are given verification/approval/submit powers
> in the experimental branches (in addition to Google engineers). This
> is not possible at the moment because Gerrit doesn't support
> per-branch permissions, so there might be a period where all the
> reviews need to go through Google engineers (but that's not meant to
> be permanent).
>
> With the way git works (and Gerrit on top of that), there might be
> some difficulty being very fine-grained in picking individual changes
> without writing additional tools.
>
> JBQ
>

> ...
>
> read more »

[Jean-Baptiste Queru]

There's no update on this at the moment, but the idea is very much
alive and being considered carefully, and things look reasonably
positive (i.e. the concept hasn't been shot down).

Indeed, one of the benefits of such a branch is to avoid fragmentation
and help people working on custom builds of Android focus on real
innovation instead of spending most of their time tracking and merging
changes from other projects.

JBQ