Re: Dependency on Package where Upstream License Changed to Non-Free
Hello,
> > The source of the EPS lib is contained in the UMLet release
>
> Then it's not an external dependency, you have a fork. A fork that is -
> and therefore will remain - GPL. What you may miss out on are updates,
> that's all.
It was shipped with UMLet only for convenience. But since jibble no
longer releases the file under GPL, this seems to be the only place were
to get it.
> > 2. Ship the EPS library as part of the UMLet package.
>
> Keep the GPL code already within UMLet, create a new home for it -
> say on SourceForge - as a fork. Future upstream releases can be
> assessed when the time comes.
I am reluctant to take over upstream maintenance of the EPS library.
> > 3. Create a new package containing only the EPS library.
>
> Why? Is any other package likely to use it? What would be gained? I
> can't see that is worthwhile paying for the current version to go into
> non-free and moving your package to contrib.
What I meant here, is taking the source of the EPS library shipped with
UMLet and create a package from that one. So basically doing a fork,
without providing a new upstream, instead considering the UMLet
distribution as upstream. This would lead to having a source package
UMLet and the two binary packages libeps and umlet.
The library sounds useful for others too, but this is only a theoretical
possibility.
> > What would you suggest?
> Personally, 2. Fork it.
Thanks Neil for your input.
After considering your arguments and my requirements, I've decided not
to create a separate package for the EPS lib. I will consider it to be a
part of UMLet. The reason for this is, that if UMLet upstream decides to
replace or remove the EPS part (and drops it from their distribution) I
won't have a library package without an upstream maintainer left.
Regards Ben
--
Please do not send any email to ben-ml@gmx.net -- all email not
originating from the mailing list will be deleted. Use the reply to
address instead.
Reply to: