From: Joseph M. <mu...@le...> - 2010-01-12 19:28:38
|
Peter, I noticed the following code in vgl, which appears to restrict vgl from commercial use. I believe it must be removed unless we receive unrestricted permission from the University of Manchester. Joe =========================================================================== Project: Generic Polygon Clipper A new algorithm for calculating the difference, intersection, exclusive-or or union of arbitrary polygon sets. File: gpc.h Author: Alan Murta (email: gp...@cs...) Version: 2.32 Date: 17th December 2004 Copyright: (C) 1997-2004, Advanced Interfaces Group, University of Manchester. This software is free for non-commercial use. It may be copied, modified, and redistributed provided that this copyright notice is preserved on all copies. The intellectual property rights of the algorithms used reside with the University of Manchester Advanced Interfaces Group. You may not use this software, in whole or in part, in support of any commercial product without the express consent of the author. There is no warranty or other guarantee of fitness of this software for any purpose. It is provided solely "as is". =========================================================================== |
From: Peter V. <pet...@ya...> - 2010-01-12 19:22:24
|
Joe, This does only restrict the function vgl_clip(vgl_polygon<T>,...) to non-commerical use, not the whole of vgl. E.g., all other functions in vgl_clip.h can be freely used. So we can either just leave everything as it is, and leave it to the user of that code to decide whether (s)he uses it, and in which context. Alternatively, and that's what I would propose, we could place the two vgl_clip() functions in vgl_clip.h inside an "#ifdef NONCOMMERCIAL". Then, to use it, active modification of the code (or a compiler switch) is needed to activate it. This safely protects people from inadvertently using it in a commercial application. Other opinions on this issue? -- Peter. --- Den tis 2010-01-12 skrev Joseph Mundy <mu...@le...>: > Från: Joseph Mundy <mu...@le...> > Ämne: Restricted polygon code > Till: Vxl...@li..., pet...@ya... > Datum: tisdag 12 januari 2010 19.31 > > Peter, > > I noticed the following code in vgl, which appears to restrict vgl > from commercial use. I believe it must be removed unless we receive > unrestricted permission from the University of Manchester. > > Joe > > =============================================================== > > Project: Generic Polygon Clipper > > A new algorithm for calculating the difference, intersection, > exclusive-or or union of arbitrary polygon sets. > > File: gpc.h > Author: Alan Murta (email: gp...@cs...) > Version: 2.32 > Date: 17th December 2004 > Copyright: (C) 1997-2004, Advanced Interfaces Group, > > University of Manchester. > > This software is free for non-commercial use. It may be > copied, modified, and redistributed provided that this > copyright notice is preserved on all copies. The intellectual > property rights of the algorithms used reside with the University > of Manchester Advanced Interfaces Group. > You may not use this software, in whole or in part, in support > of any commercial product without the express consent of > the author. > There is no warranty or other guarantee of fitness of > this software for any purpose. It is provided solely "as is". __________________________________________________________ Ta semester! - sök efter resor hos Kelkoo. Jämför pris på flygbiljetter och hotellrum här: http://www.kelkoo.se/c-169901-resor-biljetter.html?partnerId=96914052 |
From: Ian S. <ian...@st...> - 2010-01-12 22:33:06
|
Having looked at the AIG/Manchester website, they are still maintaining a deliberate commercial/non-commercial distinction. So I doubt a plea to relinquish the condition would help. I think Peter's suggestion is entirely within the spirit of this license condition. Since there is no complicated legalese regarding the condition, that should be enough. I'd suggest making NONCOMMERCIAL a CMake option, but I don't want to encourage any contributors of de novo VXL code to use the same restriction. Whilst it is a reasonable to use this option in the case of merging an existing state-of-the-art library, I'd object strongly to someone writing code specially for VXL, with a no-commercial-use condition. Ian. Peter Vanroose wrote: > Joe, > > This does only restrict the function vgl_clip(vgl_polygon<T>,...) > to non-commerical use, not the whole of vgl. > E.g., all other functions in vgl_clip.h can be freely used. > > So we can either just leave everything as it is, and leave it to the user of that code to decide whether (s)he uses it, and in which context. > Alternatively, and that's what I would propose, we could place the two vgl_clip() functions in vgl_clip.h inside an "#ifdef NONCOMMERCIAL". Then, to use it, active modification of the code (or a compiler switch) is needed to activate it. This safely protects people from inadvertently using it in a commercial application. > > Other opinions on this issue? > > -- Peter. > > > --- Den tis 2010-01-12 skrev Joseph Mundy <mu...@le...>: >> Från: Joseph Mundy <mu...@le...> >> Ämne: Restricted polygon code >> Till: Vxl...@li..., pet...@ya... >> Datum: tisdag 12 januari 2010 19.31 >> >> Peter, >> >> I noticed the following code in vgl, which appears to restrict vgl >> from commercial use. I believe it must be removed unless we receive >> unrestricted permission from the University of Manchester. >> >> Joe >> >> =============================================================== >> >> Project: Generic Polygon Clipper >> >> A new algorithm for calculating the difference, intersection, >> exclusive-or or union of arbitrary polygon sets. >> >> File: gpc.h >> Author: Alan Murta (email: gp...@cs...) >> Version: 2.32 >> Date: 17th December 2004 >> Copyright: (C) 1997-2004, Advanced Interfaces Group, >> >> University of Manchester. >> |
From: Joseph M. <mu...@le...> - 2010-01-12 22:44:43
|
Ian, I agree with your sentiment. Let's have a CMake option. I guess the only question whether the option should it be COMMERICAL or NONCOMMERCIAL. I think COMMERCIAL is a bit better since one would be paying attention to the flag to insure commercial use, whilst the default would be not commercial for most VXL users. Joe -----Original Message----- From: Ian Scott [mailto:ian...@st...] Sent: Tuesday, January 12, 2010 5:33 PM To: p.v...@ie... Cc: Joseph Mundy; Vxl-maintainers Subject: Re: [Vxl-maintainers] Restricted polygon code Having looked at the AIG/Manchester website, they are still maintaining a deliberate commercial/non-commercial distinction. So I doubt a plea to relinquish the condition would help. I think Peter's suggestion is entirely within the spirit of this license condition. Since there is no complicated legalese regarding the condition, that should be enough. I'd suggest making NONCOMMERCIAL a CMake option, but I don't want to encourage any contributors of de novo VXL code to use the same restriction. Whilst it is a reasonable to use this option in the case of merging an existing state-of-the-art library, I'd object strongly to someone writing code specially for VXL, with a no-commercial-use condition. Ian. Peter Vanroose wrote: > Joe, > > This does only restrict the function vgl_clip(vgl_polygon<T>,...) > to non-commerical use, not the whole of vgl. > E.g., all other functions in vgl_clip.h can be freely used. > > So we can either just leave everything as it is, and leave it to the user of that code to decide whether (s)he uses it, and in which context. > Alternatively, and that's what I would propose, we could place the two vgl_clip() functions in vgl_clip.h inside an "#ifdef NONCOMMERCIAL". Then, to use it, active modification of the code (or a compiler switch) is needed to activate it. This safely protects people from inadvertently using it in a commercial application. > > Other opinions on this issue? > > -- Peter. > > > --- Den tis 2010-01-12 skrev Joseph Mundy <mu...@le...>: >> Från: Joseph Mundy <mu...@le...> >> Ämne: Restricted polygon code >> Till: Vxl...@li..., pet...@ya... >> Datum: tisdag 12 januari 2010 19.31 >> >> Peter, >> >> I noticed the following code in vgl, which appears to restrict vgl >> from commercial use. I believe it must be removed unless we receive >> unrestricted permission from the University of Manchester. >> >> Joe >> >> =============================================================== >> >> Project: Generic Polygon Clipper >> >> A new algorithm for calculating the difference, intersection, >> exclusive-or or union of arbitrary polygon sets. >> >> File: gpc.h >> Author: Alan Murta (email: gp...@cs...) >> Version: 2.32 >> Date: 17th December 2004 >> Copyright: (C) 1997-2004, Advanced Interfaces Group, >> >> University of Manchester. >> |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2010-01-13 07:10:33
|
On Tue, Jan 12, 2010 at 6:43 PM, Joseph Mundy wrote: > Ian, > I agree with your sentiment. Let's have a CMake option. I guess the only > question whether the option should it be COMMERICAL or NONCOMMERCIAL. I > think COMMERCIAL is a bit better since one would be paying attention to the > flag to insure commercial use, whilst the default would be not commercial > for most VXL users. > Joe Just to make a note that the option should probably be named something starting with BUILD_... The BUILD_ options are the ones that I usually pay attention to most, when building a fresh download. Just my $0.02 --Miguel |
From: Joseph M. <mu...@le...> - 2010-01-13 14:50:54
|
Ok, so let's go with BUILD_COMMERCIAL Peter, will you add it? Thanks, Joe -----Original Message----- From: fig...@gm... [mailto:fig...@gm...] On Behalf Of Miguel A. Figueroa-Villanueva Sent: Wednesday, January 13, 2010 2:10 AM To: Joseph Mundy Cc: Ian Scott; p.v...@ie...; Vxl-maintainers Subject: Re: [Vxl-maintainers] Restricted polygon code On Tue, Jan 12, 2010 at 6:43 PM, Joseph Mundy wrote: > Ian, > I agree with your sentiment. Let's have a CMake option. I guess the only > question whether the option should it be COMMERICAL or NONCOMMERCIAL. I > think COMMERCIAL is a bit better since one would be paying attention to the > flag to insure commercial use, whilst the default would be not commercial > for most VXL users. > Joe Just to make a note that the option should probably be named something starting with BUILD_... The BUILD_ options are the ones that I usually pay attention to most, when building a fresh download. Just my $0.02 --Miguel |
From: <pe...@va...> - 2010-01-13 14:07:57
|
Joe Mundy wrote: > Ok, so let's go with > BUILD_COMMERCIAL The goal of this new setting is to avoid that people who want to build a commercial application using vxl, won't by accident use GPL (or similar) source code. So by default, this setting must be ON. The C++ source will thus need a #ifndef BUILD_COMMERCIAL ... #endif around GPL code. So I see a disadvantage with this solution: people who build the code *without* any setting (e.g. because they don't use CMake, or and old version of the generated makefiles, or whatever) will accidentally *include* the GPL code! Therefore, if indeed BUILD_COMMERCIAL should be the default --which is to be overridden only *on purpose*-- shouldn't we preferably use something like BUILD_NONCOMMERCIAL as a CMake setting, which is then of course *not* set by default? In that case, the conditioning around GPL code would instead become: #ifdef BUILD_NONCOMMERCIAL ... #endif -- Peter. |
From: Joseph M. <mu...@le...> - 2010-01-13 14:52:54
|
Peter, That is fine, go with BUILD_NONCOMMERCIAL I was just put off a bit by the double negative. Joe -----Original Message----- From: pe...@va... [mailto:pe...@va...] Sent: Wednesday, January 13, 2010 8:31 AM To: Joseph Mundy Cc: 'Vxl-maintainers' Subject: Re: Restricted polygon code Joe Mundy wrote: > Ok, so let's go with > BUILD_COMMERCIAL The goal of this new setting is to avoid that people who want to build a commercial application using vxl, won't by accident use GPL (or similar) source code. So by default, this setting must be ON. The C++ source will thus need a #ifndef BUILD_COMMERCIAL ... #endif around GPL code. So I see a disadvantage with this solution: people who build the code *without* any setting (e.g. because they don't use CMake, or and old version of the generated makefiles, or whatever) will accidentally *include* the GPL code! Therefore, if indeed BUILD_COMMERCIAL should be the default --which is to be overridden only *on purpose*-- shouldn't we preferably use something like BUILD_NONCOMMERCIAL as a CMake setting, which is then of course *not* set by default? In that case, the conditioning around GPL code would instead become: #ifdef BUILD_NONCOMMERCIAL ... #endif -- Peter. |
From: Ian S. <ian...@st...> - 2010-01-13 15:07:54
|
For the avoidance of doubt, I would like to confirm that the VXL community/consortium does not see this option as an invitation to add new VXL code with no-commercial-use restrictions. Its purpose is to allow us to integrate pre-existing, license encumbered, state-of-the-art code into VXL. We should normally reject offered code that was written specially for VXL if the contributor insisted on a no-commercial-use clause. Imorphics cooperates closely with non-commercial organisations, particularly ISBE at the University of Manchester. Managing conflicts over clauses like this would be very disruptive. I'd like to see a comment to that effect in the code, beside the declaration of the BUILD_NONCOMMERCIAL setting. If anyone objects, please let me know. Ian. Joseph Mundy wrote: > Peter, > That is fine, go with BUILD_NONCOMMERCIAL I was just put off a bit by the > double negative. > Joe > > -----Original Message----- > From: pe...@va... [mailto:pe...@va...] > Sent: Wednesday, January 13, 2010 8:31 AM > To: Joseph Mundy > Cc: 'Vxl-maintainers' > Subject: Re: Restricted polygon code > > Joe Mundy wrote: >> Ok, so let's go with >> BUILD_COMMERCIAL > > The goal of this new setting is to avoid that people who want to build a > commercial application using vxl, won't by accident use > GPL (or similar) source code. So by default, this setting must be ON. > The C++ source will thus need a > #ifndef BUILD_COMMERCIAL > ... > #endif > around GPL code. > > So I see a disadvantage with this solution: people who build the code > *without* any setting (e.g. because they don't use CMake, or > and old version of the generated makefiles, or whatever) will accidentally > *include* the GPL code! > > Therefore, if indeed BUILD_COMMERCIAL should be the default --which is to be > overridden only *on purpose*-- shouldn't we > preferably use something like > BUILD_NONCOMMERCIAL > as a CMake setting, which is then of course *not* set by default? In that > case, the conditioning around GPL code would instead > become: > #ifdef BUILD_NONCOMMERCIAL > ... > #endif > > -- Peter. > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2010-01-19 14:09:04
|
On Wed, Jan 13, 2010 at 11:07 AM, Ian Scott wrote: > For the avoidance of doubt, I would like to confirm that the VXL > community/consortium does not see this option as an invitation to add > new VXL code with no-commercial-use restrictions. Its purpose is to > allow us to integrate pre-existing, license encumbered, state-of-the-art > code into VXL. We should normally reject offered code that was written > specially for VXL if the contributor insisted on a no-commercial-use clause. > > Imorphics cooperates closely with non-commercial organisations, > particularly ISBE at the University of Manchester. Managing conflicts > over clauses like this would be very disruptive. > > I'd like to see a comment to that effect in the code, beside the > declaration of the BUILD_NONCOMMERCIAL setting. If anyone objects, > please let me know. > > Ian. I followed this thread and I agree with Ian that we should not reject or remove code because it is GPL (or similar), but (if VXL is BSD licensed) then we should limit it as much as possible. In thinking about this, I figure the following: - BUILD_RESTRICTED (as Amitha suggested in the last e-mail) or whatever is selected should require active manipulation of the user, so that commercial code doesn't inadvertently include it. - To avoid abuse of this we should have an automatic system (script maybe) that checks the inclusions of code of this type and generates an error if it is not one of the exceptions. Somehow, this needs to produce a visible error that people pay attention to (e.g., in the dashboard). The system that I have been using for checking the coding style in private code is KWStyle (http://public.kitware.com/KWStyle/ ; also from Kitware). Currently, I have cmake support that, if turned on, it runs KWStyle over the code and either generates the output and/or produces an entry in the dashboard. Note that this configuration would only be necessary by one client. That is, regular users would not need to install run KWStyle in their machines. I think we could use this to check for things like the BUILD_RESTRICTED and other coding guidelines and see a nicely generated output like in: http://66.194.253.24/KWStyleExamples/Insight/KWSMatrix.html Thoughts? --Miguel |
From: Ian S. <ian...@st...> - 2010-01-19 14:22:05
|
Miguel and Peter, I think there has been some confusion here, that others have tried to clear up before, apparently unsuccessfully. The BUILD_RESTRICTED or BUILD_NONCOMMERCIAL switch or whatever it is called is *entirely orthogonal* to the issue of GPL code. A: The switch is to allow us to include existing code that has some general no-commercial-use restriction (is perpendicular to) B: We cannot have GPL or LGPL source code in VXL at all. The two issues do not overlap. In particular this switch will not allow us to put GPL code into VXL. The GPL licence is very clear that we cannot include GPL source code in VXL without releasing VXL under a GPL compatible licence - which we do not want to do. Ian. Miguel A. Figueroa-Villanueva wrote: > On Wed, Jan 13, 2010 at 11:07 AM, Ian Scott wrote: >> For the avoidance of doubt, I would like to confirm that the VXL >> community/consortium does not see this option as an invitation to add >> new VXL code with no-commercial-use restrictions. Its purpose is to >> allow us to integrate pre-existing, license encumbered, state-of-the-art >> code into VXL. We should normally reject offered code that was written >> specially for VXL if the contributor insisted on a no-commercial-use clause. >> >> Imorphics cooperates closely with non-commercial organisations, >> particularly ISBE at the University of Manchester. Managing conflicts >> over clauses like this would be very disruptive. >> >> I'd like to see a comment to that effect in the code, beside the >> declaration of the BUILD_NONCOMMERCIAL setting. If anyone objects, >> please let me know. >> >> Ian. > > I followed this thread and I agree with Ian that we should not reject > or remove code because it is GPL (or similar), but (if VXL is BSD > licensed) then we should limit it as much as possible. > > In thinking about this, I figure the following: > > - BUILD_RESTRICTED (as Amitha suggested in the last e-mail) or > whatever is selected should require active manipulation of the user, > so that commercial code doesn't inadvertently include it. > > - To avoid abuse of this we should have an automatic system (script > maybe) that checks the inclusions of code of this type and generates > an error if it is not one of the exceptions. Somehow, this needs to > produce a visible error that people pay attention to (e.g., in the > dashboard). > > The system that I have been using for checking the coding style in > private code is KWStyle (http://public.kitware.com/KWStyle/ ; also > from Kitware). Currently, I have cmake support that, if turned on, it > runs KWStyle over the code and either generates the output and/or > produces an entry in the dashboard. Note that this configuration would > only be necessary by one client. That is, regular users would not need > to install run KWStyle in their machines. > > I think we could use this to check for things like the > BUILD_RESTRICTED and other coding guidelines and see a nicely > generated output like in: > > http://66.194.253.24/KWStyleExamples/Insight/KWSMatrix.html > > Thoughts? > > --Miguel |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2010-01-19 18:50:23
|
On Tue, Jan 19, 2010 at 8:47 AM, Ian Scott wrote: > Miguel and Peter, > I think there has been some confusion here, that others have tried to clear > up before, apparently unsuccessfully. > > The BUILD_RESTRICTED or BUILD_NONCOMMERCIAL switch or whatever it is called > is *entirely orthogonal* to the issue of GPL code. > > A: The switch is to allow us to include existing code that has some general > no-commercial-use restriction > (is perpendicular to) > B: We cannot have GPL or LGPL source code in VXL at all. > > The two issues do not overlap. In particular this switch will not allow us > to put GPL code into VXL. The GPL licence is very clear that we cannot > include GPL source code in VXL without releasing VXL under a GPL compatible > licence - which we do not want to do. Right, that is what I gather from the discussion. So, my e-mail is towards the how to control the abuse or misuse of this newly added BUILD_RESTRICTED? I mean, if someone new to VXL starts committing code and sees that there is code that is RESTRICTED to non-commercial applications, that person might get the urge to restrict his code... I think that a style checker, such as KWStyle, can help to automate the detection of these and other issues of coding guidelines making them more visible. --Miguel |
From: Brad K. <bra...@ki...> - 2010-01-20 14:48:01
|
Miguel A. Figueroa-Villanueva wrote: > Right, that is what I gather from the discussion. So, my e-mail is > towards the how to control the abuse or misuse of this newly added > BUILD_RESTRICTED? I mean, if someone new to VXL starts committing code > and sees that there is code that is RESTRICTED to non-commercial > applications, that person might get the urge to restrict his code... Perhaps we should have a separate switch for *each* piece of restricted code: BUILD_RESTRICTED_GPC BUILD_RESTRICTED_MYLIB ... This has the following advantages: 1.) Users must explicitly enable each piece of code, which will make them aware of the license issue 2.) Documentation of each switch can include a summary of its license 3.) The complication it adds will discourage code from being added this way We could also *not* configure the option into a header file, but instead make all users #define or -D the macro themselves to get the piece of the header with the restricted code. The more complicated, the better. -Brad |
From: Gehua Y. <yan...@gm...> - 2010-01-20 15:13:20
|
To put my two cents in, I like Brad's proposal of having separate switch for each piece of restricted code. Gehua. On Wed, Jan 20, 2010 at 9:31 AM, Brad King <bra...@ki...> wrote: > Miguel A. Figueroa-Villanueva wrote: >> Right, that is what I gather from the discussion. So, my e-mail is >> towards the how to control the abuse or misuse of this newly added >> BUILD_RESTRICTED? I mean, if someone new to VXL starts committing code >> and sees that there is code that is RESTRICTED to non-commercial >> applications, that person might get the urge to restrict his code... > > Perhaps we should have a separate switch for *each* piece of restricted > code: > > BUILD_RESTRICTED_GPC > BUILD_RESTRICTED_MYLIB > ... > > This has the following advantages: > > 1.) Users must explicitly enable each piece of code, which will make them > aware of the license issue > 2.) Documentation of each switch can include a summary of its license > 3.) The complication it adds will discourage code from being added this way > > We could also *not* configure the option into a header file, but instead > make all users #define or -D the macro themselves to get the piece of the > header with the restricted code. The more complicated, the better. > > -Brad > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2010-01-20 16:21:46
|
On Wed, Jan 20, 2010 at 10:31 AM, Brad King wrote: > Miguel A. Figueroa-Villanueva wrote: >> Right, that is what I gather from the discussion. So, my e-mail is >> towards the how to control the abuse or misuse of this newly added >> BUILD_RESTRICTED? I mean, if someone new to VXL starts committing code >> and sees that there is code that is RESTRICTED to non-commercial >> applications, that person might get the urge to restrict his code... > > Perhaps we should have a separate switch for *each* piece of restricted > code: > > BUILD_RESTRICTED_GPC > BUILD_RESTRICTED_MYLIB > ... > > This has the following advantages: > > 1.) Users must explicitly enable each piece of code, which will make them > aware of the license issue > 2.) Documentation of each switch can include a summary of its license > 3.) The complication it adds will discourage code from being added this way > > We could also *not* configure the option into a header file, but instead > make all users #define or -D the macro themselves to get the piece of the > header with the restricted code. The more complicated, the better. > > -Brad I think having separate switches is a good idea. I also thought about requiring a uniform header in every *.h file that included a license statement. Either the license (https://vxl.svn.sourceforge.net/svnroot/vxl/trunk/core/vxl_copyright.h) or a link to it. This way people contributing code, mainly new students/users making smaller contributions (since I am sure that others are well aware of the license terms), will understand that they are giving it away and most importantly that they can not include code with incompatible license agreements. --Miguel -- Miguel A. Figueroa Villanueva +1 787 832-4040 x.3205 Department of Electrical and Computer Engineering University of Puerto Rico - Mayagüez Campus |
From: Brad K. <bra...@ki...> - 2010-01-20 18:16:07
|
On 1/20/2010 11:21 AM, Miguel A. Figueroa-Villanueva wrote: > I also thought about requiring a uniform header in every *.h file > that included a license statement. I believe that, strictly speaking, every file needs its own copyright and license notice. We've largely ignored this in vxl previously. If you want to spearhead an effort to address this problem I'm happy to advise. I spent quite a while investigating this issue for CMake and other Kitware projects. We need to distinguish the copyright from the license. Basically the copyright holder allows others to use his/her/its creation by granting certain rights under terms of a license. > Either the license > (https://vxl.svn.sourceforge.net/svnroot/vxl/trunk/core/vxl_copyright.h) > or a link to it. This assigns copyright to the "TargetJr Consortium" and "GE". I don't think we want to have any individual own everything. I propose that we allow each contributor to maintain copyright on its contributions but require that the code be released under a specific license. The Boost community used to allow every package to choose its own license so long as it is "compatible" with a set of requirements. This created problems for commercial institutions whose lawyers were asked to separately check every license. To solve this problem they created the "Boost Software License 1.0" and got all authors that contributed to Boost to agree on the one license. This page has some interesting information from Boost's experience: http://www.boost.org/users/license.html If we settle on one license it should be OSI-approved: http://www.opensource.org/licenses/ I suggest one of these: http://www.opensource.org/licenses/bsl1.0.html http://www.opensource.org/licenses/apache2.0.php http://www.opensource.org/licenses/bsd-license.html All are similar in spirit. Boost is the least restrictive as it does not require notices to be included with binary distributions. We chose the 3-clause BSD license for CMake 2.8 (which replaced the non-OSI 4-clause BSD-style license used previously) for simplicity. FYI, I've already contributed two libraries to vxl/contrib/rpl under the Boost license. I chose it because it is very open and easy to read and understand for those not experienced in licensing issues. -Brad |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2010-01-20 21:40:46
|
On Wed, Jan 20, 2010 at 2:15 PM, Brad King wrote: > On 1/20/2010 11:21 AM, Miguel A. Figueroa-Villanueva wrote: >> I also thought about requiring a uniform header in every *.h file >> that included a license statement. > > I believe that, strictly speaking, every file needs its own > copyright and license notice. We've largely ignored this > in vxl previously. If you want to spearhead an effort to > address this problem I'm happy to advise. I spent quite a > while investigating this issue for CMake and other Kitware > projects. I believe that this is an important issue, and I am willing to work on it. However, I would like feedback from most maintainers in terms of their viewpoints on this matter, since it is sort of a sensitive issue. If there is resistance then I wouldn't care to deal with it. --Miguel |
From: Amitha P. <ami...@us...> - 2010-01-21 02:59:38
|
Brad King wrote: > This assigns copyright to the "TargetJr Consortium" and "GE". > I don't think we want to have any individual own everything. > I propose that we allow each contributor to maintain copyright > on its contributions but require that the code be released under > a specific license. When someone contributes a patch, they also add their name to the copyright list? They may or must? In general, I agree with this. I would argue, however, that the copyright boilerplate is as small as possible in each file. Ideally not more than two lines. Something like // Copyright (C) 2010 Somebody // See LICENSE.TXT for license. If we need to have whole paragraphs of license text, I'd prefer that it appears at the bottom of each file. Amitha. |
From: Peter V. <pet...@ya...> - 2010-01-21 08:43:41
|
I'm also in favour of a max. 2-line copyright text per file. -- Peter. --- Den tors 2010-01-21 skrev Amitha Perera <ami...@us...>: > In general, I agree with this. I would argue, however, that > the copyright boilerplate is as small as possible in each file. > Ideally not more than two lines. Something like > // Copyright (C) 2010 Somebody > // See LICENSE.TXT for license. -- __________________________________________________________ Låna pengar utan säkerhet. Jämför vilkor online hos Kelkoo. http://www.kelkoo.se/c-100390123-lan-utan-sakerhet.html?partnerId=96915014 |
From: Brad K. <bra...@ki...> - 2010-01-21 13:52:24
|
Hi Folks, See below for comments on copyright/license notices in sources. I think it is more important to agree on an OSI-approved license first. It is important to use an OSI-approved license because: (1) It adds credibility to our claim of "Open Source". (2) Open source philanthropists typically recognize only OSI-approved licenses (e.g. Google Summer of Code). The current "vxl_copyright.h" text is BSD in spirit, but not the specific form that is OSI-approved. Again, I suggest one of these: - BSD: http://www.opensource.org/licenses/bsd-license.html Closest to vxl_copyright.h; perhaps out-dated in terminology. - Boost: http://www.opensource.org/licenses/bsl1.0.html Very simple, written by lawyers; not sure how well scrutinized. - Apache: http://www.opensource.org/licenses/apache2.0.php Relatively complex, but survived scrutiny by lawyers. Any opinions? Once chosen, we need to ask all contributors to commit (or authorize us to commit) retroactive copyright lines that reference the chosen license. Last year I put together a list of names/emails of almost every person that ever committed to vxl, so we should be able to contact everyone. Amitha Perera wrote: > When someone contributes a patch, they also add their name > to the copyright list? They may or must? They may do so. If they do not then they effectively assign copyright to the current holders. Peter Vanroose wrote: > Amitha Perera wrote: >> In general, I agree with this. I would argue, however, that >> the copyright boilerplate is as small as possible in each file. >> Ideally not more than two lines. Something like >> // Copyright (C) 2010 Somebody ^^^ The "(C)" is not necessary; "Copyright" is sufficient. >> // See LICENSE.TXT for license. > I'm also in favour of a max. 2-line copyright text per file. If we reference a license file by name we need to be sure it is included in installations too (since the header files will reference it). FYI, Boost uses this: // Copyright 2010 Somebody // Use, modification and distribution are subject to the // Boost Software License, Version 1.0. (See accompanying file // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) In CMake C++ sources we use this: /*============================================================================ CMake - Cross Platform Makefile Generator Copyright 2000-2010 Kitware, Inc., Insight Software Consortium Distributed under the OSI-approved BSD License (the "License"); see accompanying file Copyright.txt for details. This software is distributed WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the License for more information. ============================================================================*/ The "Copyright.txt" file gets installed with the CMake documentation along with equivalents for each third-party library we distribute with it. Ideally it would be named "LICENSE" or something like that, but the BSD license template includes a copyright line, which makes it specific to the holder of the copyright. In CMake Module files, which may have several contributors and also may be copied into external projects, we use this: #============================================================================= # Copyright 2006-2009 Kitware, Inc. # Copyright 2006-2008 Other Author # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. # # This software is distributed WITHOUT ANY WARRANTY; without even the # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the License for more information. #============================================================================= # (To distributed this file outside of CMake, substitute the full # License text for the above reference.) Note the last bit about substituting the full license. We did this because module files may be copied/modified into projects that need fixes but cannot wait for a new CMake release. In those projects the Copyright.txt file will not be present/identical. -Brad |
From: Ian S. <ian...@st...> - 2010-01-21 18:06:55
|
If someone is willing to go through with a license clean-up, then "please-do and good luck" If you really want to change the license then I vote for the BSD license here, because it is simple to read and very similar to our existing license. If needed, I think I should be able to arrange appropriate sign-offs for both Imorphics employees and Manchester University employees and students. On the other hand, I'm not quite sure what this buys us. If anyone is sufficiently concerned about rogue contributions, then I'm sure it would be possible to write a script to check for new copyright assignments in VXL and check no-one sticks anything silly in. Ian. On 21/01/2010 13:52, Brad King wrote: > Hi Folks, > > See below for comments on copyright/license notices in sources. > > I think it is more important to agree on an OSI-approved license first. > It is important to use an OSI-approved license because: > > (1) It adds credibility to our claim of "Open Source". > (2) Open source philanthropists typically recognize only OSI-approved > licenses (e.g. Google Summer of Code). > > The current "vxl_copyright.h" text is BSD in spirit, but not the specific > form that is OSI-approved. Again, I suggest one of these: > > - BSD: http://www.opensource.org/licenses/bsd-license.html > Closest to vxl_copyright.h; perhaps out-dated in terminology. > > - Boost: http://www.opensource.org/licenses/bsl1.0.html > Very simple, written by lawyers; not sure how well scrutinized. > > - Apache: http://www.opensource.org/licenses/apache2.0.php > Relatively complex, but survived scrutiny by lawyers. > > Any opinions? > > Once chosen, we need to ask all contributors to commit (or authorize us > to commit) retroactive copyright lines that reference the chosen license. > Last year I put together a list of names/emails of almost every person > that ever committed to vxl, so we should be able to contact everyone. > > Amitha Perera wrote: >> When someone contributes a patch, they also add their name >> to the copyright list? They may or must? > > They may do so. If they do not then they effectively assign copyright > to the current holders. > > Peter Vanroose wrote: >> Amitha Perera wrote: >>> In general, I agree with this. I would argue, however, that >>> the copyright boilerplate is as small as possible in each file. >>> Ideally not more than two lines. Something like >>> // Copyright (C) 2010 Somebody > ^^^ > The "(C)" is not necessary; "Copyright" is sufficient. > >>> // See LICENSE.TXT for license. >> I'm also in favour of a max. 2-line copyright text per file. > > If we reference a license file by name we need to be sure it is included > in installations too (since the header files will reference it). > > FYI, Boost uses this: > > // Copyright 2010 Somebody > // Use, modification and distribution are subject to the > // Boost Software License, Version 1.0. (See accompanying file > // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) > > In CMake C++ sources we use this: > > /*============================================================================ > CMake - Cross Platform Makefile Generator > Copyright 2000-2010 Kitware, Inc., Insight Software Consortium > > Distributed under the OSI-approved BSD License (the "License"); > see accompanying file Copyright.txt for details. > > This software is distributed WITHOUT ANY WARRANTY; without even the > implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > See the License for more information. > ============================================================================*/ > > The "Copyright.txt" file gets installed with the CMake documentation along > with equivalents for each third-party library we distribute with it. Ideally > it would be named "LICENSE" or something like that, but the BSD license > template includes a copyright line, which makes it specific to the holder > of the copyright. > > In CMake Module files, which may have several contributors and also may > be copied into external projects, we use this: > > #============================================================================= > # Copyright 2006-2009 Kitware, Inc. > # Copyright 2006-2008 Other Author > # > # Distributed under the OSI-approved BSD License (the "License"); > # see accompanying file Copyright.txt for details. > # > # This software is distributed WITHOUT ANY WARRANTY; without even the > # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > # See the License for more information. > #============================================================================= > # (To distributed this file outside of CMake, substitute the full > # License text for the above reference.) > > Note the last bit about substituting the full license. We did this because > module files may be copied/modified into projects that need fixes but cannot > wait for a new CMake release. In those projects the Copyright.txt file will > not be present/identical. > > -Brad > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Chuck A. <chu...@ki...> - 2010-01-13 18:58:47
|
I think we need to differentiate here the difference in a non-commercial use restriction and the use of GPL code. As fas as I know there is no restriction with GPL code to using it for commercial purposes, only that source code still needs to be made available. The specific code in question, however, is explicitly licensed for non-commercial use only regardless of whether the code for the given product is made available or not. These are 2 different conditions and I don't think it's appropriate to lump them together. Chuck Atkins R&D Engineer Kitware, Inc. (518) 371-3971 x603 -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos On Wed, Jan 13, 2010 at 8:31 AM, <pe...@va...> wrote: > Joe Mundy wrote: > > Ok, so let's go with > > BUILD_COMMERCIAL > > The goal of this new setting is to avoid that people who want to build a > commercial application using vxl, won't by accident use > GPL (or similar) source code. So by default, this setting must be ON. > The C++ source will thus need a > #ifndef BUILD_COMMERCIAL > ... > #endif > around GPL code. > > So I see a disadvantage with this solution: people who build the code > *without* any setting (e.g. because they don't use CMake, or > and old version of the generated makefiles, or whatever) will accidentally > *include* the GPL code! > > Therefore, if indeed BUILD_COMMERCIAL should be the default --which is to > be overridden only *on purpose*-- shouldn't we > preferably use something like > BUILD_NONCOMMERCIAL > as a CMake setting, which is then of course *not* set by default? In that > case, the conditioning around GPL code would instead > become: > #ifdef BUILD_NONCOMMERCIAL > ... > #endif > > -- Peter. > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Joseph M. <mu...@le...> - 2010-01-13 18:57:42
|
I agree. The GPL license does not restrict commercial use but it does require copy left so that the commercial source code using GPL code becomes free software. We want to keep VXL non-GPL so that commercial users can feel free to incorporate the libraries in their products or services involving their proprietary code without concern. So hopefully there is no GPL code in VXL. If so it will be removed. The point of the BUILD_NONCOMMERCIAL is to allow some code that is restricted to non-commercial use in VXL to be inadvertently used for commercial purposes. The GPL case below shouldn't apply to VXL or to the BUILD_NONCOMMERCIAL switch. Joe From: Chuck Atkins [mailto:chu...@ki...] Sent: Wednesday, January 13, 2010 1:29 PM To: pe...@va... Cc: Joseph Mundy; Vxl-maintainers Subject: Re: [Vxl-maintainers] Restricted polygon code I think we need to differentiate here the difference in a non-commercial use restriction and the use of GPL code. As fas as I know there is no restriction with GPL code to using it for commercial purposes, only that source code still needs to be made available. The specific code in question, however, is explicitly licensed for non-commercial use only regardless of whether the code for the given product is made available or not. These are 2 different conditions and I don't think it's appropriate to lump them together. Chuck Atkins R&D Engineer Kitware, Inc. (518) 371-3971 x603 -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos On Wed, Jan 13, 2010 at 8:31 AM, <pe...@va...> wrote: Joe Mundy wrote: > Ok, so let's go with > BUILD_COMMERCIAL The goal of this new setting is to avoid that people who want to build a commercial application using vxl, won't by accident use GPL (or similar) source code. So by default, this setting must be ON. The C++ source will thus need a #ifndef BUILD_COMMERCIAL ... #endif around GPL code. So I see a disadvantage with this solution: people who build the code *without* any setting (e.g. because they don't use CMake, or and old version of the generated makefiles, or whatever) will accidentally *include* the GPL code! Therefore, if indeed BUILD_COMMERCIAL should be the default --which is to be overridden only *on purpose*-- shouldn't we preferably use something like BUILD_NONCOMMERCIAL as a CMake setting, which is then of course *not* set by default? In that case, the conditioning around GPL code would instead become: #ifdef BUILD_NONCOMMERCIAL ... #endif -- Peter. ---------------------------------------------------------------------------- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Amitha P. <ami...@us...> - 2010-01-19 11:37:33
|
pe...@va... wrote: > Joe Mundy wrote: >> Ok, so let's go with >> BUILD_COMMERCIAL > > The goal of this new setting is to avoid that people who want to build a commercial application using vxl, won't by accident use > GPL (or similar) source code. So by default, this setting must be ON. > The C++ source will thus need a > #ifndef BUILD_COMMERCIAL > ... > #endif > around GPL code. > > So I see a disadvantage with this solution: people who build the code *without* any setting (e.g. because they don't use CMake, or > and old version of the generated makefiles, or whatever) will accidentally *include* the GPL code! Perhaps call it "BUILD_RESTRICTED"? Not that the exact word is really important to me. :-) Amitha. |