| 1 |
robert burrell donkin wrote: |
| 2 |
> On 4/25/07, Dalibor Topic <robilad@×××××.org> wrote: |
| 3 |
|
| 4 |
>> * no one can force the spec leads to do the right things, even if the |
| 5 |
>> whole EC was replaced instantly. |
| 6 |
> |
| 7 |
> this one is solvable. spec leads just need to be forced to issue |
| 8 |
> public licenses up front at the start of the process rather than |
| 9 |
> relying on hub-and-spoke contracts with participants. |
| 10 |
|
| 11 |
Good idea, but in practice nothing prevents a spec lead from having |
| 12 |
further license arrangements on their output, afaict, so I don't think |
| 13 |
that hub-and-spoke contracts will go away (or that spec leads would want |
| 14 |
to limit their own licensing options that way, in general). |
| 15 |
|
| 16 |
I'd suggest advancing that idea on the merit of clarity of legal |
| 17 |
arrangements around a JSR, rather than as a means of forcing the spec |
| 18 |
leads to behave in a specific way. |
| 19 |
|
| 20 |
>> I don't think that the confrontational 'let's make noise inside the JCP' |
| 21 |
>> approach would work for us who aren't on the EC, and that's pretty much |
| 22 |
>> everyone. |
| 23 |
> |
| 24 |
> +1 |
| 25 |
> |
| 26 |
> but FOSS people setting out better ways to run standards processes may |
| 27 |
> well make a difference. in particular, the downstream perspective is |
| 28 |
> completely missing from the current debate. |
| 29 |
|
| 30 |
That's correct, but I don't think that the EC membership has so far |
| 31 |
cared that much about the perspective outside their own organizations |
| 32 |
... yet. |
| 33 |
|
| 34 |
That's not a particular surprise, since people on the EC will largely |
| 35 |
push the agendas of the organizations they belong to, after all they are |
| 36 |
(for the most part) paying for the privilege of getting their products |
| 37 |
turned into standards, and being able to influence the standardization |
| 38 |
process. |
| 39 |
|
| 40 |
There is a simple fix, though: Sun seems to have figured out that |
| 41 |
cooperating with downstreams can be benefitial for them, and that |
| 42 |
cooperation will likely lead to some benefits for Sun in terms of how |
| 43 |
ubiquitous their technologies will be deployed/deployable downstream, as |
| 44 |
the downstreams really like Free Software & transparency and all the |
| 45 |
other sane engineering stuff. |
| 46 |
|
| 47 |
The way Sun goes is the way the rest of the EC will follow, if it turns |
| 48 |
out to work for Sun. |
| 49 |
|
| 50 |
Proposals to change the JCP process have been discussed regularly |
| 51 |
outside the JCP, but in general have not resulted in changes of the |
| 52 |
processes. We could speculate why that's the case, but afaict, directly |
| 53 |
changing specifics of the process from outside does not really work. One |
| 54 |
can discuss ideas to do things in a better way, but at the end of the |
| 55 |
day it's up to the spec leads to adopt them or not. |
| 56 |
|
| 57 |
I'd suspect that the main reason for the lack of adoption of proposals |
| 58 |
to improve the JCP from outside the process comes from them being made |
| 59 |
outside the process, rather than by those inside the process. |
| 60 |
|
| 61 |
So I think it's more effective to have positive feedback for JSRs run |
| 62 |
reasonably, than to try from outside to teach spec leads how they should |
| 63 |
run their JSRs, or to force them to do specific things. |
| 64 |
|
| 65 |
What works is the 'market' supporting the specs that are well done, and |
| 66 |
ignoring those that aren't. Ignoring intransparently run JSRs is cheap |
| 67 |
and easy, and they ignore us anyway, so no harm done. |
| 68 |
|
| 69 |
>> I'd rather suggest that the |
| 70 |
>> ASF gets going working on creating open source TCKs for all RIs |
| 71 |
>> implemented under its spec leadership (the whole XML & WS-* stuff, |
| 72 |
>> Tomcat, and all that). |
| 73 |
> |
| 74 |
> i can't find any spec lead by apache on http://www.jcp.org/en/jsr/all |
| 75 |
|
| 76 |
My apologies for that assertion, I was mistakenly under impression that |
| 77 |
the ASF was leading specs, rather than individual companies whose spec |
| 78 |
leads happen to be ASF's members. |
| 79 |
|
| 80 |
> i agree that there are many specifications which were and are strong |
| 81 |
> influenced by apache ethos. apache has also been home to a lot of |
| 82 |
> reference implementations. but this is personal, not official. |
| 83 |
|
| 84 |
Is the reasoning why the ASF has been home to a lot of reference |
| 85 |
implementations without being the home for their test suites documented |
| 86 |
somewhere? I'm curios what motivates the persons using Apache as the |
| 87 |
home for their RIs to not develop their TCKs inside Apache. |
| 88 |
|
| 89 |
cheers, |
| 90 |
dalibor topic |
| 91 |
-- |
| 92 |
gentoo-java@g.o mailing list |
Archives