Garrett D'Amore wrote:
Shawn Walker wrote:
I don't agree with that. The OpenSolaris constitution structure
doesn't mean that an ON-sponsored project is subservient to the ON
Community Group. If you're really that worried about that sort of
influence, then you don't want to be on opensolaris.org anyway :)
I think this project needs to have its own CCs that do its own voting,
etc. Other consolidations do this, why not this one?
Why do you need CCs to make decisions? Even then, you don't need your
own CG to have CCs if you align with the correct CG :)
This is about communication and direction, as well as overlap. From a
strictly os.org point of view, I don't see why this shouldn't be a
sponsored project of the ON CG. To me, it fails the common test for
an independent CG. If you don't want it sponsored by ON, then I think
it needs to be sponsored by some other related CG.
What test is that? Other consolidations have their own CGs, why not
this one?
I don't see this as a consolidation; and aren't consolidations strictly
a Sun thing anyway? I thought you were wanting to remove all 'Sun'
aspects from this...
I also believe the issue of where the code lives is completely
separate from community governance structures. The ON CG doesn't get
control over your project's repository just because they are your
sponsor, any more than the installer, etc. CGs get control over the
pkg(5) repository because they sponsor the Image Packaging System
project..
No, but I think this project should have its own CCs who vote on matters
both internal to this project, but also get representation in the larger
audience. These CCs might well fall below the threshold for ON CC
grants (which are based on contribution to ON!)
I don't understand your objections here.
I don't understand what the concern is about autonomy. The OpenSolaris
constitution makes it very clear here that project decisions remain the
purvue of projects; not of the CG (as I understand it).
Even then, I suspect this will change soon if the constitution is
further updated and that point your concerns will be moot (based on
current direction).
As such, I'll digress on this point. I personally would not approve a
CG for this project; I don't believe it meets the criteria under the
current constitution for the scope that is intended for a Community
Group. But it isn't my decision, so proceed however you will.
Even FSF projects require some sort of contributor agreement for
contributions of a certain scope to gcc, etc.
FSF does the same thing for the same reasons that SCA does. It has
nothing to do with assurances of original authorship, and *everything*
to do with making sure that there is a single copyright owner who can
change the license at any time. (This allows FSF to globally change the
GPLv2 to v3 on its projects, for example, without requiring individual
authors to sign another agreement.)
It isn't just about authorship; it also has to do with patent rights,
contributions from those under an employment agreement, etc. from my
rough, non-legally qualified understanding of things.
I'm primarily concerned about any drivers or fixes from this project
that result in other users from being unable to benefit from them since
they won't be able to be integrated back into ON.
I'm not sure that an agreement does anything really to mitigate the risk
of copyright violation or plagiarism. If the author has ripped off the
original copyright notices, who's to say they're going to be honest in
their agreement? (Especially since the SCA and the code submissions
generally happen at two points in time that are very disjoint from one
another.)
There's a big difference between someone's verbal assent that they have
the right to contribute something and won't assert patents, etc. and a
written, signed agreement :)
But I digress on this point; I'll let you followup with the appropriate
parties.
Yes, but I'm assuming that a very similar formal RTI process will
still be needed for this project.
No, much less formal. No C-Team review. A basic code review and
sign-off by a CC who would basically be acting as CRT advocate. The
idea here is a much lower barrier to entry.
As I said, "similar".
If you've ever tried to commit code to ON, you'd understand that there
is a very high bar to get new code into ON.
I have RTIs for ON as an external community member, so I'm somewhat
familiar with the fairly arduous process :)
Cheers,
--
Shawn Walker
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
