Re: bt747: doubts on licenses and embedded libraries
On Sunday 15 May 2011 14:48:07 Eric Lavarde wrote:
> Hello Monica,
Hi,
> interesting that you're now working on bt747: I'm also using this
> program to download my GPS tracks and flag my photos, wanted as well to
> package it, and basically silently gave up as I looked into it :-P
I'd actually favor your decision, instead :-)
> Anyway I'm happy that someone has more courage and/or time to do it!
>
> On 15/05/11 13:22, Mònica Ramírez Arceda wrote:
> > El dg 15 de 05 de 2011 a les 19:08 +0800, en/na Paul Wise va escriure:
> >> Yep, package any embedded code copies separately.
> >>
> >> For modified code copies, try to get the changes into their proper
> >> upstream or the Debian package if it exists.
> >
> > Ok, I'll try it, altough this library doesn't exist in Debian, for now.
> >
> > But I don't understand what I have to do when I have these changes :-(
>
> To be honest, I had the same problem as you with Freeplane and JOrtho,
> and I decided to keep JOrtho as part of the freeplane package, under the
> binary name libjortho-freeplane-java.
> The reasons were:
> - JOrtho was not in Debian either
> - JOrtho seemed not very active (dead?).
> - the changes done by the Freeplane developer on JOrtho were already
> raised to the JOrtho team but still not included though compatible.
> - by having a separate binary package, I can change the dependencies if
> required at some point in time, so it doesn't close any future option.
Well, in my opinion, these are no good reasons to fold even more nearly
unmaintained pieces of code (I admit, I haven't looked at JOrtho) inside
source packages targeted to the Debian archive. This would open the door for
more burden possibly to be placed on Release Team, Security Team, QA team,
possible NMUers, etc shoulders. I believe packages should enter Debian archive
whenever 'they are ready' to meet a certain threshold, at least (working with
upstream upfront until the issues are resolved is the way to go), instead of
getting rot inside the unstable or testing suites or maintained via nmus
because the project as a whole approaches a release. Cleaning up or reducing
the amount of embedding copies is a daunting task.
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: