It has never been the intention to turn the RAtoolset into a RIPE centric toolset. If it were we could have developed our own. The ISI people approached us with a request to consider supporting it after NSF funding for the RA project finished and the developers moved to other tasks. I am generally not very fond of "committees" for design purposes. I would rather keep channels open at NANOG, ARIN, APNIC, APOPS, RIPE, etc and try to address everyone's requests. Also, last but not least, the fact that we are making a commitment to devote resources to the maintenance and further development of the RAToolset does not mean we won't incorporate other people's development efforts into the toolset. We will just make sure we have the resources to do it. Joao At 03:59 -0400 4/10/01, Ray Plzak wrote:

Assuming that RIPE is going to be the agent for a global set of tools, what are the plans for a configuration control board. One would assume that such a body would be formed so that the tool set does not become RIPE centric but takes on the broader global view of all users and is sensitive to their needs.

Ray

--

At 5:20 AM -0400 4/10/01, Ray Plzak wrote:

...

Also, last but not least, the fact that we are making a commitment to devote resources to the maintenance and further development of the RAToolset does not mean we won't incorporate other people's development efforts into the toolset. We will just make sure we have the resources to do it.

But it doesn't ensure that you will incorporate them either. The bottom line is that where the resource controller makes the final decision based upon the organization's resource availability and its impact on the contributors to that resource, that will be the primary consideration and not necessarily those of the global users of the product.

I don't see any change from the current situation where you had to ask Cengiz nicely to make any change (and obviously firstly persuade him that it was a good idea). From my long range dealings with RIPE NCC I don't expect my dealings with them to be any different, except have the possibility of them getting more work done (and being able to divide and conquer them :-) RIPE NCC seem to have enough mechanisms in place to get feedback from their community and if they see this software as having a global constituency rather than just a RIPE one then I'm going to be a happy camper. Mark. --

On Thu, 2001-10-04 at 11:20, Ray Plzak wrote:

But it doesn't ensure that you will incorporate them either. The bottom line is that where the resource controller makes the final decision based upon the organization's resource availability and its impact on the contributors to that resource, that will be the primary consideration and not necessarily those of the global users of the product.

These issues would probably go away if a GNU-like license were applied. Maybe it's an idea to copyleft the whole bunch? The current license on (almost all) source files says: ... use, copy, modify, and distribute this software ... for lawful non-commercial purposes and without fee is hereby granted, ... The copyright owner is USC. Now, I don't think anybody has ever given much thought about the "lawful non-commercial" use, but unless I am mistaken it clearly prohibits the majority of ISPs to use this software. An explicit copylefting of this project would allow anyone to modify and distribute the package, keep the sources available and open, and hence allow a fair degree of democratic control over its evolution. If, for example, enough people want a set of changes that (hypothetically speaking) RIPE NCC weren't willing to implement, these people could take the sources, create their own modifications and make it available to the community again. Yes, we might see diverging implementations, but at least everyone will have the opportunity to see their need-to-have features implemented. Cheers, Steven

On Thu, 2001-10-04 at 12:27, Bill Manning wrote:

I don't think that the USC licence will allow a GNU type licence to be applied. And while it would be prudent to chat w/ USC legal, I expect that "use" of the software may not include the aspect of a client that generates aa query that is sent over the Internet. The software itself is the recipeitn of that query and the folks running that server may be said to use it. RIRs seem to make a fine home, since they are not commercial entities... Right?

RIRs are a fine home for the server(s), yes (that's one of the reasons why the RIPE members contribute to the RIPE NCC after all), but the RAToolset/IRRToolset software includes tools such as roe(1), the Route Object Editor, and aoe(1), the AS Object Editor. These are clients that contact a IRR server. The IRR server is (usually) running at a RIR, but the clients are not. And yet, the client software has that Naughty Copyright Notice attached to ALL of its source files (and manual page). Like I said, most (techie) people don't give a hoot, but legal departments at largish outfits can seriously halt Progress(tm). Although RIPE and the RIPE NCC are non-profit organisations, most of the members are most definitely out to make a (euro-)buck. It's only proper that if these tools are to be hosted/provided/maintained by the RIPE NCC, that the restrictive license is removed. Replacing it with a RIPE/RIPE NCC copyright may make non-RIPE members nervous, so I still think a GNU-like license is the safest and fairest option. Cheers, Steven