Re: [Xen-devel] open source and trademark

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Sat, Oct 07, 2006 at 02:48:34PM -0400, Rik van Riel wrote:
> Kurt Skurtveit wrote:
> 
> >>Given internal (and external) concerns with our upcoming inclusion of a
> >>hypervisor-based on a popular open source project, we're considering
> >>using a neutral reference: 'CNH' - Common Neutral Hypervisor
> >>I hope this is an acceptable term for others with similar issues.
> >
> >This is from the same Red Hat that has the most restrictive of
> >trademark policies in the open source world with Fedora Core and RHEL?
> >Please, climb off your soap box.
> 
> It's not a question of soap box, but a question of "collection"
> vs "component", as well as a question of practical matters.
> 
> Components like glibc, the Linux kernel, Xen, and other programs
> need to be maintained for years in RHEL.  Probably way beyond the
> time where XenSource would still be interested in approving patches
> for 3.0.3.   If XenSource were to lose interest in supporting an
> old release, that should not mean distributions lose their ability
> to support users using that release.

And at the other end of the spectrum, Fedora's mission is to track
the very leading edge of open source development. For the kernel
this means that the daily rawhide releases are based off pre-releases
of Linus' newest kernel and forward-ported  xen-unstable. We typically
only lock onto a formal release of the kernel/xen shortly before the
final test release. The trademark rules lead to the ridiculous situaton
whereby we can't call the intermediate rawhide releases xen (because 
they're based on xen-unstable), but once FC6 locks onto official 3.0.3
we could then call it Xen[1].

So we are left with two bad options - either stop using xen-unstable for
rawhide releases (which would mean much less testing exposure for Xen
unstable tree leading to lower quality releases), or change the name in
Fedora which will cause great confusion for users & developers alike and
fragment the Xen community :-(  The value of testing xen-unstable in our
rawhide releases is faaaar to great to stop - anyone can look at the 
archives to see the kind of serious bugs we've uncovered through exposing 
xen-unstable to Fedora testers, so it looks like a rename is the lesser
of two evils :-( 

> Personally, I think Debian was right with their "iceweasel" decision.

I agreee - its just not a scalable approach to require every single
distributor push all their patches back through a single point to get
'approval'. Even today there are countless patches pushed submitted
to xen-devel mailing lists which never get so much as a ack/nack for
weeks at a time, requiring frequent reminder emails from the submitter.
To suggest people need to follow such a process to all patches they
distribute is impractical.

>From reading the trademark rules / FAQs it appears one of the motivating
factors for only allowing official releases to be called Xen is an idea
that this improves quality / compatability for end users. This is is a
rather dubious idea. What improves quality is getting as much testing as
possible - throughout development - for example by distributing xen-unstable
releases to as many users as possible. Providing a stable HV ABI & application
API also improves quality seen by users - current situation is akin to 
every single kernel release requiring a matched glibc release. Bludgeoning
people over trademarks doesn't improve quality, it merely fractures the
development community :-( One of the great strengths of Linux is that there
is such an open & free development process, even though Linus has the one
'master' tree, anyone who wants can maintain custom trees - and the users
don't suffer from compatability problems because everyone understands the
value of providing a consistent stable ABI across releases & branches.

Regards,
Dan.

[1] In actuallity it looks like we can't call FC6 bits Xen anyway, 
    because while the HV is pretty much identical to 3.0.3 we forward
    port the kernel bits fo 2.6.18.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel