Break non-GPL runtime out into a separate gem

[headius]

Many organizations, like the Apache Software Foundation, refuse to ship any code that is GPL, LGPL, or variations thereof. This led to jruby/jruby#4603, where the LGPL portions of racc were mistakenly shipped with JRuby.

However, it's not easy to source just the non-LGPL parts of the racc gem. If you install the gem, you get mixed sources with mixed licenses (LGPL plus Ruby's licenses).

It would be best if the non-LGPL portions of racc could be split off into a separate "racc-runtime" gem that both JRuby and CRuby could use for redistribution.

I'm willing to help with this, but it really should just involve duplicating the project structure with just the non-LGPL portions as the "racc-runtime" gem, and adding a dependency on "racc-runtime" to "racc".

[zenspider]

I'm not even really sure why this gem has the runtime in it, considering it ships with ruby (under the favorable license afaik).

[headius]

@zenspider Indeed, and MRI doesn't ship the LGPL bits.

Best case to me would be a separate repo, perhaps under ruby/racc-runtime, and a separate gem so that both JRuby and MRI can update between releases.

[headius]

cc @hsbt

[zenspider]

I'm down with that. @tenderlove ?

[headius]

Also note ongoing effort to gemify all of stdlib. This won't be possible for MRI's racc bits without racc-runtime gem. https://bugs.ruby-lang.org/issues/5481

[zenspider]

I have been pushing on this for years... glad it is finally getting traction from someone real on core (not counting MY being on core. :P).

[tenderlove]

Yes, I agree. We should extract the runtime bits to a separate gem.

[hsbt]

I agreed too. But I'm not familiar with this issue. I'm going to handle this in Gemification plan.

[zenspider]

@hsbt btw... I own the "ruby" gem name. The plan was to make it a meta gem that depends on all the gems for a particular release. Making it easy to keep them in sync. You're welcome to it.

[alexdowad]

A different angle on this:

1. Racc currently has an option to embed the runtime in the generated parser. This eliminates all runtime dependencies on the racc gem.
2. Embedding the runtime adds about 20KB of code to the generated parser.
3. 20KB is small.
4. A significant part of that 20KB is just comments, which could be stripped out. That would make the overhead of always embedding the runtime less than 20KB.
5. Less than 20KB is really small.

I think the best way to handle this would be to make Racc always embed the runtime. CRuby and JRuby can keep their current Racc runtime files for backwards compatibility, but there will never be a need to extract files from the racc gem again.

NOW! Note that Racc's -E option is not really friendly, in that it defines important code in module Racc. If a project used two different Racc-generated parsers which both embedded different versions of the runtime, bad things could happen.

-E should really be fixed up so that multiple such parsers can be loaded in the same Ruby process without stepping on each other's toes.

[tenderlove]

I really like the idea of splitting the code because I'd like racc to be a default gem, and we can't ship GPL code with Ruby. Besides the licensing benefit, splitting the compiler from the runtime means that we could independently build an MIT licensed compiler that uses the existing runtime.

[zenspider]

@alexdowad are you referring to the pure ruby runtime? Last time I measured it was MUCH slower than the C component.

[headius]

Git 'er done. Forgot I'd opened this (it was a very busy summer). Sadly it seems everyone else forgot it too, so this probably won't make Ruby 2.5.

I'll see if I can do something.

[zenspider]

Everything was re-licensed AFAIK... so I think this can be closed?

[headius]

I believe this means we can now source racc entirely from the racc gem, yes?

[hsbt]

yes.