You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Henri Yandell <ba...@apache.org> on 2008/03/20 16:18:49 UTC
Similar terms to AL 2.0
[Once it's sync'd], our list of licenses with similar terms to AL 2.0 is at:
http://www.apache.org/legal/resolved.html
Given that that list was created a couple of years back, and the
additions were just organic, I'd like to start this thread for other
ones that people think need to be added.
Here's my starter list:
* Artistic License (list variants?)
* Ruby License
* Microsoft Public License
* ASL 1.0 [Or possibly here we just say OpenSSL]. This has the
advertising clause - do we consider such a thing similar terms?
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: Similar terms to AL 2.0
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Mar 20, 2008 at 3:27 PM, Henri Yandell <ba...@apache.org> wrote:
> On Thu, Mar 20, 2008 at 3:16 PM, Matthieu Riou <ma...@offthelip.org>
> wrote:
> >
> > On Thu, Mar 20, 2008 at 1:13 PM, Sam Ruby <ru...@intertwingly.net>
> wrote:
> >
> >
> > >
> > > On Thu, Mar 20, 2008 at 3:26 PM, Henri Yandell <ba...@apache.org>
> wrote:
> > > > On Thu, Mar 20, 2008 at 10:47 AM, Sam Ruby <ru...@intertwingly.net>
> > wrote:
> > > > > On Thu, Mar 20, 2008 at 11:18 AM, Henri Yandell <
> bayard@apache.org>
> > wrote:
> > > > > > [Once it's sync'd], our list of licenses with similar terms to
> AL
> > 2.0 is at:
> > > > > >
> > > > > > http://www.apache.org/legal/resolved.html
> > > > > >
> > > > > > Given that that list was created a couple of years back, and
> the
> > > > > > additions were just organic, I'd like to start this thread
> for
> > other
> > > > > > ones that people think need to be added.
> > > > >
> > > > > Overall, I'd prefer if we had actual use cases before we start
> > adding
> > > > > new license.
> > > > >
> > > > > > Here's my starter list:
> > > > > >
> > > > > > * Artistic License (list variants?)
> > > > >
> > > > > Artistic 2.0, clause (7) looks troublesome.
> > > >
> > > > Agreed. It's clause 5 in Artistic 1.0. So that's out for 'similar
> > > > terms' I believe.
> > > >
> > > > Raises the question of 'Can I use Perl?', and 'Can I depend on an
> > > > Artistic licensed work, other than that which ships with Perl by
> > > > default?'.
> > >
> > > Of course we can use Perl. And the code under the Artistic License
> > > coming from CPAN are analogous to Ruby gems.
> > >
> > > When people use frameworks like Rails, they often stick snapshots of
> > > specific versions of gems that they depend on in a "vendor" directory
> > > and distribute it. I'm comfortable with that practice for gems
> > > licensed under the Ruby license - but not the MRI itself. But given
> > > the differences between the Ruby license and the Artistic License, I
> > > would be reluctant to giving the thumbs up to a similar practice for
> > > Perl.
> > >
> > >
> >
> > From what I understand, most Perl packages, like the runtime, rely on
> the
> > first version of the Artistic License:
> >
> > http://dev.perl.org/licenses/artistic.html
> >
> > This one seems less problematic to me than the 2.0, don't you think?
>
> Section 5 in the first version seems much the same as section 7 in the
> second version. If that's our sticking point, then I don't see the two
> licenses being any less problematic.
>
True enough, for some reason I interpreted it differently on first read. I'm
not sure it's that much of a problem though, as everything can be an
aggregation. But this discussion can wait, premature optimization...
Thanks!
Matthieu
>
> Hen
>
Re: Similar terms to AL 2.0
Posted by Henri Yandell <ba...@apache.org>.
On Thu, Mar 20, 2008 at 3:16 PM, Matthieu Riou <ma...@offthelip.org> wrote:
>
> On Thu, Mar 20, 2008 at 1:13 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
>
> >
> > On Thu, Mar 20, 2008 at 3:26 PM, Henri Yandell <ba...@apache.org> wrote:
> > > On Thu, Mar 20, 2008 at 10:47 AM, Sam Ruby <ru...@intertwingly.net>
> wrote:
> > > > On Thu, Mar 20, 2008 at 11:18 AM, Henri Yandell <ba...@apache.org>
> wrote:
> > > > > [Once it's sync'd], our list of licenses with similar terms to AL
> 2.0 is at:
> > > > >
> > > > > http://www.apache.org/legal/resolved.html
> > > > >
> > > > > Given that that list was created a couple of years back, and the
> > > > > additions were just organic, I'd like to start this thread for
> other
> > > > > ones that people think need to be added.
> > > >
> > > > Overall, I'd prefer if we had actual use cases before we start
> adding
> > > > new license.
> > > >
> > > > > Here's my starter list:
> > > > >
> > > > > * Artistic License (list variants?)
> > > >
> > > > Artistic 2.0, clause (7) looks troublesome.
> > >
> > > Agreed. It's clause 5 in Artistic 1.0. So that's out for 'similar
> > > terms' I believe.
> > >
> > > Raises the question of 'Can I use Perl?', and 'Can I depend on an
> > > Artistic licensed work, other than that which ships with Perl by
> > > default?'.
> >
> > Of course we can use Perl. And the code under the Artistic License
> > coming from CPAN are analogous to Ruby gems.
> >
> > When people use frameworks like Rails, they often stick snapshots of
> > specific versions of gems that they depend on in a "vendor" directory
> > and distribute it. I'm comfortable with that practice for gems
> > licensed under the Ruby license - but not the MRI itself. But given
> > the differences between the Ruby license and the Artistic License, I
> > would be reluctant to giving the thumbs up to a similar practice for
> > Perl.
> >
> >
>
> From what I understand, most Perl packages, like the runtime, rely on the
> first version of the Artistic License:
>
> http://dev.perl.org/licenses/artistic.html
>
> This one seems less problematic to me than the 2.0, don't you think?
Section 5 in the first version seems much the same as section 7 in the
second version. If that's our sticking point, then I don't see the two
licenses being any less problematic.
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: Similar terms to AL 2.0
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Mar 20, 2008 at 1:13 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Thu, Mar 20, 2008 at 3:26 PM, Henri Yandell <ba...@apache.org> wrote:
> > On Thu, Mar 20, 2008 at 10:47 AM, Sam Ruby <ru...@intertwingly.net>
> wrote:
> > > On Thu, Mar 20, 2008 at 11:18 AM, Henri Yandell <ba...@apache.org>
> wrote:
> > > > [Once it's sync'd], our list of licenses with similar terms to AL
> 2.0 is at:
> > > >
> > > > http://www.apache.org/legal/resolved.html
> > > >
> > > > Given that that list was created a couple of years back, and the
> > > > additions were just organic, I'd like to start this thread for
> other
> > > > ones that people think need to be added.
> > >
> > > Overall, I'd prefer if we had actual use cases before we start
> adding
> > > new license.
> > >
> > > > Here's my starter list:
> > > >
> > > > * Artistic License (list variants?)
> > >
> > > Artistic 2.0, clause (7) looks troublesome.
> >
> > Agreed. It's clause 5 in Artistic 1.0. So that's out for 'similar
> > terms' I believe.
> >
> > Raises the question of 'Can I use Perl?', and 'Can I depend on an
> > Artistic licensed work, other than that which ships with Perl by
> > default?'.
>
> Of course we can use Perl. And the code under the Artistic License
> coming from CPAN are analogous to Ruby gems.
>
> When people use frameworks like Rails, they often stick snapshots of
> specific versions of gems that they depend on in a "vendor" directory
> and distribute it. I'm comfortable with that practice for gems
> licensed under the Ruby license - but not the MRI itself. But given
> the differences between the Ruby license and the Artistic License, I
> would be reluctant to giving the thumbs up to a similar practice for
> Perl.
>
>From what I understand, most Perl packages, like the runtime, rely on the
first version of the Artistic License:
http://dev.perl.org/licenses/artistic.html
This one seems less problematic to me than the 2.0, don't you think?
Cheers,
Matthieu
> > > > * Ruby License
> > >
> > > Section 4 specifies some limits when applied to the MRI itself, but
> > > these limits do not apply to other software distributed under this
> > > license. Using (but not distributing) the MRI itself is a an
> > > acceptable system requirement.
> > >
> > > This makes it confusing to document. Ruby is category A except when
> > > it is not, in which case it is OK. That's why my preference is to
> > > start a page on things that can be considered 'systems' and simply
> > > state that "anything written in Ruby and made available under the
> Ruby
> > > license is OK as a dependency for a project written in Ruby".
> >
> > +1 to not being 'similar terms', and +1 to your answer.
> >
> > My general thinking with the page is to dump answers on there, and as
> > the answers conglomerate into groups we can build subpages. So I'll be
> > adding the question/answer tonight, but feel free to go with the
> > system page if you want. I know you've a bunch of examples.
>
> +1 to a YAGNI approach to refactoring
>
> > > > * Microsoft Public License
> > >
> > > +1
> >
> > Phew. Least one of my mental list fits :)
>
> :-)
>
> > > > * ASL 1.0 [Or possibly here we just say OpenSSL]. This has the
> > > > advertising clause - do we consider such a thing similar terms?
> > >
> > > Could be consider a "restriction significantly different" from
> Apache
> > > License 2.0. I presume that there is a good reason that clause was
> > > dropped.
> >
> > Agreed. Also would apply to BSD's advertising clause.
> >
> > Do we have any OpenSSL use cases to pursue this as a separate
> > question? Not sure how mod_ssl etc fit in with OpenSSL.
>
> The way I see it, the less "similar" a license is, the more carefully
> we grant specific exceptions.
>
> MsPL is very similar; Ruby is mostly similar; Artistic a bit less so;
> BSD is also a bit less so, but in a different way.
>
> Neither mod_ssl nor apache_ssl appear to be hosted on ASF sites?
>
> - 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: Similar terms to AL 2.0
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Mar 20, 2008 at 3:26 PM, Henri Yandell <ba...@apache.org> wrote:
> On Thu, Mar 20, 2008 at 10:47 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> > On Thu, Mar 20, 2008 at 11:18 AM, Henri Yandell <ba...@apache.org> wrote:
> > > [Once it's sync'd], our list of licenses with similar terms to AL 2.0 is at:
> > >
> > > http://www.apache.org/legal/resolved.html
> > >
> > > Given that that list was created a couple of years back, and the
> > > additions were just organic, I'd like to start this thread for other
> > > ones that people think need to be added.
> >
> > Overall, I'd prefer if we had actual use cases before we start adding
> > new license.
> >
> > > Here's my starter list:
> > >
> > > * Artistic License (list variants?)
> >
> > Artistic 2.0, clause (7) looks troublesome.
>
> Agreed. It's clause 5 in Artistic 1.0. So that's out for 'similar
> terms' I believe.
>
> Raises the question of 'Can I use Perl?', and 'Can I depend on an
> Artistic licensed work, other than that which ships with Perl by
> default?'.
Of course we can use Perl. And the code under the Artistic License
coming from CPAN are analogous to Ruby gems.
When people use frameworks like Rails, they often stick snapshots of
specific versions of gems that they depend on in a "vendor" directory
and distribute it. I'm comfortable with that practice for gems
licensed under the Ruby license - but not the MRI itself. But given
the differences between the Ruby license and the Artistic License, I
would be reluctant to giving the thumbs up to a similar practice for
Perl.
> > > * Ruby License
> >
> > Section 4 specifies some limits when applied to the MRI itself, but
> > these limits do not apply to other software distributed under this
> > license. Using (but not distributing) the MRI itself is a an
> > acceptable system requirement.
> >
> > This makes it confusing to document. Ruby is category A except when
> > it is not, in which case it is OK. That's why my preference is to
> > start a page on things that can be considered 'systems' and simply
> > state that "anything written in Ruby and made available under the Ruby
> > license is OK as a dependency for a project written in Ruby".
>
> +1 to not being 'similar terms', and +1 to your answer.
>
> My general thinking with the page is to dump answers on there, and as
> the answers conglomerate into groups we can build subpages. So I'll be
> adding the question/answer tonight, but feel free to go with the
> system page if you want. I know you've a bunch of examples.
+1 to a YAGNI approach to refactoring
> > > * Microsoft Public License
> >
> > +1
>
> Phew. Least one of my mental list fits :)
:-)
> > > * ASL 1.0 [Or possibly here we just say OpenSSL]. This has the
> > > advertising clause - do we consider such a thing similar terms?
> >
> > Could be consider a "restriction significantly different" from Apache
> > License 2.0. I presume that there is a good reason that clause was
> > dropped.
>
> Agreed. Also would apply to BSD's advertising clause.
>
> Do we have any OpenSSL use cases to pursue this as a separate
> question? Not sure how mod_ssl etc fit in with OpenSSL.
The way I see it, the less "similar" a license is, the more carefully
we grant specific exceptions.
MsPL is very similar; Ruby is mostly similar; Artistic a bit less so;
BSD is also a bit less so, but in a different way.
Neither mod_ssl nor apache_ssl appear to be hosted on ASF sites?
- 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: Similar terms to AL 2.0
Posted by Henri Yandell <ba...@apache.org>.
On Thu, Mar 20, 2008 at 10:47 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Thu, Mar 20, 2008 at 11:18 AM, Henri Yandell <ba...@apache.org> wrote:
> > [Once it's sync'd], our list of licenses with similar terms to AL 2.0 is at:
> >
> > http://www.apache.org/legal/resolved.html
> >
> > Given that that list was created a couple of years back, and the
> > additions were just organic, I'd like to start this thread for other
> > ones that people think need to be added.
>
> Overall, I'd prefer if we had actual use cases before we start adding
> new license.
>
>
> > Here's my starter list:
> >
> > * Artistic License (list variants?)
>
> Artistic 2.0, clause (7) looks troublesome.
Agreed. It's clause 5 in Artistic 1.0. So that's out for 'similar
terms' I believe.
Raises the question of 'Can I use Perl?', and 'Can I depend on an
Artistic licensed work, other than that which ships with Perl by
default?'.
> > * Ruby License
>
> Section 4 specifies some limits when applied to the MRI itself, but
> these limits do not apply to other software distributed under this
> license. Using (but not distributing) the MRI itself is a an
> acceptable system requirement.
>
> This makes it confusing to document. Ruby is category A except when
> it is not, in which case it is OK. That's why my preference is to
> start a page on things that can be considered 'systems' and simply
> state that "anything written in Ruby and made available under the Ruby
> license is OK as a dependency for a project written in Ruby".
+1 to not being 'similar terms', and +1 to your answer.
My general thinking with the page is to dump answers on there, and as
the answers conglomerate into groups we can build subpages. So I'll be
adding the question/answer tonight, but feel free to go with the
system page if you want. I know you've a bunch of examples.
> > * Microsoft Public License
>
> +1
Phew. Least one of my mental list fits :)
> > * ASL 1.0 [Or possibly here we just say OpenSSL]. This has the
> > advertising clause - do we consider such a thing similar terms?
>
> Could be consider a "restriction significantly different" from Apache
> License 2.0. I presume that there is a good reason that clause was
> dropped.
Agreed. Also would apply to BSD's advertising clause.
Do we have any OpenSSL use cases to pursue this as a separate
question? Not sure how mod_ssl etc fit in with OpenSSL.
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: Similar terms to AL 2.0
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Mar 20, 2008 at 11:18 AM, Henri Yandell <ba...@apache.org> wrote:
> [Once it's sync'd], our list of licenses with similar terms to AL 2.0 is at:
>
> http://www.apache.org/legal/resolved.html
>
> Given that that list was created a couple of years back, and the
> additions were just organic, I'd like to start this thread for other
> ones that people think need to be added.
Overall, I'd prefer if we had actual use cases before we start adding
new license.
> Here's my starter list:
>
> * Artistic License (list variants?)
Artistic 2.0, clause (7) looks troublesome.
> * Ruby License
Section 4 specifies some limits when applied to the MRI itself, but
these limits do not apply to other software distributed under this
license. Using (but not distributing) the MRI itself is a an
acceptable system requirement.
This makes it confusing to document. Ruby is category A except when
it is not, in which case it is OK. That's why my preference is to
start a page on things that can be considered 'systems' and simply
state that "anything written in Ruby and made available under the Ruby
license is OK as a dependency for a project written in Ruby".
> * Microsoft Public License
+1
> * ASL 1.0 [Or possibly here we just say OpenSSL]. This has the
> advertising clause - do we consider such a thing similar terms?
Could be consider a "restriction significantly different" from Apache
License 2.0. I presume that there is a good reason that clause was
dropped.
> Hen
- 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