Rockbox mail archive
Subject: Re: Legal issues, names, privacy, and pseudonyms
From: BlueChip (cs_bluechip_at_webtribe.net)
At 22:11 09/06/04, you wrote:
>>There is a solution to this puzzle, it's finding someone who is smart enough
>>to work out what it is! I do not believe in "impossible"
>The traditional solution is, of course, a fork distributed as a patch to
>the release source. For example, when Alan Cox wanted a more feature rich
>bleeding edge kernel than Linus Torvalds was willing to sanction, he
>created the -ac series Linux kernel patches. For a while this was
>actually the only sensible way to get some quite necessary functionality
>from Linux. A lot of this functionality was then rolled back into the
>"official" kernel at a later date.
>So one possible solution is for Bluechip (or whoever) to create a GPLed
>version Rockbox as a patch on the daily build. They are then free to
>follow their own policies about what to accept and not to accept. Rockbox
>gets to retain its purity, those users that want it can have builds with
>extra functionality, everyone wins. (Except perhaps the person who has to
>maintain the patches, since it's a bit more work that maintaining a source
>tree.) The core developers can keep an eye on the patch, and take what
>they like from it.
>I have no axe to grind either way on this issue. It just seems that the
>core team wants to take Rockbox in a different direction from Bluechip. I
>think there's actually room for both a solid stable core feature set and a
>more bleeding edge open development version. And the beauty of GPL is
>that both are possible if people want them enough. And both sets of
>developers get complete control over what goes in 'their' build.
>For embedded devices the issue of which features get incorporated are
>actually more important than in your average piece of software, since you
>do have a more limited amount of memory available.
>I suspect that most Rockbox users are not the kind of people that want or
>can roll their own Rockbox. More choice for them is not necessarily a bad
>thing. And if everyone can manage to stay amicable and friendly about it,
>in the way Linus Torvalds and Alan Cox did, all Rockbox users should be
>able to benefit from it.
Phew, someone objective :)
You made the point well, the biggest problem with a fork is finding someone
who has enough spare time to update it every day. And that's not me :(
Although I do maintain meticulous notes on everything I change in the core.
As for roll-your-own ...that is a task that can be made simple:
Which chunks of source would you like to compile?
3. Debug or Normal build?
4. Simulator or Real thing?
5. Enhanced Audio Feature Support?
Rockbox would never supply every possible build - that would be throughly
unmaintainable - but for those with 20 minutes to spare, a few questions
and a "make" and it is all done. Getting a compile using the notes that
come with my devkit is virtually fool-proof already.
I would love to see the doors of Rockbox fly open so that plugins, like
mine, can run freely.
I appreciate that the volume scaling is a bit of a dodgy unique'ness with
this specific plugin, but excepting that, Audio_3587 requires nothing that
has not already been considered for inclusion into Rockbox.
And if Audio_3587 gets enough positive feedback, I am sure the keys to
those metaphorical doors will be found to keep the user-base happy. After
all, that is the Prime Directive of this project.
If people want to see a fork, I will happily contribute to that project as
well as this, but I think that better options MUST be available.
Thanks for your thoughts Chrisi, I hope my rebuttal clarifies a good reason
not to split this project, but to open it dynamically to more powerful options.
Page was last modified "Jan 10 2012" The Rockbox Crew