incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <>
Subject Re: Help with Dependency Licensing
Date Wed, 12 Apr 2017 01:03:09 GMT
On Tue, Apr 11, 2017 at 8:29 PM Niclas Hedhman <> wrote:

> On Wed, Apr 12, 2017 at 12:31 AM, Mike Jumper <>
> wrote:
> >
> > Even in the case of the GPL, my understanding is that the virality takes
> > hold upon linking (at build time), not upon referencing the API via an
> > import, include, etc. in the source.
> >
> Your understanding is, simply put, not aligned with the FSF, and the ASF
> has decided to follow FSF's conclusion. In fact, a former Director at ASF
> and lawyer, Larry Rosen, was trying to fight this stance, basically making
> the claim that GPL is overreaching, and that ended with Larry being kicked
> out (not only for this particular question).
> <quote src="" emphasis="mine">
> It has always been the FSF's position that *dynamically linking
> applications to libraries creates a single work derived* from both the
> library code and the application code.The GPL requires that all derivative
> works be licensed as a whole under the terms of the GPL, an effect which
> can be described as “hereditary.” So, if an application links to a library
> licensed under the GPL, the application too must be licensed under the GPL.
>  :
>  :
> FSF's position has remained constant throughout: the LGPL works as intended
> with all known programming languages, including Java. Applications which
> link to LGPL libraries need not be released under the LGPL. Applications
> need only follow the requirements in section 6 of the LGPL: allow new
> versions of the library to be linked with the application; and allow
> reverse engineering to debug this.
> </quote>
> At first, the "link to LGPL libraries need not be released under LGPL" is
> an indicator that Apache licensed projects could depend on LGPL projects,
> but it is this "Section 6" that makes LGPL incompatible, since we don't
> require this of our downstreams. This was hotly debated back in the days
> when this FSF article was written, and it took us a year or two to nail it
> down.
> More info at
> John, As for the case of Hibernate; If you depend on JPA, you don't depend
> on Hibernate. However, if you depend on JPA in a way so that only Hibernate
> makes the project work, and that EclipseLink or other implementations can't
> be used instead, then you are in gray territory and should ask Legal for
> advice. I am uncertain of that position.
The info I provided was based on a discussion on legal, originally carried
over from a discussion on optional dependencies on software licensed under
the Amazon Software License -

> Cheers
> --
> Niclas Hedhman, Software Developer
> - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message