You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Justin Mclean <ju...@me.com> on 2016/02/14 04:17:57 UTC
Release dependant on LGPL
Hi,
Apache Mynewt [1] is moving towards making it’s first release.
We found that one of the libraries we depend on, viper which is MIT licensed [2], in turn depends on a library that is LGPLv3 licensed (go-yaml) [3].
It is intended to replace the viper/yaml libraries with ones comparable with the Apache license and/or enquire if we can obtain the yaml code under a different license. So this will be fixed in a future incubating release.
Would it be acceptable to make an incubating release with this LGPL dependancy intact? No LGPL code would be contained in the release.
Thanks,
Justin
1. http://mynewt.incubator.apache.org
2. https://github.com/spf13/viper/blob/master/LICENSE
3. https://github.com/go-yaml/yaml/blob/v2/LICENSE
Re: Release dependant on LGPL
Posted by Christopher Collins <cc...@apache.org>.
Hi Henri,
We ended up writing a new YAML decoder and publishing it under the
Apache 2.0 license.
Chris
On Wed, Apr 13, 2016 at 03:44:09PM -0700, Henri Yandell wrote:
> Just wondering - did you enquire about the yaml code under a different
> license and/or find a decent alternative?
>
> Thanks,
>
> Hen
>
> On Sat, Feb 13, 2016 at 7:17 PM, Justin Mclean <ju...@me.com> wrote:
>
> > Hi,
> >
> > Apache Mynewt [1] is moving towards making it’s first release.
> >
> > We found that one of the libraries we depend on, viper which is MIT
> > licensed [2], in turn depends on a library that is LGPLv3 licensed
> > (go-yaml) [3].
> >
> > It is intended to replace the viper/yaml libraries with ones comparable
> > with the Apache license and/or enquire if we can obtain the yaml code under
> > a different license. So this will be fixed in a future incubating release.
> >
> > Would it be acceptable to make an incubating release with this LGPL
> > dependancy intact? No LGPL code would be contained in the release.
> >
> > Thanks,
> > Justin
> >
> > 1. http://mynewt.incubator.apache.org
> > 2. https://github.com/spf13/viper/blob/master/LICENSE
> > 3. https://github.com/go-yaml/yaml/blob/v2/LICENSE
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
Re: Release dependant on LGPL
Posted by Henri Yandell <ba...@apache.org>.
Just wondering - did you enquire about the yaml code under a different
license and/or find a decent alternative?
Thanks,
Hen
On Sat, Feb 13, 2016 at 7:17 PM, Justin Mclean <ju...@me.com> wrote:
> Hi,
>
> Apache Mynewt [1] is moving towards making it’s first release.
>
> We found that one of the libraries we depend on, viper which is MIT
> licensed [2], in turn depends on a library that is LGPLv3 licensed
> (go-yaml) [3].
>
> It is intended to replace the viper/yaml libraries with ones comparable
> with the Apache license and/or enquire if we can obtain the yaml code under
> a different license. So this will be fixed in a future incubating release.
>
> Would it be acceptable to make an incubating release with this LGPL
> dependancy intact? No LGPL code would be contained in the release.
>
> Thanks,
> Justin
>
> 1. http://mynewt.incubator.apache.org
> 2. https://github.com/spf13/viper/blob/master/LICENSE
> 3. https://github.com/go-yaml/yaml/blob/v2/LICENSE
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Release dependant on LGPL
Posted by Sam Ruby <ru...@intertwingly.net>.
PIng? Can I get a confirmation that you are OK with Toree proceeding
under similar circumstances? They are actively working towards a
release.
If you like, I can open a legal JIRA or move this to legal-discuss.
- Sam Ruby
On Fri, Feb 19, 2016 at 9:04 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Fri, Feb 19, 2016 at 8:29 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> I would say that for this single request and this single release, a one-time
>> exception is warranted.
>
> Cool, except that I will note that Toree is in the same situation, and
> is preparing a release. I would hope that that request would be OK
> too?
>
> - Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Fwd: Release dependant on LGPL
Posted by Hitesh Shah <hi...@apache.org>.
FYI for the Toree release.
More details on the thread here: http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E - if folks are not following the discussion on general@incubator.
thanks
— Hitesh
Begin forwarded message:
> From: Jim Jagielski <ji...@jaguNET.com>
> Subject: Re: Release dependant on LGPL
> Date: February 24, 2016 at 3:22:25 AM PST
> To: Sam Ruby <ru...@intertwingly.net>
> Cc: general@incubator.apache.org
> Reply-To: general@incubator.apache.org
>
> Under the same conditions, yes.
>> On Feb 19, 2016, at 9:04 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>>
>> On Fri, Feb 19, 2016 at 8:29 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>> I would say that for this single request and this single release, a one-time
>>> exception is warranted.
>>
>> Cool, except that I will note that Toree is in the same situation, and
>> is preparing a release. I would hope that that request would be OK
>> too?
>>
>> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: Release dependant on LGPL
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Feb 24, 2016 at 3:22 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> Under the same conditions, yes.
>
Thanks, we will proceed with the release.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Release dependant on LGPL
Posted by Jim Jagielski <ji...@jaguNET.com>.
Under the same conditions, yes.
> On Feb 19, 2016, at 9:04 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Fri, Feb 19, 2016 at 8:29 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> I would say that for this single request and this single release, a one-time
>> exception is warranted.
>
> Cool, except that I will note that Toree is in the same situation, and
> is preparing a release. I would hope that that request would be OK
> too?
>
> - Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release dependant on LGPL
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Feb 19, 2016 at 8:29 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I would say that for this single request and this single release, a one-time
> exception is warranted.
Cool, except that I will note that Toree is in the same situation, and
is preparing a release. I would hope that that request would be OK
too?
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release dependant on LGPL
Posted by Jim Jagielski <ji...@jaguNET.com>.
I would say that for this single request and this single release, a one-time
exception is warranted.
> On Feb 15, 2016, at 6:01 PM, Craig Russell <cr...@oracle.com> wrote:
>
> I agree that an incubating release does not need to be fully compliant with the proscription against mandatory LGPL dependencies for Apache releases.
>
> Clearly the podling is well aware of the need to replace the LGPL dependency before graduation. And I agree with Greg that a podling learning the requirements of release and turning the crank is most important.
>
> Craig
>
>> On Feb 15, 2016, at 1:49 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>>
>> On Mon, Feb 15, 2016 at 1:16 PM, Luciano Resende <lu...@gmail.com> wrote:
>>> Apache Toree had a similar issue, and we have discussed this in
>>> legal-discuss, and here is the feedback from Jim, VP of Legal
>>>
>>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201602.mbox/%3C2A8B931C-1AD6-4230-B2DE-0B33361B3A2B%40jaguNET.com%3E
>>
>> The LGPL's reverse engineering provisions make it more difficult to
>> understand the licensing obligations of any ostensibly
>> Apache-2-licensed product with an LGPL-licensed mandatory runtime
>> dependency. Jim speaks for many of us in that thread.
>>
>> However, one of the reasons we have the "incubating" label is to let
>> people know that "incubating" releases may not be fully compliant with
>> all Apache policies.
>>
>> See https://issues.apache.org/jira/browse/LEGAL-86 for an example of
>> where incubating releases were allowed with a runtime dependency on a
>> non-approved license. Just as Greg laid out, a plan was proposed for
>> removing the dependency before graduation and the VP Legal at the
>> time, Sam Ruby, gave his OK.
>>
>> With LEGAL-86, VP Legal's approval was sought in advance, and in
>> general podlings should should be aware of resources like the
>> legal-discuss@apache list and should learn when and how to utilize
>> them. However, unless Greg advises Mynewt to consult VP Legal (and I'm
>> all but certain he won't), that won't be necessary in this case.
>>
>> Marvin Humphrey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release dependant on LGPL
Posted by Jim Jagielski <ji...@jaguNET.com>.
I would say that for this single request and this single release, a one-time
exception is warranted.
> On Feb 15, 2016, at 6:01 PM, Craig Russell <cr...@oracle.com> wrote:
>
> I agree that an incubating release does not need to be fully compliant with the proscription against mandatory LGPL dependencies for Apache releases.
>
> Clearly the podling is well aware of the need to replace the LGPL dependency before graduation. And I agree with Greg that a podling learning the requirements of release and turning the crank is most important.
>
> Craig
>
>> On Feb 15, 2016, at 1:49 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>>
>> On Mon, Feb 15, 2016 at 1:16 PM, Luciano Resende <lu...@gmail.com> wrote:
>>> Apache Toree had a similar issue, and we have discussed this in
>>> legal-discuss, and here is the feedback from Jim, VP of Legal
>>>
>>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201602.mbox/%3C2A8B931C-1AD6-4230-B2DE-0B33361B3A2B%40jaguNET.com%3E
>>
>> The LGPL's reverse engineering provisions make it more difficult to
>> understand the licensing obligations of any ostensibly
>> Apache-2-licensed product with an LGPL-licensed mandatory runtime
>> dependency. Jim speaks for many of us in that thread.
>>
>> However, one of the reasons we have the "incubating" label is to let
>> people know that "incubating" releases may not be fully compliant with
>> all Apache policies.
>>
>> See https://issues.apache.org/jira/browse/LEGAL-86 for an example of
>> where incubating releases were allowed with a runtime dependency on a
>> non-approved license. Just as Greg laid out, a plan was proposed for
>> removing the dependency before graduation and the VP Legal at the
>> time, Sam Ruby, gave his OK.
>>
>> With LEGAL-86, VP Legal's approval was sought in advance, and in
>> general podlings should should be aware of resources like the
>> legal-discuss@apache list and should learn when and how to utilize
>> them. However, unless Greg advises Mynewt to consult VP Legal (and I'm
>> all but certain he won't), that won't be necessary in this case.
>>
>> Marvin Humphrey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: Release dependant on LGPL
Posted by Craig Russell <cr...@oracle.com>.
I agree that an incubating release does not need to be fully compliant with the proscription against mandatory LGPL dependencies for Apache releases.
Clearly the podling is well aware of the need to replace the LGPL dependency before graduation. And I agree with Greg that a podling learning the requirements of release and turning the crank is most important.
Craig
> On Feb 15, 2016, at 1:49 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>
> On Mon, Feb 15, 2016 at 1:16 PM, Luciano Resende <lu...@gmail.com> wrote:
>> Apache Toree had a similar issue, and we have discussed this in
>> legal-discuss, and here is the feedback from Jim, VP of Legal
>>
>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201602.mbox/%3C2A8B931C-1AD6-4230-B2DE-0B33361B3A2B%40jaguNET.com%3E
>
> The LGPL's reverse engineering provisions make it more difficult to
> understand the licensing obligations of any ostensibly
> Apache-2-licensed product with an LGPL-licensed mandatory runtime
> dependency. Jim speaks for many of us in that thread.
>
> However, one of the reasons we have the "incubating" label is to let
> people know that "incubating" releases may not be fully compliant with
> all Apache policies.
>
> See https://issues.apache.org/jira/browse/LEGAL-86 for an example of
> where incubating releases were allowed with a runtime dependency on a
> non-approved license. Just as Greg laid out, a plan was proposed for
> removing the dependency before graduation and the VP Legal at the
> time, Sam Ruby, gave his OK.
>
> With LEGAL-86, VP Legal's approval was sought in advance, and in
> general podlings should should be aware of resources like the
> legal-discuss@apache list and should learn when and how to utilize
> them. However, unless Greg advises Mynewt to consult VP Legal (and I'm
> all but certain he won't), that won't be necessary in this case.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release dependant on LGPL
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Feb 15, 2016 at 4:49 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Mon, Feb 15, 2016 at 1:16 PM, Luciano Resende <lu...@gmail.com> wrote:
>> Apache Toree had a similar issue, and we have discussed this in
>> legal-discuss, and here is the feedback from Jim, VP of Legal
>>
>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201602.mbox/%3C2A8B931C-1AD6-4230-B2DE-0B33361B3A2B%40jaguNET.com%3E
>
> The LGPL's reverse engineering provisions make it more difficult to
> understand the licensing obligations of any ostensibly
> Apache-2-licensed product with an LGPL-licensed mandatory runtime
> dependency. Jim speaks for many of us in that thread.
>
> However, one of the reasons we have the "incubating" label is to let
> people know that "incubating" releases may not be fully compliant with
> all Apache policies.
>
> See https://issues.apache.org/jira/browse/LEGAL-86 for an example of
> where incubating releases were allowed with a runtime dependency on a
> non-approved license. Just as Greg laid out, a plan was proposed for
> removing the dependency before graduation and the VP Legal at the
> time, Sam Ruby, gave his OK.
>
> With LEGAL-86, VP Legal's approval was sought in advance, and in
> general podlings should should be aware of resources like the
> legal-discuss@apache list and should learn when and how to utilize
> them. However, unless Greg advises Mynewt to consult VP Legal (and I'm
> all but certain he won't), that won't be necessary in this case.
I'm not Greg, but I would suggest at least notifying VP Legal, and by
that I mean sending a note to Jim copying legal-discuss, and not
merely assuming that he is both lurking here and is likely to make the
same determination that I would (and did) under similar circumstances.
I'm just being careful and respectful - I am NOT expecting this to
turn up any issues. And a single request can cover both the Mynewt
and Toree cases, even though they are subtly different (Mynewt plans
to replace the library under question, and the library that Toree
depends on is actively being re-licensed).
Unless anybody objects or would rather be the one to do so, I will
send this note, and refer to this discussion for context.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release dependant on LGPL
Posted by Craig Russell <cr...@oracle.com>.
I agree that an incubating release does not need to be fully compliant with the proscription against mandatory LGPL dependencies for Apache releases.
Clearly the podling is well aware of the need to replace the LGPL dependency before graduation. And I agree with Greg that a podling learning the requirements of release and turning the crank is most important.
Craig
> On Feb 15, 2016, at 1:49 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
>
> On Mon, Feb 15, 2016 at 1:16 PM, Luciano Resende <lu...@gmail.com> wrote:
>> Apache Toree had a similar issue, and we have discussed this in
>> legal-discuss, and here is the feedback from Jim, VP of Legal
>>
>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201602.mbox/%3C2A8B931C-1AD6-4230-B2DE-0B33361B3A2B%40jaguNET.com%3E
>
> The LGPL's reverse engineering provisions make it more difficult to
> understand the licensing obligations of any ostensibly
> Apache-2-licensed product with an LGPL-licensed mandatory runtime
> dependency. Jim speaks for many of us in that thread.
>
> However, one of the reasons we have the "incubating" label is to let
> people know that "incubating" releases may not be fully compliant with
> all Apache policies.
>
> See https://issues.apache.org/jira/browse/LEGAL-86 for an example of
> where incubating releases were allowed with a runtime dependency on a
> non-approved license. Just as Greg laid out, a plan was proposed for
> removing the dependency before graduation and the VP Legal at the
> time, Sam Ruby, gave his OK.
>
> With LEGAL-86, VP Legal's approval was sought in advance, and in
> general podlings should should be aware of resources like the
> legal-discuss@apache list and should learn when and how to utilize
> them. However, unless Greg advises Mynewt to consult VP Legal (and I'm
> all but certain he won't), that won't be necessary in this case.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: Release dependant on LGPL
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Feb 15, 2016 at 1:16 PM, Luciano Resende <lu...@gmail.com> wrote:
> Apache Toree had a similar issue, and we have discussed this in
> legal-discuss, and here is the feedback from Jim, VP of Legal
>
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201602.mbox/%3C2A8B931C-1AD6-4230-B2DE-0B33361B3A2B%40jaguNET.com%3E
The LGPL's reverse engineering provisions make it more difficult to
understand the licensing obligations of any ostensibly
Apache-2-licensed product with an LGPL-licensed mandatory runtime
dependency. Jim speaks for many of us in that thread.
However, one of the reasons we have the "incubating" label is to let
people know that "incubating" releases may not be fully compliant with
all Apache policies.
See https://issues.apache.org/jira/browse/LEGAL-86 for an example of
where incubating releases were allowed with a runtime dependency on a
non-approved license. Just as Greg laid out, a plan was proposed for
removing the dependency before graduation and the VP Legal at the
time, Sam Ruby, gave his OK.
With LEGAL-86, VP Legal's approval was sought in advance, and in
general podlings should should be aware of resources like the
legal-discuss@apache list and should learn when and how to utilize
them. However, unless Greg advises Mynewt to consult VP Legal (and I'm
all but certain he won't), that won't be necessary in this case.
Marvin Humphrey
Re: Release dependant on LGPL
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Feb 15, 2016 at 1:16 PM, Luciano Resende <lu...@gmail.com> wrote:
> Apache Toree had a similar issue, and we have discussed this in
> legal-discuss, and here is the feedback from Jim, VP of Legal
>
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201602.mbox/%3C2A8B931C-1AD6-4230-B2DE-0B33361B3A2B%40jaguNET.com%3E
The LGPL's reverse engineering provisions make it more difficult to
understand the licensing obligations of any ostensibly
Apache-2-licensed product with an LGPL-licensed mandatory runtime
dependency. Jim speaks for many of us in that thread.
However, one of the reasons we have the "incubating" label is to let
people know that "incubating" releases may not be fully compliant with
all Apache policies.
See https://issues.apache.org/jira/browse/LEGAL-86 for an example of
where incubating releases were allowed with a runtime dependency on a
non-approved license. Just as Greg laid out, a plan was proposed for
removing the dependency before graduation and the VP Legal at the
time, Sam Ruby, gave his OK.
With LEGAL-86, VP Legal's approval was sought in advance, and in
general podlings should should be aware of resources like the
legal-discuss@apache list and should learn when and how to utilize
them. However, unless Greg advises Mynewt to consult VP Legal (and I'm
all but certain he won't), that won't be necessary in this case.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release dependant on LGPL
Posted by Luciano Resende <lu...@gmail.com>.
Apache Toree had a similar issue, and we have discussed this in
legal-discuss, and here is the feedback from Jim, VP of Legal
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201602.mbox/%3C2A8B931C-1AD6-4230-B2DE-0B33361B3A2B%40jaguNET.com%3E
On Sat, Feb 13, 2016 at 8:46 PM, Greg Stein <gs...@gmail.com> wrote:
> Speaking as an IPMC Member, and a Mynewt Mentor … yes, this is fine with a
> disclaimer in the release notes. The Incubator process is about tracking
> these down, and getting them fixed. Incubation releases are not expected to
> be *fully* conformant to all ASF policies, especially if there is a known
> path to remedy the issue. For example, I'm pretty sure we've seen
> Incubation releases still dependent upon Hibernate, until the podling gets
> the work down to make that dependency optional.
>
> IMO, it is more important to get the podling turning the crank of a
> release, to learn these things, and prep the future release processes, than
> to clear out that (disclosed!) dependency upon an LGPL library.
>
> Cheers,
> -g
>
>
> On Sat, Feb 13, 2016 at 9:17 PM, Justin Mclean <ju...@me.com>
> wrote:
>
> > Hi,
> >
> > Apache Mynewt [1] is moving towards making it’s first release.
> >
> > We found that one of the libraries we depend on, viper which is MIT
> > licensed [2], in turn depends on a library that is LGPLv3 licensed
> > (go-yaml) [3].
> >
> > It is intended to replace the viper/yaml libraries with ones comparable
> > with the Apache license and/or enquire if we can obtain the yaml code
> under
> > a different license. So this will be fixed in a future incubating
> release.
> >
> > Would it be acceptable to make an incubating release with this LGPL
> > dependancy intact? No LGPL code would be contained in the release.
> >
> > Thanks,
> > Justin
> >
> > 1. http://mynewt.incubator.apache.org
> > 2. https://github.com/spf13/viper/blob/master/LICENSE
> > 3. https://github.com/go-yaml/yaml/blob/v2/LICENSE
>
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Release dependant on LGPL
Posted by Sterling Hughes <st...@apache.org>.
On 2/19/16 6:15 AM, Bertrand Delacretaz wrote:
> On Sun, Feb 14, 2016 at 5:46 AM, Greg Stein <gs...@gmail.com> wrote:
>> ...Speaking as an IPMC Member, and a Mynewt Mentor … yes, this is fine with a
>> disclaimer in the release notes....
>
> Except we don't have a standard for release notes, so how about we
> require a mention in the DISCLAIMER file that incubating releases are
> required to include?
>
> Something like "This release is not fully compliant with Apache
> release policy and includes..." in that file.
>
That would be fine with us. The main point of this release was to
familiarize ourself with the process, and find out all the warts. We
have a beta2 planned shortly afterwards, where we will clean up
everything we found going through beta1 (which seems doable.)
We'd like to go ahead, just so we've put it through the paces prior to
our next beta, and we have the full list of things we need to improve.
As a quick summary on the license front, we've found:
- We have some Go LGPL dependencies in our build tool that need to ...
go... This is a day's worth of work, unfortunately because of where
they are in the dependency chain.
- (more serious) Some of the chip vendor license headers have a modified
3-clause BSD license for their driver headers. They end up being some
derivant of:
http://www.st.com/web/en/resource/legal/legal_agreement/license_agreement/ultimate-liberty-v2.txt?sc=software_license_agreement_liberty_v2
"4. This software, including modifications and/or derivative works of
this software, must execute solely and exclusively on microcontroller or
microprocessor devices manufactured by or for STMicroelectronics."
That's obviously not kosher. We have two potential remedies, which
we'll need to work through prior to next release:
1- Many of these vendors seem to have the same header files licensed
many ways, depending on version and phase of the moon. Sometimes the
exact same files are available straight up BSD. We'll move to those
where possible.
2- For ones that aren't, Newt has a package search and install tool.
These files are in packages that only need to be included when building
for that platform (and therefore compliant with the license.) We can
break these out and host them on Github, and people can search for and
install them.We've done this with one of the packages as a test for this
release: https://github.com/runtimeinc/mynewt_stm32f3
3- We'll work with the chip vendors and ask them to re-license their
files. This will be a slower process, but many of them are actually
excited about Mynewt, and may be receptive.
Thanks,
Sterling
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release dependant on LGPL
Posted by Sterling Hughes <st...@apache.org>.
On 2/19/16 6:15 AM, Bertrand Delacretaz wrote:
> On Sun, Feb 14, 2016 at 5:46 AM, Greg Stein <gs...@gmail.com> wrote:
>> ...Speaking as an IPMC Member, and a Mynewt Mentor … yes, this is fine with a
>> disclaimer in the release notes....
>
> Except we don't have a standard for release notes, so how about we
> require a mention in the DISCLAIMER file that incubating releases are
> required to include?
>
> Something like "This release is not fully compliant with Apache
> release policy and includes..." in that file.
>
That would be fine with us. The main point of this release was to
familiarize ourself with the process, and find out all the warts. We
have a beta2 planned shortly afterwards, where we will clean up
everything we found going through beta1 (which seems doable.)
We'd like to go ahead, just so we've put it through the paces prior to
our next beta, and we have the full list of things we need to improve.
As a quick summary on the license front, we've found:
- We have some Go LGPL dependencies in our build tool that need to ...
go... This is a day's worth of work, unfortunately because of where
they are in the dependency chain.
- (more serious) Some of the chip vendor license headers have a modified
3-clause BSD license for their driver headers. They end up being some
derivant of:
http://www.st.com/web/en/resource/legal/legal_agreement/license_agreement/ultimate-liberty-v2.txt?sc=software_license_agreement_liberty_v2
"4. This software, including modifications and/or derivative works of
this software, must execute solely and exclusively on microcontroller or
microprocessor devices manufactured by or for STMicroelectronics."
That's obviously not kosher. We have two potential remedies, which
we'll need to work through prior to next release:
1- Many of these vendors seem to have the same header files licensed
many ways, depending on version and phase of the moon. Sometimes the
exact same files are available straight up BSD. We'll move to those
where possible.
2- For ones that aren't, Newt has a package search and install tool.
These files are in packages that only need to be included when building
for that platform (and therefore compliant with the license.) We can
break these out and host them on Github, and people can search for and
install them.We've done this with one of the packages as a test for this
release: https://github.com/runtimeinc/mynewt_stm32f3
3- We'll work with the chip vendors and ask them to re-license their
files. This will be a slower process, but many of them are actually
excited about Mynewt, and may be receptive.
Thanks,
Sterling
Re: Release dependant on LGPL
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sun, Feb 14, 2016 at 5:46 AM, Greg Stein <gs...@gmail.com> wrote:
> ...Speaking as an IPMC Member, and a Mynewt Mentor … yes, this is fine with a
> disclaimer in the release notes....
Except we don't have a standard for release notes, so how about we
require a mention in the DISCLAIMER file that incubating releases are
required to include?
Something like "This release is not fully compliant with Apache
release policy and includes..." in that file.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Release dependant on LGPL
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sun, Feb 14, 2016 at 5:46 AM, Greg Stein <gs...@gmail.com> wrote:
> ...Speaking as an IPMC Member, and a Mynewt Mentor … yes, this is fine with a
> disclaimer in the release notes....
Except we don't have a standard for release notes, so how about we
require a mention in the DISCLAIMER file that incubating releases are
required to include?
Something like "This release is not fully compliant with Apache
release policy and includes..." in that file.
-Bertrand
Re: Release dependant on LGPL
Posted by Luciano Resende <lu...@gmail.com>.
Apache Toree had a similar issue, and we have discussed this in
legal-discuss, and here is the feedback from Jim, VP of Legal
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201602.mbox/%3C2A8B931C-1AD6-4230-B2DE-0B33361B3A2B%40jaguNET.com%3E
On Sat, Feb 13, 2016 at 8:46 PM, Greg Stein <gs...@gmail.com> wrote:
> Speaking as an IPMC Member, and a Mynewt Mentor … yes, this is fine with a
> disclaimer in the release notes. The Incubator process is about tracking
> these down, and getting them fixed. Incubation releases are not expected to
> be *fully* conformant to all ASF policies, especially if there is a known
> path to remedy the issue. For example, I'm pretty sure we've seen
> Incubation releases still dependent upon Hibernate, until the podling gets
> the work down to make that dependency optional.
>
> IMO, it is more important to get the podling turning the crank of a
> release, to learn these things, and prep the future release processes, than
> to clear out that (disclosed!) dependency upon an LGPL library.
>
> Cheers,
> -g
>
>
> On Sat, Feb 13, 2016 at 9:17 PM, Justin Mclean <ju...@me.com>
> wrote:
>
> > Hi,
> >
> > Apache Mynewt [1] is moving towards making it’s first release.
> >
> > We found that one of the libraries we depend on, viper which is MIT
> > licensed [2], in turn depends on a library that is LGPLv3 licensed
> > (go-yaml) [3].
> >
> > It is intended to replace the viper/yaml libraries with ones comparable
> > with the Apache license and/or enquire if we can obtain the yaml code
> under
> > a different license. So this will be fixed in a future incubating
> release.
> >
> > Would it be acceptable to make an incubating release with this LGPL
> > dependancy intact? No LGPL code would be contained in the release.
> >
> > Thanks,
> > Justin
> >
> > 1. http://mynewt.incubator.apache.org
> > 2. https://github.com/spf13/viper/blob/master/LICENSE
> > 3. https://github.com/go-yaml/yaml/blob/v2/LICENSE
>
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Release dependant on LGPL
Posted by Greg Stein <gs...@gmail.com>.
Speaking as an IPMC Member, and a Mynewt Mentor … yes, this is fine with a
disclaimer in the release notes. The Incubator process is about tracking
these down, and getting them fixed. Incubation releases are not expected to
be *fully* conformant to all ASF policies, especially if there is a known
path to remedy the issue. For example, I'm pretty sure we've seen
Incubation releases still dependent upon Hibernate, until the podling gets
the work down to make that dependency optional.
IMO, it is more important to get the podling turning the crank of a
release, to learn these things, and prep the future release processes, than
to clear out that (disclosed!) dependency upon an LGPL library.
Cheers,
-g
On Sat, Feb 13, 2016 at 9:17 PM, Justin Mclean <ju...@me.com> wrote:
> Hi,
>
> Apache Mynewt [1] is moving towards making it’s first release.
>
> We found that one of the libraries we depend on, viper which is MIT
> licensed [2], in turn depends on a library that is LGPLv3 licensed
> (go-yaml) [3].
>
> It is intended to replace the viper/yaml libraries with ones comparable
> with the Apache license and/or enquire if we can obtain the yaml code under
> a different license. So this will be fixed in a future incubating release.
>
> Would it be acceptable to make an incubating release with this LGPL
> dependancy intact? No LGPL code would be contained in the release.
>
> Thanks,
> Justin
>
> 1. http://mynewt.incubator.apache.org
> 2. https://github.com/spf13/viper/blob/master/LICENSE
> 3. https://github.com/go-yaml/yaml/blob/v2/LICENSE
Re: Release dependant on LGPL
Posted by Greg Stein <gs...@gmail.com>.
Speaking as an IPMC Member, and a Mynewt Mentor … yes, this is fine with a
disclaimer in the release notes. The Incubator process is about tracking
these down, and getting them fixed. Incubation releases are not expected to
be *fully* conformant to all ASF policies, especially if there is a known
path to remedy the issue. For example, I'm pretty sure we've seen
Incubation releases still dependent upon Hibernate, until the podling gets
the work down to make that dependency optional.
IMO, it is more important to get the podling turning the crank of a
release, to learn these things, and prep the future release processes, than
to clear out that (disclosed!) dependency upon an LGPL library.
Cheers,
-g
On Sat, Feb 13, 2016 at 9:17 PM, Justin Mclean <ju...@me.com> wrote:
> Hi,
>
> Apache Mynewt [1] is moving towards making it’s first release.
>
> We found that one of the libraries we depend on, viper which is MIT
> licensed [2], in turn depends on a library that is LGPLv3 licensed
> (go-yaml) [3].
>
> It is intended to replace the viper/yaml libraries with ones comparable
> with the Apache license and/or enquire if we can obtain the yaml code under
> a different license. So this will be fixed in a future incubating release.
>
> Would it be acceptable to make an incubating release with this LGPL
> dependancy intact? No LGPL code would be contained in the release.
>
> Thanks,
> Justin
>
> 1. http://mynewt.incubator.apache.org
> 2. https://github.com/spf13/viper/blob/master/LICENSE
> 3. https://github.com/go-yaml/yaml/blob/v2/LICENSE