[Ctk-developers] COPYRIGHT & LICENSING

Luis Ibanez luis.ibanez at kitware.com
Wed Apr 14 09:51:52 EDT 2010 

Just a word of warning:

Should CTK include any code that is distributed under the LGPL license,
it will be very important for such code to be clearly labeled and to be
build
only as an option.  Ideally it should be put in a separate directory, or
even
better, in a separate source tree.

That is,
none of the essential classes should be covered by a LGPL license.


The eventual LGPL code should then be compiled and archived into a
*shared* library, in order to avoid propagation of the license to the rest
of the system.


The option of using LGPL code should probably be turned one from the
CMake configuration at build time, and should be accompanied by the
proper warnings, to make developers aware of the consequences that
activating this code will have for the Licensing of the application that
they are building at that point.


       Luis


-------------------------------------------------------------------------------------------------------------
On Wed, Apr 14, 2010 at 8:52 AM, Steve Pieper <pieper at bwh.harvard.edu>wrote:

> Additional considerations regarding Qt:
>
> Qt samples and user-contributed widgets are typically licensed under the
> LGPL or the GPL (depending on history and developer preference - see
> http://qt-apps.org for examples).
>
> My understanding of the Nokia policy is that if we start with /just/ the
> LGPL'd Qt distribution and write a widget, we can distribute our widgets
> under any license.
>
> However if we *incorporate and modify* existing GPL or LGPL code we need to
> use the same license for our resulting code (the 'copyleft' requirement).
>
> Note that it is probably okay to /use/ an LGPL'd widget set via superbuild
> without impacting the licensing of CTK widgets themselves (for example, if
> we wanted to subclass existing widgets from something like Qxt
> http://www.libqxt.org/).
>
>
> As a practical matter, at the intersection of development and governance,
> we need to develop a policy about what external code we can incorporate in
> CTK and we need to be careful to follow that policy.
>
> My recommendations based on the current environment are:
>
> 1) Qt-based CTK Widgets will need to incorporate LGPL'd example code from
> the wider developer community and will therefor need to be under the LGPL
> license (different from the rest of CTK).
>
> 2) CTK developers will carefully review any projects from which they wish
> to draw code and strictly avoid using any GPL'd code.  (If the code is
> particularly unique and valuable, contact the authors and ask if they will
> consider releasing an LGPL or BSD-style version).
>
>
> I would be very interested in comments from experienced Qt developers on
> these topics:
>
> - does the analysis above match your understanding?
>
> - do we need to base our CTK widgets on LGPL'd examples?  Or could we
> accomplish our goals while adhering to a strict Apache/BSD-style licensing
> approach only?
>
>
> Regards,
> Steve
>
>
>
>
>
>
>
> On Apr/14/10 7:53 AM, Marco Viceconti wrote:
>
>> Lawrence is right to say that no one had strong opinions in favour of
>> BSD as such, and in the end the decision was taken only because most
>> existing codes represented around the table were already BSD. On the
>> contrary there was strong consensus on staying away from copyleft
>> licenses.
>>
>> Stephen point on patents is very relevant, so I recognise that it is
>> probably a good idea to go for Apache 2.0 for CTK. As a side effect, we
>> shall now revise this matter internally to B3C, and we might indeed
>> decide to adopt Apache 2.0 also for MAF3.
>>
>> Cheers
>>
>> Marco
>>
>>
>>
>>
>> Il giorno 13 Apr 2010, alle ore 17:16, Tarbox, Lawrence ha scritto:
>>
>>  I concur with Stephen.
>>>
>>> The pure BSD license does not address certain key issues, such as
>>> patents, trademarks, and contributions, that potentially could be very
>>> problematic in an open source project with multiple contributors from
>>> multiple organizations. The Apache license closes those holes, while
>>> still being essentially a BSD license at its core. (Compare the text
>>> of clauses 3, 8, and 9 with the BSD license - they are nearly
>>> identical to the BSD license.)
>>>
>>> As far as I know, there is little problem including BSD code in a
>>> project licensed under Apache, as long as there are no problems with
>>> patent or trademark infringements in the BSD code.
>>>
>>> My recollection of the previous discussions was more that we did not
>>> want CTK to use a 'copyleft' license, such as GPL, and that we
>>> preferred a more commercial friendly license with terms similar to
>>> BSD. The discussion brought out that most of the code that we already
>>> use has been released under licenses with terms similar to BSD, though
>>> not everyone was using a pure BSD license. I believe Apache has terms
>>> similar to and compatible with BSD, and would be a better match to our
>>> needs than simple BSD.
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ctk-developers-bounces at commontk.org
>>> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen
>>> Aylward
>>> Sent: Tuesday, April 13, 2010 8:45 AM
>>> To: Marco Viceconti
>>> Cc: ctk-developers at commontk.org
>>> Subject: Re: [Ctk-developers] COPYRIGHT & LICENSING
>>>
>>> Hi,
>>>
>>> The Apache 2.0 license is actually a BSD-style license. It is the
>>> new-BSD license with two additional paragraphs that are important
>>> based on our experiences with ITK. Note that ITK is now released
>>> under the Apache 2.0 license.
>>>
>>> There are some great articles on the benefits of Apache 2.0, such as
>>> "Apache better than GPL for open-source business?"
>>> http://news.cnet.com/8301-13505_3-10229817-16.html
>>>
>>> The full text of the license is available at:
>>> http://www.apache.org/licenses/LICENSE-2.0.html
>>>
>>> A FAQ on the Apache 2.0 license is at:
>>> http://www.apache.org/foundation/licence-FAQ.html
>>>
>>> Below is my interpretation of those two additional paragraphs:
>>>
>>> First paragraph
>>> =============
>>> "Submission of Contributions. Unless You explicitly state otherwise,
>>> any Contribution intentionally submitted for inclusion in the Work by
>>> You to the Licensor shall be under the terms and conditions of this
>>> License, without any additional terms or conditions. Notwithstanding
>>> the above, nothing herein shall supersede or modify the terms of any
>>> separate license agreement you may have executed with Licensor
>>> regarding such Contributions."
>>>
>>> The above says that by contributing changes back to the main
>>> repository, you're agreeing to release your changes also under the
>>> Apache 2.0 license. Without this additional paragraph we'll need to
>>> specify licensing terms for every change to the code made by any
>>> contributor - that isn't feasible. Again, this paragraph does not
>>> request copyright transfer, just a license to redistribute, use etc.
>>>
>>> Second paragraph
>>> ===============
>>> "Grant of Patent License. Subject to the terms and conditions of this
>>> License, each Contributor hereby grants to You a perpetual, worldwide,
>>> non-exclusive, no-charge, royalty-free, irrevocable (except as stated
>>> in this section) patent license to make, have made, use, offer to
>>> sell, sell, import, and otherwise transfer the Work, where such
>>> license applies only to those patent claims licensable by such
>>> Contributor that are necessarily infringed by their Contribution(s)
>>> alone or by combination of their Contribution(s) with the Work to
>>> which such Contribution(s) was submitted. If You institute patent
>>> litigation against any entity (including a cross-claim or counterclaim
>>> in a lawsuit) alleging that the Work or a Contribution incorporated
>>> within the Work constitutes direct or contributory patent
>>> infringement, then any patent licenses granted to You under this
>>> License for that Work shall terminate as of the date such litigation
>>> is filed."
>>>
>>> This paragraph says that if you submit code to the repository you're
>>> also granting everyone a license to use that code even if you've filed
>>> for a patent that the code implements. Consider that if someone adds
>>> something to the CTK core that is covered by one of their own patents,
>>> then we may end up being sued (it really does happen way too often in
>>> America), having to pay them money to use CTK, or having to re-write
>>> that code.
>>>
>>> Hope this helps,
>>> Stephen
>>>
>>> On Tue, Apr 13, 2010 at 9:04 AM, Marco Viceconti
>>> <viceconti at tecno.ior.it> wrote:
>>>
>>>> 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<http://www.spl.harvard.edu/%7Ekikinis>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ctk-developers mailing list
>>>> Ctk-developers at commontk.org
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>>
>>>>
>>>
>>>
>>> --
>>> Stephen R. Aylward, Ph.D.
>>> Director of Medical Imaging Research
>>> Kitware, Inc. - North Carolina Office
>>> http://www.kitware.com
>>> stephen.aylward (Skype)
>>> (919) 969-6990 x300
>>> _______________________________________________
>>> Ctk-developers mailing list
>>> Ctk-developers at commontk.org
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>
>>> The material in this message is private and may contain Protected
>>> Healthcare Information (PHI). If you are not the intended recipient,
>>> be advised that any unauthorized use, disclosure, copying or the
>>> taking of any action in reliance on the contents of this information
>>> is strictly prohibited. If you have received this email in error,
>>> please immediately notify the sender via telephone or return mail.
>>>
>>>
>> --------------------------------------------------
>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20100414/cb54569f/attachment.html>

More information about the Ctk-developers mailing list