GPL, GWT, GXT, FSF, confusion

I really believe that switching to GPL did more harm then good. A forum thread of more than 50 pages is no good sign…

It is quite hard to tell how GPL works for web applications. Does sending html/css/javascript code to a browser mean I am conveying the application to the user?

What is the application in this case? As far as I remember I deployed a war file. Is my user getting the war file? Is he able to deploy the aplication? What about all of my server side business logic and settings that never get to user?

I think that what developers at GXT are demanding is wrong. As long as this isn’t clarified, GXT is a “no go”.

Or does someone want to buy a commercial license that only works on an unreleased version of GWT for a Proof-Of-Concept project? My customers definitely not.

Further reading:

Darrel quotes the mail sent by a member of the FSF foundation

Pavera argues about GPL, browser, combined work and conveyance

So my question at the end is: was it worth it?

Security Anforderungen 2.0: Gruppen, Rollen, Flexibilität

Was habe ich mich gefreut, als Jira das Sicherheitskonzept um Rollen (Projekt-Rollen) erweitert hat. Statt Rechtekonfigurationen an Benutzergruppen zu binden, hat man jetzt die Möglichkeit Rechte an bestimmte Rollen zu binden. Für jedes Projekt folgt dann die Benutzer/ Rolle Zuweisung: dadurch ergibt sich letztlich, welche Rechte ein Benutzer für ein bestimmtes Projekt haben wird.

Gerade in kleine, agil arbeitende Teams ist das wesentlich effizienter: in einem Projekt ist man der Projektleiter, bei einem anderem lediglich ein Entwickler. So flexibel wie Entwickler heute die Rollen wechseln müssen, so flexibel konfigurierbar muss heute auch unternehmenskritische Software sein. In der Vergangenheit musste man in Jira für jede mögliche Kombination der Rollen in einem Projekt entsprechende Benutzergruppen einführen. Benutzergruppen sind aber statisch/ global und nehmen keine Rücksicht auf besondere Projektgegebenheiten. Am Ende bekommt jedes Projekt eigene Benutzergruppen.

Die Einführung von Projektrollen und Sicherheitskonfigurationen für Projektrollen im Allgemeinen reduziert die Konfiguration drastisch. Danke Atlassian!

Ein Rollenmodell ist nicht mit den heute üblichen deklarativen Mitteln konfigurierbar. Wir scheitern an der instanzbasierten Sicherheit. Je nach Projekt hat der Benutzer andere Rollen. Um so wichtiger ist es, ein Security Framework zu wählen, mit dem man die nötige Flexibilität und die Möglichkeit bekommt, eigene Anforderungen umzusetzen.

Auch wenn JAAS ein beeindruckendes Werk ist, mangelt es meiner Meinung nach an Flexibilität. Anpassungen sind sehr schnell nicht mehr portabel, eine Bindung zu der Laufzeitumgebung und oder Infrastruktur ist das Ergebenis. Spring Security (formerly known as Acegi) ist hingegen sehr flexibel. Security wird dadurch nicht trivial, aber besondere Anforderungen und entsprechende Lösungsansätze scheitern nicht mehr an dem Framework.

Schade dass in der Spring Security Dokumentation zu diesem Thema nichts zu finden ist. Eine Interessante Ausarbeitung zum Thema Gruppen und Rollen auf Konzeptebene ist hier zu finden.

LGPL, dynamic linking and Java

Just came across this one:

It has always been the FSF’s position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as “hereditary.” So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL. By contrast, libraries licensed under the GNU Lesser General Public License (LGPL) may be linked to proprietary applications.

To use a GPLed library in a product, you need the Classpath Exception:

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

If you don’t directly link to GPLed code (e.g. using JMS, SOAP or similar communication approaches) it seems to be enough to provide installation instructions, so the user can deploy the GPL libraries himself. You have to provide bridge code licensed under compatible licenses to make this possible. If your code only compiles if a given GPL library is available in the classpath (import statements, use of derived classes, etc), then you must license your code under the GPL as well…

MyGWT ist no more…

Maybe some of you already visited the project homepage of MyGWT in the last days. Yes, MyGWT is gone. The project got finally “moved” to the extjs project, something that was announced long ago.

I was surprised to see GXT getting GPLed. Or better, dual licensed. There is the open source license (GPL), and there is the commercial license. The commercial license calculated per developer anyhow touching GXT classes, what in our agile days of development practically means every single developer of the team.

Browsing the dual license page of GXT I came across this statement:

Contribute to the Open Source community by placing your application under an Open Source license (e.g. GPL v3). This option secures all users the rights to obtain the application’s full source code, modify it, and redistribute it.

IMHO, this statement wishful thinking and not implied by the GPL license. In my understanding (and I impressed to see in how many ways GPL is getting interpreted) that GPL is meant to protect the customer, not the code owner (author). In other words: I get all the code, so my future is secured. I can do whatever I want, as long as my changes and my code is GPLed as well. This means that MY CUSTOMER will get all my code and my changes:

One of the fundamental requirements of the GPL is that when you distribute object code to users, you must also provide them with a way to get the source.

I understand users here the ones getting my product. In the special case of a web-app that is not going public, the user is my customer that is deploying the web-app, and people using the services provided by the application do not get touched my the GPL.

From the GPL FAQ section:

If I know someone has a copy of a GPL-covered program, can I demand he give me a copy?

No. The GPL gives him permission to make and redistribute copies of the program if he chooses to do so. He also has the right not to redistribute the program, if that is what he chooses.

Another very interesting misunderstanding that comes woth GPL, again quoted from the GPL FAQ:

Does the GPL allow me to sell copies of the program for money?

Yes, the GPL allows everyone to do this. The right to sell copies is part of the definition of free software. Except in one special situation, there is no limit on what price you can charge. (The one exception is the required written offer to provide source code that must accompany binary-only release.)

As far as i understand GPL, I must not make my code public. I can. Expecting users to do this (”This option secures all users the rights to obtain the application’s full source code, modify it, and redistribute it.” – quoted from above) is not true, and I believe it is a violation of GPL.

Only my two cents.