Re: Swixml 1.1 and LGPL

Kate/All,

I am not a lawyer and do not claim to be one, so for the legalities-an IP
lawyer (possibly from ASF should be contacted).

The source code already has been released under a certain agreement.  That
license can not "all of a sudden" be switched to a more restrictive license.
The big dog is out on the current code base.

Wolf currently holds the main Intellectual property of the core components.
He is the maintainer of the software.

He no longer owns the software, the public does.

Wolf owns the copyright of the software.
But, as a current holder of the current release of the software, I can do
what I want with it, without repercussion.

I can sell it, I can bundle it, I can modify it to my liking and sell that
version as something else.  If I do, I just can't call it Swixml.

I like that.

I am not saying that is my intention.  Just that I could if I wanted to.

It is my intention although to modify the code to my liking.  To suit my
purpose.  Currently, I retain the copyrights to some of the functionality in
the 2.0 version of code that I sent Wolf.  (By the way, I think that code
should start making the rounds now).

Now, I was nice enough to include my modifications under the APL license.

With, LGPL, I would have to, mandatory.

Now, again with that said. I do agree with Kris in that the issue really
isn't the license.  In fact, the Apache License is just fine.  Even if
Apache is licensing new development under a new APL style license, Swixml
can continue using the "old" license.

I think the LGPL license is fine for libraries. Which is what it was created
for. Small, useful pieces of code that be used for many things.

Swixml isn't a library. It is an XML to Java binding engine for Swing.

To the point on splinter code.

Splinter code will still exist in the market place regardless of license.
In fact, the only change in license will most likely result is in more
offshoots, not less,  of version 1.1 code.

I still think it is a mistake.

What we really want to do is just tell everyone about Swixml, so that we can
get more developers on the band wagon.

That does bring me to another point - Wolf, you really need to get the CVS
up and running so that we can all contribute.  Otherwise, Swixml will feel
too closed for most developers and not bother with it.

Respectfully,

Brian Michael

> Wolf owns swixml... he can put any license on it whenever he wants.
> he can't change the license on products already out in the wild but
> there's nothing to say all distribution of product x from today forwards
> is under license y.  Yes it woudl lead to confustion if you did that in
> without updating the version at the same time... but it's still legal.
> Not only that he can release it under as many simultaneous licenses as
> he wants. Many companies do this.  Release stuff under GPL but offer a
> seperate licese for companies who wish to use their product without
> being subject to the gpl... of course that's usually in exchange for money.
> 
> my vote if changing licenses between releases is to increment the
> version number slightly just to elimate confusion.
> 
> 
> As for the actual license chosen. if sharing changes is the concen
> BSD/MIT license covers that just fine and is probably the lease
> restrictive license type out there.  It also has the advantage of being
> very easy to understand.  That being said, I'm completely fine with
> LGPL. An advantage it has over MIT is that it explicitly mentions source
> code..whereas MIT just says you need to be able to tweak it but doesn't
> mention providing access to the source code itself. hmm never noticed
> that before.
> 
> -Kate
> 
> Brian P Michael wrote:
> 
>>> I'm currently working on the upcoming Swixml 1.1, which is mainly a
>>> maintenance release.
>>> 
>>> Still, I'm considering to switch the license from Apache to LGPL - if
>>> you want to get the understandable version, read it here:
>>> http://creativecommons.org/licenses/LGPL/2.1/
>>> 
>>> Please let me now if you would have a problem with this.
>>> 
>>> Thanks
>>> 
>>> Wolf Paulus
>>> 
>>> C a r l s b a d   C u b e s
>>> mailto:[email protected]
>>> 
>>> CONFIDENTIALITY NOTICE:
>>> This message is intended only for the use of the individual or entity
>>> to which it is addressed, and may contain information that is
>>> privileged, confidential and exempt from disclosure under applicable
>>> law.
>>> If you are not the intended recipient, please contact the sender by
>>> reply email and destroy all copies of the original message.
>>> 
>>> 
>>> _______________________________________________
>>> Forum mailing list
>>> [email protected]
>>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>>> 
>>>    
>>> 
>> Wolf,
>> 
>> I think the Apache License is fine.
>> 
>> Also, all copies of the current code are covered under Apache, which
>> is a far less restrictive license.
>> 
>> I do not believe you can change the current code's license structure to a
>> more restrictive license.  That would actually be illegal and would actually
>> break the terms of the Apache License itself.
>> 
>> The Apache license provides for full commercialization of Swixml by the
>> community, which I support. It also allows full use of product without
>> distribution of modified code.
>> 
>> One of the reasons I chose Swixml was for it's license structure.
>> 
>> I DO NOT SUPPORT the switch in licensing.
>> 
>> Nor do I feel that you can legally switch to a more restrictive license for
>> all code that is already under Apache License.
>> 
>> Now, with that said, any new code that is created by you could be licensed
>> under any new license terms, but the core code must keep it's original
>> license structure.
>> 
>> If you switch licensing of the core code, you will find a re-release of
>> SWIXML released under the SWIXML name with the current Apache License.  In
>> this manner, SWIXML would stay with the Apache License.
>> 
>> Once you let the Dog out, it's out.  That's the price of open source.
>> 
>> Sincerely,
>> 
>> Brian P Michael
>> [email protected]
>> 
>> 
>> _______________________________________________
>> Forum mailing list
>> [email protected]
>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>> 
>> 
>>  
>> 
> 
> 
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>