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.bannasch@deanbrook.org> wrote:

Re: [Jmol-developers] Jmol in JS (and hopefully NextGen MW
At 11:38 AM -0400 10/14/12, Robert Hanson wrote:
On Sun, Oct 14, 2012 at 11:07 AM, Stephen Bannasch <stephen.bannasch@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.


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!
Jmol-developers mailing list