I'm writing to ask if there's any possibility of reconsidering the
Spring ME licence.
Before I put that question, I should introduce myself, and my interest
in Spring ME:
I'm working for a startup company that's developing (amongst other
things) static analysis tools for Java. Our global program analysis
tracks which objects a variable can reference, and looks for possible
code defects. Right now, I'm looking to add Spring support to our
analyses. As an example: if two threads access a singleton-scoped
bean, there could be a data race. I've discovered that the
BeanFactory generated by Spring ME is sufficiently simple that we can
track references to Spring-managed beans, allowing our tools to detect
such defects.
Sadly, I have two problems. Firstly, Spring ME doesn't seem to
support all the features we'd like (so far I've discovered some XML
constructs, field injection, annotations). Secondly, the GPL
licensing would prohibit us from using it in our product.
Obviously, I would much rather start with Spring ME and contribute
fixes as required than try to start from scratch. There could be
mutual benefit to that, and I much prefer the idea of improving an
existing open source library to re-inventing the wheel in a
proprietary code repository. So that's my position: I'd like to help
with the project, but can't with the current licence.
Considering the above: is a change of licence a possibility?
I'd like to suggest either the Apache 2.0 licence (for consistency
with Spring), or the LGPL (which would require us to make our changes
available under the same licence).
Regards,
Martin
On Thu, Feb 17, 2011 at 2:45 PM, wilfred <wilfred...@gmail.com> wrote:
> I think it's fair to say that - with the amount of traction Spring ME
> is having - there won't be too many people complaining, so I could
> consider doing that. However, I think it's important to point out here
> that it's based on GPL with Classpath Exception. As a consequence, it
> should not be a problem embedding it in your product, I would expect.
> Can you give an example of something the current license does not
> allow you to do?
I saw this in the COPYING file:
"***Certain*** source files provided in this distribution are subject to
the following clarification and special exception to the GPL, but
only when this is explicitly stated in the particular source file's header."
(Emphasis mine). At first, I thought it was just the files that are
intended to be linked into a Java ME application that had this
exception (MinimalBeanFactory and BeansException). It appears I'm
mistaken as a quick grep shows that every (non-generated) Java file
includes the phrase "As a special exception".
However, non-Java files don't have this exception, but the only
example of this that I've found is context.stg. But I imagine that'd
be straight-forward to fix(?).
That said, I'm still a bit nervous about it (and I can imagine some of
our users will be wary, even though it's no more a part of their build
than Java itself). I'll need to ask whether this would be OK, as I
don't feel in a position to make that decision myself.
So... none of that actually answers your question. :o)
I'll have to ask if we can use it as is (assuming we can have
clarification on non-Java sources). Then I'll get back to you.
Cheers,
Martin
Martin
--
You received this message because you are subscribed to the Google Groups "Spring ME" group.
To post to this group, send email to spri...@googlegroups.com.
To unsubscribe from this group, send email to spring-me+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spring-me?hl=en.
Regarding licensing, I've been instructed to "proceed with caution".
I'm a bit worried by some of license terms (the exception talks about
being allowed to produce 'executables', but really we're looking at
build plugins). But I'm happy to defer licensing worries until we've
got a proof-of-concept working.
> I think I will move the source code to Github, which would ease the process of working on your own forked version, as long as I am able to pull changes back in.
Sure. Sounds good.
> Lately somebody told me he was using
> it inside Ricoh hardware, if I remember well. That's all fine by me, and it
> fits the license agreement.
We're considering embedding Spring ME itself, not just the generated
BeanFactory class. Not sure whether that's different to Ricoh.
> If the context.stg file is a problem, then I will fix it just like that.
That'd be great, thanks.
> if you're thinking about making considerable changes, then I'd also be happy
> to accept you as a committer.
I'm going to start putting together a proof-of-concept Spring
integration by embedding the current Spring ME version. If that works
out, and we decide to persue the product idea, then we'll see what
features we might contribute, based on the projects we need to
support.
Thanks,
Martin
Martin
Sure. That's my understanding. I'll admit that right now, I'm not
sure exactly how this differs from the LGPL in practice.
> @Martin, there is always the option of getting a dedicated license that
> would allow you to do whatever you want. And promise you know that I won't
> charge you an arm and a leg. ;-)
Thanks, I'll mention this as an option. :o)
Martin
Well, I just submitted a patch on Kenai.
At one point I found myself logged into Kenai as Luca Tagliani, which
doesn't exactly inspire confidence in the Kenai hosting. :(
Another +1 for Github. :)
Martin