[Ctk-developers] COPYRIGHT & LICENSING

Steve Pieper pieper at bwh.harvard.edu
Wed Apr 14 12:52:29 UTC 2010


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
>>>>> _______________________________________________
>>>>> 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



More information about the Ctk-developers mailing list