You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Matthieu Riou <ma...@offthelip.org> on 2007/08/30 00:53:06 UTC
Ruby license and Ruby packaging
Hi,
We're thinking of proposing buildr [1] for the Apache Incubator. However
buildr is a Ruby project and there are a few associated legal hurdles on the
way. So I have a few questions:
1. The Ruby interpreter is not really a problem (just like the JDK isn't a
problem), however a lot of libraries in the Ruby ecosystem reuse the Ruby
license [2]. Is it compatible with the ASL and would it be authorized for
third-party inclusion in an Apache work?
2. Ruby distribution heavily relies on the RubyGems [3] packaging system. In
many ways it's very similar to Linux packaging systems, like APT. In short
it handles third party dependencies for a given software by installing them,
after asking. So if you try to install "foo" and if "foo" depends on "bar"
and "baz", it will ask you whether you also want to install "bar" and "baz"
and if so, will download them from a central repository and install them for
you. In this context, does the licenses of third-party dependencies matter
as none of them are actually distributed?
Buildr as several dependencies toward Ruby License third party softwares and
a couple ones toward LGPL software (that wouldn't be that easy to remove),
which normally wouldn't be kosher at all. However given that none of them
are distributed, would that matter?
Thanks,
Matthieu
[1] http://buildr.rubyforge.org/
[2] http://www.ruby-lang.org/en/LICENSE.txt
[3] http://docs.rubygems.org/
Re: Ruby license and Ruby packaging
Posted by Matthieu Riou <ma...@offthelip.org>.
On Dec 6, 2007 1:24 PM, Henri Yandell <ba...@apache.org> wrote:
> On Aug 29, 2007 2:53 PM, Matthieu Riou <ma...@offthelip.org> wrote:
> > Hi,
> >
> > We're thinking of proposing buildr [1] for the Apache Incubator. However
> > buildr is a Ruby project and there are a few associated legal hurdles on
> the
> > way. So I have a few questions:
> >
> > 1. The Ruby interpreter is not really a problem (just like the JDK isn't
> a
> > problem),
>
> Yep, it's environmental and installed by the user. If we had a JNLP,
> then the JDK might do an automatic upgrade or something; but I think
> you get a click through license.
>
> > however a lot of libraries in the Ruby ecosystem reuse the Ruby
> > license [2]. Is it compatible with the ASL and would it be authorized
> for
> > third-party inclusion in an Apache work?
> >
> > 2. Ruby distribution heavily relies on the RubyGems [3] packaging
> system. In
> > many ways it's very similar to Linux packaging systems, like APT. In
> short
> > it handles third party dependencies for a given software by installing
> them,
> > after asking. So if you try to install "foo" and if "foo" depends on
> "bar"
> > and "baz", it will ask you whether you also want to install "bar" and
> "baz"
> > and if so, will download them from a central repository and install them
> for
> > you. In this context, does the licenses of third-party dependencies
> matter
> > as none of them are actually distributed?
> >
> > Buildr as several dependencies toward Ruby License third party softwares
> and
> > a couple ones toward LGPL software (that wouldn't be that easy to
> remove),
> > which normally wouldn't be kosher at all. However given that none of
> them
> > are distributed, would that matter?
>
> The answer I've always seen on this is that it has to be apparent to
> the user that they are installing them, and that they see the license;
> rather than magic that happens in the background.
>
So in the case of RubyGems, it's definitely apparent as it asks you whether
you want to install those dependencies or not (unless you force a yes to all
using a specific option but then you know what you're doing). The license is
not displayed for every dependency though but you know you're installing
something else.
Cheers,
Matthieu
> Hen
>
Re: Ruby license and Ruby packaging
Posted by Henri Yandell <ba...@apache.org>.
On Aug 29, 2007 2:53 PM, Matthieu Riou <ma...@offthelip.org> wrote:
> Hi,
>
> We're thinking of proposing buildr [1] for the Apache Incubator. However
> buildr is a Ruby project and there are a few associated legal hurdles on the
> way. So I have a few questions:
>
> 1. The Ruby interpreter is not really a problem (just like the JDK isn't a
> problem),
Yep, it's environmental and installed by the user. If we had a JNLP,
then the JDK might do an automatic upgrade or something; but I think
you get a click through license.
> however a lot of libraries in the Ruby ecosystem reuse the Ruby
> license [2]. Is it compatible with the ASL and would it be authorized for
> third-party inclusion in an Apache work?
>
> 2. Ruby distribution heavily relies on the RubyGems [3] packaging system. In
> many ways it's very similar to Linux packaging systems, like APT. In short
> it handles third party dependencies for a given software by installing them,
> after asking. So if you try to install "foo" and if "foo" depends on "bar"
> and "baz", it will ask you whether you also want to install "bar" and "baz"
> and if so, will download them from a central repository and install them for
> you. In this context, does the licenses of third-party dependencies matter
> as none of them are actually distributed?
>
> Buildr as several dependencies toward Ruby License third party softwares and
> a couple ones toward LGPL software (that wouldn't be that easy to remove),
> which normally wouldn't be kosher at all. However given that none of them
> are distributed, would that matter?
The answer I've always seen on this is that it has to be apparent to
the user that they are installing them, and that they see the license;
rather than magic that happens in the background.
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
Posted by 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
Posted by 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
Re: Ruby license and Ruby packaging
Posted by 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
Posted by Sam Ruby <ru...@intertwingly.net>.
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.
> (Grumbles about why can't people just stick to existing licenses
> instead of making up new ones...)
>
> --
> J Aaron Farr jadetower.com [US] +1 724-964-4515
> 馮傑仁 cubiclemuses.com [HK] +852 8123-7905
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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
Posted by J Aaron Farr <fa...@apache.org>.
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.
(Grumbles about why can't people just stick to existing licenses
instead of making up new ones...)
--
J Aaron Farr jadetower.com [US] +1 724-964-4515
馮傑仁 cubiclemuses.com [HK] +852 8123-7905
---------------------------------------------------------------------
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
Posted by Sam Ruby <ru...@intertwingly.net>.
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.
- 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
Re: Ruby license and Ruby packaging
Posted by Erik Abele <er...@codefaktor.de>.
On 30.08.2007, at 00:53, Matthieu Riou wrote:
> We're thinking of proposing buildr [1] for the Apache Incubator.
> However buildr is a Ruby project and there are a few associated
> legal hurdles on the way. So I have a few questions:
>
> 1. The Ruby interpreter is not really a problem (just like the JDK
> isn't a problem), however a lot of libraries in the Ruby ecosystem
> reuse the Ruby license [2]. Is it compatible with the ASL and would
> it be authorized for third-party inclusion in an Apache work?
I don't think so since it seems that the Ruby license is a bit more
restrictive than the AL2.0.
> 2. Ruby distribution heavily relies on the RubyGems [3] packaging
> system. In many ways it's very similar to Linux packaging systems,
> like APT. In short it handles third party dependencies for a given
> software by installing them, after asking. So if you try to install
> "foo" and if "foo" depends on "bar" and "baz", it will ask you
> whether you also want to install "bar" and "baz" and if so, will
> download them from a central repository and install them for you.
> In this context, does the licenses of third-party dependencies
> matter as none of them are actually distributed?
No, it doesn't matter, we can still license our own work as we see
fit, but see below.
> Buildr as several dependencies toward Ruby License third party
> softwares and a couple ones toward LGPL software (that wouldn't be
> that easy to remove), which normally wouldn't be kosher at all.
> However given that none of them are distributed, would that matter?
I remember some dicussions about hard and soft dependencies and
afaicr it was considered crucial to get rid of hard dependencies on
code whose license is more restrictive
than the AL.
There's a posting [1] which should help explaining the situation but
in the end you'll have to sort out these things in the Incubator so
I'd suggest to simply take it over there...
HTH...
Cheers,
Erik
[1] http://mail-archives.apache.org/mod_mbox/roller-dev/200511.mbox/%
3CNBBBJGEAGJAKLIDBKJOPIEKNEHAC.noel@devtech.com%3E
---------------------------------------------------------------------
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
Posted by Roland Weber <ro...@apache.org>.
Hello Matthieu,
the Ruby license is not listed in the current draft guidelines:
http://people.apache.org/~rubys/3party.html
That means someone more knowledgeable than me will have to look into
it to decide whether you would be allowed to package that code.
However, the draft also mentions some ways to deal with Category X
licenses, in particular the "System Requirements" option:
http://people.apache.org/~rubys/3party.html#options
You will typically sort out the licensing details in the Incubator.
hope that helps,
Roland
---------------------------------------------------------------------
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