[Ctk-developers] COPYRIGHT & LICENSING
Marco Viceconti
viceconti at tecno.ior.it
Tue Apr 13 13:04:26 UTC 2010
If I understand correctly the discussion so far, it seems that under
an appropriate FOSS license the tracking of copyright is unnecessary.
Still, I disagree that it is irrelevant, as in addition to the
personal proudness there is also an institutional proudness, that
tracking copyright to the institution that contributed with a portion
of code, somehow sustains. Because of this I would suggest that each
contributor should have the right to keep the copyright to his-her own
institution.
For the license, I agree with Luis that the choice is between an
handful of options, such as MIT, BSD and Apache 2.0 licenses. Indeed,
this point was extensively discussed in one of the first meetings of
the CTK Group, as correctly pointed out by Jörg Riesmeier. In that
meeting we noticed that a) many of our frameworks and libraries are
distributed under BSD, and b) that BSD has all the features we thought
the CTK should had.
http://www.commontk.org/cgi-bin/trac.cgi/wiki/Whitepaper#BSDstylelicense
Of course nothing is carved in stone, but I do not thing we should
simply ignore what has been already extensively discussed. Thus, I
would suggest to consider the topic in this light: there is decision
in favour of BSD. Is there any argument that makes Apache 2.0
preferable over BSD? If we opt for Apache 2.0, is there any problem in
re-using inside CTK code licensed under BSD, such as DCMTK?
A last comment: while Apache 2.0 is clearly a more modern option, BSD
has beauty of being the clearest license you can read. Now if it is
true, like many says that in the end you get the same protection with
both, I would opt for BSD if nothing else only for this.
Cheers
Marco
Il giorno 12 Apr 2010, alle ore 16:23, Luis Ibanez ha scritto:
>
> I agree with Bill,
>
> The choice of a good License is more important that who holds the
> Copyright (and patents, and trademarks) associated with the code.
>
>
> In practice, tracing the Copyright holders of code in an Open Source
> project is an impossible task.
>
>
> Whoever is contributing code to an Open Source project with the
> intention of conserving ownership or control over such code has
> flawed understanding of how software development works in a
> peer-production environment.
>
>
> Files tend to (and *should*) be modified by many different developers,
> who are affiliated to different institutions. Every institution will
> hold the
> copyright of every modification.
>
>
> You may know "who" is the copyright holder of a file, the first day
> that file
> is committed. But after ten years of this file being modified and
> retouched
> by twenty other developers from ten other institutions, you have a
> file
> where
>
>
> 55% of the lines are copyrighted by institution A
> 27% by institution B
> 13% by institution C..
> ... and so on.
>
>
> In a well-managed open source project, such modifications of any given
> file by many different developers *is expected* to happen.
>
> When a file has only been touched by a single developer, that's an
> indication
> that nobody else in the project cares about such file, and that the
> project has
> poor practices of code review and suffers from lack of participation.
>
> So, even if any given organization want to conserve "ownership" of the
> code, that is simply unrealistic in practice.
>
> Assigning copyright of the code to a non-for-profit organization is
> actually
> a way of protecting the developers (and their institutions).
>
> This is discussed in great detail in:
>
> "Intellectual Property and Open Source
> A Practical Guide to Protecting Code"
> by Van Lindberg
> http://oreilly.com/catalog/9780596517960
>
>
>
>
> In any case, what is more important is to chose a License, that make
> irrelevant
> (and unnecessary) to track ownership of the source code. The MIT,
> BSD and
> Apache 2.0 licenses are typical good choices that satisfy such
> condition.
>
>
> The Apache 2.0 license is particularly attractive in this case
> because it is
> the only one from this group, that includes specific clauses about
> code
> contributions.
>
>
>
> Luis
>
>
>
> -------------------------------------------------------------------------------------------
> On Mon, Apr 12, 2010 at 8:39 AM, Bill Lorensen <bill.lorensen at gmail.com
> > wrote:
> I agree with that license is more important that the copyright
> holders.
>
> In VTK, many files have multiple copyrights, but all share the same
> license.
>
> Bill
>
> On Mon, Apr 12, 2010 at 8:35 AM, Ron Kikinis
> <kikinis at bwh.harvard.edu> wrote:
> > Luis,
> >
> > The apache license sounds reasonable to me. In terms of making ISC
> the owner
> > of the copyright:
> > As you know, we have taken a different approach with Slicer in
> that the
> > contributors keep the copyright and only grant an irrevocable and
> unlimited
> > license for use in Slicer (I am not a lawyer so this is not legal
> language).
> >
> > On an other point: ISC was created to hold the copyright for ITK.
> The
> > website does not really reflect the more recent additions of cmake
> and
> > IGSTK. The board of directors primarily reflects ITK and would
> probably
> > require some updates.
> >
> > One question: how "dictator proof" is ISC?
> >
> > Ron
> >
> >
> >
> > On 4/9/10 10:36 AM, Luis Ibanez wrote:
> >>
> >> Yes,
> >> it is not the most amusing conversation to have,
> >> but it is better to do this early...
> >>
> >>
> >> 1) Most files in CTK are lacking Copyright
> >> notices and an explicit License.
> >>
> >> 2) There is not LICENCE file at the top of
> >> the source tree.
> >>
> >>
> >>
> >> I propose that we assign the copyright of the source code
> >> to the Insight Software Consortium (ISC), and that we
> >> distribute the code under an Apache 2.0 License.
> >>
> >> http://www.opensource.org/licenses/apache2.0.php
> >>
> >>
> >>
> >> The ISC is the organization that holds the copyright of
> >>
> >> * ITK
> >> * CMake (along with Kitware)
> >> * IGSTK
> >>
> >>
> >> More information about the ISC at:
> >>
> >> http://www.insightsoftwareconsortium.org/
> >>
> >>
> >> It will also be important for your respective organizations
> >> to join the ISC, or for you to join as individuals, so you
> >> help ensure that the CTK project is managed as you
> >> intended.
> >>
> >>
> >> Every day that passes without having a clear License
> >> and Copyright statement is a day were we are brewing
> >> a recipe for disaster.
> >>
> >>
> >>
> >> If someone needs to be persuaded, we can provide details
> >> on the horror story of how much trouble we are having in ITK
> >> with source code of dubious origin (no copyright notice nor
> >> license) that we adopted from www.netlib.org....
> >>
> >>
> >>
> >> Luis
> >> _______________________________________________
> >> Ctk-developers mailing list
> >> Ctk-developers at commontk.org
> >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >
> > --
> > Ron Kikinis, M.D.,
> > Robert Greenes Distinguished Director of Biomedical Informatics
> > Professor of Radiology, Harvard Medical School
> > Director, Surgical Planning Laboratory
> > http://www.spl.harvard.edu/~kikinis
> > _______________________________________________
> > Ctk-developers mailing list
> > Ctk-developers at commontk.org
> > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
> >
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
--------------------------------------------------
MARCO VICECONTI, PhD
(viceconti at tecno.ior.it)
Laboratorio di Tecnologia Medica tel. 39-051-6366865
Istituto Ortopedico Rizzoli fax.
39-051-6366863
via di Barbiano 1/10, 40136 - Bologna, Italy
Tiger! Tiger! Burning bright in the forest of the night,
what immortal hand or eye could frame thy fearful symmetry?
--------------------------------------------------
Opinions expressed here do not necessarily reflect those of my employer
More information about the Ctk-developers
mailing list