> I hope such a spec would be developed "in the open" from the beginning,
> rather than being developed behind closed doors and only opened much
> later. And perhaps that's what you're getting at with your points below...

It's absolutely my intent to make sure that any spec is developed in the open. Believe me when I say that I'm seriously constrained in terms of what I can do outside of Microsoft vs. inside. It's *much* easier to get stuff done inside the company vs. getting stuff done outside. So for me, it's a lot more interesting writing code vs. meeting with lawyers :)

>> See: RubyTests project on RubyForge

Thanks - will look at that stuff.

> Well, of course Microsoft would be interested in something they could
> take behind closed doors :) Seriously though, for the spec/test suite,
> just about anything is fine; I'd be very surprised if anyone were able
> to take a test suite to closed source and do anything evil with it.

The bottom line on license agreements (and this is nothing that I can change) is that projects with copyleft style licenses are projects that I cannot work on. That's why the selection of the license agreement is important to me personally. I want to work in an open fashion, but I also need to respect the needs of my employer. While I actually personally agree that copyleft licenses are good for open source projects because of the requirement for giving back, there are significant legal risks that (now that I understand what they really mean) I would not be willing to undertake in certain software projects.

> RubyTests already has committers from almost all the major projects
> (except the CLR-based ones, though they're welcome to come too). And
> we've already contributed our JRuby tests back, eventually to use
> RubyTests as our primary test repository.

Will do. Good to see that it's the Ruby license too :)

> Owner?

The reason for this is roughly as follows. Typical disclaimer about IANAL here as well:

In 'real' standards organizations like ISO or ECMA, there are a set of by-laws that govern the behavior of individuals and companies that participate in the standardization effort. This may include statements like participants agree to license at reasonable or zero cost (RAND[Z]) any patents etc that they may have that pertain to the technologies being standardized or to agree not to sue over those patents. This is done to avoid individuals or companies subverting the standardization process such that the only way that something can be implemented according to spec is to infringe on patent(s) that they own. Clearly this is a bad thing, and clearly such things have been attempted (successfully?) in the past.

For more details and discussion: http://xml.coverpages.org/patents.html

> Yes, rspec creates nice
> output. It's not nearly human-readable enough for an implementer to flip
> through it and find some implementation detail they might have missed. A
> test/spec suite also assumes a number of things: namely, that the parser
> and core interpreter are already functional, and that a number of basic
> builtin classes and libraries already work correctly. But how do you get
> up to that point without a grammar, documentation on the interpreter,
> and so on?

+1. But the value of rspec is defining the behavior of an existing Ruby interpreter, especially with respect to the 'language nooks and crannies' :)

> To this end, I believe a complete
> specification should also include a list of applications that should
> reasonably be expected to work on a given implementation. Is a Ruby
> implementation complete without support for RubyGems or Rake? Or without
> Rails? RSpec? These are staples of the Ruby world.

+1. This is the issue that I was trying to (and obviously failing to) bring up when talking about how the community should define Ruby behavior. It's unreasonable to expect that a non C Ruby implementation be able to run *any* Ruby program. What's acceptable vs. non-acceptable is not really a language issue at all - it's an issue of what defines reasonable expectations about what programs can or cannot run.

Thanks,
-John