JBoss to go closed source?

[James]

Heard a rumor about JBoss going closed source? If they do this, how
can those who contributed code become compensated? Will blog this
breaking story here: http://blogs.ittoolbox.com/eai/leadership

 

[The Abrasive Sponge]

Heard a rumor about JBoss going closed source? If they do this, how
can those who contributed code become compensated? Will blog this
breaking story here: http://blogs.ittoolbox.com/eai/leadership

http://www.jboss.org/faq/license
-------------------------------------------------------------
Could JBoss Inc. ever create a closed source fork of JBoss AS?

No. The LGPL prohibits closed source additions to JBoss. The LGPL is
very logical and explicit about this: "a) The modified work must itself
be a software library. b) You must cause the files modified to carry
prominent notices stating that you changed the files and the date of any
change. c) You must cause the whole of the work to be licensed at no
charge to all third parties under the terms of this License. ", from the
LGPL. JBoss Inc. fully intends to abide by the license, and our business
model is, in fact, built on this foundation. Note that this is in stark
contrast to a BSD or Apache-style license that allows for forking and
creation of commercial projects. The latter allows for a "bait and
switch" to users where the major sponsor withdrawals support from the
open source project and forks a commercial version.

 

[James]

The question isn't whether LGPL permits it. JBOSS has the liberty of
modifying its license to another style and can then close the source.

 

[Tor Iver Wilhelmsen]

The question isn't whether LGPL permits it. JBOSS has the liberty of
modifying its license to another style and can then close the source.

What they cannot do is retroactively remove the license to LGPL
licensed versions. So any new licensed version will represent a
"licensing branch"

 

[Bent C Dalager]

What they cannot do is retroactively remove the license to LGPL
licensed versions. So any new licensed version will represent a
"licensing branch"

One interesting question is who owns the copyright to the code in the
first place. If Sally contributes code to JBoss, then presumably the
copyright on this code belongs to Sally. It is up to Sally to decide
on a license for her code and if she refuses to change it from LGPL
(which would be the license implied by contributing the code to an
LGPL project) then JBoss would need to throw out everything she
contributed and reimplement those parts.

Alternatively, there may be some legal clause somwhere that transfers
sufficient copyright on contributed code to JBoss so that they _can_,
indeed, change the license on the code contributed by Sally.

Cheers
Bent D

 

[Chris Smith]

One interesting question is who owns the copyright to the code in the
first place. If Sally contributes code to JBoss, then presumably the
copyright on this code belongs to Sally. It is up to Sally to decide
on a license for her code and if she refuses to change it from LGPL
(which would be the license implied by contributing the code to an
LGPL project) then JBoss would need to throw out everything she
contributed and reimplement those parts.

Alternatively, there may be some legal clause somwhere that transfers
sufficient copyright on contributed code to JBoss so that they _can_,
indeed, change the license on the code contributed by Sally.

GNU projects require that you sign a copyright transfer form before they
will accept contributions. In the case of GNU, this is intended not to
protect the right to change licenses, but rather to preserve the ability
of the FSF to file lawsuits against anyone violating licenses on the
code.

I haven't contributed to JBoss, and I don't know if there's such a
process or not.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tim Tyler]

GNU projects require that you sign a copyright transfer form before they
will accept contributions. In the case of GNU, this is intended not to
protect the right to change licenses, but rather to preserve the ability
of the FSF to file lawsuits against anyone violating licenses on the
code.

I haven't contributed to JBoss, and I don't know if there's such a
process or not.

AFAICT, JBoss is not a FSF project - though it is goverend by one
of their licenses.

The text on:

http://www.gnu.org/licenses/why-assign.html

....apparently refers only to FSF projects - not GPL/LGPL ones.

There appears to be no clause about assigning copyright for contributed
work to the FSF in the actual text of the licenses themsevles.

As the above page notes:

``If there are multiple authors of a copyrighted work, successful
enforcement depends on having the cooperation of all authors.''

 

[Chris Smith]

AFAICT, JBoss is not a FSF project - though it is goverend by one
of their licenses.

Yes, you are right about all of this. As I said, I don't know anything
about JBoss's policy for copyright assignment. I brought up the FSF
policy only as an example of a concrete consequence of the copyright
issue that was being discussed.

Sorry to cause any confusion.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[James]

This has absolutely nothing to do with intelligence. It does have to
do with stealing the intellectual property of those who have
contributed their own time that do not work for JBoss Group and having
it stolen if they go out of business. VCs are not stupid. The
developers who contribute to open source projects such as JBoss may
be...

 

[Tim Tyler]

This has absolutely nothing to do with intelligence. It does have to
do with stealing the intellectual property of those who have
contributed their own time that do not work for JBoss Group and having
it stolen if they go out of business. VCs are not stupid. The
developers who contribute to open source projects such as JBoss may
be...

JBoss is distributed under the LGPL license.

You might want to explain how anyone can "steal" the intellectual
property in a LGPL project - without breaking copyright law.

 

[Cindi Jenkins]

You might want to explain how anyone can "steal" the intellectual

property in a LGPL project - without breaking copyright law.

It is simple, all JBoss has to do is change the licensing for the next version...

 

[Chris Smith]

It is simple, all JBoss has to do is change the licensing for the
next version...

That depends very much on who owns the copyright for JBoss code. I
haven't contributed to the project, so I don't know whether they require
a copyright transfer; if they don't, then there would be problems with
changing the license.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tim Tyler]

It is simple, all JBoss has to do is change the licensing for the
next version...

You mean JBoss can steal their /own/ intellectual property - if they all
agree to it?

I can't see how that would be theft - the IP is already theirs.

 

[Cindi Jenkins]

The issue is whether is it legal for a company to change licensing in
situations where the community has contributed time, energy and code.
Should JBoss be allowed to change their license and not provide
compensation for those who have contributed in the past?

 

[Tim Tyler]

The issue is whether is it legal for a company to change licensing in
situations where the community has contributed time, energy and code.
Should JBoss be allowed to change their license and not provide
compensation for those who have contributed in the past?

Usually all copyright holders have to agree on any licensing
terms. If copyrighted material is used without the permission
of the copyright holder, the use is not permitted by law.

As with other areas of copyright law, you can surrender these
rights if you choose to do so, using a license.

So, this boils down to whether the contributors retained copyright -
and what license they offered in exchange for the use of their code.