I don't think so. Why do you say that? All they have to do is provide changes
to YOUR subsystem. What you describe is GPL. If they change the jmol code they
must share those changes that they made to that code only not to their code. Am
I wrong?
Sent from my stupid iPhone
On Oct 14, 2012, at 12:58 PM, Stephen Bannasch <stephen.banna...@deanbrook.org>
wrote:
> At 11:38 AM -0400 10/14/12, Robert Hanson wrote:
>> On Sun, Oct 14, 2012 at 11:07 AM, Stephen Bannasch
>> <stephen.banna...@deanbrook.org> wrote:
>> At 10:25 AM -0400 10/14/12, Robert Hanson wrote:
>>
>> I don't know which path is likely to be more successful, but I worry that
>> LGPL licensing will be a barrier for commercial publishers.
>>
>> LGPL is especially appropriate for commercial publishers. That's why we use
>> it instead of GPL and what makes it "Lesser".
>>
>> However when I think about the possible impact I want to have on learning I
>> am concerned about the possible reluctance of acommercial publisher to use
>> the combined product when part of it is licensed under the LGPL.
>>
>> What is your concern about LGPL?
>>
>> At the Concord Consortium we've been releasing all our source code under the
>> LGPL for many years. When we chose to use thislicense one of the theoretical
>> benefits is that our work could both be integrated into closed-source
>> projects AND the license itself would prevent closed-source commercial forks
>> extending our work. That restriction might then encourage a group interested
>> in a new feature to instead develop it and contribute it back to the
>> community.
>>
>> ?? LGPL certainly does not prevent closed-source commercial forks extending
>> your work. Why do you say that?
>
> Someone who integrates LGPL into closed-source work must develop systems for
> extending LGPL license and making the source code for LGPL work available to
> anybody to whom closed-source distribution is made in source or executable
> form.
>
> This is not something that many commercial publishers do or have mechanisms
> for doing.
>
> If the closed-source work extends LGPL code that is integrated into their
> product they must extend LGPL license to their additions to anybody they
> distribute either the closed-source project or a binary executable which
> contains project.
>
> This is also not something most commercial publishers have understanding of
> or mechanisms for accomplishing.
>
> If closed source project extends LGPL work and these new features in LGPL
> library involve new ways of communicating with orinteracting with
> closed-source part of work then new features in LGPL work must work and be
> understandable and extendable to another user without access to closed-source
> work.
>
> It is my experience that almost nobody understands this last element (usually
> eyes start to glaze over at this point in thediscussion) , let alone lawyers
> vetting IP details working for closed-source project.
>
> Version 3.0 of LGPL includes portions of v3.0 of GPL by reference.
>
> http://www.gnu.org/licenses/lgpl.html
>
> There are many subtle aspects of this license which I suspect most people
> don't understand.
>
> So our decisions flow from these judgements as regards to OUR work and
> experience:
>
> 1. LGPL license is harder to understand and for external groups unfamiliar
> with to vet.
> 2. In our projects it hasn't provided benefit.
> 3. In our judgement risk associated with more BSD-like (attribution-only)
> licenses is low.
> 4. BSD-like (attribution-only) licenses are very easy to understand and
> appear to encourage more collaborative development.
>
>> The reality (for the work we have done) is that we have had practically no
>> contributions from external groups. In addition the LGPL subtle and hard to
>> explain to other groups.
>> I haven't found that to be the case. Maybe there's another reason you have
>> had practically no contributions.
>
> Yes, I think there are many reasons for this. However at least from our data
> I can't say the LGPL has helped. I have had conversations with publishers who
> did not want to use any code that was licensed under the LGPL. I of course
> have worked to explain that this should not be a problem for them ... that
> explanation has not always been successful (see earlier reference to
> eyesglazing over ...).
>
>> So we are considering revising how we license code created by CC in general.
>> Well, that's fine, but Jmol is still LGPL.
>
> Of course it is.
>
> I am explaining our goals, analysis and decisions.
>
> Takanori Nakane chose to license GLmol under dual-license: either MIT or
> LGPL: https://github.com/biochem-fan/GLmol
>
> It is up to you to decide license for Jmol and you have chosen LGPL.
>
> Perhaps you will change the license, perhaps not, again it is of course up to
> you.
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
