Thank you for your comment. Yes, it is always good to keep the conversation open.

That said, I am very curios to your explanation to the hostile comments about the OpenBD project.

Honestly, I was a little bit taken aback from your post, since I sense you to be a genuine speaker and appreciated your posts so far.

Have a good time at CFUnited.

Thanks for keeping this conversation going! I think it is great that we have these exchanges as it helps to air many issues which might otherwise be confusing to people less involved with the announcements.

I’m a little locked right now with CF United, but I’ll definitely post before the weekend with some clarifications of what I was trying to communicate.

Thanks for continuing to engage and being so passionate about the community.

@Sasha,

Awesome. Always great to have a true expert available. I think this is one of the many great things we will gain the the ColdFusion community from having access to the JBoss brain trust after the JBoss/Railo announcement!

Thank you for outlining the whole issue. Clearly I was mistaken with my comments. I stand corrected.

The difference between the GPL and the LGPL is NOT with regard to the changes you apply to the codebase itself. Hence, contrary to the first quote above, if a company was to modify an LGPL codebase and distribute the result, then they would be mandated to contribute the changes back under the LGPL (same as for the GPL).

The difference lies in the “virality” of the requirement to contribute the changes back to the community. In the case of the LGPL, the constraint only applies to the original codebase i.e. the original project. In the case of the GPL, it applies to any software binding into it. In the case of a VM or interpreter for example, a pure GPL license would apply to ANY application running on top of it (again, IF AND ONLY IF the bundled gets distributed - as both the GPL and LGPL are only triggered when the software gets distributed)

Consequently, and to go back to your example. If Adobe was to perform changes to OpenBD or Railo (for example, some performance optimizations) and wanted to distribute these software, Adobe would have to contribute back these changes to the community in BOTH cases. Where things differ is whether they would be allowed to embed Railo or OpenBD in their own solution and keep their own software under a proprietary license: the LGPL permits this, the GPL doesn’t (modulo section 6 of the LGPL). But the same logic not only applies to companies like Adobe who might want to “embed” that software into their own solution, but also to any company that would want to bundle their own ColdFusion application with OpenBD and distribute that bundle to some of their customers or partners. They wouldn’t be allowed to do so with the GPL as it would require them to also open source their own CFML application under the GPL. Such a user is no different from an OEM with regard to the GPL: both of them just i) bind into your engine and ii) distribute the software.

In conclusion:

i) both the LGPL and GPL requires changes to be contributed back to the community in case they are distributed

ii) the notion that matters in the (L)GPL is the notion of *distribution*, which doesn’t differentiate the case of an OEM from the case of any other user who would want to distribute some packaged GPL software.

And last but not least, choosing the GPL or any other OSI-approved license for a software is totally fine. The choice of a specific license really needs to satisfy the desires of the community contributing to that project. Various groups have different views on what is good (TM) or bad (TM). I think Marc Fleury’s blog on this topic is very much in line with what many JBoss’ian would agree with: http://blogs.jboss.com/blog/mfleury/2004/08/02/From+GPL+to+BSD+to+LGPL:+On+the+Issue+of+Business+Friendliness.html

I hope it clarifies things. Cheers,

Sacha

You stated that my understanding of the LPGL is not correct. Please explain, because it does allow companies to take the code, embed it into their own solution and sell/distribute it.

This is a contrast to the GPL. I did not state anything else in my post. If so please explain.

Thank you for much for the explanation.

I was merely pointing out that some successful project are using the GPL license. If they use the core license (who does nowadays) or a different version of. I did not go into details.

I meant to say that RedHat uses Linux. Thus referring to RH Linux.

Your understanding of the LGPL is incorrect. The LGPL is a copy-left license (hence requires to provide the changes back to the community) but, unlike the GPL, is not a “viral” copyleft license which would “contaminate” the software linking with it in case it would be distributed.

Also, the examples of GPL projects you are referring to are slightly misleading.

- The Sun Java SE open source project (OpenJDK) doesn’t have a strict GPL, but a so called “GPL + Classpath Exception” (or GPL+E) license. This license is very close to an LGPL license in its behaviour but preferred by some companies for the way it differs from the LGPL (precisely, section 6 of the LGPL).

- Linux: while the Linux kernel is indeed under the GPL, it also has an “exception” to the pure GPL: code running in user-space is not subject to the “virality” of the GPL. If such a clause didn’t exist, proprietary vendors (such as Oracle, IBM, etc.) wouldn’t be able to distribute their proprietary software on top of Linux as it would make their product subject to the virality of the GPL (hence require them to GPL their own software)

- Red Hat: this is a company, not an open source project, so I am not sure to which project you are referring to (and JBoss is part of Red Hat and mostly using the LGPL for its projects)

- MySQL: while MySQL indeed uses the GPL, it does so as it serves as the foundation of its business model. Indeed, MySQL owns the copyright to its entire codebase and can then “dual-license” its product under the GPL and any other proprietary license. Given that the strict-GPL is not considered to be a fine license for the OEMs (as distribution triggers the virality clause - which is exactly what OEMs do, they distribute software) - they go back to MySQL (Sun now) to ask for a proprietary license on the exact same binary. Consequently, the choice of the GPL here is a deliberate choice to “force” the OEMs to pay for the software (which is a totally fine business model by the way). However, let’s make an assumption now: if MySQL AB (or SUN now) were to NOT own the copyright (or a sufficient license) on the MySQL codebase. Then, they would have never chosen the GPL license as it would have prevented proprietary OEMs to use it. The very fact that they own the copyright and want to make money out of it is what led to the choice of this license specifically.

I hope it clarifies a few things.

Cheers,

Sacha

I don’t see that by saying “..the OpenBD project is better of not being here” makes his concern valid. The full blog post of Peter is towards making the OpenBD project look bad. This all with limited knowledge.

That said, I happy to see good comments and will reply to some here:

“It’s unfortunate that 4 or 5 members of the steering committee have resigned in recent weeks, which creates some doubt about the strength of the OpenBD project.”

Has it ever come to mind that the initial people on the Steering Committee have been asked to join and might not been the once that would have contributed the most? Mike Brunt and Andy Alan have left because they simply had no time to contribute, Mark Drew said the same (but his real intention is that he wants to help Railo and not OpenBD (this is fine and no problem with that)). The only person that left with anger is Sean that had a little dispute with another member.

In the meantime other people have joined. Some of the are “Java Gurus”, but I think we will make some announcements soon.

Don’t forget, contributing to a open source project is done by people who all have a day job and they are doing this by their own will and time.

I hope that you and others see that the OpenBD project has not lost its momentum and strength. Indeed, far from it.

“Code submitted to OpenBD can’t be used in Railo, nor could it be used by Adobe.”

In the light of an open source project under GPL this is true. But we already said many times, that we are looking into Classpath Exception and that could apply.

OpenBD has the Plug-in Architecture. Plug-In’s contributed like that can be moved to a LPGL or alike license.

If you want to contribute right now and this is the only issue holding you back, then please contact us. I am sure we can work something out.

- We now have 2 OS CFML engines to contribute to, making it difficult to choose where to direct out efforts.
- Railo discussed their plans with Adobe before going public, presenting a good case for going OS, i.e. joining JBoss.org and gaining exposure to Java developers.
- In contrast, it appeared that New Atlanta (at the time) was going OS with only existing CF customers in mind and with their .NET products that the proposed upsell / “upgrade” path - hence the ill feelings. Though it’s fair to say that this now isn’t the case, and things have been explained more clearly.
- It’s unfortunate that 4 or 5 members of the steering committee have resigned in recent weeks, which creates some doubt about the strength of the OpenBD project.
- Code submitted to OpenBD can’t be used in Railo, nor could it be used by Adobe. That’s not to say that the LGPL is “better”, but in this case perhaps it is more suitable in the interest of compatibility across engines (or suitable for Adobe anyway :P). Where does this leave the decision to contribute code?.. Do we contribute to Railo and hope it ends up in OpenBD and in CF?

Of course we want to see things play out nicely for all parties but Railo does seem to have one up on OpenBD at the moment in their communication with Adobe, which I think is absolutely essential for success. Just my 2 cents.

I can feel you. Honestly speaking, I would be confused as well, if I would not be on the Steering Committee of OpenBD myself.

I have been very vocal about this issue and have pushed to release this “news” to the public. The “One Month…” post has been a result of this.

History is that TagServlet, the Scottish company by Alan Williamson, has built the engine and licensed it to New Atlanta. I don’t know their agreement, but it looks like it was a agreement that did not allow TagServlet to release their code as open source without New Atlanta’s blessing. Thus the whole, New Atlanta releases open source version.

But rest assured, that the members of the Steering Committee have no connection to New Atlanta nor do we want to. Since it is an open source project any company can offer services and support around it. Just like my company http://www.sixsigns.com will.

Terry, there are real people behind the OpenBD project and we are here for the CFML community. We want to help and we will release every code we write under the open source license. You can start using OpenBD without worrying. It is a fully featured CFML engine with all the bell and whistles.

If you have any more questions please feel to write to me anytime.

http://www.newatlanta.com/products/bluedragon/open_source/faq.cfm

This clearly shows that New Atlanta taking all credit for the OpenBD project, but now they want nothing to do with it??. At no point in the entire FAQ is TagServlet mentioned.
I really want an open source CFML engine, but jeez, the creditability of OpenBD is really lacking at this point. Every week some new controversy is raised about the project.