--- Charles D Hixson <[EMAIL PROTECTED]> wrote:
> Stephen Reed wrote: > > I would appreciate comments regarding additional > > constraints, if any, that should be applied to a > > traditional open source license to achieve a free > but > > safe widespread distribution of software that may > lead > > to AGI. > > ... > > > My personal opinion is that the best license is the > GPL. Either version > 2 or 3...currently I can't choose between them > (partially because > version 3 is still being written). [snip] > How do you keep the bad guys from using it? You > keep on developing. > Those who fork tend to fall behind, unless they get > community support. As a long time gcc tool chain user I agree with the comments below but let me draw a distinction between an AGI and all software that precedes it. I think that an AGI might be dangerous, especially an uncontrolled AGI. I wish to impose well-founded ethical and law-abiding policies on the various downloaded AI softwares. There are already laws and enforcement world wide that constrains most bad guys, but there is little precedent outside of robotics, numerical control and embedded, e.g. medical software for building in safety as part and parcel of the software. That puts me at odds with the GPL which forbids any additional constraints in derivations of its license. The Apache Software License can be further constrained in derived works, e.g. adding a must-be-federated clause. A "let's cross that bridge when we come to it" attitude might be to open source the pre-AI software, developing action justification, Friendship goal structure, proscribed behaviors, policy hierarchies, self-improvement monitoring and so forth without usage constrictions. As you point out, this will ease adoption and the great majority of downloaders will choose to operate in federated mode, out of self-interest. Should evidence arise that an AGI could indeed evolve, then alarmists and skeptics will arise, a hoopla will ensue, and behavior constraints will be externally imposed. > Now I'll admit that this is an idealized picture of > the development > process, but the outline is correct. Keeping a > project going takes a > good manager...one who can "herd cats". It requires > inspiring a degree > of faith and trust in people who will be working > without being paid. > This means you've got to inspire them as well as get > them to trust you. > And you've got to articulate a vision of where the > project should be > headed next, roadmap is the common term, without > stifling creativity. > > P.S.: Note that gcc has several "chunks". Each > language has a largely > separate implementation, but each needs to generate > the same kind of > intermediate representation. This allows several > essentially > independent teams to each work separately. As to > just *how* > independent... consider the gdc compiler ( > http://sourceforge.net/projects/dgcc ). This > project is prevented by > licensing constraints from having ANY direct > connection to the rest of > gcc. Yet it can still be integrated into gcc by an > end user. > > > ------- > To unsubscribe, change your address, or temporarily > deactivate your subscription, > please go to > http://v2.listbox.com/member/[EMAIL PROTECTED] > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
