Re: Ruby license and Ruby packaging

[Robert Burrell Donkin <rd...@apache.org>]

On Fri, 2007-10-12 at 10:00 -0400, Sam Ruby wrote:
> On 10/8/07, J Aaron Farr <fa...@apache.org> wrote:
> >
> > Bringing this thread back from the dead...
> >
> > "Sam Ruby" <ru...@intertwingly.net> writes:
> >
> > > On 8/31/07, Erik Abele <er...@codefaktor.de> wrote:
> > >>
> > >> No, it doesn't matter, we can still license our own work as we see
> > >> fit, but see below.
> > >
> > > Actually, I believe that's the crucial bit here.  If it weren't for
> > > the fact that .gem files are exploded upon installation this
> > > discussion would be very straightforward.
> > >
> > > I believe that the license in question will fit into "Category B", the
> > > only question remaining would be how we can document and package our
> > > downloads in ways that "minimize the chance that a user of an Apache
> > > product will create a derivative work of a reciprocally-licensed
> > > portion of an Apache product without being aware of the applicable
> > > requirements."
> > >
> > > I have to believe that this is possible.  To believe otherwise would
> > > essentially lock much of the development of Ruby code out of the ASF,
> > > which would be rather unfortunate.
> >
> > Do we have any definitive word about the Ruby License here in Apache?
> > It does seem to fit into Category B, however, we'd have to make it
> > clear that we're distributing it under the optional conditions.
> 
> Hearing no objections, I'll explicitly add it to the Category B list
> in 72 hours.

the ruby license is badly drafted

it is also a dual license. (there has been legal doubt raised over the
exact meaning of dual licenses - see
http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html#x1-90004)

IMO these risks are sufficiently large to ask council to take a look
before allow it 

- robert

Re: Ruby license and Ruby packaging

[Henri Yandell <ba...@apache.org>]

On Nov 28, 2007 4:45 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> Robert Burrell Donkin wrote:
> >
> > the ruby license is badly drafted
>
> Care to cite a specific issue?

Reminds me that we should put Artistic on the list somewhere.

> > it is also a dual license. (there has been legal doubt raised over the
> > exact meaning of dual licenses - see
> > http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html#x1-90004)
>
> We have plenty of examples where we have accepted multiple licensed code
> in the past.  Pretty much all MPL licensed code is either dual licensed
> or even triple licensed.

Agreed - dual licensing seems to be here to stay.

> > IMO these risks are sufficiently large to ask council to take a look
> > before allow it
>
> Note that we are talking 'category B' here -- which essentially means
> incorporating binaries whole, and without modification.

What's the point?

Category B says 'no scripting languages'. The Ruby license is unlikely
to be applied to binary packages.

Hen

---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

Re: Ruby license and Ruby packaging

[Sam Ruby <ru...@intertwingly.net>]

Robert Burrell Donkin wrote:
> 
> the ruby license is badly drafted

Care to cite a specific issue?

> it is also a dual license. (there has been legal doubt raised over the
> exact meaning of dual licenses - see
> http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html#x1-90004)

We have plenty of examples where we have accepted multiple licensed code 
in the past.  Pretty much all MPL licensed code is either dual licensed 
or even triple licensed.

> IMO these risks are sufficiently large to ask council to take a look
> before allow it 

Note that we are talking 'category B' here -- which essentially means 
incorporating binaries whole, and without modification.

Badly drafted but well known and widely used is often better than 
apparently clear but unknown; similarly multiply licensed codebase may 
create problems for some (like contributors) and not for others.

> - robert

- Sam Ruby


---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org