-----Original Message----- From: Joao Luis Silva Damas [mailto:joao@ripe.net] Sent: Thursday, October 04, 2001 4:38 AM To: plzak@arin.net; 'Andrei Robachevsky'; db-wg@ripe.net; routing-wg@ripe.net; irrtoolset@ripe.net Subject: RE: Re-homing of RAToolSet to RIPE NCC

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.

Didn't say that RIPE centricity was the intention. What I did say was if one assumes that RIPE is to be the agent for a global product then there should be a means to be sensitive to the global community.

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.

Wasn't talking about design by committee. Since this is existing software, the activity is one of maintenance not development. Changes should be made to correct implementation errors of the current design. PPP should take into account the requirements and needs of the entire community hence a need to ensure that there is a means to be sensitve to those needs.

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. Ray

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

--

to divide and conquer them :-) RIPE NCC seem to have enough mechanisms in place to get feedback from their community

Precisely, "their community"

see this software as having a global constituency rather than just a RIPE one then I'm going to be a happy camper.

Therefore the need to reach out to the global constituency. Ray

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

The way Cengiz explained USC's copyright to me it was supposed to mean: You can not sell this stuff (the software) without giving us a part of the profit. It was not supposed to mean: if you are a commercial company, you can't use it. After the RA project was about providing infrastructure to support an Internet that had become commercial, right? In any case, no one, other than USC, can remove their copyright from the code but if the real interpretation of the copyright statement happens to be the more restrictive one, then the RIPE NCC would certainly have a problem with this code, because we *HAVE* to make the software we develop available for use by the community. Joao At 05:13 -0700 4/10/01, Bill Manning wrote:

% 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.

I spect that the USC tag still claims that it needs to stay w/ the code so RIPE would need to do a "clean-room" reimplementation to expunge the USC tag.

Of course RIPE could also cut a deal w/ USC on broad commercial use of the tools. That has often proved to be the cheapest/easiest course. % % Cheers, % Steven %

-- --bill

--

On Thu, 2001-10-04 at 05:57, Bill Manning wrote:

Neither myself or Cengiz can interprete USC legal issues. If this was me, I'd contact USC legal for a valid ruling.

The explanation I gave to Joao is the one Jon Postel gave me and to others. If my memory serves me right, Jon came up with the copyright message in the first place. And it is up to each project director (at the time Jon) what copyright message goes to each project. Also, I dont hesitate for a moment that new developers will address the concerns and needs of the global community and they are best positioned to be the new host of the toolset. Cengiz

% % The way Cengiz explained USC's copyright to me it was supposed to mean: % % You can not sell this stuff (the software) without giving us a part % of the profit. % % It was not supposed to mean: if you are a commercial company, you can't use it. % % After the RA project was about providing infrastructure to support an % Internet that had become commercial, right? % % In any case, no one, other than USC, can remove their copyright from % the code but if the real interpretation of the copyright statement % happens to be the more restrictive one, then the RIPE NCC would % certainly have a problem with this code, because we *HAVE* to make % the software we develop available for use by the community. % % Joao % % At 05:13 -0700 4/10/01, Bill Manning wrote: % >% 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. % > % > % > I spect that the USC tag still claims that it needs to stay % > w/ the code so RIPE would need to do a "clean-room" % > reimplementation to expunge the USC tag. % > % > Of course RIPE could also cut a deal w/ USC on broad % > commercial use of the tools. That has often proved to % > be the cheapest/easiest course. % >% % >% Cheers, % >% Steven % >% % > % > % >-- % >--bill % % % -- %

-- --bill