On Thu, Jul 04, 2013 at 11:43:27PM +0300, Engel Nyst wrote:
On 05/18/2013 07:24 AM, Richard Fontana wrote:
> The point of this change in copyleft-next is that, if, say, rtslib had
> been under copyleft-next (and had escaped the nullification of
> proprietary/copyleft dual licensing provision somehow [1]), then some
> downstream noncopyleft (or proprietary) endeavor should not need to
> worry about the mere use of an external library as in itself having a
> copyleft effect on the immediate work in question -- unless the
> licensor of the copyleft-next library says something explicit to make
> clear that this is intended (in which case it still is not a foregone
> conclusion that the dependency relationship gives rise to some
> copyleft effect).
>
Isn't it contradictory with section 3, first paragraph?
> This condition may not be avoided through such means as separate
> Distribution of portions of the Derived Work.
I suppose it clarifies the meaning of that sentence in section
3. Merely distributing some Apache License 2.0 Python program that
happens to say "import <name of copyleft-next-licensed library>" is
not in itself "separate Distribution of portions of the Derived
Work".
The section 3 language is adapted from similar language in GPLv3
section 5, which as I recall was tied up with the deletion of the
language from GPLv2 section 2 antepenultimate paragraph.
For reference, the comment to this commit[1] is saying that the
licensor
should include a statement like "Any code that imports bar, and which
otherwise meets the definition of 'Derived Work' of bar in
copyleft-next, shall be considered a Derived Work of bar even if such
code is not distributed with bar."
Yes, but this is intended to hint at the view that such code *by
itself* would not, or should not, meet the definition of 'Derived
Work'.
- RF