[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GPLv3 comedy unfolding -- The Honest Public License (GPLv3 "is not b

From: Alexander Terekhov
Subject: Re: GPLv3 comedy unfolding -- The Honest Public License (GPLv3 "is not based on trust")
Date: Thu, 17 Aug 2006 21:27:48 +0200

The essence is this: "I would like to see if we can make HPL the 
"Greater GPL", because virality is what made open source what it is 
today. If we relax it, we are toasted."


The Honest Public License

A few weeks ago, I wrote a post about my way of doing dual licensing,
keeping myself honest with the open source community. Today, I would
like to turn the table and ask the community to be honest with itself.

The problem I am addressing is the famous "ASP loophole" of the GPL v2.
Famous because everybody in the industry talks about it, but nobody has
ever done anything about it ;-) The loophole is easy to explain: GPL v2
talks about distribution of software and includes a copyleft clause that
triggers when you distribute your code (that is, everything around the
code becomes GPL as well). In 1991, we used floppies to distribute
software. I still remember booting Linux with the boot and root floppies
and getting the network piece of the OS with N1, N2, etc. Nowadays, the
world of software is seeing a shift to distributing software as a
service (SaaS). I believe 90% of the software will be distributed as
SaaS in the coming years.

What's the ASP loophole? Some people interpret distribution of software
as a service not as distribution of software (because GPL v2 was created
before web services were on the horizon and therefore did not address
them in the license). They believe that they can use open source
software to offer services to the public, without returning anything to
the community. That's taking open source software as free beer. It is
just not being honest with the community, to the people who sweat to
write the code to see someone running away with it and not contributing
anything back. That's totally against the spirit of free software and
the GPL. You have the freedom to use it for yourself or internally in
your organization, but when you distribute it to the public, you have to
give back to the community. It is that simple. That's the spirit of GPL.
That's why open source will take over the world of software: it creates
great software and phenomenal support.

I have always included distribution of software as a service in my
interpretation of the GPL, but I am not a lawyer. And lawyers always
find a way around something, if it is not spelled out in a clear way (I
am talking about my brother, mostly ;-) Therefore, for my interpretation
to be valid, a brief clarification of the GPL v2 is needed.

That's why we created the first draft of the Honest Public License, a
slight modification of GPL v2 with just an additional paragraph (here
you can see the diff between HPL and GPL v2). We took that paragraph
from the latest draft of GPL v3, relaxing it a bit (what's in GPL v3 was
taken from AGPL, but I feel it to be too strong, since it is not based
on trust -> I trust my community, I do not need to force them to open a
service for me to suck up their code). The goal is to make HPL upward
compatible with GPL v3 as much as possible (one note: the FSF is
thinking about the ASP loophole, not just Affero or me ;-) We sent it to
the FSF for review (I would love to keep the preamble, if they allow me
to do it), to lots of open source luminaries (that gave it the thumbs
up) and intend to submit it to the OSI.

The goal of HPL is to keep the community honest with itself. The use of
the name "Honest" is ABSOLUTELY not intended to mean that GPL or any
other licenses are dishonest. It is quite the opposite, actually. But
some people are taking advantage of a GPL legal loophole and are
defeating the spirit of the GPL. HPL is just GPL extended to cover the
distribution of software as a service to the public. It does not take
away any freedom (i.e. you can use it internally in your corporation),
it just covers when someone distributes the code to the public (whether
with a floppy or as a service). It is meant to keep people honest with
their community.

What motivated this new license now? We have a general availability
version of Funambol coming out in September. I already know there are
commercial companies that are live with our code and do not return
anything. More than two years ago, we did something similar, switching
Sync4j from BSD to GPL. There were companies taking our code and running
away with it, without returning anything. One even managed to get public
with software based on our code, and our community never saw a line of
their modifications. Now is no different. On top of this, I followed a
discussion on Matt's blog, which made me think that nobody has ever done
anything about the loophole because large interests are at stake (I
really would love to see the improvements to the Linux file system that
have been made, I could use them for my open source project ;-)

In any case, this is a battle for open source, not against anyone in
particular. It is a fight to keep the spirit of open source alive, more
than anything else. We'll keep the license open for comments for thirty
days (please click on comments below to leave your opinion) and then we
will finalize it. My hope is that HPL one day will disappear because GPL
v3 will supersede it. I plan to work hard to make it happen in the
upcoming months.

posted by Fabrizio at 07:54   

Donald C. Kirker said...

    Very interesting reading.

    I am a little bit confused with the second paragraph and what
distributing software as a service is exactly. I am trying to put
together what it means, but it just doesn't seem like my definition is
correct (maybe it is, but I don't think it is because I think it would
be wrong to do).

    Also, what does this mean for charging for GPL software (mainly fees
for support and the like)?

Fabrizio said...

    Hi Donald,
    distributing software as a service is offering software in ASP,
where you do not physically ship the software to your users.

    The HPL does not have anything to do with charging, it is exactly as
GPL (same answer as to the "how do I charge for GPL software?"
Donald C. Kirker said...

    Ok, I get it now! The customer never actually obtains the software,
it just runs on the "providers" servers. I would guess that this would
be similar to Google Calendar or Spreadsheet?

    I think I see the loophole now. Under the GPL an ASP could host the
software, and not provide the source code, correct? With the HPL, the
ASP would have to provide the source code?
Anonymous said...

    Hi Fabrizio,

    I think I understand where you are coming from with your HPL
proposal; if people run the licensed software as a service, they need to
pass on the license and make the source code available to all users. I'm
curious how this works for Funambol's business model though.

    Funambol has a dual-licensing approach, currently either commercial
or GPL. But in my interpretation, currently under the GPL, and even
under this new HPL license, if a company wanted to run a Funambol server
and charge end-users for access to the service, they could still do this
without paying Funambol any commercial licensing fees, as long as they
are willing to make the source code available to any user that requests
it. Does Funambol plan to make money by hoping people will pay for a
commercial license just to avoid the burden of delivering source code
upon request? Even when customizations are made to use the Funambol
software with a proprietary system, the 'connector' model can be used to
isolate the proprietary system and limit the amount of 'custom' code
that needs to be released to only the code in the 'connector' module. If
connecting to a proprietary system were not possible without making
source code of the proprietary system available, then how can Funambol
release an Exchange connector under GPL without also releasing the
Exchange source code?

    I guess the HPL would protect against people making significant
changes to the Funambol server and making that the core of their
business, without giving the code back to the community. Using the
software for any use, personal or commercial, would still be allowed as
long as changes to the software itself are made available.

    - cj
Fabrizio said...

    Hi cj,
    if people run Funambol as a service and return their changes and
stuff around it (GPL is viral...) to the community, I am totally fine.
Everybody will benefit, including us. That's the spirit of open source.
What bothers me is that some think they can run away with the code and
not return anything to the community. Open source is not free as in free
beer. You have to pay: give back the code.
    Obviously, for people that do not want to give back, the honest dual
licensing applies. It is quid pro quo: you give back code or you give
back cash, that we are going to use to improve the product (and pay for
our kids going to school). There is no free beer.
Fabrizio said...

    Hi Donald,
    you got it perfectly right.

Anonymous said...

    Hi everybody!

    My question: where do you draw the line?

    Case1: I change something deep inside Funambol server

    Case2: I build a new SyncSource

    Case3: I develop a WebApplication using/controling Funambol server
functionality on an unchanged Funambol Server

    Case4: I develop a WebApplication using the data syncd by Funambol

    When should I provide my sourcecode?

    Another question: How do you define "public"?

    Thanks for your comments,
Patrick Ohly said...

    I understand what you are trying to
    achieve and am sympathetic with it. Having said that, I'd also have
    raise my concerns:

    1. The new license must be GPL compatible, i.e. it must be possible
to link GPL libraries against it without requiring special permissions
from the authors of those libraries. The Affero license tried something
similar as you, but that made it GPL incompatible [1]. If the new
license is not GPL-compatible, then this license change will hurt the
open source community considerably. This applies to both the client and
the server side.

    2. The legal status and the GPL compatibility of the new license
must be very clear and should be evaluated by authorities in the field,
ideally the FSF itself. Otherwise there'll always be doubt about the
legality of linking it against GPL - I personally have those doubts and
it will require some very good arguments to convince me otherwise.

    3. A clarification of how the GPL/HPL applies to Java would be
beneficial. If you aggregate different modules on an application server,
does that constitute linking? Probably not. Are custom SyncSources
linked into the Funambol server in the sense of the GPL? I suppose they
are, even if they are installed separately.

Tomasz Mazurek said...

    You've made some nice points about dishonesty of the loophole
abusers, but you haven't stated much arguments from a less moral and
more pragmatic point of view.

    I wrote quite a lengthy article on the subject of Free Software and
SaaS. Especialy the last part titled "Economic impact of the GPL" may be
interesting to you as it stresses the significance of the proper viral
clause effect.

    You can read it at:
Anonymous said...

    The HPL seems illegal !

    The GPL clearly states at the very beginning :

    "Everyone is permitted to copy and distribute verbatim copies of
this license document, but changing it is not allowed."

    In the current legal context this restriction is an unfortunate

    Mister Capobianco openly admits to not having permission to use the
GPL in this way. Here we have a person who has basically stolen the GPL,
added a clause, changed it's name and called it a "new" licence.

    I wonder if he has considered participating in the discussion about
the next generation of FSF licences, even if this means dealing with
people who have different opinions than him, and people who can be on
occasion rather opinionated. He could probably contribute greatly to the
community, as his points seem otherwise valid.

    Another point : I find this constant description of the GPL as
"viral" rather frustrating. First a product may by no means be
"contaminated" by GPL code, it's owners must *choose* to use the GPL. In
a world where states are allowed to dictate how an individual is allowed
to use knowledge, some are grateful that the laws that are used to
control knowledge can also be used to force it to be free. The use of
the GPL is a choice, a political choice. There are other licences, open
source or otherwise which may be used, and are in some cases this is
preferable (the FSF recommends releasing code snippets as Public Domain
for example). In the end the choice is in the hands of the developers,
the GPL doesn't force them into anything, unless they are distributing
somebody else code, in which case they must share.
Fabrizio said...

    Patrick, Markus,
    you touched on the most important aspect of this change for our
product. Where you draw the line?
    I feel we should make sure that HPL is compatible to other OSS
licenses, when it comes to building a SyncSource or a Client. MySQL had
the same problem, so did Hyperic. The solution could be something like
the FLOSS exception of MySQL (check it on their site). We could relax
the license for clients and connectors, to allow different OSS licenses
to work when integrating with our server. That would solve any
incompatibility problem and foster development of even more clients and
connectors (even BSD ones).
    On the definition of "public", I believe it to be clear enough. If
you using internally (yourself or your organization), you are not giving
it to the public. If you are offering an ASP service to the public...
that's easy. It is the same as distribution with GPL: when does it
apply? When you get a CD from your IT manager? When you give it to a


Fabrizio said...

    Hi Tomasz,
    very interesting article.

    I really like the Greater GPL concept. I disagree on Linux not
caring about what Google is doing to it. I am sure the file system
changes are something spectacular, that everyone in the OS community
would like to see (despite Google - for now - does not have an OS
competing with Linux).

    In general, I loved your article. I would like to see if we can make
HPL the "Greater GPL", because virality is what made open source what it
is today. If we relax it, we are toasted.

Fabrizio said...

    Dear anonymous,
    we asked the FSF for permission to change the GPL and they told it
was ok for us to do it, but we should remove the preamble. I can assure
you HPL is not illegal. We are talking to the FSF and waiting for
feedback, which will be incorporated in the next draft. We care about
what the FSF thinks. We want this to be a temporary step forward towards
GPL v3.

    Your comment "In the end the choice is in the hands of the
developers, the GPL doesn't force them into anything, unless they are
distributing somebody else code, in which case they must share." makes
my day. Let me subscribe to it and HPL saying "distributing software
including distributing software as a service" and we are on the same

    BTW, I love opinionated people and discussions. Funambol is a very
large open source project. It is full of opinionated people. If I did
not care about opionions, I would have changed our license, called
Funambol Public License. I did not. I threw the concept out, for
discussion with opinionated people. It is the best way to improve your
ideas in the first place.

    Thanks for contributing to the debate.

Anonymous said...

    Hi everybody!

    Fabrizio, thanks for your comment.

    Actually I think my post was not really interpreted the way I

    To be HONEST: I am a student of computer science, I just started to
get used to Funambol server, I have a new idea for an application based
on Funambol server provided as a service and my primary goal is to make
money with that idea as I have to earn some after graduation.

    From my point of view, many successfull and complex open source
projects are driven by companies, often with dual licensing (see JBoss,
Mysql, Funambol etc.). Thier business models only work because there are
companies out there that don't want to use GPL and pay for not using it.
This business model is not possible for ASP when their service is based
on GPL/HPL, neither is consultancy (at least I haven't seen a
possibility yet).

    To be not missunderstood: I don't want to take free software as free
beer, but I acutally see big problems as I don’t see any other ASP
business model then by user fees or by ads.

    Given I realized my idea, put it on a small server I can afford
starting my business. Anyone can take it, put it on a faster server with
more space for user data and make the money (given my idea works). How
can you solve that dilemma?

    To be true – I don’t know. The only thing I can image (even if I
know this point rises new problems to discuss) is making ASPs to make
their changed code public a certain time after they release a feature to
public. This would give them some possibility to make money / grow their
community but their code gets back to the open source community (not
immediately of course).

    If you really decide to intorduce the HPL, I think it is very very
important to draw the lines in the ASP point with clear concrete
examples in an less abstract view than in the discussions above (please
feel free to refer to my cases posted before) because there is nothing
you can refer to yet. Also and especially if it comes to other services
provided by the same ASP that are somehow connected to Funambol server.

    I like the idea of Open Souce but I just can’t see how the HPL works
together with ASP business models (which is needed if you don’t do it
just for fun or to complete your other services).

    Awaiting your comments,

    BTW: Maybe you should put a link to this discussion on
Patrick Ohly said...


    you replied to my concerns that the HPL might make it illegal to
combine it with GPL libraries saying that "The solution could be
something like the FLOSS exception of MySQL (check it on their site)."

    I had a look and found that this does not address my concerns: MySQL
is pure GPL, with the mentioned FLOSS exception which relaxes the
license to allow linking against libraries that are not GPL and not
already compatible with it.

    The HPL might turn out to be one of those incompatible licenses, so
you would have to ask the MySQL authors to add the HPL to their
exception list, then repeat that with every other GPL library again and

    Let me repeat: it's not your permission which is needed (and which
you certainly would be happy to grant), it is the permission of every
other involved party because their GPL license might not allow linking
against HPL.

    Best regards, Patrick


reply via email to

[Prev in Thread] Current Thread [Next in Thread]