Do we need to hide packages in NEW queue (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))

[Andreas Tille]

Am Tue, Jan 25, 2022 at 01:45:11PM -0800 schrieb Russ Allbery:
> Jonas Smedegaard  writes:
> 
> > I just don't think the solution is to ignore copyright or licensing
> > statements.
> 
> That's not the goal.  The question, which keeps being raised in part
> because I don't think it's gotten a good answer, is what the basis is for
> treating copyright and licensing bugs differently than any other bug in
> Debian?
> 
> The need for pre-screening was obvious when we had export control issues,
> but my understanding is that those have gone away.  Are we working from
> legal advice telling us that this pre-screening is required for some legal
> purpose?  If so, is it effective for the legal purpose at which it is
> aimed?  Is this system left over from old advice?  Have we checked our
> assumptions recently?

May be some intermediate step would be to not hide packages in NEW queue
but exposing them as an apt source.  If I'm correct this is not the case
since it had certain legal consequences for the project if code with
certain non-free licenses would be downloadable from some debian.org
address.  May be NEW could be considered as some kind of pre-non-free as
long as it is not checked and the legal consequences are not valid for
us any more.  But I'm not educated in international law - just asking
whether somebody might know better.

I'd consider it a big step forward to develop against packages from NEW
queue.  (And yes, *I* know how to help myself with a local mirror but
team wide development is something else.)
 
> NEW processing is a lot of friction for the project as a whole and a lot
> of work for the ftp team.  If we were able to do less work at the cost of
> a minimal increase in bugs, or at the cost of handling bugs a bit
> differently, maybe that would be a good thing?
> 
> In other words, it's unclear what requirements we're attempting to meet
> and what the basis of those requirements is, which makes it hard to have a
> conversation about whether the current design is the best design for the
> problem we're trying to solve.

I'm CCing debian-legal for this branch of the discussion (but I do not
read this list and think keeping debian-devel in the row is a good idea).

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Re: Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Andreas Tille]

On Mon, Aug 30, 2021 at 06:18:20AM -0700, Felix Lechner wrote:
> 
> Can we ship GNU Parallel with a small wrapper that removes the notice?
> Being text-based, it would not modify the software at all. I am
> thinking about something like:
> 
> $ echo 'NOTICE: Wanted output.' | perl -pe '{ s/^NOTICE:\s*(.*)/$1/ }'
> Wanted output.

I admit I also considered a wrapper but with a different functionality:
Simply check whether --citation was used before and if not do so.

I did not implemented this since from a user point of view the visible
effect is the same as the patch and the upstream author is probably
similarly (un)happy about it as the patch.

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Andreas Tille]

Hi,

since this issue becomes complex I'd like to bring up it at debian-legal
list for advise.

Kind regards

 Andreas.

On Mon, Aug 30, 2021 at 08:08:26AM +0200, Ole Tange wrote:
> Ian Turner  wrote:
> > On 8/28/21 7:41 AM, Andreas Tille wrote:
> >>I updated the patch in Git[1] but did not yet activate it yet.  I'm fine
> >>with uploading parallel with the patch activated if you really think we
> >>should disrespect the wish of the author and insist on plain GPL text.
> >
> > My reading of bug 905674 is that the citation notice has been previously
> > judged to be incompatible with the DFSG and that's why it was removed.
> > Also ultimately Debian developers will have to make their own decision,
> > though if you are asking my personal opinion, I think it would be best to
> > remove it.
> 
> The only license that gives you the right to change the source code is GPLv3.
> 
> #905674 and #915541 refer to the wording of version 20141022. The
> current wording (20210722) has been cleared by Richard M. Stallman to
> be compatible with GPLv3. This is because the citation notice is not
> part of the license, but part of academic tradition (this was not
> clear in version 20141022).
> 
> DFSG mentions "The license must not restrict anyone from making use of
> the program in a specific field of endeavor", and since the academic
> tradition is not part of the license and since the tradition does not
> "restrict anyone from making use of the program in a specific field of
> endeavor", it is hard to see, how you would argue the wording of
> version 20210722 does not adhere to DFSG (the wording in 20141022 was
> different, and it is this old wording that is the background for
> #905674 and referred in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915541#5).
> 
> If your stance is based on reading #905674 I will encourage you to
> read the current wording, and argue how the current wording does not
> adhere to DFSG.
> 
> If you disagree with Richard M. Stallman's interpretation of GPLv3 and
> feel the citation notice does not adhere to GPLv3, you should treat
> the software as if it is not available under GPLv3. And since GPLv3 is
> the only thing that would give you the right to change it, you would
> not be allowed to change the software.
> 
> In other words: If you want to remove the citation notice to make the
> software compliant with your interpretation of GPLv3, you first have
> to accept that the software is already compliant with GPLv3, because
> nothing else gives you the right to change it. And if you accept this,
> you do not need to change it to make it compliant.
> 
> 
> Citations are what indirectly fund maintaining GNU Parallel (for
> details see: 
> https://git.savannah.gnu.org/cgit/parallel.git/tree/doc/citation-notice-faq.txt).
> Before the citation notice was implemented hardly anyone cited GNU
> Parallel, and that would not have been sustainable in the long term.
> 
> Therefore it is more important to keep the notice than to be included
> in different distributions. Specifically, it will be preferable to be
> moved from Debian main to Debian non-free over having the notice
> removed (and staying in main).
> 
> In other words: It is preferable having fewer users, who all know they
> should cite, over having many users, who do not know they should cite.
> 
> This is because long-term survival with funding is more important than
> short-term gains in popularity that can be achieved by being
> distributed as part of a distribution.
> 
> If the goal had been to get more users, then the license would have
> been public domain.
> 
> 
> By removing the citation notice you are knowingly making it harder for
> me to justify spending time on developing GNU Parallel, and sending a
> signal to future developers that Debian does not care about their long
> term survival - only short term benefits to the project. I hope we can
> agree we want more free software in the future - not less.
> 
> > I am among those not persuaded by Ole's arguments to the
> > contrary, in the specific context of the Debian project.
> 
> If the revised wording (from version 20141022 to version 20210722)
> does not change your opinion, I feel the only compromise that is
> acceptable to all the active parties is to keep the citation notice
> even if this means moving the software from main to non-free.
> 
> 
> /Ole
> 

-- 
http://fam-tille.de

Re: FreeMedForms projet

[Andreas Tille]

On Sat, Jan 11, 2020 at 08:39:48AM +0800, Paul Wise wrote:
> 
> The bigger problem for entering Debian is what Andreas mentions, that
> the software uses Qt4 instead of Qt5. Once you have released a new
> version that uses Qt5 it could potentially enter Debian.

To be correct: Version 0.9.4 in Debian is Qt4, but Version 1.0.0 in Git
is Qt5.  It just does not build successfully[1] ... and since monthes
nobody was able fix this.  Eric said he can not reproduce this build
issue (in private mail) and non of the Debian maintainers found a clue
so far.

Kind regards
 Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874880#104

-- 
http://fam-tille.de

Re: FreeMedForms projet

[Andreas Tille]

On Fri, Jan 10, 2020 at 07:45:34AM -0500, Daniel Hakimi wrote:
> Can you please clarify -- you said the license was the same, but you didn't
> say what that license actually was. What license is your code available
> under?

GPL-3+ [1]

BTW, I think if a Debian package is published the requirement to sign
anything to get the source code is useless since interested parties can
easily download the Debian source package.

This is for instance true for the latest source in Git which just has a
compile bug which we desperately try to fix to finalise the Qt4
removal[2].

Kind regards

  Andreas.

[1] 
https://salsa.debian.org/med-team/freemedforms-project/blob/master/COPYING.txt
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874880#104
 
> On Fri, Jan 10, 2020, 07:18 Eric Maeker  wrote:
> 
> > Hi,
> >
> > For now, our NPO is too poor to engage in consulting or to pay external
> > developments and we awfully miss time to manage all aspects of a widely
> > collaborative project.
> > Sounds like we are travelling to "contrib" or "non-free" package ? Or may
> > be "non-debian" ?
> >
> > Belle journée
> > Cordialement
> >
> >
> >  *Dr Maeker Éric*
> >
> > *Gériatre, psychogériatre*
> > eric.mae...@gmail.com
> > Twitter  @DrMaeker 
> > RPPS 10002307964
> >
> > maeker.fr  Site personnel
> > empathies.fr  Association Emp@thies
> > freemedforms.com  Logiciel médical
> >
> > La gériatrie, c'est la médecine pour les pères et les mères Noël
> >
> >
> > Le ven. 10 janv. 2020 à 03:03, Paul Wise  a écrit :
> >
> >> On Thu, Jan 9, 2020 at 8:00 PM Eric Maeker wrote:
> >>
> >> > Free Source code is provided to any demander approved by the NPO, code
> >> licence is still the same.
> >>
> >> I don't like this, people seeking source code should not have to get
> >> approval first. That said, I note that the source code is available
> >> directly from the site without approval.
> >>
> >> > But, the code documentation is only reserved to approved developers by
> >> this NPO.
> >>
> >> I definitely don't like this, it would be much better to publish the
> >> code documentation to everyone under a free license.
> >>
> >> > We do encourage new dev to apply to our NPO and to sign a CLA (which is
> >> still a draft piece of text actually).
> >>
> >> I don't like this either, it would be much better for devs to release
> >> their contributions under the same license that you do, then you can
> >> incorporate their changes, preserving their copyright over their
> >> changes and passing on their license to you to downstream users. So
> >> the whole of the software is then owned by a variety of copyright
> >> holders, each of whom also have to abide by the license given to them
> >> by the other contributors. The license on the software then cannot be
> >> changed without contributor consensus, so it becomes a much more solid
> >> project from a user perspective. Single-owner projects are much more
> >> easy to turn proprietary.
> >>
> >> http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html
> >>
> >> > The problem is that FreeMedForms EHR needs access to private data
> >>
> >> Could you explain why this data needs to be private? It would be much
> >> better to release it publicly under a free license.
> >>
> >> > The private data are only available to paying partners to the NPO.
> >>
> >> Is this the only form of income that the NPO has available to it? It
> >> sounds like the NPO is seeking what is called an "Open Core" business
> >> model, where the core part of the project is public and freely
> >> licensed but addons are proprietary. The incentives here can be quite
> >> perverse, often companies seek to prevent outside contributions to the
> >> core or even remove features from the core so that more people start
> >> paying them for the proprietary addons. So I encourage you to consider
> >> alternative income streams.
> >>
> >> I think the best option for the would be to consult with as many of
> >> the practices, clinics, hospitals and emergency departments that you
> >> know about that use the software and find out the best way for the NPO
> >> to have enough resources to continue development consistent with the
> >> interests of the community of folks who use the software. Examples of
> >> potential income models could include: large grants/sponsorships that
> >> cover development and other costs, a membership subscriber base that
> >> pays for all maintenance and development costs, or more of a
> >> crowd-funding model where folks interested in specific features pay
> >> for their development, or a community of consultants that do all work
> >> on the project as requested by their customers or possibly a
> >> combination of these and other options.
> >>
> >> > Forks trie to access our private data using the open sourced server
> >> protocol (query to a php script).
> >>
> >> I would suggest to just make the data public and under a free license,
> >> but if you don't 

Re: jmapviewer: bing logo

[Andreas Tille]

Hi Felix,

On Thu, Oct 16, 2014 at 07:39:08PM +0200, Felix Natter wrote:
 
 Short term sponsoring will be much appreciated :-)

In case I'm not AFK (on 20.+21.10. I will be offline) usually sponsoring
in a less than 24h time frame is the usual response time.

Please keep on your good work

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016201625.ga30...@an3as.eu

Re: Status of uw-prism packaging for Debian

[Andreas Tille]

Hi Ira,

On Mon, Aug 18, 2014 at 01:42:51PM -0700, Ira Kalet wrote:
 
 I had the good fortune at a recent social event to meet an attorney
 for one of the big multinational corporations in the medical device
 business, whose job is to look after FDA regulatory issues.  He even
 was familiar with RTP systems.  He agrees with the view that if the
 Prism software is not represented as a ready-to-use device or
 system, and is only distributed as a source code library, then no
 FDA involvement should be necessary.

Thanks for your continuous effort into this.
 
 The way Common Lisp code is packaged in Debian appears to be most
 suitable to this anyway.

I have to admit that I do not have the slightest idea how Common Lisp is
handled in Debian and that I feel incompetent to give a sensible answer
to your question.  So please take my answer with a grain of salt.  It
might be best to contact the Lisp developers list[1] about Lisp details.

 Building a runnable binary is highly Lisp
 vendor specific and would be difficult to automate.  But treating it
 as a library from which someone really knowledgeable could build a
 binary on their own would be relatively easy.  I would support this.

In general a Debian package tries to deliver a ready to run program (if
this is the nature of the software and if it is not just a library).
However, I'm not only Lisp-illiterate I have only a very vague
imagination what Prism finally is and how use cases of this software
really look like.  So it might perfectly be that the term library fits
better than a ready to run program.

BTW, in the consequence of our discussion another idea popped up in my
mind.  I have no idea whether this is possible but are there chances
that a patient suspects some mistake in calculating radiations and might
go to court and sue the person / hospital claiming they might have
caused some harm to him.  Is there any chance that this will fire back
to Debian / the Debian maintainer in some way?  If there would be a
chance for this we should be quite carefully in wording the description
for a potential prism package.

For instance to declare the program (library?) only fit for educational
use or something like this.  In case we should decide for such a means
I guess we would be done also with FDA issues since we are not shipping
a device but rather a program to demonstrate something for educational
purposes.  (If people might use it for real calculations anyway - that's
their problem.)

What do you think about this?
 
 Sorry to have taken the time of so many people to sort this out.

Well, sometimes it needs careful discussion to create a system which can
be used in health care.  I do not think that this was extraordinary long
discussion compared to the complexity of the problem.

 If this source only strategy is OK with you all, what are the next steps?

As far as I understood previous mails of yours we need some
preconditions for prism in Debian anyway.  What about simply starting
with packaging these preconditions.  Even if we might finally decide
that we do not deliver a prism binary package (but just provide
packaging stuff to make it simple creating a Debian package with very
less effort) we can turn Debian into a system where it is brain dead
easy to install Prism onto.  Perhaps it is a good idea to contact the
Lisp developers via their mailing list[1] how to start with these Lisp
preconditions.

Hope this helps and thanks for your effort

 Andreas.

[1] http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/ 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140819063801.gc12...@an3as.eu

Re: Status of uw-prism packaging for Debian

[Andreas Tille]

[Please keep Ira Kalet and the Debian Med mailing list in CC]

Hello,

I'm forwarding a part of a discussion to you legal experts for
clarification:

On Thu, Jul 31, 2014 at 11:15:49AM -0700, Ira Kalet wrote:
 
 3. Finally, there is still the issue of what the US FDA might say
 about distribution within the US, as software products that do what
 Prism does are considered medical devices and cannot be distributed
 without FDA 510K premarket approval, an onerous process to be sure.
 It does not matter that no money is involved.  What do you do about
 other debian-med packages?  Might any of them be considered a
 medical device?
 
 I'm not aware that we have a comparable case.  From my admittedly naive
 point of view distribution wise it does not matter whether the program
 is distributed from your web site or in addition from the Debian
 mirrors.  There was a time when Debian was maintaining a specific non-US
 archive containing crypto stuff that was covered by some US export law
 but this was a long time ago and all crypto software is included in
 Debian.  However, if you want to know for sure I might forward this
 question to the debian-legal list.
 
 
 By all means, please check with any legal resources you might have.
 My UW web site is source only, and in order for anyone to use the
 code, they have to learn Lisp, and understand Prism well enough to
 build a running system.  I believe this takes it out of the realm of
 product.  A package that can be installed by just clicking, that
 results in a complete runnable radiation therapy planning system
 might be considered by the FDA a real product.  I don't really
 know for sure.
 
 Also there is a disclaimer on my web site that might not satisfy the
 Debian policy requirements that I read.  It says that the software
 is provided for research and study.  The license does not legally
 restrict its use in a clinical application, though other such
 systems, such as PLUNC from Univ. of North Carolina do include such
 restrictions in their license agreement.  Maybe it could just go
 into the non-free area.

What do you think?

Kind regards and thanks for any advise

  Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140801085611.ge6...@an3as.eu

Re: sift and blimps license interpretation - can Debian redistribute these?

[Andreas Tille]

Hi Laszlo,

I'm forewarding this to debian-legal list [keeping
debian-med-packag...@lists.alioth.debian.org in CC would be great]
because I do not feel fully competent for this question.

However, I think in any case it is worth trying to educate authors about
the advantages of a free license.  We had some successful and also some
unsuccessful trials here on this list.  If you are writing like I'm
writing you on behalf of the Debian Med team ... (you will find this
string in the list archive when seeking for it) this could have at least
one positive effect that upstream is learning about our project and
might change their mind over time.

Kind regards

  Andreas.

- Forwarded message from Laszlo Kajan lka...@rostlab.org -

Date: Sun, 19 Feb 2012 12:23:07 +0100
From: Laszlo Kajan lka...@rostlab.org
To: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org,
Tim Booth tbo...@ceh.ac.uk, H. Soon Gweon soo...@gmail.com
Subject: sift and blimps license interpretation - can Debian redistribute these?

Dear fellow packagers!

I am not certain about the interpretation of the attached sift/blimps license 
(ftp://ftp.ncbi.nih.gov/repository/blocks/unix/blimps/LICENSE - I
am packaging these right now). The license is not free that's for sure, but:

* Can Debian redistribute it at all? - in other words: can we have sift and 
blimps in non-free?

This seems to be the relevant bit:

 2. [...] b.  Licensee may not charge any fee or royalty for copies
 of the Program or Derivative Work.  Licensee is authorized to
 sublicense the Program and any Derivative Work to third parties on a
 royalty-free basis subject to the terms of this license but may not
 otherwise distribute the Program or any Derivative Work.
 Notwithstanding the foregoing, Licensee may be reimbursed for any
 actual expenses it incurs in reproducing or delivering a copy of the
 Program or any Derivative Work.

Is redistribution 'sublicensing'? Debian does redistribution on a 'royalty-free 
basis', so my judgement is that Debian is allowed to
redistribute sift/blimps.

If Debian is not allowed to redistribute it, probably neither is Ubuntu or 
Biolinux.

Thank you for your help in advance!

Best,

Laszlo



   Thank you for your interest in licensing SIFT and the
Blimps searching programs. These files and programs are copyrighted by
the Fred Hutchinson Cancer Research Center and are made freely available
for noncommercial use. We cannot provide any support for them beyond what
we do to maintain them for our research. However, we would appreciate
being informed of how they are being used.


FHCRC currently has no policy regarding commercial use of SIFT
and Blimps, although they may have in the future. So commercial users
may use them now under the noncommercial license.

-
Pauline Ng
Fred Hutchinson Cancer Research Center FAX: 206-667-5889
1100 Fairview AV N, A1-162, PO Box 19024   Seattle, WA 98109-1024


(C) Copyright 1993-2001, Fred Hutchinson Cancer Research Center

LICENSE -- License and copyright information for SIFT and BLIMPS

---
  FHCRC NONCOMMERCIAL LICENSE
 Fred Hutchinson Cancer Research Center
 1100 Fairview AV N
   Seattle, WA  98109-1024


This license may be copied and distributed but may not be modified in
any way.

   RECITALS:

  A.  Fred Hutchinson Cancer Research Center is a nonprofit
corporation dedicated to investigating the nature and causes of cancer
and methods of cancer prevention and treatment and for conducting
education in all phases of cancer research.

  B.  This license is designed to permit certain activities with
respect to any computer programs to which it applies on the terms
stated in this license.

 TERMS AND CONDITIONS:

  1.   Definitions.

  Program means the computer software and associated
documentation in whatever form or format including source and object
code.

  Derivative Work means any modification, addition, upgrade,
update or improvement of the Program and any other work constituting a
derivative work under the copyright laws.

  Licensee means licensee of the Program under this license.

  FHCRC means Fred Hutchinson Cancer Research Center.

  2.  License, Copy, Distribute and Create Derivative Work.  FHCRC
hereby grants Licensee and Licensee accepts, subject to the terms and
conditions of this Agreement, a nonexclusive, royalty-free license to
use, copy and sublicense the Program and prepare and sublicense
Derivative Works.  This license is expressly limited as follows:

   a.  All copies of the Program must conspicuously show an
appropriate copyright 

Re: r-cran-maptools_0.7.16-1_i386.changes REJECTED (fwd)

[Andreas Tille]

On Mon, 16 Mar 2009, Leandro Doctors wrote:


2009/3/16 Julia Koschinsky jkosc...@asu.edu:

as far as the GeoDa Center is concerned, anyone who wants to use,
add value, make available or any other use they see for our sample
data for non-commercial purposes is welcome to it.

  -

Isn't it this non-commercial-only restriction against DFSG?


Yes, IMHO it is.  So the package was reuploaded to non-free.


(Please, -legal people, CC to me, as I am not subscribed to that list)


... which is a good idea anyway

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Yet another list statistics for debian-project

[Andreas Tille]

On Sun, 18 Jan 2009, MJ Ray wrote:


I suspect analysis by month and by volume would be more illuminating. I
took a look at the code, but there's not much explanation.  Is it
possible to add volumes in an easy way?


Sorry the code is crude at best - I will rewrite it from scratch
if this analysis will be accepted.  It should just use as a quick
and dirty helper for a talks of mine at DebConf and I never
thought that it became that popular.  SO if you need explanations
you will probably have to wait until this is done.

You might get rough information about the volume if you analyse
not only the index page in the archive but also the real mail
content (and strip off quotings).  But I personally do not intend
to do this work.

Kind regards

   Andreas.


PS: I do not read this list.  Please CC me.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Yet another list statistics for debian-legal

[Andreas Tille]

Hi,

as you can read in my lightning talk at DebConf

   http://people.debian.org/~tille/talks/200808_lightning/

I did some investigation on who is frequently posting
on our mailing lists.  I now created graphs until
end of last year and write a short summary for
those lists I regard worth a comment.  I'm not
CCed to all of this list so if you want to discuss
something please keep me in CC.  If you want to
discuss the results in general just write to debian-project.

All graphs and the code that was used to create the
graphs are available at

   http://people.debian.org/~tille/liststats/

If you are interested in a mailing list which was not
analysed, just tell me.  I was running the scripts on
those lists I personally had some interest and those
with more than 1000 subscribers.

I plan to clean up code and write some doc about it
but this will not happen in the next couple of weeks.

The graph for this specific list is

--- start of mailing list specific part --
   http://people.debian.org/~tille/liststats/authorstat_legal.pdf

The quite often observed wave-shaped pattern and only a view
activists left to discuss legal problems.

Kind regards

Andreas

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Non-free package licenses and replacements

[Andreas Tille]

On Sat, 24 Jan 2004, Niklas Vainio wrote:

 The page is at http://www.iki.fi/nvainio/debian/non-free.html
This is a good effort.  As a maintainer of three non-free packages
(molphy, treetool, phylip) I can assure you that I regularly try
to contact the authors of these programms.  For the first two
(molphy and treetool) it is just the problem that the authors are
not available any more.  I'm very positive that they would clarify
the license to be free once the DFSG criteria would be explained to
them.  Perhaps we might need some kind of echelon system to find
out the current address of the authors to be able to ask them.

The third one phylip has kind of a stuborn author - I failed to
explain the advantage and the sense of a free license ...

Kind regards

   Andreas.

Re: question about leaving lzw and unknown-license code in source

[Andreas Tille]

On Mon, 11 Nov 2002, Bas Zoetekouw wrote:

  Is there any way for xmedcon to become official without taking those parts
  mentioned above out of the source code (which neither the upstream author 
  nor
  me would find very attractive).

 Nope.  We cannot distribute software that doesn't have a proper license (the
 Siemens stuff) or is affected by patents (the lzw stuff).
 Note that the source is distributed along with the binaries (as required
 by GPL et al), so disabling the patented/non-free stuff without removing
 it altogether, won't help you at all.
Could you please enlighten us how it is handled in packages like

   gimp1.2-nonfree - GIF support for the GNU Image Manipulation Program

or similiar?  Any references to apply this principle?

Kind regards

 Andreas.

wxWindows and OpenSSL (fwd)

[Andreas Tille]

Hello,

I'd like to foreward this problem because I'm no expert in law.  I would
really appreciate, if you would foreward your answers to 
 [EMAIL PROTECTED], because I'm not subscribed to
debian-legal.  (The relation to Debian is, that
I plan to package GnuMed once it is in a releasable state.)

-- Forwarded message --
Date: Fri, 24 Nov 2000 23:26:54 +1100
From: Horst Herb [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: gnumed-devel [EMAIL PROTECTED]
Cc: oss [EMAIL PROTECTED]
Subject: wxWindows and OpenSSL

I stil have a problem substituting openssl (http://www.openssl.org):
according to the GNU priests, its license is incompatible with the GPL.
What shall we do? The only GPL'd substitute is early alpha and probably not
ready when GNUMed will be. Most of the cryptographic functions would be
available as GPL code though, and we could write our own ssl library.
Opinions? The options are either to ignore the licensing incompatibility or
follow the right path.

In my opinion, the GPL is the only way to enforce open sourcing and free
software, and therefore we should stick to it.

I would appreciate comments, suggestions - especially critics / negative
comments are highly welcome.

Regards,
Horst