business models for developing GPL Joomla! extensions
Herman Peeren
Joomla! extensions. Thoughts and suggestions welcome. It would be nice
if we could compile a nice list of possibilities.
We just had a nice discussion about Joomla! extensions and GPL here:
http://groups.google.com/group/joomla-dev-general/browse_thread/thread/b0a4b0059cc265e1
And terribly much has been written about it in the past; sometimes
seems like this community is writing more comments than code ;-)
I would like it if in this thread we abstain from discussions about
wether the GPL is necessary for extensions or whether commercial GPL
is possible, but just look if we can just positively describe business
models and give some examples of how to earn a living developing
Joomla! extensions that are distributed under GPL.
Louis Landry
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org
Oli Griffiths
I have a question however, and it relates to the warez discussion from earlier.
If my component has documentation, css, html, js files etc that are not covered by the gpl and are copyrighted to me, if someone takes my component and begins to distribute it does my copyright come into effect. I would have thought it definitely does if they are distributing the extension as their own, copyright infringement comes to mind, but what if they’re just distributing it?
Can I attach additional conditions to the assets within my extension that are not code based to restrict their use?
I have no problem with releasing software as open source, I also have no problem with someone buying my component, and making a better version of it to call their own, I do however have a problem with the ease at which joe bloggs can purchase my extension and email it to his mate jon doe who can immediately install it on his website, meaning I lose revenue because I am unable to enforce the usage of my extension that Ive invested a lot of time into building.
If we cant find a way to protect our investment, then we will only ever be able to offer hosted services where this gpl issue doesn’t apply, which in turn means we arent able to introduce our software into the community.
Does anyone see my viewpoint?
On 24/02/2010 17:29, "Louis Landry" <louis....@joomla.org> wrote:
http://howsoftwareisbuilt.com/2009/12/15/interview-with-james-vasile-software-freedom-law-center/
Great read somewhat on this topic.
I actually don't think the business model has to vary that much from proprietary software vendors. I think it probably means you have to be less lazy as a vendor than if you were a proprietary shop, but that probably works in your favor in the long run anyway.
- Louis
On Wed, Feb 24, 2010 at 4:19 AM, Herman Peeren <herman...@gmail.com> wrote:
I'd like to further investigate business models for developing GPL
Joomla! extensions. Thoughts and suggestions welcome. It would be nice
if we could compile a nice list of possibilities.
We just had a nice discussion about Joomla! extensions and GPL here:
http://groups.google.com/group/joomla-dev-general/browse_thread/thread/b0a4b0059cc265e1
And terribly much has been written about it in the past; sometimes
seems like this community is writing more comments than code ;-)
I would like it if in this thread we abstain from discussions about
wether the GPL is necessary for extensions or whether commercial GPL
is possible, but just look if we can just positively describe business
models and give some examples of how to earn a living developing
Joomla! extensions that are distributed under GPL.
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com <mailto:joomla-dev-general%2Bunsu...@googlegroups.com> .
Louis Landry
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
Oli Griffiths
My concerns regard the ease at which the product can be simply emailed to someone else and they can use it without paying for it.
In by book, if customer A purchases my software off me, a contract exists between me and that customer, and part of the terms of that contract is that the the product is for that customer only. If that customer then goes on to distribute my software onto someone else, they are breaking that contract.
Now, without any restriction routines in the code, that customer can easily distribute that application, whether or not they are breaking copyright or trademarks makes no difference, they can technically still email it to a friend and they can install and use it and are then breaking the terms of sale.
Having restriction routines in the code makes it that bit more difficult for Mr Joe Bloggs (with no coding experience) to email the component to his friend Mr Jon Doe (also with no coding experience).
Now if either party are experienced enough to be able to remove the restriction routines then so be it, they werent going to pay for the software in the first place.
It makes it very difficult for me to justify building on a gpl framework to my boss and being able to release and distribute our own software without any protection for our investment.
On 24/02/2010 18:27, "Louis Landry" <louis....@joomla.org> wrote:
Those things you are referring to could certainly be licensed however you wish so long as they themselves were not somehow derivative of some other GPL'd work -- and in the vast majority of cases I don't think they would be.
If you really care about those "warez sites" and their distribution of your packages (which I really don't think is that big of a deal), then yes you could probably fight that using a separate copyright license on other non-derivative materials in the package. You could also probably explore using trademark as a means of managing that situation.
As someone who sells GPL software and certainly some of it can be found on "warez sites" I have never really had an issue with it. As Alan pointed out in another thread, the people who search for your software on those sites aren't likely to pay you anyway so it isn't really a lost sale. Also, in a lot of cases those aren't the types of customers you really want to support either.
That may not be comforting enough for everyone, but it is something that I have learned by being in this business. If you make a good product, people will want it. If you offer it at a reasonable price and back it up, people will buy it from you.
All of that being said, I certainly see your viewpoint and wish you the best of luck :-)
- Louis
On Wed, Feb 24, 2010 at 11:57 AM, Oli Griffiths <o...@organic-development.com> wrote:
That’s an interesting article Louis, thanks for that.
I have a question however, and it relates to the warez discussion from earlier.
If my component has documentation, css, html, js files etc that are not covered by the gpl and are copyrighted to me, if someone takes my component and begins to distribute it does my copyright come into effect. I would have thought it definitely does if they are distributing the extension as their own, copyright infringement comes to mind, but what if they’re just distributing it?
Can I attach additional conditions to the assets within my extension that are not code based to restrict their use?
I have no problem with releasing software as open source, I also have no problem with someone buying my component, and making a better version of it to call their own, I do however have a problem with the ease at which joe bloggs can purchase my extension and email it to his mate jon doe who can immediately install it on his website, meaning I lose revenue because I am unable to enforce the usage of my extension that Ive invested a lot of time into building.
If we cant find a way to protect our investment, then we will only ever be able to offer hosted services where this gpl issue doesn’t apply, which in turn means we arent able to introduce our software into the community.
Does anyone see my viewpoint?
On 24/02/2010 17:29, "Louis Landry" <louis....@joomla.org <http://louis....@joomla.org> > wrote:
http://howsoftwareisbuilt.com/2009/12/15/interview-with-james-vasile-software-freedom-law-center/
Great read somewhat on this topic.
I actually don't think the business model has to vary that much from proprietary software vendors. I think it probably means you have to be less lazy as a vendor than if you were a proprietary shop, but that probably works in your favor in the long run anyway.
- Louis
On Wed, Feb 24, 2010 at 4:19 AM, Herman Peeren <herman...@gmail.com <http://herman...@gmail.com> > wrote:
I'd like to further investigate business models for developing GPL
Joomla! extensions. Thoughts and suggestions welcome. It would be nice
if we could compile a nice list of possibilities.
We just had a nice discussion about Joomla! extensions and GPL here:
http://groups.google.com/group/joomla-dev-general/browse_thread/thread/b0a4b0059cc265e1
And terribly much has been written about it in the past; sometimes
seems like this community is writing more comments than code ;-)
I would like it if in this thread we abstain from discussions about
wether the GPL is necessary for extensions or whether commercial GPL
is possible, but just look if we can just positively describe business
models and give some examples of how to earn a living developing
Joomla! extensions that are distributed under GPL.
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com <http://joomla-de...@googlegroups.com> .
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com <http://joomla-dev-gene...@googlegroups.com> <mailto:joomla-dev-general%2Bunsu...@googlegroups.com> .
Tobias Jonch
klas....@gmail.com
Dne 24. feb. 2010 22:08 je Tobias Jonch <joe...@gmail.com> napisal:
>
> You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
>
>
> To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
klas....@gmail.com
As user I gladly pay for extensions that fall into 2 categories:
a) low cost wide use extensions (extensions that anone needs..editors, galeries etc.) with short release cycles, fast development and high code quality. it is just cheaper to pay for them than spend time to debug free ones.
b) high end specialized extensions that can't survive in collaborative free model - extensions that are used by so small number of people that they need to be commercial to exist. This time extension needs to have lower price than what it would cost to develop such extension on your own.
Dne 24. feb. 2010 23:09 je klas....@gmail.com napisal:
Andrew Eddie
From the practical side I think there is a distinction we need to
make. There is the question of investigating business models for
selling software and then there are the special considerations for
using the GPL license.
On the first point there are a lot of questions the intrepid developer
must ask of him or herself, or be asked of (I'm not going to address
those that are selling software for casual pocket money). These can
include the following:
Have I seen my accountant? If you have not set your business entity
up correctly to minimise your tax and personal liability, then you are
already sliding down a slippery slope the it doesn't matter what
license you ultimately choose for your software. Once you are serious
about making a business out of software, go see your accountant. It
might cost two or three-thousand dollars for the advice and to set up
the company properly, but it will be money well spent.
Do you have a business plan? (Oops, this is the step I missed). Have
you counted the cost of being in business. Have you looked at price
points and how many units you'd need to sell to actually make a
reasonable living? Have you investigated the saturation of the
extensions in the sector you want to enter (in other words, who are
your competitors and how can you be better)? Have you worked out what
advertising you are going to need (aka, so I'm on the JED, what now)?
Do I have the expertise to run the sales and server infrastructure or
am I going to outsource it?
Have you put all my eggs in the one basket? Does your business plan
allow for seasonal ups and downs? Do I need to stream my income
sources across several different vectors so that if one is in a low
season, the balance keeps my bottom line healthy?
How are you going to support the software? Will you use an annual
subscription, per domain or per site (note, that while you can't
enforce per-install licensing, there is nothing stopping you from
contracting with your customer on a per-domain or per-install basis -
your good customers will honour this)? Will you have open community
support or closed ticket support? Have you set out good terms for
what's included and not included in your support packages (being
helpful is great but if you don't set boundaries you will go crazy, or
broke, or both)?
Have you done all your marketing homework? Have you spent enough on
the site design that is actually going to sell your product (don't
blame the GPL for your business fails if, honestly, your site looks
like a dogs breakfast)? Have you analysed the type of people you
think you are going to attract? Have you worked out where the type of
customers you want "hang out" (what magazines, blogs, etc do they
read)?
Will you have a refund policy? Honestly, some people you really don't
want as customers. You may get the odd person paying for something,
downloading it and keeping it. But you also get people who really
should not be licensed to own a computer. Even if you have a strict
no-refund policy, give the refund anyway because the $50 or $100 bucks
you have to give back is incomparable to the time you are going to
waste trying to pacify your customer. Look out for the phrase "this
isn't really what I expected" - hit the refund button as fast as you
can.
Is this product that augments your site, or is it suited for web site
projects? By that I mean is your product something that's just a
plug-and-play extension (eg, a Comments system), or does it require
another professional or training to actually implement (eg, a CCK)?
For the later, there is a greater burden on producing material that
actually shows how the software should be used. In my experience, the
software "that can do anything" is more difficult to explain. Most
people like being herded down a particular path.
Are you prepared to say no to your customer? Make sure your service
boundaries are clear. Always have the link to the consultants page
handy so that you can say to your customer (even if you know the
answer) "I'm sorry, we don't provide that service, but here's a link
to people that might be able to help you".
When you've got that *all* under control, then it's time to look at
what implications the GPL has on how you sell your software - but in
all honestly, that's nearly at the tip of the mountain to climb. If
you haven't thought about the other things first, you are in for a lot
of pain and grief. The license is the last thing you need to worry
about expect to know that in a GPL world, the playing field is a lot
more level than in other sectors. You have to be very good at what
you do to rise above the pack. But that also means that small fish
can play in a big pond because throwing lots of capital around does
not necessarily guarantee success.
Anyway, those are some thoughts based on my personal mistakes,
successes and experiences. Hope it helps.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Herman Peeren
primary posting here) was continued with 4 postings at:
http://groups.google.com/group/joomla-dev-general/browse_thread/thread/13c6d2fc58555bbc#
That was probably due to replying the e-mail, so a "RE: " was added to
the title.
Thank you all for the contributions so far. I learn a lot from it.
What I realized after I read the interview with James Vasile (the link
Louis provided) is, that * commercial open source extensions are
hardly copied WITHIN an open source community * . That was really an
eye-opener for me! Looking around on the JED or other "normal" Joomla!-
sites I did not find any evidence of the contrary (yet). You always
have to go to a warez-site to find it without paying for it (ok, there
even are pirates "specialised" in Joomla!, but it obviously is warez).
Just like with propriety software. So, if you seriously use or develop
software within an open source community, then to be accepted within
that community, you'll have to comply to the moral values of that
community. That is something even more compelling than legal
procedures.
My short summary so far:
1. there appears to be hardly any difference between business
models for propriety software and open source. Just get your business
based on a solid marketing foundation.
2. if you really have to protect some algorithm or other part of
your software, there are possibilities. Mainly by making your free
software dependent from parts that are hided (e.g. in a webservice).
But it is wise to take a closer look at the parts you want to hide: is
it really worth the trouble.
3. it is hard to stop you legally from not complying to GPL when
making extensions, but being excluded from the distribution channels
of the community is bad business. You'll also get back some protection
by the community for not allowing free copies of your software in the
official distribution channels.
4. for any commercial software (open and closed source): make clear
what the extra's are in comparison free (as in free beer) software. In
a way, you sell the extra's: a better quality, support, updates or
hardware (not with Joomla!, but I know from software for lightshows).
Alan Sparkes
Should post this up as a new section on joomla.org or as a generic article
for anyone in software dev.
Is very relevant to my position at the moment ..so thanks again
Alan
On Thu, 25 Feb 2010 17:26:31 +1000, Andrew Eddie <mamb...@gmail.com>
wrote:
>> Joomla! extensions that are distributed under<script
type="text/javascript"
src="https://www.joomkit.com:2096/3rdparty/roundcube/program/js/tiny_mce/themes/advanced/langs/en.js?s=1240817786"></script>
GPL.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Joomla! General Development" group.
>> To post to this group, send an email to
>> joomla-de...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> joomla-dev-gene...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>>
>>
--
----
Alan Sparkes
Joomkit Ltd
Web Design & Development
Joomla! CMS Consulting
online: www.joomkit.com
contact: in...@joomkit.com
support: sup...@joomkit.com
phone: +44 (0)845 680 9513
mobile: +44 (0)7875189513
Company no :06682016
VAT no: 947906870
Phil E. Taylor
and the GPL world" - I know I would buy a copy! Seriously!
Hannes Papenberg
Soren
component but release it so that it would not work until someone
entered their license number that would be verified against a central
database?
If the user is an experienced developer he would easily be able to
edit the code (as it was open source) and bypass the license check,
but I would not be so worried about that. You could even make it work
for the first 30 days before the license activation came up.
Is this a viable solution?
Best regards,
Soren Beck Jensen
http://www.notwebdesign.com
Herman Peeren
worth the trouble? The way to avoid the license number check will be
on warez-sites even before the modified source will be dropped there.
elin
Establish clear branding with a clear reputation, clear identifiers
and strong brand promise. Pick an identity you can trademark and then
guard it. This is the Red Hat model to a large extent. People buy Red
Hat linux because it's Red Hat Linux even though you can get the same
code for free without even going to a warez site. It's the same reason
that people buy the "brand name" instead of the generic in the grocery
store.
In the Joomla! economy leverage the free opportunities the project
provides whether services like joomlacode or marketing opportunities
such as JED, Joomla! Resources Directory, Joomla! Connect, putting a
link and something about your products in your forum signature and use
the free advertising and page rank that comes as a result of being a
frequent forum poster, make yourself available as a speaker at JUG
meetings, offer to give talks at Joomla! Days.
Sell, sell sell. Great code is not enough. You need to be out there
promoting your product, whether that means frequent blogging. posting
on Twitter, or in general going to where your market is. There are no
short cuts.
Keep in mind that reputation matters incredibly. The best advertising
is a recommendation from someone people trust. So, remember too that
you are the spokesperson for your product so if you personally behave
in a way that is embarrassing by implication you embarrass your
product. Don't get into shouting matches; don't commit voting fraud
on the JED; don't bad mouth competitors.
Most of all, remember that starting a business is incredibly hard
work. Most small businesses fail and they almost all take a while to
reach profitability. Make sure that you understand that those facts
(which have nothing to do with the GPL) mean that you are going to be
working incredibly hard for a long while.
Elin
Alan (instance)
the viewpoint). It seems to me that in order to adopt this viewpoint,
you need to ignore the intent of many who have contributed to the
Joomla core. I'm wary of speaking for others, so I note that this is
my personal opinion.
The work I have done on this project is predicated on the assumption
that it is and will remain GPL, and that the "ecosystem" it fosters
will *respect* that. I think developers who are perfectly happy with
using the Joomla core, then finding schemes to violate that spirit
are, in effect, stealing my work. You are concerned about protecting
your "investment", yet in order to take this kind of position, you
must simultaneously ignore the considerable investment that makes
leveraging your efforts possible.
There are days when I think we should have a commercial license for
Joomla (I'm not suggesting this, I realize that such a suggestion
sparks justifiable indignation). A non-FOSS license would allow the
introduction of proprietary code. The kicker is that based on what I
know about proprietary CMS systems, a fair market price for Joomla is
probably in the US$5,000 to $10,000 range, plus annual maintenance.
This means that your customer's budget for extensions would be reduced
by a considerable amount, which in turn makes your potential customer
base much smaller. Suddenly it's a lot harder to leverage that
investment.
So, those who want to sell closed extensions do so because of a large
market that exists solely because Joomla is open source. They want to
have their cake and eat it too. I find this self-centered (and
somewhat irritating).
We spend far too much time worrying about "bad users" and give "good
users" little credit. Sure one person may pass a copy of the code to
another, but that's going to happen whether or not it's open source. I
think that as long as your pricing is reasonable, a fair number of the
recipients of code through these "unofficial channels" will come back
and buy a license or buy an upgrade. I have examples of these "good
users", some who basically demand that I put a donation facility on my
site so they can contribute to our work on extensions we give away.
I also have no problem with distributing documentation under closed
licenses. Clearly, documentation isn't a derivative work and you can
tackle it any way you like. Some projects only sell documentation in
printed form. Personally I don't think that approach serves them well,
but they have the right to choose their own strategies.
Running a business based on GPL code essentially forces you to focus
on the provision of services that are related to that code. As other
have said, it keeps you on your toes. If your customer service sucks,
you can expect someone who does it better to grab your revenue stream.
If your product maintenance is sub-standard, you are taking a
considerable risk. But, there are many examples of successful
businesses who have embraced the model, adopted a service-oriented
paradigm, and thrived.
As developers, it's extremely difficult to accept that the actual code
is a relatively small part of the value that gets delivered to a
customer, but every successful open source businesses I have seen
proves that although code is necessary, it's not sufficient.
On Feb 24, 12:57 pm, Oli Griffiths <o...@organic-development.com>
wrote:
Jennifer Marriott
purchases a lot of extensions - If someone offers an extension and it
depends on some sort of "phone home" check-in/protection to work, or
it relies on integral portions to be served by the extension creator's
server, it only takes one time for that extension creator to suffer
any sort of infrastructure failure, to collapse their business and
their reputation.
Even though the reality we all know, is that server failure happens
and glitches occur, at the end of the day people (especially people
that develop sites for clients) just can't afford to have client sites
fail in that manner. It is just too risky.
Jenny
Oli Griffiths
Hi Alan,
I see your point, but im not talking about closed source projects. Im all up for keeping stuff open source so it can be modified and derivative works can come along.
I appreciate that the joomla development team has made a significant investment into the core, but they're all aware that its an open source and free cms. And I know that if someone wants to get software for free, they will, regardless of how it may be protected.
My point is, we are working from a commercial point of view, whereas joomla is not a commercial product and as such different rules apply. As working from a commercial pov, there are various ways as pointed out by other members of this discussion to earn a living from gpl software, but not being able to protect our investment in any way other than by offering additional services or on the good will of our customers is a scary prospect for any business trying to make it in the software world.
The software we produce is an asset for us, an asset that we want to be able to protect. We have made significant financial investment into our products, and to just release release our software that anyone can then just pass onto a friend without paying for is just a crazy prospect for us. They may be genuinely good customers who arent going to download stuff off warez sites, but when given the opportunity to aquire something off a mate for free, i know which option alot of people will take. I mean, why do you think the cassette tape was such a winner, not because of the better sound quality off vinyl, or even the ease of use, but the ability to copy your tapes and give them to a friend. Its the same principle. Given the choice of A) take this free bit of software that I should really pay for off my friend, or B) go and pay for it myself, i know what most people will go for.
By no means am I trying to belittle the investment that the core joomla team have invested into the project (which is something that we want to get involved in too and contribute back to the core) but one has to take a different view point when building commercial applications to provide a viable revenue stream for a business, and I dont mean hobbiest lifestyle businesses, but real companies with real employees that have salaries and bills to pay. Without being able to protect our investment, what is there to stop Mr Joe Bloggs who owns Joes IT Business and works next door from buying 1 version of our component and selling it onto his customers! And to any business person, going down that route just seems crazy.
Oli
________________________________________
From: joomla-de...@googlegroups.com [joomla-de...@googlegroups.com] On Behalf Of Alan (instance) [alan.l...@abivia.com]
Sent: 25 February 2010 13:36
To: Joomla! General Development
Subject: Re: business models for developing GPL Joomla! extensions
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
Hannes Papenberg
I disagree with you here. Joomla is not a free-for-all, have-fun hobby
project, but very much commercial. It is a program that was developed by
a group of developers to improve their offerings to customers and thus
gain an advantage in business against others.
I personally might have some noble motives to work on Joomla, but my
main source of energy to work on this are money and the possibility to
learn from others, not that I'm providing you a cool simple software.
You might have invested a lot of time (and money) into your project, but
you are looking at your project as your product that you want to sell.
Look at it as a marketing investment that brings you customers, which
then ask you for modifications that they pay you for.
Hannes
>> If we cant find a way to protect our investment, then we will only ever be able to offer hosted services where this gpl issue doesn�t apply, which in turn means we arent able to introduce our software into the community.
Oli Griffiths
By no means am I saying that joomla is a free-for-all hobby project, Im also not trying to make any enemies here, I am just trying to make a case for independent software retailer to be able to protect their investment.
I think soren hit the nail on the head, one can add restriction routines that stop joe bloggs from distributing the software to anyone that it wasnt originally intended for, and this would probably suffice for the majority of cases. If someone really wants to get your software for free, they will, it being open source makes this easier.
What I am proposing is the ability to restrict the casual user from distributing the software which breaches terms of sale contracts that exist between the vendor and the customer for all the associated material that goes with a component. By just giving it to someone else, they would be violating that contract.
The issue that I have with GPL is that it is designed to protect the end user, not really the developer, except in the case that someone else takes the software, removes the gpl license from it and makes a proprietary product out of it, clearly they are in violation of the gpl license, but i digress.
There are clearly business models that exist for commercial gpl software, what I and others in this discussion are trying to do is explore those and get them out into the open and discussed.
I feel that the GPL doesnt give enough protection to the developer and so am looking at other ways in which our investment can be protected.
Oli
________________________________________
From: joomla-de...@googlegroups.com [joomla-de...@googlegroups.com] On Behalf Of Hannes Papenberg [hack...@googlemail.com]
Sent: 25 February 2010 14:59
To: joomla-de...@googlegroups.com
Hannes
>> If we cant find a way to protect our investment, then we will only ever be able to offer hosted services where this gpl issue doesn’t apply, which in turn means we arent able to introduce our software into the community.
Hannes Papenberg
This is just a friendly discussion between developers on this list. :-)
>>> If we cant find a way to protect our investment, then we will only ever be able to offer hosted services where this gpl issue doesn�t apply, which in turn means we arent able to introduce our software into the community.
Alan (instance)
that do quite well doing just that. What I'm trying to say is that if
you're using GPL code as a base, that's the game you're in, like it or
not.
To answer your specific question, what stops some Joe across the road
from taking your code and building a business around it is being
better at it. If a one man shop can get up to speed on your code and
offer better support and documentation, then I suggest you have a
problem with the market you're targeting. If your product is
sufficiently complex, then Joe is going to have a heck of a time
keeping up on support, customer service, bug fixes (he can wait for
your updates, but what the hell does he tell the customer between now
and then?), new features, user forums, and so on.
Basically it won't be long before Joe falls flat on his face. Savvy
customers will look at the code, see your copyright notice, check out
your site, and become customers. If he's modified the copyrights, you
have legal recourse. The net is a big place, and people will start
complaining about his support in places he can't control. Google will
find the users who figured it out, and "Turns out Joe's code was
written by, and is supported by Oli" will show up prominently (for
example on JED).
The challenge with GPL code is you can't rest on your laurels... if
you want to milk the market for revenue and then not follow up on
support and service, you can expect someone else to make a go of it.
Andrew's advice about having multiple revenue vectors was also bang
on.
If you are intent on finding ways to "protect" your code, I
respectfully suggest that you've picked a platform with the wrong
license. You say that the GPL protects end users, but I see it as
protecting the developers. You can use our code, but you need to
release your work under the same terms. Using our work to build your
business without respecting our intent is merely trying to gain an
advantage that isn't shared by those who follow the license. The GPL,
with all it's quirks, and nuances of interpretation, insures that all
developers are on a level playing field. Tilting it is not an option.
Alan (instance)
issue, it's nothing personal. I've been on the proprietary side of
this discussion, and it took me a while to come around as well. It's a
big paradigm shift to consider you code as something other than an
asset to be protected.
On Feb 25, 11:24 am, Hannes Papenberg <hackwa...@googlemail.com>
wrote:
Mike McGinn
give the code away
sell support and access to updates released before the general public release
sell your advanced users/developers manual in paper format or in some
compliled format.
sell your templates
sell your content streams
sell in-person training
sell time for making custom modifications
sell hosting for the code to sit on
sell domain names for the hosting
sell internet access
There are more income vectors in play but this is what I have viewed
so far in the last 15 years of using Joomla and other open source web
apps.
Are there any more income vectors that any of you have witnessed?
> --
> You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
> To post to this group, send an email to joomla-de...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>
>
--
Michael Scott McGinn
http://www.waptug.org
http://mycmshosting.peoplelex.com
Herman Peeren
> Are there any more income vectors that any of you have witnessed?
Yes:
- sell an extension! It works, if the extension is worth the money.
Or were you referring to this in your first point "give the code
away"? It is the same as "sell your templates" (that in some open
source projects are seen as extensions).
- sell general training. Maybe also: write a book or put something
on Lynda.com (don't know what provision you get, if any)
- ask a voluntary donation (I have sometimes read about it doesn't
work very, but maybe people have other experiences; I'll ask around a
bit)
greg keys
Currently all of our extensions are 100% commercial opensource. It would seem the main advantage of releasing our code as
GPL would be the advertising afforded by the size of the community.
My question to those of you out there who have been on both sides of the table both commercial and GPL is, did you see your profits increase when you went GPL, or did they only slightly increase? I understand that a lot of this has to do with the structure of your business and the quality of your product, I'm just curious that when both of those things are taken care of, do you actually wonder why you never switched sooner, or are you considering switching back?
Greg Keys
www.Socialables.com
(971) Tec-Webs or 971-832-9327
--
Andrew Eddie
(JXtended) started out by thinking the best approach was to lock down
the documentation to only registered subscribers of support once they
made a purchase. The trouble with that was the documentation is
actually a really good marketing tool (for a third-party extension)
and, quite frankly, hiding documentation behind a login means Google
can't index it. So, we decided to push all the docs into the open so
that people could make a better informed decision before they buy. We
also had a lot of questions about whether we had good documentation
and with those docs behind a login, they only had our word that it was
good or otherwise. To cut a long story short, we saw no negative
impact (short or long term) bringing the product docs out into the
open. I think it's especially important to have these visible
particularly when it's not feasible to provide trial versions with the
GPL.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
> --
> You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
> To post to this group, send an email to joomla-de...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
Herman Peeren
- while being paid by your customers for coding custom solutions,
base your work on a more general solution that can be given to the
community.
- find some customers that are willing to pay you for making an
extension and let them use the code before it is released to the
general public.
The translation extension Nooku Content is using some combination of
those 2: a framework (Nooku Framework) is being developed with help of
an active community and the translation component is based on that
framework.
Herman Peeren
anything in "commercial GPL"? As I am starting to see the
possibilities of just that, can we discuss your insights on that
point? Could be interesting.
greg keys
I don't specifically oppose any of them. When we opened for business, like everyone else in our shoes
we wanted to protect our investment, which basically boils down to our pocketbook, isn't that what this is all really about anyway
Making money / A living?
I just want to know which way is going to make us the most money. It may sound selfish but in reality it's just a
simple business question that everyone in our shoes is asking themselves.
When I stated " Currently all of our extensions are 100% commercial open-source. It would seem the main advantage of releasing our code as
GPL would be the advertising afforded by the size of the community." I never meant to imply we oppose commercial GPL, quite the contrary
we are considering it and wondering if it would be beneficial.
Our code is all open-source because we want others to learn from what we do and trust our code is safe, however we don't want someone taking it and re-releasing it as their own, making a profit off our hard work. Which is why it's commercial.
We believe If someone wants to make a profit they need to use what they learn and do the work themselves.
At the same time it seems the community overall is self policing and we could release our extensions as Commercial GPL without the risk of loosing everything.
Can someone out there assure us with their experience that, switching made all the difference when comes down to licensing. Or is it the same either way?
In Summary:
Do you make more money off Commercial GPL products than you would trying to control the code yourself with restrictions to prevent theft?
--
Andrew Eddie
>
> In Summary:
> Do you make more money off Commercial GPL products than you would trying to
> control the code yourself with restrictions to prevent theft?
I would hate to even contemplate my budget if I where to add line
items for adding copy protection and then policy it. However, the
cost of not being able to list on the JED would be significant to my
bottom line. The traffic (and therefore sales) from the JED if you
are in the top of your categories is significant.
I've certainly not had any problem with anyone trying to fork any of
my commercial work. The only serious cases I've heard of is where a
former employee/volunteer has made off with code and done the dirty on
their former employer. I'm sure cases do exist but my understanding
is they are rare and the anti-forking rules on the JED are very fair
and reasonable.
greg keys
commercial GPL licensing structure.
Andrew Eddie
That's great. If you need to pick my brain at a more detailed level,
you know my email. Happy to talk to people about this stuff.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Oli Griffiths
Correct me if I'm wrong by making an extension gpl with no usage
restrictions are you not therefore cutting off one revenue stream
which is repeat business, you can't resell the same product to the
same person as they can just install it on any site they want.
?
Andrew Eddie
The GPL covers the distribution of the source code, but I think there
are possibilities that you can look at having your customers enter
into service contracts with you that can allow you to charge on a more
granular basis. There would be no problem at all with charging for
each site that you want end-user support for - that would be fairly
easy. There's also nothing to stop you from "asking" for a per-site
charge - as long as you make the charge reasonable and of value,
people will generally pay it.
That is another pretty interesting point as well - setting your price
point to attract the type of customer you want :)
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Herman Peeren
important from a business point of view, I'd say. I thought MageBridge
(by Yireo) is doing that; I'll ask them how.
The Forking-rules of the JED, very well that you mention it Andrew,
for they are an important reason why this system works: if you want to
use the main distribution channels of this community you'll have to
comply to the rules of this community. Those rules are also protecting
your product! For me that is one of the most important things I
learned from this discussion.
The Forking-rules (or anti-forking rules as Andrew called them) are
part of the TOS (terms of service) of the JED: http://extensions.joomla.org/tos
************************
Extensions and Forks
An extension that is derived from another extension will only be
listed under the following conditions:
1. The original extension license allows this, or the current
developer of the original extension has specifically authorized it if
the license does not.
2. The extension is renamed, so it is very clear that this is a
separate project.
3. A new version scheme, so it is clear that this is a separate
project.
4. Extension will be actively developed on.
If the original extension is listed on the Joomla! Extensions
Directory:
1. The fork will only be considered for listing if the original
extension has been listed for more than 3 months.
2. It will only be allowed when the extension has been changed by
adding new functionality.The amount of functionality to be added is
determined on a case by case basis and is at the sole discretion of
the Joomla! Extensions Directory team and Open Source matters.
3. Development of the extension follows it's own path, and will not
be based on the original extension after listing.
************************
Using pragmatic arguments, showing you can build a good business using
the JED (and thereby complying to the rule that your extension has to
be GPL) appears to be more fruitful than all the endless legal
discussions where we will never agree upon. It is very understandable
that developers are anxious to loose more than they gain by putting
their stuff in the JED (and thus complying to the GPL), but if we can
show the opposite, then maybe some devs that are on the sideline now
will join in too adding even more quality to the JED.
BTW, in this thread we have mentioned a "phone home" principle as a
means of protection, but the JED-TOS clearly excludes this
possibility: "Extensions may not 'call home' to function. Extensions
are allowed to 'call home' to do version checks and other 'call homes'
will be evaulated on a case by case basis. Acceptance of a method and/
or function is at the sole discretion of the Joomla! Extensions
Directory team and Open Source Matters."
Oli Griffiths
additional functionality or content that is fed from a remote server?
I see the latter still complying with the jed tos, but the first not?
On 26 Feb 2010, at 09:20, "Herman Peeren" <herman...@gmail.com>
wrote:
Herman Peeren
wrote:
> Is there a difference between phone home software and offering
> additional functionality or content that is fed from a remote server?
>
> I see the latter still complying with the jed tos, but the first not?
Yes: if the extension cannot function without the external service, as
is proposed in this thread to protect your application, then it is not
in line with the TOS. So: if you cannot get a functioning copy of the
software without using a (paid) webservice, you will not be listed in
the JED. It is seen as circumventing the GPL-policy.
Using remote services to get content is something else: you can e.g.
check the latest version number somewhere so updating-software knows
if there is a newer version (this is e.g. used in Sam's JUpdateMan).
When you use Google Maps for instance, you also use external
information.
The border between the two can be very vague; a broad gray area. That
is probably why it is stated the way it is: to evaluate on a case by
case basis with what *intention* the phone home software is used. You
can easily ask yourself: do you use it to "protect" something that you
are anxious to license under GPL or are you referring to external
sources of information? I can think of many cases where the
distinction is not clear at all. It is easier to honestly ask yourself
what your intention is (and if that is valid).
Herman Peeren
API / webservices is also, that you can make it available for multiple
platforms: e.g. to be used in Joomla!, Drupal, DotNetNuke, whatever.
Such a general webservice can also never be seen as an extension of
Joomla!.
Oli Griffiths
may not stop the applcation being usable if they are unavailable
doesn't breach the gpl. Is this therefore within the constraints of
the gpl or the jed tos?
On 26 Feb 2010, at 10:22, "Herman Peeren" <herman...@gmail.com>
wrote:
Herman Peeren
set its own rules, based on our perception of what the use of the GPL
is. It is not useful to discuss it in purely legal terms, I think, for
that is an endless swamp and we will never agree. We, in this case OSM
and the JED-managers, set the rules of the game. If it is an
extension of the GPL, then it is so. Other communities have their own
variations (like in Wordpress-themes more elements have to comply to
GPL than in Joomla!-templates).
On Feb 26, 12:08 pm, Oli Griffiths <o...@organic-development.com>
wrote:
Herman Peeren
interpretation of the GPL by the Joomla!-project I respect the
implementation of their view. More: I begin to understand and value
that view. For me it is fruitful to decouple the legal talking about
the GPL from the philosophy behind it and the practical way to
implement the principles.
Oli Griffiths
implementing it's interpretation of the gpl and how it affects the
joomla project/community.
For example, the gpl doesn't restrict you from adding code to restrict
the usage of software (correct me if I'm wrong) however being open
source allows the savvy users to remove those restrictions and this
doesn't violate the license.
The jed tos however does restrict this kind of thing, which directly
limits a commercial app developer from enforcing usage and as such
doesn't allow for reselling per site licences and repeat business from
an existing customer, other than just asking them to purchase
additional licences, it can't be enforced.
For a commercial app developer this is a real concern as it's an
important revenue stream.
On 26 Feb 2010, at 11:41, "Herman Peeren" <herman...@gmail.com>
wrote:
Alan (instance)
the same opinion. Then I had the opportunity to sit at the same table
with James Vasile for lunch. Which means I got to ask him about *his*
interpretation, and since he's counsel for OSM, his interpretation is
Joomla's interpretation.
The core of his argument was that, although this interpretation had
not been settled by a judge, there were a large number of cases where
the defendant (the person or company with a more liberal
interpretation) settled in favour of the group who filed suit under
the GPL. These settlements were usually reached just before the case
actually went to trial. Basically, a defendant only settles at that
point when they have an expectation of losing. Vasile observed that
when a number of defendants settle in this way, their combined weight
becomes equivalent to that of an actual court decision. It should also
be noted that many of these defendants were large corporations, which
means they expected to lose despite being able to throw an army of
legal professionals at the problem.
I believe this argument. Since that time, there have been quite a
large number of cases settled, both in the US and in Europe, that
continue to strengthen it. Most recently, the JMRI decision (http://
ostatic.com/blog/the-model-train-software-brouhaha-ends-open-source-
wins) sets a precedent for damages from copyright infringement.
The inevitable conclusion is, like it or not, the "Joomla
interpretation" is the legally accepted interpretation. I confess that
I still have a little "proprietary blood" in my system, and from time
to time I would love to veer from this interpretation, but it seems
clear to me that if I did, I would be in an indefensible position.
Herman Peeren
one) you can read some very valuable arguments. Not the legal
arguments, which can continue forever and ever and ever, without
coming anywhere. What attracts me is some thinking about the
philosophy of the GPL (or the "belief" in it, as some would say) and
how we can convince devs that it actually *works*. A more *pragmatic*
approach thus. Just like we do in this thread: if we abstain from a
discussion whether the GPL is necessary and how it should be
interpreted, can we build a sound business?
One of the necessary conditions for the principles of the GPL to
function well, is that everybody in the group is complying. That is
the rationale behind the whole witch-hunt (sorry, don't mean it so
harsh, but it is how some feel it). Every community is free to set
their own rules to protect those values. I don't think it is all legal
interpretation, it is also a broader implementation of the principles
behind it.
So, I wonder, what would happen if you would license some software
under GPL. What would be the profits and losses, what the bottom line.
What is your worst case scenario. And what are the alternatives (and
their bottom line)?
Oli Griffiths
developers managing the companies ivesting the time and money into
building software to license as gpl.
Not being able to volume resell the same product to the same customer
is a big cause for concern. If your product sales were a person, it's
like cutting off a leg!
I thought the the spirit if gpl is that the source code is available,
users can modify it to fit their implemetation, learn from it and
build new things from it.
I don't see how limiting the usage of the software to a per site
license stops this.
?
On 26 Feb 2010, at 12:53, "Herman Peeren" <herman...@gmail.com>
wrote:
Sam Moffatt
are competent in a reasonable swag of languages (Perl, Python, C/C++,
Bash), when was the last time you sat down looked over the source code
of your applications? The majority of the time people don't bother and
this is the thing. The person who is spending time to work out where
in your code you're enforcing protections either a) is cheap and
doesn't value your time or b) your product is so expensive that it is
worth that time. In either case it isn't a lost sale. The majority of
people aren't out to screw people over, they're out to find something
that works for their site and does what it needs. If that is a
non-commercial extension then great - no up front cost. If it is a
commercial extension then that is some form of costing model and that
is life. A large portion of the Joomla! community aren't developers by
definition. They don't like code which is why they're using a CMS.
They're using it in some cases because someone else told them that it
is the right thing to do.
So you're welcome to write that it is disabled per site in the code
and that people have to activate it. The customers you want will do
the right thing. The ones you don't probably won't. They are going to
be trouble regardless. Putting the code in is fine, what isn't fine is
trying to stop someone removing it.
The other alternatives (online activation/required web service) are
fraught with danger. Even large companies have shown this to be flawed
and not what consumers want because at the end of the day we forget
why we're doing this: to make a consumers life easier/better/more
productive than it was before. Consumers like being treated well, they
like being shown trust and faith. Someone on Twitter compared the
steps a pirate movie takes to go from putting the DVD in and watching
to a legitimate DVD. Suffice to say the one step pirate operation is a
much better proposition than 10 steps of ads, copyright warnings, more
ads and more copyright warnings. What is the product you personally
want? The one with annoying copy protection or the one with a bit of
trust?
Sam Moffatt
http://pasamio.id.au
Jennifer Marriott
The freedom to run the software.
The freedom to study the software.
The freedom to modify the software.
The freedom to share the software.
Limiting usage would be contrary to these freedoms.
As I said before I was speaking as a consumer of extensions. I buy
them for myself and my clients. When I spoke of "phone home" it was
in reference to the type of phoning home the discussion was indicating
- the extension has to phone home to actually work. I was not talking
about extensions that do a version check to indicate whether an
extension is up to date. I was speaking of personal experience when I
stated that I would never again purchase an extension that has to
phone home to work. It is too risky to base my reputation on the
basis of someone else making sure their hosting bill is paid, or that
they haven't exceeded their bandwidth limit. That lesson was most
definitely learned the hard way. I will not repeat that mistake, and
I will at every possible opportunity advise others to never make that
mistake.
I buy a lot of subscriptions to either groups of extensions or to
individual extensions. This makes me a repeat customer because I
follow the development of the extensions I subscribe to, and when an
update is released, I may have let my subscription lapse, and then
renew my subscription. There are all sorts of ways to get repeat
business from a consumer, that do not involve restricting the
customer's freedoms that the gpl offers. Offering quality products,
and quality customer service is the number one way to get repeat
business. Building a quality relationship of trust with your
customers so that they don't just buy one of your extensions, but all
of them - that is a way to guarantee repeat sales from one customer.
If you only have one extension, have the extension be the very best of
its kind, and with a subscription model you will have people coming
back every time to renew. Offer high quality customer support, or
customization for a fee, and you will have repeat business from the
same customer.
Again I am just speaking from my own personal experience.
On Feb 26, 8:09 am, Oli Griffiths <o...@organic-development.com>
wrote:
> I think isn't not the developers that need convincing, it's the non
> developers managing the companies ivesting the time and money into
> building software to license as gpl.
>
> Not being able to volume resell the same product to the same customer
> is a big cause for concern. If your product sales were a person, it's
> like cutting off a leg!
>
> I thought the the spirit if gpl is that the source code is available,
> users can modify it to fit their implemetation, learn from it and
> build new things from it.
>
> I don't see how limiting the usage of the software to a per site
> license stops this.
>
> ?
>
> On 26 Feb 2010, at 12:53, "Herman Peeren" <herman.pee...@gmail.com>
Oli Griffiths
If an extension states that you should buy a new copy for each website that you want to use it on, would you even though the one you have can just be installed without any problems.
Im not saying that anyone should not have the freedom to change, study, modify etc, but to share the extension that has other non-gpl materials in it would break the terms of sale set out when you purchase the software. You would be agreeing to use the software on one domain as part of the terms of sale, thats covers the gpl and the non-gpl parts of the extension.
All im saying is that given the choice of either a) purchase the software once and reuse it on as many domains as you want, vs. b) buy the software for each domain you wish to use it on and having no way to enforce this, i know which most people would choose. For the same reason why most people dont click the donate button on free software sites, there will be the odd few but the majority wont bother.
________________________________________
From: joomla-de...@googlegroups.com [joomla-de...@googlegroups.com] On Behalf Of Jennifer Marriott [marpomu...@gmail.com]
Sent: 26 February 2010 15:57
To: Joomla! General Development
Subject: Re: business models for developing GPL Joomla! extensions
greg keys
Suppose you are charging to distribute your GPL software and you have a particular version scheme. 1.0, 2.0, 3.0 etc....
Does it not it comply with GPL if you were to charge for the different versions. ie version 2.0 has significant feature enhancements or changes
so you simply charge for the update. That would seem like a very reasonable and fair means to continue your revenue stream
while at the same time re-warding those developers who continue to develop their product and in a way forcing people to continue to shop
at your store. After all the point has been made that the original developer is protected by the community and joomla.
So one business model could be. You buy a version 1.0 of our product for X amount all releases within your version are free for you after purchasing
the original ( I whole heatedly believe in giving as part of all business models, it encourages word of mouth sales) so version 1.01 1.02 1.03 etc... So basically they would be getting bug fixes and minor changes for free.
However you could change the version when you introduce significant changes or features to the product, it would then become version 2.0 and your customers would have to pay to obtain this update....
Would that not be a fair model that complies with the Commercial GPL license?
Herman Peeren
- I have a choice to develop Joomla!-extensions or not.
- If I choose Joomla! as my platform, I have a choice if I want to
be listed in the JED or not. If so, my extension must be GPL-licensed
and maybe I have to comply to some additional rules (made to avoid
closing parts of my sourcecode in other ways).
These are the rules of the game, the cards have been shuffled,
discussions has been there extensively in the past; that horse is
dead, no use beating it again (I say this to myself in the first
place, for time and again that little voice pops up saying "yes, but
wouldn't it be better if..." and "it is not the right interpretation
or choice..."; ssssst! Useless, done, over and out).
It is not completely clear if, assumed I want to be listed in the JED,
it is allowed to demand as part of my sale that installation is
limited to one website. I think it will *not* be accepted for 1) the
JED-TOS says "Additional restrictions may not be placed on top of the
GPL" and 2) it is not in the spirit of GPL. But this point can be
further investigated (known cases?) and clarified. If it is allowed
then I have to take into account if implementing such a restriction is
worth the trouble: how much extra customers would such a restriction
give me and on the other side how much customers (like Jennifer) would
it cost plus the costs of the time it takes to control my customers,
argue with them if I find they have installed extra copies etc. I find
it hard to imagine, that balance would be positive. If I would not
have to put much energy in things like that, I would have much more
time for support and further development, hence a better product and
more and more satisfied customers.
The choice whether or not I want to be listed in the JED (and use GPL)
could theoretically be made on ideological grounds, but then maybe the
first choice, to develop for the Joomla!-platform, could better be re-
considered. So then it is a matter of calculating (and maybe some
market-research): how much more extensions do I think to sell in the
Joomlasphere if I comply to the rules of this community (GPL etc.) or
not. My rough estimation of the effect of being in the JED or not on
sales is a factor 4 at least; I even think in the direction of a
factor 8. Marketing research and experience can precisize this
estimation. Take into account, that I will get trouble presenting
myrself as Joomla! extension-provider, like OSM-trouble with the name
of my website, extension or logo, if I choose not to comply to GPL
(and that takes time and maybe legal costs). Suppose I will not be
able to get repeated revenues from the same customer for the same
version of my Great Software... well, then I make the Extended
Magnificent Software part 2 (like Greg just described) and everybody
comes back again, because they allready were so satisfied with edition
0.8; not even for their next website, but even for the one they
allready bought my earlier version for. Because I don't have to spend
much time to provide copy protection and other controll.
If, in spite of how well I did this all, my software would be forked
an put in the JED not complying the forking rules, it won't be too
much trouble pointing out to the JED-managers what has happened and,
wow, what a service, they will take care of that further.
Oli Griffiths
The problem is this information isn't widely available and it would be
very useful for developers and non developers who may be financing a
project to take it into consideration.
My main concern as a developer and a businessman is about the repeat
volume sales. There are alot of companies that use joomla to build
websites for their customers. By not being able to do per domain sales
they are able to purchase 1 copy and use it time and again at no extra
cost. As a business person if you are presented with the choice of a)
purchase this product tat you are able to reuse as often as you like
or b) purhase this software that you have to pay for each time, what
would you choose? There is a clear winner from a business perspective.
If the gpl doesn't forbid per use licensing, that being you have to
purchase a new copy of the app every time you want to use it on a new
install, then I find it rather strange that this is enforced in the
jed tos as it's is particuarlaly unfriendly towards commercial
applications where that repeat business can make up a significant
proportion of your revenue.
On 26 Feb 2010, at 20:16, "Herman Peeren" <herman...@gmail.com>
wrote:
greg keys
What I would like to do is find the happy medium between the two which I think I may have with the versioning sales.
Unfortunately that model really only works if the developer intends to keep developing, it does not work for the business
who wants to develop something once and move on to the next money maker. Because after 3 months or whatever
if the original developer hasn't done anything with their product that's when someone else can swoop in and steal that
revenue stream using the original developers foundation.
greg keys
from stealing their work like a bunch of sharks going after a piece of meat.
Herman Peeren
wasting your time on questions like if it could not be better done in
a different way. I doubt if the "extra" restriction in the JED-TOS is
really "extra" or an implication (or interpretation for my part) of
the GPL. But it is not really important for it won't change anything:
because the rules are set by now it is only important to get it clear
what the exact rules are. And then play the game.
Oli Griffiths
I don't see how limiting the revenue streams for commercial deelipers
who wish to still release open source really benefits anyone but the
person not willing to pay for repeat licenses. It certainly doesn't
benefit the developers as they get less revenue, it doesn't help the
community as if the developers have less to play with they can't
devote as much time to the project and it doesn't benefit the
application because it won't grow as much as it could.
The response that I received from the chap at gnu.org said that it was
ok to put in per usage restrictions but that being open source someone
can legitemately remove them
On 26 Feb 2010, at 20:51, "Herman Peeren" <herman...@gmail.com>
wrote:
Andrew Eddie
There is no problem at all with charging for upgrades/updates etc.
Making minor (bug fix) updates free and major versions with new
features an extra cost to upgrade is a reasonable strategy. The GPL
is agnostic towards this approach.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Herman Peeren
chance, counting the days away...
But I have not seen much evidence of that in the JED yet, at least not
with popular software (but maybe you know counter-examples). Take
DocMan for instance. For a long time there was no native 1.5 version.
People asked for it, so it was evident there was a market. But no
sharks took that pray (or it was not noticed). The original developers
took it up and now you can buy it, for the price of just about 3
Belgium beers. Do you expect any sharks around that in the coming
months? No, they have an exellent reputation and I don't think much
developers in the Joomlasphere will touch their software.
Maybe the image of sharks lurking around for their pray comes from the
competitive attitude in the "normal" world. Maybe our model is more
about cooperation and doing a collective effort from which everybody
wins ("you may say I'm a dreamer... but I'm not the only one. Maybe
some day you'll join us... and the world will be as one" - John
Lennon).
Andrew Eddie
>
> If the gpl doesn't forbid per use licensing, that being you have to
> purchase a new copy of the app every time you want to use it on a new
> install, then I find it rather strange that this is enforced in the
> jed tos as it's is particuarlaly unfriendly towards commercial
> applications where that repeat business can make up a significant
> proportion of your revenue.
Hi Oli
Can you explain that paragraph a bit more. I don't understand what
you mean by "enforced in the jed tos". Thanks.
Herman Peeren
> Hi Oli
> Can you explain that paragraph a bit more. I don't understand what
> you mean by "enforced in the jed tos". Thanks.
I see it as a comment on my remark:
----------------------------------------------------
It is not completely clear if, assumed I want to be listed in the JED,
it is allowed to demand as part of my sale that installation is
limited to one website. I think it will *not* be accepted for 1) the
JED-TOS says "Additional restrictions may not be placed on top of the
GPL" and 2) it is not in the spirit of GPL. But this point can be
further investigated (known cases?) and clarified.
-----------------------------------------------------
as opposed to what the GNU-guy told him before.
Louis Landry
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
Oli Griffiths
On 26 Feb 2010, at 21:59, "Herman Peeren" <herman...@gmail.com>
wrote:
Andrew Eddie
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Airton Torres
developing extensions for Joomla!.
Just to throw some ideas on how you can profit from a full GPL compliant
business model, I have stumbled upon a very nice idea Peter Van Westen
(NoNumber) is using for his extensions. He develops and offers his
extensions for free, but he also created packages of codes for the
commercial use of his extensions.
What he does, he asks for the developers who create sites for their clients
using his extensions to purchase a code pack and charge their clients for
it. It's not mandatory and the only benefit the buyer gets from purchasing
the codes is that some text in the admin part of the extension gets changed
from "This is a non commercial version..." to "This is a commercial
version....". He makes a really good point on that and, from the comments on
the page I linked bellow he has had some good return from that approach.
Here is NoNumber's page: http://www.nonumber.nl/why-these-codes
Comments?
Regards,
Airton Torres
----- Original Message -----
From: "Andrew Eddie" <mamb...@gmail.com>
To: <joomla-de...@googlegroups.com>
Sent: Friday, February 26, 2010 7:32 PM
Subject: Re: business models for developing GPL Joomla! extensions
Oli Griffiths
greg keys
There is a lot which could be said about that system, while I like it and may use it on smaller
extensions, I can't see that as one of the better ways to secure an income stream to promote
high quality development.
Anytime you rely on someone to buy a license because it's the right thing to do or because it will promote development,
I believe they are more likely to keep the money in their wallet for the guy who gives them no choice but to buy it.
People are very "Now" Oriented. Most could care less about the future development they just want what they
want "Now" if they have to pay for it, those who need it will bite the bullet and pay, that is what helps development
the most in my opinion leave them little choice.
It can be hard to be nice in business sometimes. It was implied earlier, in business you have to learn how to do the hard stuff
sometime like saying "No" I think a solid income stream also depends on the learning to say " You Must Pay for this" rather
than "Please Pay for this, if you want me to survive"
Oli Griffiths
This echoes my point of the volume resell thing. Given the choice of buy it once use it as many times as you want, vs buy it every time you want to use it, most people will opt for the first option, its a no brainer for most people, same reason why most people don’t click the donate button on free app sites, wallet closed > wallet open.
On 26/02/2010 23:23, "greg keys" <greg...@gmail.com> wrote:
@Airton
There is a lot which could be said about that system, while I like it and may use it on smaller
extensions, I can't see that as one of the better ways to secure an income stream to promote
high quality development.
Anytime you rely on someone to buy a license because it's the right thing to do or because it will promote development,
I believe they are more likely to keep the money in their wallet for the guy who gives them no choice but to buy it.
People are very "Now" Oriented. Most could care less about the future development they just want what they
want "Now" if they have to pay for it, those who need it will bite the bullet and pay, that is what helps development
the most in my opinion leave them little choice.
It can be hard to be nice in business sometimes. It was implied earlier, in business you have to learn how to do the hard stuff
sometime like saying "No" I think a solid income stream also depends on the learning to say " You Must Pay for this" rather
than "Please Pay for this, if you want me to survive"
Greg Keys
>> .
>> For more options, visit this group at
http://groups.google.com/group/joomla-dev-general?hl=en-GB
>> .
>>
>
> --
> You received this message because you are subscribed to the Google Groups
"Joomla! General Development" group.
> To post to this group, send an email to
joomla-de...@googlegroups.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
http://groups.google.com/group/joomla-dev-general?hl=en-GB.
>
>
--
You received this message because you are subscribed to the Google Groups
"Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/joomla-dev-general?hl=en-GB.
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com <mailto:joomla-dev-general%2Bunsu...@googlegroups.com> .
greg keys
since we know joomla won't be changing that anytime soon :)
Perhaps we should start a new topic, Commercial GPL business Models.
to get an idea of different means to accomplish that.
Greg Keys
www.Socialables.com
(971) Tec-Webs or 971-832-9327
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
Andrew Eddie
and we can work out what his/her real fears are :) As Louis says, the
end-user doesn't really care about what the license is, and those that
do care are most likely ideologically sympathetic to the GPL.
I'd suggest you play with some spreadsheets and do projections based
on your current figures and see how different strategies might be
affected. These would include:
* Charging for version increment
* Charging for support per site
* Model what happens if you go to selling units per customer versus
units per site, taking into account the increased recognition and
traffic from the JED
You also have to look at the cost of maintaining your infrastructure
to support per-site licensing - that's not insignificant. At the end
of the day, there are many factors to take into account. Your
business partners also has to realise that staying with commercially
locked down code is not necessarily the safest or best option as well.
For example, if you are worried about piracy, but spend absolutely
nothing on policing, then what are you worried about? If you do start
policing, your unit price needs to go up, therefore sales probably are
negatively affected. And going GPL doesn't mean you have to stick
with your price point. Put the price up a bit to cover the lost sales
from doing the per-site thing - but then, you traffic is up from being
on the JED and that just might even things out.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Andrew Eddie
>
> Perhaps we should start a new topic, Commercial GPL business Models.
> to get an idea of different means to accomplish that.
I think that's the intention of this thread :) However, what someone
could do is start to process all the thoughts and options on the docs
wiki - that could be useful.
elin
challenging. :)
Overall I think a lot of this discussion is missing the point. If you
are talking about selling plug and play extensions, the business you
are talking about is a retail business. Like all retailers, sure you
have to worry about "shrinkage" but it's also a part of the cost of
doing business that you need to build into your margins. Except in
this case, the cost of someone sharing a copy of something you've sold
them is the opportunity cost; it's not like you've lost a physical jar
of peanut butter that you now can't sell to someone else. Of course
you don't want to let it get out of control, but that's where you do
the strategies like holding back support and documents, frequent
updates only for paying customers, only supporting one site and so on
come in. You need to do a really careful cost/benefit analysis of the
resources you are spending and customers you are losing through
annoyance versus the extra purchases you get as a result of more
aggressive approaches.
I know this is too US-centric, but why do people pay so much more to
buy a cup of coffee at Starbucks than at McDonald's? As a retailer
that's what you need to understand; then you need to decide which type
of company you are ... or if you are an independent coffee shop
offering something local. Truth is, customers are sensitive to a lot
more than just price. They don't necessarily prefer something that is
free to something that costs money. That is especially true in the
corporate environment. There's lots of evidence from economics and
psychology supporting that. IF you are spending huge amounts of your
time preventing a 16 year old with a WOW site from getting a free copy
of your extension from a friend and not on thinking about how to
attract and meet the needs of paying customers, I don't think you're
making the right choices. Yes, your paying customers will be able to
install on as many sites as they want, but that's a selling point that
should be reflected in your prices.
Elin
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> On 27 February 2010 08:22, Oli Griffiths <o...@organic-development.com>
> wrote:
> > Yup, that's what I was referring to.
>
> > On 26 Feb 2010, at 21:59, "Herman Peeren" <herman.pee...@gmail.com>
> > wrote:
>
> >> On Feb 26, 10:27 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> >>> Hi Oli
> >>> Can you explain that paragraph a bit more. I don't understand what
> >>> you mean by "enforced in the jed tos". Thanks.
>
> >> I see it as a comment on my remark:
> >> ----------------------------------------------------
> >> It is not completely clear if, assumed I want to be listed in the JED,
> >> it is allowed to demand as part of my sale that installation is
> >> limited to one website. I think it will *not* be accepted for 1) the
> >> JED-TOS says "Additional restrictions may not be placed on top of the
> >> GPL" and 2) it is not in the spirit of GPL. But this point can be
> >> further investigated (known cases?) and clarified.
> >> -----------------------------------------------------
>
> >> as opposed to what the GNU-guy told him before.
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Joomla! General Development" group.
> >> To post to this group, send an email to
> joomla-de...@googlegroups.com
> >> .
> >> To unsubscribe from this group, send email to
> joomla-dev-gene...@googlegroups.com
> >> .
> >> For more options, visit this group athttp://groups.google.com/group/joomla-dev-general?hl=en-GB
> >> .
>
> > --
> > You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> > To post to this group, send an email to
> joomla-de...@googlegroups.com.
> > To unsubscribe from this group, send email to
> joomla-dev-gene...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/joomla-dev-general?hl=en-GB.
greg keys
elin
there is not a license server involved, if you put a removable
restriction to one site in, that's fine.
anything that disables the extension if say a licensing server goes
down, that's bad
[8:03:34 PM] Toni Marie: one time the XXXXXXXX site went down and all
hell broke loose
[8:04:08 PM] Toni Marie: but we all agree that graphics and css and
whatnot are not covered by the GPL, so if they want to restrict those
pages with a single-site code, great
[8:08:13 PM] Toni Marie: we also have no problem with "marking" the
license in say an MD5 hash in a license.txt file so a developer will
know which sites have purchased and are entitled to support
[8:08:26 PM] Toni Marie: md5 is easily reverse engineered, won't
disable the extension
[8:09:09 PM] Elin Waring: One thing that you won't allow is hiding the
fact taht it is GPL, right?
[8:09:46 PM] Toni Marie: absolutely
[8:10:38 PM] Toni Marie: it's a fairly simple thing to say the the
code is gpl and open to modification, improvement, etc but that you
are licensing individual instances so that you may provide support and
know who is entitled to it
You can always contact the team if you have specific questions about
things like this. They work with a lot of developers thinking about
various options.
Elin
On Feb 26, 8:00 pm, greg keys <gregk...@gmail.com> wrote:
> I started a wave to try and organize the conversation, let me know if you
> would like to be added to it, or if you need wave invite.
>
> Greg Keyswww.Socialables.com
> (971) Tec-Webs or 971-832-9327
>
> On Fri, Feb 26, 2010 at 3:46 PM, Andrew Eddie <mambob...@gmail.com> wrote:
> > On 27 February 2010 09:36, greg keys <gregk...@gmail.com> wrote:
>
> > > Perhaps we should start a new topic, Commercial GPL business Models.
> > > to get an idea of different means to accomplish that.
>
> > I think that's the intention of this thread :) However, what someone
> > could do is start to process all the thoughts and options on the docs
> > wiki - that could be useful.
>
> > Regards,
> > Andrew Eddie
> >http://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! General Development" group.
> > To post to this group, send an email to
> > joomla-de...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > joomla-dev-gene...@googlegroups.com<joomla-dev-general%2Bunsu...@googlegroups.com>
Michael Scott McGinn
greg keys wrote:
> I started a wave to try and organize the conversation, let me know if
> you would like to be added to it, or if you need wave invite.
>
> Greg Keys
> www.Socialables.com <http://www.Socialables.com>
> (971) Tec-Webs or 971-832-9327
>
>
>
>
> On Fri, Feb 26, 2010 at 3:46 PM, Andrew Eddie <mamb...@gmail.com
> <mailto:mamb...@gmail.com>> wrote:
>
> On 27 February 2010 09:36, greg keys <greg...@gmail.com
> <mailto:greg...@gmail.com>> wrote:
> >
> > Perhaps we should start a new topic, Commercial GPL business Models.
> > to get an idea of different means to accomplish that.
>
> I think that's the intention of this thread :) However, what someone
> could do is start to process all the thoughts and options on the docs
> wiki - that could be useful.
>
> Regards,
> Andrew Eddie
> http://www.theartofjoomla.com - the art of becoming a Joomla developer
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! General Development" group.
> To post to this group, send an email to
> joomla-de...@googlegroups.com
> <mailto:joomla-de...@googlegroups.com>.
> To unsubscribe from this group, send email to
> joomla-dev-gene...@googlegroups.com
> <mailto:joomla-dev-general%2Bunsu...@googlegroups.com>.
Sam Moffatt
coming back repeatedly. You can sell however you want you just can't
limit the nominated freedoms.
You can put any form of software restriction you want and you can sell
however you want you just can't legally prevent someone from removing
the restriction.
So if you want you could have per directory licensing if you really
wanted on top of per server, per domain, per planet pricing. You can
put in code to limit it to ensure that your code only runs on the same
planet it was licensed to if you want however you can't sue someone
for removing that limitation. So you can set up your sales model to
sell per planet licensing (or per country, per state, per city, per
domain, per pie, etc) if you want to.
GPL only applies to the code so you're welcome to use the trademarks
and other copyright controls to protect your extension. Branding and
other items are important as well as reputation.
I think Red Hat are an interesting example of an organisation that is
selling something you can get for free already (literally identical
with CentOS). They're selling peace of mind - that is their
reputation. They're selling the fact that they certify that if you get
X and Y together Z will work properly. I work for an organisation that
has a site licence for Red Hat which annoys me because it has an
outdated version of PHP (and well everything) but it is certified. If
something doesn't work, it gets fixed. For where I work that is the
value. They could deploy Gentoo or Debian but they don't get the same
assurances. So what I see is perhaps more important than the license
is your reputation and branding. The rest will typically flow from
there.
Cheers,
Sam Moffatt
http://pasamio.id.au
Alan (instance)
consider the value of our source code to be essentially zero. The
initial development cost isn't an asset, it's an expense. The asset is
the support we offer our customers. That's what they pay for and
appreciate. I our extension revenue is support revenue, and the better
the code, the lower our costs. As long as we do a good job of support,
of listening to our users and giving them the features they want, I
have little fear that someone else can erode that revenue
significantly.
In this model, it doesn't matter if someone buys a support contract
and then installs it on multiple sites, because the support costs are
linked to the individual. Once they've figured out how to use it on
one site, they're not going to need much support for the other sites,
so there is neither more revenue no more expense.
I like a variation on Peter van Western's model, where there is a
single-site and a multi-site fee. When a multi site license is
purchased, some part of the extension's admin interface is branded
with the name of the purchaser of the multi-site license. This
branding helps the site developer demonstrate to their customers where
they've added value. There are a number of other GPL-conforming
approaches you can take along these lines to encourage per-site
revenue or at least more revenue from people who install something on
multiple sites.
My personal conviction is that unless you're in a really specific
vertical, there are enough customers out there to build a respectable
business, even if you have an average "pass-along rate" of 2 or more.
I don't think I would adopt the approach of bundling GPL code with a
lot of material that has more restrictive licensing terms. It would be
my expectation that this would just inspire users to set up sites/
resources where they build alternate materials under an open license
and distribute my code along with it. It seems to me that the absolute
worst thing you can do in an open source business is alienate and/or
irritate your customers. I'd rather direct that energy in a positive
way that improves my ability to make more customers happier with less
direct effort.
Jisse Reitsma (Yireo)
you think creatively.
To go back to Richard Stallmans idea, the GPL is there for developers,
and not neccessarily the end-user. With our MageBridge extension we
provide access to our SVN-server through which all the GPL-code is
accessible, but we just don't package the code as click-click
extension. So the freedom to discover how we do things is there (for
developers), but we just do not provide free beer. And that's what the
GPL is all about.
Tobias was mentioning to use a webservice, but this is like shooting a
mouse with a bazooka. If you need a webservice to protect your code,
this proves that there's something wrong with your business model. I
remember debugging a base64-encrypted Joomla! plugin once (which was
base64-ed for about 100 times) to find out what it was doing: It was
fetching a plain text-file from a remote server, and executing it as
PHP-code. This also meant that if the remote server was unreachable,
it in fact also killed the Joomla! site. Using a webservice adds
another dependancy. If you don't need it, don't use it.
With MageBridge we're in a different game: It connects Joomla! with
Magento through XML-RPC which has a couple of side-effects: In Magento
we can't use the GPL but use a custom EULA instead. So while we're
"forced" to share the GPL-code, we are allowed to keep the other half
just for paying customers - and only one half is worthless, you need
the full thing to actually use it. Because of this, we are not worried
at all about the GPL-issue. But that's very specific for our case.
Besides this, we also use some licensing to protect our work. Somebody
can fetch our component from a warez-site, but only with a valid
license-key configured for the right domain you can download new
updates from our own download-server. And because we regularly update
our MageBridge extension (about 3 times a week), there is a very good
reason to use a valid license.
I think this is also a very honest way of dealing with things: The
source code is free, and the GPL is there to guarantee that. But you
pay for updates and support. Of course some Chinese company could copy
the code and resell it again, but they are simply far less capable of
providing support. And I think this should be the winning argument
with any commercial GPL-project.
Herman Peeren
> I started a wave to try and organize the conversation, let me know if you
> would like to be added to it, or if you need wave invite.
Yes, I have once played around a bit with Google-Wave and am
interested in seeing how that can help organizing this. But I have
never used it so far for real and I might need a little help with it;
do you need my e-mailadress for it or can I find that wave somewhere
or... how do I get connected?
Google Wave is used as the means of communication by the organisers of
the Dutch Joomla!Days; I heared some enthusiastic remarks about it.
greg keys
it would be best to keep in invite only for now, we can change it if you all want.
--
Herman Peeren
> what someone
> could do is start to process all the thoughts and options on the docs
> wiki - that could be useful.
Yes, I was thinking of making a website for it, but if we can simply
put that in the wiki it is even better! I will first see what Google
Wave brings us. I'll make a summary for the wiki later; intended for
showing to developers (and business partners) with doubts. I think it
is good if we put some effort in convincing developers to take part
i.s.o. staying on the side. Even more quality into the JED is good for
the whole Joomla!-ecosystem.
In the summary I will be carefull to keep it factual and avoid
questionable opinions about legal issues etc.
I was really surprised to see what I learned from this practical
discussion, abstaining from the theoretical and ideological issues
around the GPL.
Oli Griffiths
Not had the chance to wave at anyone other than my colleagues yet, very
exciting!
Herman Peeren
Beyond" (Wiesbaden May 30 - June 1)
http://jandbeyond.org/attendees/proposed-talks-and-sessions.html
Oli Griffiths
On a side note, does anyone know anything about joomla day uk, the joomladay
server appears to be out of action
Oli Griffiths
over the course of this discussion. I don't think I am alone in my view
points so I will try and briefly list them:
1. I have no problem with releasing software as open source. I see the value
and the merits of doing so. Encryption is not an option for me.
2. Like other commercial developers, we are a company paying wages etc to
develop our extensions, to us, the code and associated materials are
valuable
3. Our components include the gpl license which covers the code and users
may view, edit, adapt, modify etc without any problems. It also contains
other copyrighted material that may be licensed separately, dictating its
use and so on.
4. I understand form what elin is saying that adding license restriction
routines to the code is acceptable, but enforcing that those routines stay
in the code is not possible under the terms of the gpl. However is it
possible under licenses for the other material packaged with the product. In
this case if someone removes the restriction and installs the software on
other domains they are not licensed to, are they breaching those terms
(hypothetically speaking)?
5. I see the support model as a valid one, however it assumes that users
require support. Now of course this is the case for some people, however we
pride ourselves on making software that shouldn't require a large amount of
support. That the UI and its functionality are logical and easy to
understand. We even run our software through usability testing to ensure
that we get things just right. Our approach is get it right first time.
Surely this model just promotes making software that is hard to understand,
thus forcing users to need support. (im not including feature request
support in this as its a different matter).
6. Per use restrictions appear to be allowed, and as Toni Mare stated from
elins post that license servers shouldn't be used, I disagree with this as I
believe it depends on the implementation. I read a blog not long ago about
licensing software and how to do it, one of the methods was a license server
that every time you get a successful response, it updates a local file on
the filesystem that in the event the server goes down, the local file is
used and allows the component to function for X days. I also believe that if
the license server is unavailable it shouldn't bring down your website,
perhaps just make the admin interface unavailable, making most components
useless.
Ultimately, we want to do the following things:
A. to be able to sell our software,
2. release it as open source with good associated material (help, docs etc).
3. to be able to charge on a per domain basis for the software.
4. enforce per domain usage by restriction routines in the code (although we
know this can be removed legally, what about the other materials not covered
by gpl?)
5. provide great support and continuing feature improvement
6. be able to give back to the community though open source software
7. protect our investment in our code
8. be listed on the JED
9. have an ultimately happy experience of contributing our time and effort
to the joomla and other communities where customers value our software and
what we offer as solutions
Alan (instance)
support. I think a large proportion of users are willing to pay a
reasonable sum for an extension on the rationale that it gets them
support "insurance". A lot of corporate IT departments won't touch a
product that doesn't have support.
Don't get me wrong, I'm not suggesting you offer a free download
alongside a "with support" download. I just think that some people
will obtain a free download no matter how much effort you put into it,
and that the combined cost of putting in a bunch of proprietary stuff,
then finding and harassing people who use unauthorized copies will
exceed the benefit. I also think the negative sentiment you create in
the community by doing something like that makes you far more
vulnerable to some Joe across the street, who can put up a version
that replaces your proprietary content with new material under a more
liberal license.
I don't have an example, but I bet it's easy to find a company who
spent so much effort defending against "leakage" that their product
suffered to the point where a less paranoid competitor could fork the
project, fix the obvious pain points, and win support of the users as
a result. In fact, one aspect of Joomla's success is due to a very
similar scenario.
Oli Griffiths
going to circumvent usage restrictions or to download stuff off warez
sites. They aren't going to pay for the software in any case.
What I'm concerned with is the ease at which joe bloggs can email the
software to a friend, or use the software on 100 domains whilst only
paying for it once.
If I am able to license the additional material under a different
license then at least we are covered. I'm not saying we are going to
be filing suits against people who remove the restrictions, but if
someone were to take our product, remove the restrictions and start
selling it as the product then we have a problem. You can say that
users won't do this because of the community spirit I disagree with
that, or that someone can take our software and rewrite all the
documentation, JavaScript and css AND provide support better than we
can, then fair enough, that's fair game.
It's not about going after people who are actively trying not to pay
for the product, I just don't want to make it easy for the average
user to not have to pay for a per domain license. Without usage
restrictions we are just going on users "good will" that they will buy
a new license each time they want to use it, because they won't.
I just want to sell per domain licenses, provide good support, know that
my product (not just the code) is protected by copyright/other license
"if" we ever "need" to go down that route.
On 27 Feb 2010, at 13:28, "Alan (instance)" <alan.l...@abivia.com>
wrote:
Herman Peeren
payed for everytime it is used, I see the following options for
further investigation:
1. investigate cases from JED-listed commercial vendors and other
experiences with per use commercial GPL
2. see how far we can get with dual licencing parts of the
software.
3. compare per use non JED sales against one time JED-listed sales.
How high is the JED-factor?
The final calculation will be a combination of those.
Herman Peeren
to put (removable) provisions in the software that make re-use
difficult (and what advantages or disadvantages such provisions will
have on sales).
Oli Griffiths
restrictions in the code is fine, inferring they can still be listed
in the jed, just so u know.
On 27 Feb 2010, at 16:09, "Herman Peeren" <herman...@gmail.com>
wrote:
elin
restriction to the license that says they can't do that.
Elin
On Feb 27, 12:49 pm, Oli Griffiths <o...@organic-development.com>
wrote:
> Just to confirm, from elins post, it says that per site license
> restrictions in the code is fine, inferring they can still be listed
> in the jed, just so u know.
>
> On 27 Feb 2010, at 16:09, "Herman Peeren" <herman.pee...@gmail.com>
Herman Peeren
wrote:
> Just to confirm, from elins post, it says that per site license
> restrictions in the code is fine, inferring they can still be listed
> in the jed, just so u know.
Look out for "wishful reading" and putting it here without the
nuances. That it was in Elin's post doesn't make it all clear and
settled by a final authority. In Toni's answer there was also a small
mistake, saying "md5 is easily reverse engineered" (no: MD5 is a one
way encoding, just like a checksum; there can be more originals that
have the same encoding), which makes the argument weaker.
I read that paragraph as: you could put a "marking" in your software
(like some MD5-string) to mark that individual copy of the software
and if someone wants support, you can easily check if that copy is on
the site you have sold it for. But that is no showstopper for the
application (or the 100th copy of it) to run.
For the GPL-part: it always must be *removable* restrictions. So far,
so clear.
The only part where you could apply other licenses is images, swf
(yes: with possibilities to call the server etc...), javascript etc.
And also: if the software is a bridge to other software (like
MageBridge is) then you could license the non-Joomla!-side differently
than GPL.
(during me writing this Elin reacted)
greg keys
if you didn't get one and want one simply sign up with google or ask someone for an invite,
everyone added to the wave has full access to edit and chat, it's my hope that we can consolidate and glean the information
from this discussion into something Developers can use for making good decisions about their Commercial GPL businesses.
I've been a part of a wave like this for converting Android to my particular phone, it worked very well to keep everything organized.
to find the wave if it doesnt show up in your inbox search for commercial GPL
Herman Peeren
I found the wave, first time I use it seriously. Nice summary and a
good start with a practical example. We can also use a spreeadsheet in
a wave, cann't we?
Phil Snell
I think javascript would certainly qualify as code. So does that mean only the php needs to be gpl, and the javascript can be whatever license? Sure the javascript is going to be out in the open, but that doesnt change the fact of the legal question. Can the javascript have some kind of license that dictates, 'must not be copied/modified/distributed in any other form'?
Phil Snell
can I legally copy a gpl extension's database schema, write my own code, and release that under a non gpl license? is the conceptual schema part of the gpl licensed material, are the sql statements? this relates I think to the issue of 'assets', and where that line is actually drawn.
Phil Snell wrote:
--
Herman Peeren
Toni Marie. I do a lot with Actionscript (used in Flash and Flex; a
grown up object oriented language nowadays, suitable for making full
blown client side applications). Actionscript is also not necessary
GPL to be listed in the JED, although it is code. I'm always a bit
careful publishing things from private emails, and opinions and
interpretations may have changed, but I think this is relevant. This
was Toni's answer:
"It's definitely code, but to comply with Joomla's license the feeling
is that php interacting with Joomla is derivative of Joomla and
therefore MUST be GPL. Since Joomla doesn't have actionscript in the
core, it would be hard to consider any actionscript derivative."
So, it seemed that the JED does not just propagate the GPL because it
is a good principle (for it then would have required GPL for *all*
code, including Javascript and Actionscript) , but mainly to be sure
the GPL-rights of Joomla! were not harmed (for a moment I even had the
bad feeling that they were mainly trying to protect the Joomla!-
project from legal claims, but as Sam points out in the earlier
thread: it was also meant to provide us, developers, with legal
protection ... sic!). I would say: as far as Javascript is a derivate
of the Javascript that is used in Joomla, it should be GPL. But:
MooTools is released under the MIT license, which gives you the
possibility to use it and modify it in every circumstance (BTW when
using JQuery you may choose if you want to license under MIT or GPL).
O boy, we are nearing the swamp again... let's stay practical and not
get lost in discussions if the way the rules are aplied in the JED are
right or not; let's just get sorted out exactly what the rules are and
then let's look for optimal strategies to play the game.
Thanks Phil for mentioning sql. Apart from the sql-statements you
could also use other programming statements in MySql. In fact, it is a
small programming language (I know: bad practice, for it makes you
more dependent from MySql as a DBMS where we are just moving in the
opposite direction with JDatabaseQuery etc.), but I mention it for
completeness, that it can be used as extra server-side programming-
language. Client-side we have more possibilities; on most clients we
can use Java. So: several possibilities to code parts of Joomla!-
extensions without using PHP... Not that it is the way to go, but just
to indicate some possibilities to license some important parts of the
code differently by not using PHP.
Andrew Eddie
>
> Ultimately, we want to do the following things:
> A. to be able to sell our software,
> 2. release it as open source with good associated material (help, docs etc).
> 3. to be able to charge on a per domain basis for the software.
> 4. enforce per domain usage by restriction routines in the code (although we
> know this can be removed legally, what about the other materials not covered
> by gpl?)
Whatever you "lock down" (javascript, images, docs), you *have* to be
prepared to police that. If you don't, there is no point in locking
it down. Ask yourself (or your business partners) this: what is your
budget for your attorney to send cease-and-desist letters and to
prosecute offenders? I will wager that few extension developers have
enough margin to have a legal team on a $50K (minimum, if you want to
win) retainer. If you aren't prepared to police it, then all the
discussion about getting around the GPL amounts to bluff - in which
case, all the perceived problems with the GPL amount to nothing.
That's my take on it anyway (aka it's not worth the effort of trying
to get around it - it costs too much).
Oli Griffiths
it more difficult for the average user to remove the restrictions than it is
to just buy a new copy. Its also about the reassurance that "if" we should
ever need to, we have the option, and are legally entitled to go after
anyone abusing their right to use the software. What if our next door
neighbour "ABC Computers" sees our component is gpl, removes the
restrictions and starts selling the software verbatim? We want to have the
option to act on that. With no other license/restrictions in our code we
cant do anything.
Herman Peeren
protection for later. That issue has interesting nuances too.
For now I look (again) at the possibilities to licence parts of an
extension different from GPL and some means to make it more difficult
to break that extra license. The main goal: to provide possibilities
to make a per-use license for an extension that is licensed under the
GPL (to be listed in the JED), as this seems to be a breakpoint for
some developers. I don't say it is good to do this or the way to go,
no moral judgement; I just look at the possibilities.
* you can license parts of the application different from GPL.
Mainly: non-PHP parts.
* in the other license you can put that it is not allowed to remove
those extra parts and that the license is per-use.
* you can put a unique identifier in those parts that are not
allowed to remove or modify (encoded in JavaScript, swf,
steganographic picture, whatever).
* you can make your application dependent on that identifier.
So far so good. But you can still use 100 copies of that application
without paying for it. I see 2 possibilities:
1. you can encode the domainnames and/or ip-addresses in the
software, and you can have the software check if the current domain is
the one that is licensed for. Of course it is removable (although not
allowed by the extra license), but it can be made difficult. You can
issue a warning when something is violating your extra license. Of
course the client has to contact you if they buy an extra domainname
for the same site etc. The software must also be testable on a local
testserver etc.
2. the tricky part: you can make a backdoor in your software; or
several. I think, if you make no secret of it that you do that and
why, it is no problem (it is then a choice of the customer to accept
it or not buy your software). You can do it in PHP, but also client-
side server-calls (e.g. Ajax or Actionscript) can be made; so, in the
parts of which you said that they were not allowed to be removed or
modified. You "phone home". As long as your application keeps on
functioning, it's no problem. On your base server, you can compare the
domainname and ip-address with the ones you have given a license for;
when both have changed, there is probably a violation of your per-use
license. You could issue a warning by the software, but you can also
just report to your office, investigate the reported cases, find out
addresses and send some e-mails and letters around where you point out
that your license is violated. You can also warn your paying customer
whose license is used on another site (it might not necessary be the
customer's fault if the software would have been stolen).
Of course this is not a 100% watertight solution: that is not
possible. But it is a possibility to make it a little bit more
difficult to just copy your software to another site. You can vary the
amount of policing, depending on if it is profitable.