Enforcing copyright of extensions
Tobias Jonch
Andrew Waites
Just wondering why you want o enforce copyright. I am working on an open source extension for schools (for our school) but have no problem with other schools using it if it helps them.
rgds
Andrew
> --
> 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.
Bill Engle
Although if you aren't distributing the code and it is in your
control, how would "they" copy it. Just a thought.
Bill Engle
Http://billengle.info
Andrew Eddie
students seeing it (I presume this is the reason). The GPL only kicks
in when you distribute it, and in your case you'd probably technically
be distributing to your class teacher which rightfully should be
getting a copy of the code :) (otherwise you'll probably fail the
exercise, hehe).
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Tobias Jonch
Phil Snell
Even though this is a school project, I would think your teacher would want this to represent a real world scenario. In the situation you describe, as I understand it, your teacher ( the company) would be distributing the code in a byte compiled form. Therefore, not supplying the source code in the distribution, which is in fact one of the goals he has stated. As I understand it, this violates GPL, to distribute without providing source code. So it seems like you're learning how to be in violation of a software license, seems a strange lesson.
I'm happy to be proved wrong on this, I'm not a lawyer, this is just my understanding based on what you've said.
Phil
Tobias Jonch
Phil Snell
Sam Moffatt
are required to be licenced under the GPL. As such it doesn't
particularly make sense to encrypt your extensions and I've never
really seen much proof that people tend to go into a site to steal the
extension when that would mean that you'd lose the installation
package which would mean more work, much easier to find a way of
legitimately acquiring it, with or without ioncube encoding (which can
be decoded if someone really wants; there are alternatives but they
can be reversed as well) and then releasing it that way.
Companies like EA and Sony spend millions of dollars dollars to
protect their products and annoy legitimate consumers (seriously, a
cracked version of a game gives me at least one advantage over a
legitimate version: I don't have to reach for the CD/DVD to play the
game since the copy protection that requires the original disc is
removed which when the disc isn't ) and they still seem to fail. I
don't see any great point in most Joomla! extensions trying to waste
time on futile protections which eventually makes their life harder
(ever tried to debug encoded code?). But each to their own.
Encoding the extension is fine (binary distribution) however you still
need to make a copy of the source available when you distribute which
in this case seems to defeat the purpose of encrypting to begin with.
If in doubt you can consult with a lawyer but much easier to not
encrypt/encode/otherwise obfuscate and just distribute it plain text
and know you will be compliant with the GPL and note why you did it.
Sam Moffatt
http://pasamio.id.au
Oli Griffiths
Ive had this very same discussion with a chap from GNU, you may be
interested in his response;
---------------
Oli,
I'm very sorry for the late response to this message. Because we are a
non-profit organization with very limited resources, messages to this
address often get backlogged, and we are always working hard to keep up.
> 1. I can sell any GPL code that I create for any fee and do not have
> to provide the source code as part of the program, but must make the
source
> code available on request (however Im not sure if you can charge for
this?)
If you distribute the binaries on physical media (such as a DVD), you
can accompany it with an offer to provide the source code separately.
However, this is not an option if you offer the software for download.
If you offer the software for download, the source code must be
available for download from the same place.
If the offer to provide source code is an option at all, you may ship
the source code on physical media "for a price no more than your
reasonable cost of physically performing this conveying of source". You
may not charge for the source code in any other way.
Please see section 6 of the GPL for details:
<http://www.gnu.org/licenses/gpl.html>
> 2. GPL allows any user that I sell my software to with the right to
> redistribute the program/source code for free
Correct.
> 1. If my software solely relies on a GPL platform (eg a GPL operating
> system or a GPL content management system) in order to function, does
> my code have to be GPL, or are there other licenses that I can distribute
> my program under?
Please see also these FAQs:
- <http://www.gnu.org/licenses/gpl-faq.html#PortProgramToGL>
- <http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins>
> 2. If my stand alone program uses a library or other resource that
> is covered by the GPL license (eg 1 single GPL Icon, or a 1 line GPL
> script to make a popup) does my program have to be GPL?
If your use of the GPLed material makes your program a derivative of the
material (which is a legal question for which there is no general
answer), then yes, you must license it under the GPL.
> 1. If my software has to be distributed as GPL if the above 2 statements
> are true, can I restrict the use of the software (to 1 domain for example)
> and have restriction routines within the code enforce this?
You cannot legally restrict the use of the software. You can, of course,
add code so that the program will only work on Mondays, but users are
free to remove this part of the code and distribute the program without it.
> 2. Am I allowed to attach additional terms to the GPL license that
> contractually inhibits the user from redistributing my software under
> copyright laws as my product will have other materials included with it
> (documentation, logos, and other content) that can not be GPL’d?
You cannot add restrictions to the terms of the GPL. You can license
independent material (such as documentation, as long as it is not
derived from other GPLed material) under different licenses. However,
users can still distribute the program under the GPL by removing this
material.
Kind Regards,
--
Michael Fötsch
-------------
So, basically to put the extension out into the public domain then its best
to pack it full of non-gpl material such as graphics and content that once
removed would render the component useless as no one would know how to use
this. That covers you from a legal point of view.
However, it still doesn't actually stop a user from purchasing your software
and then popping it up on their server for others to download for free. Yes
they will be in breach of copyright laws, but so is anyone who hosts cracked
software.
From Michael Fötsch says, you can add restriction routines into your code,
eg license verification that talks to another server, but if its unencrypted
then a user with a reasonable amount of code experience could track down the
code and remove it.
1 other route is to make your software be entirely dependant upon the
functions of another server (some kind of api), as such you will need a
license and it can only be used on 1 domain for example. However it can be
tricky to find which parts of your component you would be able to move to
another server.
Another route is to provide associated services, documentation, tutorials,
demo content etc that is only available by subscription.
This is the problem that I have as a company with GPL software, its fine for
free projects but makes no commercial sense. So anything we develop is not
distributed and is made available as a hosted service only, until we find a
way to combat this issue. This has the adverse affect that no one is able to
get the benefit of our software on their own website and our component isnt
released into the joomlashere.
GPL protects the recipient not the author, which in my opinion is not a
win:win situation. You can spend months developing an amazing application
only to then have someone buy a copy, stick it up on another server and
you're screwed.
It is common knowledge that a lot of commercial application are of superior
quality and functionality than free ones, bugs get fixed better, support is
better and so on. So restricting commercial developers from contributing to
the joomla community is bad, but the only way we can protect our interests
is to not distribute our works, which in turn is bad for the community.
Any ways, theres some food for thought.
Herman Peeren
software as your basis. So you know the benefits of open source. You
don't have to code everything from scratch and reinvent the wheel.
Part of the system of taking software from open source is: giving. So
it might be good as part of the learning experience, even for your
teacher, to examine the possibilities of distributing as open source,
without any obfuscation or protection.
2. Wether extensions to Joomla! are considered derivative works in the
sense of the GPL is very doubtful (I'm convinced they are not), there
has been a lot of discussion about it and there has not been (yet)
any lawsuit that clearly settles this. What is clear: any Joomla!-
extension that wants to be listed in the JED (Joomla Extension
Directory) has to be GPL. That is to say: for as far as it concerns
PHP ("Graphics, SWF and javascript need not be GPL in order to
consider the code GPL and thus compliant with Joomla's license" as one
of the people managing the JED stated to me in an email). From that
same email: "We in the JED are not lawyers and our goal is simply to
have the rules be easy for users to understand, that they know what
they are getting is GPL code and not necessarily everything in the
package. The important thing is that the information on your website
is clear for the end user, offers the freedom of the GPL for the code
(no single site licenses, encoding, etc), and that you work with us on
certain things like wording and labeling so that the end user has a
consistent experience with downloading and/or buying extensions from
the JED". The JED is an important channel for distribution of Joomla!
extensions.
3. There are commercial extensions, that are distributed under the
GPL. Some people have a succesful business with it. Their extensions
are not encoded; if you buy them, you get the source code too. There
are many doubts whether a commercial extension under GPL is possible,
but there are cases of it and they can be examined.
4. It is against the GPL to distribute a completely compiled Joomla-
application (for the Joomla!-package itself has to remain open source
in any distribution). Of course you could only compile an extension,
that would be an interesting experiment; you could also write it in
another language then (like C++ or Java or whatever) so that it is
even more clear that it is not a "derivative work". I haven't seen
that kind of extensions for Joomla! yet, but it would be an
interesting experiment.
5. If you really have to make an application that is not open source,
of course you can always base that application on another platform
than Joomla!. Even then, there are open source elements that can be
used, that have a license different from GPL.
My main point: the choice for Joomla! is a choice for open source and
part of that decision is that you are stimulated to think about a
business model that fits into the spirit of open source.
(P.S.: while typing this, Oli's contribution was submitted; there
might be some overlap)
Herman Peeren
2007). Joomla! is licensed under version 2: www.gnu.org/licenses/old-licenses/gpl-2.0.html
(from 1991; that is from before internet as we know it now). We make
extensions more "loosely coupled" nowadays then in that time and that
is part of why it is unclear whether an extension is a derivative work
("based on the Program") or not.
We must not start over again with the whole GPL-discussion (it is an
endless pool of legal subtleties), but just for information, this is
an interesting part of article 2 from GPL v.2:
"These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program."
Oli Griffiths
are not derivative works, eg a class that does not extend a joomla class,
the this can be considered to be independent and can be distributed as you
see fit, encrypted or not, your choice, it is not covered by the gpl.
However, if you distribute it as part of works that are derived from a Gpl'd
application then those independent works are also covered by the GPL and as
such the source code should be available.
Right or wrong?
Herman Peeren
extension is written by you, and you distribute it seperately from
Joomla! (as is normally done), then it is not a derivative work.
I am not a lawyer. But as developers we might say reasonable things
about software licenses, sometimes.
GPL was made because earlier open source licenses (like the BSD-
license) left the possibility to bring open software under another,
closed source license. There had even been issues with patenting open
source software by others, so that even the original developers were
not allowed to use their own code anymore. The main purpose of the GPL
is that code that is open source would never ever possibly become
closed source.
If someone makes a minor change, then she/he would acquire copyright
over the software. To avoid that it was put into the GPL that a
derivative work will also be GPL.
But: *** If you write an extension you don't modify the original
Joomla!-code! ***
You add something and that something is your original work. So you
have all rights on it and you can see for yourself how you license it.
But all code that is once brought under GPL can never be brought under
another license.
In the old days we didn't write object oriented code; we had no
classes etc. When we made an extension, we modified the program. That
is where the term "derivative or collective works based on the
Program" comes from. The technical tem "deriving from a class" is
something else than "making a derivative work". Like using words in a
language is not making a derivate of that language. If you use the
Joomla! Framework (the "language") to write your original works you
are not making a derivative work. If using a class from the Joomla!
Framework would make your extension a derivative work, then an
extension with plain PHP (no JRequest, but $_GET etc.) would not be a
derivative???
Oli Griffiths
considered derivative works even if it extends core joomla classes (jtable,
jcontroller etc) or if it uses joomla classes & methods like Jrequest etc.
Ive been led to believe that if my extension does not function on its own,
without joomla, then it is considered a derivate work as it requires another
framework in order to function correctly, and as such must inherit that
frameworks license.
So, should I have to release my extension that you consider is not a
derivative work as GPL?
Oli
Herman Peeren
mainstream at the moment would disagree...).
Only judges could say the final word on that. But I doubt if this
would ever be sorted out thouroughly in court. So, in the meantime we
have to think for ourselves. Be careful: nobody will be impressed if
you say that I said this ;-).
In the meantime: if you want to be listed in the JED, then you must
license under GPL. I see this solution: license under whatever you
want as long as you think is necessary to earn the money back you
invested in time to develop an extension. Then relicense to GPL and
put it in the JED. You see: I come from a land where we even have a
special word for compromises: polder-solution.
On Feb 22, 1:03 pm, Oli Griffiths <o...@organic-development.com>
wrote:
> So what you're saying is that an extension written entirely by me is not
> considered derivative works even if it extends core joomla classes (jtable,
> jcontroller etc) or if it uses joomla classes & methods like Jrequest etc.
>
> Ive been led to believe that if my extension does not function on its own,
> without joomla, then it is considered a derivate work as it requires another
> framework in order to function correctly, and as such must inherit that
> frameworks license.
>
> So, should I have to release my extension that you consider is not a
> derivative work as GPL?
>
> Oli
>
Wilco Jansen
Te definition of derivative work as plotted down by Herman is incorrect. I am also not a lawyer, but I know that the definition of derivative work has everything to to with how the software is build (and tied into the framework/PHP).
Please remember that licencing is about copyright. You as author of the software will always be the legal copyright owner, no one can change that. Distribution is another beast in this regard, but in the end the people buying your software can request a full copy of the source code if they want to.
Within the Joomla community there has been long and intense debates about this aspect, because people can take your source code/idea and improve or change upon it. This makes a lot of people not feel comfortable, but as we progress I have seen a lot of the people overcome these issues and really study the business model using GPL, and they seem to have overcome. Just in vary rare occasions we have seen violations of the licence (see the blog of Brian Teeman for an example), and those violations most of the time are pretty quickly involved.
For a student this is a strange discussion to be honest, unless the understanding of open source licences is part of your course. Your professor should do a bit more research on the meaning of GPL in this regard, and not force you into breaking the licence.
Sam Moffatt
When you asked your GPL knowledgeable and code familiar lawyer last
what opinion did they hold? After a complete examination of the
Joomla! code base and a full examination of your source code what
position did they take?
Joomla! and OSM asked their lawyer and their opinion is that on the
whole extensions are a derivative of Joomla!. So that's the Joomla!
policy, as simple as that (a tad trivialised and there are always if,
buts and maybe's). If you disagree and you're happy to pay for the
legal costs of OSM's lawyers to examine the source code and make a
decision on the legality of the item and if it is a derivative work or
not and thus what your licencing options are at that point given
everything then I'm sure everyone can come to an agreement.
You're also welcome to hold an opinion, however for our own legal
protection we don't include non-GPL products in the JED and other
related items. This is again advice from our lawyers that we've
consulted and know a significant amount of how we're set up and what
is important - we trust them as they're experts in the area of the
GPL, in fact they wrote GPLv3 so you can't do much better than that.
As always, until things are tested in a court of law nothing is solid
and even then until it has been appealed it does not turn into
precedent. We're out to protect Joomla! as best we can so that people
can't do evil stuff. We're mostly winning but there are parts of the
world where people are stopping the community from sharing Joomla!.
That's disappointing but it's also life and we're working to resolve
that because we don't like seeing the community threatened and
blackmailed.
If closed source software offerred such great alternatives to open
source then why does the majority of the internet run on a free open
source web server called "Apache"? If that was the case why are so
many people here in Joomla!? I was reading the FSF's Windows 7 Sins
the other day from a local LUG mailing list reference and they had the
opposite line that proprietary software was inherently insecure. As I
wrote on the LUG list, being open or closed doesn't inherently change
the security or bug fixability of the software. The coders looking
over things and fixing them causes that. There are great coders in
both open and closed source. There are also a lot of bad coders,
almost assuredly more bad coders than good coders which is
disappointing but life. You can't make generalisations like that
because it's not true. I've seen lots of poorly written open source
code but I've also dealt with a lot of poorly written proprietary code
as well. Oracle sticks in my mind as a vendor with a metric boat load
of critical bugs (things don't work at all) and a lack of desire to
fix them. Or even acknowledge them. I have many an Oracle bug war
story but that is for another time over drinks.
With regards to earning money there are a few models as you've
proposed, some more dubious than others. It is interesting to see that
Red Hat, a company that basically makes a distribution that is
completely ripped off by CentOS, is making money and positive growth
even in a tough economic climate
(http://news.cnet.com/8301-13505_3-10204473-16.html). For something
that doesn't make commercial sense, a 25% growth in a "recession"
sounds pretty funky. Each to their own and you have to make your own
business decisions after consulting your accountants and lawyers
(otherwise you could be making an uninformed decision which could cost
you money, more than the professional advice).
Sam Moffatt
http://pasamio.id.au
Oli Griffiths
time at which this is going to be clarified is in court.
My understanding of the term "derivate works" is that if I take an existing
application and modify it, then that is a derivative work.
This raises the question, "if im adding functionality, without touching the
original application in any way, does that class as modifying?"
If you answer yes to that then is can be considered that any extension to
joomla is a derivative work. If you answer no, then an extension would have
to explicitly modify an existing joomla class/library. Eg, if I extend the
Jtable class and add my own additional functions, am I modifying?
Alternatively, if I re-write the load() method, am I modifying then?
Secondly, if my application solely depends upon another framework (eg
joomla) in order to function, the GNU classes that as a derivative work:
" If a program released under the GPL uses plug-ins, what are the
requirements for the licenses of a plug-in?
It depends on how the program invokes its plug-ins. If the program uses
fork and exec to invoke plug-ins, then the plug-ins are separate programs,
so the license for the main program makes no requirements for them.
If the program dynamically links plug-ins, and they make function calls to
each other and share data structures, we believe they form a single program,
which must be treated as an extension of both the main program and the
plug-ins. This means the plug-ins must be released under the GPL or a
GPL-compatible free software license, and that the terms of the GPL must be
followed when those plug-ins are distributed.
If the program dynamically links plug-ins, but the communication between
them is limited to invoking the Œmain¹ function of the plug-in with some
options and waiting for it to return, that is a borderline case.
" http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
So to answer that, to me it looks like joomla is the second option, not the
first, therefore meaning that plugins are considered part of the main
application and must be gpl?
Thoughts?
Herman Peeren
Joomla-money in the issue. We cannot come to final conclusions here.
It is wise to be informed thoroughly by good lawyers on the subject.
It could be an idea to do something in that direction with several
people together; but I wonder if it is worth the costs. Still I
advocate to keep on thinking about it by yourself too. Until now I
have only heared from people that their lawyers say an extension is a
derivative work, but I still cannot find any published work that
really clarifies it.
On the other hand: it is also wise to explore other business models
that let you use GPL and still earn a living. That is also worth the
energy.
No misunderstanding: I really like open source software. But I just
want to avoid that months (or years) of hard work cannot be used to
pay the rent without being (called) illegal.
Oli Griffiths
doesn't get discussed in depth. This is just a discussion, im not trying to
make a case for or against, its just interesting to hear peoples view points
on the subject as it is such a grey area left open to interpretation.
Im not trying to start a war, it would just be nice to know where we as
developers actually stand. If the only way this is going to be decided is
when someone takes someone else to court, then so be it, but it would be
useful to know in the mean time what the various options are for a software
developer.
As far as I can tell, extensions to joomla are counted as derivative works
and as such can only be listed in the JED if they are gpl. If you chose not
to list it in the JED and use a different license then you are opening
yourself up to be liable to license infringement and it would be up to the
Joomla/OSM Lawyers to persue that.
However, if you do not distribute your extension and opt for a hosted
software as a service model, then there are no issues with that.
If you decide to add license checking or validation routines into your code
and list it as gpl and open source then that is technically ok, but being
open source someone can come along and remove the validation and wont be
breaking any licenses.
However, if you distribute your gpl software with additional materials eg
documentation, graphics, other scripts that are not gpl, then you as the
copyright holder can enforce that copyright over anyone who distributes your
extension.
I personally have absolutely no problem with releasing open source software
that anyone can adapt to fit their business or add additional functionality
as they see fit. What I do have a problem with is making the software
available at a price, someone paying to download it, and immediately putting
it up on rapidshare or any other server for free, that, in my opinion is
stealing if anyone downloads that software. As a software developer in that
case you have absolutely no protection over your software, which from a
business point of view is a very bad thing indeed.
Herman Peeren
GPL: http://forum.joomla.org/viewtopic.php?t=163492
Herman Peeren
http://forum.joomla.org/viewtopic.php?t=181173
Mmmm, enough to read this week....
Tobias Jonch
Andrew Eddie
software business model (closed or open source), the GPL is not a good
choice of license. I have certainly seen one or two extensions that
could use whatever license they wanted be they quite literally used
none of the Joomla API (they were effectively just PHP scripts that
used Joomla to bootstrap them into existence), but they are the
extreme exception and not the rule. If you are writing extensions
like that, then you have missed the point of use Joomla as a
framework. And once you cross that line into using the API, you slide
slide down the slope of becoming an ever increasing derivative work.
Certainly when Joomla 1.6 comes along, usage of the API becomes more
and more of an issue if you want to leverage the power of the access
control and category system - and you will do that by following the
example of the code that is distributed to you.
The other comment that should be made about encoded software is that
it's fine when the vendor is around to support it, but when they
disappear, so does any hope of salvaging your investment in their
software. I've come across many people with stories of being burned
in this way.
Having Joomla integrate with a proprietary software service is,
however, a very viable business model and one that is seen in other
sectors as well (compare with free iPhone apps that connect with a
user-pays service). The Joomla extension would need to be GPL but you
can recover costs via the signup to your service. And the beauty is
that the service itself could run on a Joomla site but you don't have
to distribute the software (unless it's AGPL, but that's a whole
'nother conversation and again, the AGPL is not a good choice for
businesses producing software, but is a very good license for free
software).
Finally, there are many developers just putting their code out their
in pain sight and making a buck out of it. You just have to realise
that business models around proprietary closed source software is
simply "a" model. It's not the only one, nor the only one that works.
I will say thought that when you are competing in the Open Source
arena, you have to be very good at what you do to stay ahead of the
pack - it has a very interesting effect of levelling the playing
field. Actually, the first question I ask people when they start
questioning whether a GPL business model can work is "have you seen
your accountant?". If the answer is no, then the license is the least
of their worries.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Tobias Jonch
elin
extensions. Our lawyer also wrote an opinion for WP which explains
why the PHP parts of extensions must be GPL.
http://wordpress.org/development/2009/07/themes-are-gpl-too/
If I were you I would make the following points to your teacher:
1. As James Vasile from Software Freedom Law Center has explained,
extensions must be GPL.
2. You could distribute binaries with the offer of the source code to
anyone you distribute to but then you will then lose access to the
most important market place, which does not include encoded
extensions.
3. You could distribute under a different license but as a business
model that means that you will always be at risk of legal action by
the copyright holders, you will lose access to the JED, you will not
be able to use the Joomla! trademarks in your marketing or on your
websites, and you will never be able to attract serious investors
because they will not want to live with those conditions.
4. Open source business models assume that you will contribute any
improvements to the core to the core because you will not want to
maintain them yourself. That means you will want to be an active
contributor and you will need to agree to the GPL for your contributed
code to do that. More importantly, success in open source requires
being a member of a contributing community and if you are someone
violating the copyrights of those who have written the code you rely
on it's pretty darn hard to be a team player with them ot them to feel
good about working with you.
5. Open source is a selling point and part of the brand promise of
Joomla!. "Because open source matters." Because you will be countering
that promise, you will lose a substantial part of the market for
extnsions who will only use real open source products.
Just some thoughts.
Elin
On Apr 3, 11:52 am, Tobias Jonch <joe...@gmail.com> wrote:
> Hi,
> Sorry to bring this back to life. Normally I'd take you guys on your word,
> but I have this feeling that simply pointing to a post in a forum won't cut
> it in terms of 'reliable references' ;-)
>
> So, it's with this reasoning that I presume to ask:
>
> Sam Moffat:
> *"**Joomla! and OSM asked their lawyer and their opinion is that on the*
> *whole extensions are a derivative of Joomla!."*
> *
> *
> Could you kindly tell me whether this deliberation from the lawyers is
> publicly available?
> If not, do you think either organization would be willing to attest (per
> email), that they do in fact have such advice from their lawyers?
> I think it's vital that I show (prove as best I can) that some of the
> foremost experts view the matter as you describe it. Like I said, this is
> not an attack on you, I'd just very much like to verify that quote.
>
> Andrew Eddie:
> *"**Finally, there are many developers just putting their code out their*
> *in pain sight and making a buck out of it."*
> *
> *
> Again, I would like to dig up some of these companies. Can anyone link me to
> successful businesses who does this? I'd be most interested in companies
> which do so in relation to Joomla, of course.
>
> Thank you,
> Tobias
> *
> *
David Barrett
specified) when these copyright/derivative points are made.
Especially when applying to plugins, code contained in such extensions can
in no way be considered de facto "derivative" of Joomla! For example, I
have written a plugin incorporated CKEditor, my own GPL browser
(ceditFinder), and shortly to include a Syntax Highlighter (also GPL, by
another author). The only file in this package that could be considered
derivative of Joomla! Is the plugin.php and plugin.xml file (and possibly
the related language files). All the other files are separate packages, and
are ported to Joomla - as opposed to Joomla! enabling the functionality of
them or them being written for Joomla!
Given the above - if I wanted, I would be within my rights to package all
the none-Joomla! elements as encoded elements. It would be breaking no laws
or copyright, though would be against open-source principles and the stated
principles of the Joomla! team. The important point being that Joomla! is
not the enabling framework - the contained packages work without Joomla, are
not dependent upon it, and in fact are a completely independent project.
I'd like to clarify that I fully support Joomla! and GPL, and release all my
extensions as such. However, the above point is valid, and invalidates the
assertion that it is a legal requirement for extensions to be GPL.
Derivative extensions, yes, but not all extensions can be declared as such.
Regards,
Dave Barrett
http://www.cedit.biz
Just some thoughts.
Elin
--
klas berlič
This is again advice from our lawyers that we've consulted and know a significant amount of how we're set up and what
is important - we trust them as they're experts in the area of the GPL, in fact they wrote GPLv3 so you can't do much better than that.
Beside separation of power, one of the biggest reasons for this is a tendency that those who created legislation tend to interpret it in the way that it was meant to be
and not in the was it was written. It takes an independent jurist to be able to judge whether legislation in fact says what it was meant to say by it's creators or not and to
be able to judge on it's implications. So those who created a particular legal document are differently not the best source to judge whether something derived from it
would stand on the court or not because they are simply too biased. What GPL more open to interpretation is a fact, that copyright and other area laws that are vaild in particular country overrule it and must be taken into account and so court in USA might decide differently that court in Gemany as legislation mi much different in this two countries.
There are in fact many opinions that counter the one that was somehow accepted as absolute truth in Joomla world:
"Derivative works are not going to encompass plugins and device drivers that are designed to be linked from off-the-shelf, unmodified, programs. If a GPL-covered program is designed to accept separately designed plugin programs, you don't create a derivative work by merely running such a plugin under it, even if you have to look at the source code to learn how."
(source http://www.linuxjournal.com/article/6366 )
Here is another, very interesting text pointig to absurdness of claims made by GPL protagonists:
"To effectuate the goals of the free software movement, the drafters of the GPL urge a generally expansive definition of derivative work. The great irony is, of course, that such an expansive definition would have second order consequences that are exactly counter to the goals of the proponents of Free Software. A broad definition of derivative would give code authors less freedom to create software that they can truly call their own and do with as they please. And if naive analytic approaches such as "subclassing equals derivation" reign, then proprietary vendors such as Microsoft could arguably stake claim to every program ever written in C++, because they authored the original class hierarchy. And since it seems unlikely that courts would employ different standards depending on the goals or ideological motivations of licensors, proponents of free software might want to be careful what they wish for: what's good for the GNU might not be good for the gander."
( source: http://www.law.washington.edu/LCT/SWP/Law/derivative.html )
Few others
http://planetgerman.blogspot.com/2006/12/gpl-derivatives.html
http://weblog.ipcentral.info/archives/2007/07/the_gpl_an_infa.html
I hope that I at least made it clear the situation if far from being resolved and that all claims are precisely that - claims made by individuals and organizations to serve their specific purposes, so the only final answer that can be ever made is - consult specialized lawyers from your own country - .
Regards,
Klas
Sam Moffatt
<quote>
Joomla! and OSM asked their lawyer and their opinion is that on the
policy, as simple as that (a tad trivialised and there are always if,
buts and maybe's). If you disagree and you're happy to pay for the
legal costs of OSM's lawyers to examine the source code and make a
decision on the legality of the item and if it is a derivative work or
not and thus what your licencing options are at that point given
everything then I'm sure everyone can come to an agreement.
On the whole extensions are a derivative of Joomla!, doesn't mean all
cases but for the majority cases we, from the advice of our lawyers,
feel that extensions are derivative. Our lawyers are the ones who will
defend us in courts of law and what ever makes their life easier makes
ours easier. That doesn't mean that there aren't exceptions and, as
noted above, if you're happy to pay our lawyers to do the work we're
happy to work from their judgements.
If you don't like our lawyers stance and you're willing to foot the
bill for any legal time to complete a full examination of the source
code, developer time to explain how everything works plus any future
litigation costs that may or may not result from action taken then
please put your money where your mouth with.
And Klas, you're right in some respects - until something is tested in
a court of law and then appealed in this particular case, Joomla!,
will anything determined be known in a legal sense. Furthermore you're
right that every jurisdiction has different laws, different
legislation and various complications of precedence of up to 800
years. Quoting general advice in different areas doesn't necessarily
apply to Joomla! and I'm yet to see detailed comparative examination
of the Joomla! case in particular by practicing lawyers.
However I'm not surprised that there is dissenting opinion. High Court
judges of various countries don't agree within themselves on matters
and often have their own dissenting judgements. Sometimes the number
in dissent is one short of a majority. Courts change decisions on
appeal which progressively works it way by appeal to the highest court
in the land which makes the final decision with a panel of judges.
Dissent is common in legal contexts in all levels, until we have
various cases decided to the high court/supreme court of all
jurisdictions we're not going to know the answer, but I'd much rather
us spend the money on making Joomla! better instead.
We make judgements on the advice offered to us. Our advice is what has
been stated. It is advice that other open source projects have
followed and from a source that has advised many prominent projects.
Short of someone recurrently funding new legal counsel to replace in
entirety the services the SFLC offer, I don't see this changing.
Cheers,
Sam Moffatt
http://pasamio.id.au
2010/4/4 klas berlič <klas....@gmail.com>:
klas berlič
As I stated - consult specialized lawyers from your own country if you seek a reliable advice for your particular case.
Tobias Jonch
Redhat
Russell Winter
Tobias--
Sam Moffatt
Select type "commercial" and I get back 1141 results. These are people
who are at least selling extensions that are GPL compatible (might be
LGPL for all we know).
We've got specific advice from the SFLC about how our system works. In
most case you will find general advice carries the disclaimer that it
may be completely wrong for your specific case and to consult with a
lawyer (preferably them) about details specific to your case. You're
welcome to consult your own lawyers about your own extension however
if you want it to be non-GPL and included in the JED then we're going
to have to consult our lawyers and at that point to make a
determination we'd need a full copy of the source and for someone to
pay the bill. Just as you don't necessarily trust our lawyers and have
your own, for the exact same reasons we've got ours --- unless, again,
you and your lawyers are willing to fund any litigation resulting from
your advice.
Red Hat over the years have contributed back to GNOME heavily and if
you have a GNOME desktop around with a bit of digging you will find
entire panel applets written by Red Hat. They also contribute to
various smaller projects and also the kernel. Red Hat also release
JBoss as well which is an open source Java servlet container. They've
got a whole heap of code they send out to the world and include in
their own packages. CentOS is a curious case of basically Red Hat
releases with Red Hat branding stripped. Even with this binary level
compatibility, people still choose Red Hat and Red Hat is turning a
profit. Red Hat is also included in the S&P 500 which shows that it
isn't a small fry in the US market.
Acquia is a strange case of the person who owns the Drupal name
creating a new competitor for the entire ecosystem in terms of
professional support, hosting and a few other things whilst not
contributing to the base as much as it could (as far as I'm informed
by other members of the Drupal community anyway). What Acquia becomes
will be interesting and how that impacts on the Drupal community will
be interesting. Acquia from memory offer SaaS style hosting (Drupal
Gardens), their own Drupal build as well as professional support. They
also charge people for commercial use of the name in certain contexts,
or that could just be Dries, not sure.
Canonical has a similar beat to Red Hat, they're the company that
builds Ubuntu. Canonical has done a lot towards GNOME as well and has
the aim of making things more accessible. Canonical has their hands in
a few things and perhaps one of the more useful things they've done is
Launchpad based upon Bazaar, the DVCS that they work on heavily.
Jaspersoft have their BI and reporting based software. They give away
tools like iReport and JasperReports as libraries that you can include
into your own applications. They're in the Java sphere. My workplace,
USQ, has a few systems that utilise JasperReports in their
applications to handle report generation.
Ingres is a name I've heard but not had much to do with. Ingres
appears to be a database company similar to what MySQL was prior to it
being eaten by first Sun and then Oracle eating Sun.
Automattic is another open source company. They give away a small
blogging system called "Wordpress". Automattic offer hosted solutions
as well (Wordpress.com), "VIP" hosting for Wordpress sites, Gravatar,
Akismet and high traffic Wordpress deployment support.
So many companies out there that give code away to have it included
elsewhere and still seem to be turning a profit. Joomla! is perhaps
unique in that we have a non-profit (OSM) in charge of it instead of
those for-profit groups (Acquia, Automattic, etc) running it. In some
respects OSM is also giving Joomla! away, but it isn't out to make a
profit, it's out to make the best CMS it can.
Cheers,
Sam Moffatt
http://pasamio.id.au
Sam Moffatt
Was just flicking through Apple's documentation looking for something
completely unrelated when I thought of this thread.
Apple are also of sorts an open source company. Whilst Apple are
perhaps best known for their insane secrecy around their products,
Apple also heavily make use of open source technologies. Apple also
develop a lot of technologies of their own as open source, such as:
- CUPS (Common Unix Print Services, if you're using Linux and
printing, you're almost certainly using CUPS)
- Calendar and Contacts Server
- Darwin Streaming Server
- WebKit (the browser engine that powers Chrome, Safari (on
iPhone/iPod/iPad/Mac OS X), Android, Palm WebOS, Epiphany, Steam,
Nokia's S60 Browser, Microsoft Entourage 2008, Adobe AIR, Adobe CS5,
etc)
- launchd (from Wikipedia "The launchd daemon is essentially a
replacement for init, rc, the init.d and rc.d scripts, SystemStarter
(Mac OS X), inetd and xinetd, atd, crond and watchdogd.") [I must
profess that having used launchd, I like it a lot more than init.d and
friends]
- libdispatch/Grand Central Dispatch (their multicore task based
programming/scheduling system).
Mac OS X's kernel (XNU) source code is also available online and a lot
of their BSD based tools are available as well. You can check out
everything in as much detail as you like on
http://opensource.apple.com/
On the topic of significant companies, Google is of course another
entry on the list of people who give their source code away. Google
have a tonne of open source projects out there from Google Go (their
programming language), Protocol Buffers (their internal RPC format),
Android (their mobile phone platform) and Chrome (their WebKit based
browser). They have swag load more stuff they're putting out there
(Google Wave, Google Web Toolkit), a list of projects tagged Google is
available http://code.google.com/hosting/search?q=label:Google
Cheers,
Sam Moffatt
http://pasamio.id.au
Amy Stephen
Last I heard, Dries charged a grand total of $700 for commercial usage
of the Drupal trademark. These charges are intended to help offset
additional costs required for attorneys to review special requests.
It's not a money maker. I would encourage you to talk to Dries about
specifically what Acquia gives back to the community. They are
significant contributors to that project and clearly making a positive
difference to the ecosystem for everyone. If you need an introduction,
let me know.
Automattic doesn't "give away a small blogging system called
WordPress. The community that created and developed and supports
WordPress does. It's not only Automattic employees, although that
company does contribute a great deal towards that work.
OSM doesn't give Joomla! away, we do, those of us in the Joomla!
community who have contributed to it. I consider myself to be one of
those people - I have worked hard for four years and part of me is in
every download. I hope that when you say "our attorneys" - you mean
mine, as well.
Ease up. You have gone from telling people that they need to pay
"your" attorneys to look at their code if they choose something other
than the GPL (um - no, they don't, although clearly OSM could go after
them and they might end up paying fines if it's found to be a
violation.) to disparaging remarks about other open source projects
because of misinformation you seem to have about companies leaders
operate.
What's the point, here?
Tobias - anyone who has a copy of GPL code can distribute it. That's
what the GPL allows. Even if that code comes from a commercial entity,
like JXtended or Acquia or Redhat, for example. GPL code can be
distributed and there is nothing anyone can do about it.
We require the use of the GPL for Joomla! Extensions if you extend the
Joomla! software and distribute your work. Some people love the GPL,
others hate it, some of us think of it as nothing more than a license.
If you dabble in Joomla! development and you distribute your work, it
is appreciated if you do like the rest of us who distribute Joomla!
extensions - use the GPL to license your work.
Phil E. Taylor
highlighted that is not the position of Joomla!/OSM.
"require" is a strong word.
The official position of OSM is:
"We believe that the best license for Joomla! extension developers to
use is the GNU General Public License version 2."
"It is our opinion that most extensions are derivative works of Joomla!
and must be licensed under the GNU GPL. "
Quoted from:
http://opensourcematters.org/index.php?option=com_content&view=article&id=70
http://opensourcematters.org/index.php?option=com_content&view=article&id=55
believe !== require :-)
opinion !== require :-)
Maybe a better statement than "require" is:
"We (OSM on behalf of Joomla! & the community) do not REQUIRE the use of
the GPL for Joomla Extensions, however 'we' believe and it is 'our'
opinion that most extensions are derivative works of Joomla! and must
be licensed under the GNU GPL."
Kindest regards
Phil.
(yeah I know, don't get me started, kettle black etc... blah blah :-) )
P.s.: The Joomla! project is no substitute for an attorney. If you have
specific legal questions that require precise answers we strongly
suggest you attain legal counsel in your own jurisdiction.
[http://opensourcematters.org/index.php?option=com_content&view=article&id=55]
Louis Landry
Tobias Jonch
Amy Stephen
I agree, actually. But, please recognize the rest of my post was a
direct response to Sam's words. Let's be a little more careful with
these comments.
The valid comparison between Joomla! and WordPress and Acquia is, as
follows:
OSM - WP Foundation - Drupal Association - each of those are non-
profit organizations. It is perfectly valid to compare how those
entities operate.
JXtended - Automattic - Acquia - each of those are private, commercial
organizations. It is perfectly valid to compare how those entities
operate (although, I think maybe not anyone's business since they are
private?)
Comparing JXtended to the WP Foundation is as wrong as comparing OSM
with Acquia.
Saying Acquia isn't "contributing to the base as much as it could " is
just as silly as saying all JXTended inventory belongs in core. Do you
think we could find people in the Joomla! community who might say
that? Certainly! And they are just as wrong as people from the Drupal
community who might suggest all SaaS delivered improvements Aquia
makes belong in core, too. Repeating those statements is not helpful -
especially when it's about a neighbor project.
Agreed, Louis? Sam?
Phil - I stand corrected. You are absolutely right. It's not
"require." Having said that, if we choose a license other than the
GPL, it won't be listed on property and there could be other
consequences if OSM chooses to pursue the matter and it is found that
the Extension is in violation of the license. Better? Thank you for
correcting me. We do not need to be more GPL than the GPL requires.
There are a lot of different business models for open source projects.
There really is only one thing in common - and that is a need for each
of us to earn a living. Most of us are trying to comply with the
community wishes, whether or not those positions can be upheld in a
court of law, or not. We want to comply because we want to cooperate
and help the project move forward for everyone's benefit.
We really do take this all too seriously sometimes. Some of these
statements end up creating push back on this project - and making
people feel like they are not part of the "we" that we need to keep
innovating Joomla!.
Sam - my apologies for the strength of my remarks. You are a leader
and I read your words with much more authority than the average bear.
You might not realize what some of that sounded like. You are a
supporter of free software and community. So, please be careful with
some of those statements made because they read differently than who I
know you to be.
Louis - thanks for the urging of me watching what I say, as well.
Amy
On Apr 5, 10:19 am, Louis Landry <louis.lan...@joomla.org> wrote:
> Amy,
>
> Sam didn't place a value judgement on Dries or Acquia's actions, he simply
> stated what he knew and/or was told by others in the Drupal community. It
> doesn't matter what the rationale behind Dries charging for name use is,
> there is a charge... which is exactly what Sam stated.
>
> As for the rest of your post, it isn't helpful and isn't relevant to the
> topic of this thread. Please keep that in mind when posting on our mailing
> lists. Thanks.
>
> - Louis
>
> On Mon, Apr 5, 2010 at 9:58 AM, Phil E. Taylor <p...@phil-taylor.com> wrote:
>
>
>
> > This is a factually incorrect statement that should be remade and also
> > highlighted that is not the position of Joomla!/OSM.
>
> > "require" is a strong word.
>
> > The official position of OSM is:
>
> > "We believe that the best license for Joomla! extension developers to
> > use is the GNU General Public License version 2."
> > "It is our opinion that most extensions are derivative works of Joomla!
> > and must be licensed under the GNU GPL. "
>
> > Quoted from:
>
> >http://opensourcematters.org/index.php?option=com_content&view=articl...
>
> >http://opensourcematters.org/index.php?option=com_content&view=articl...
>
> > believe !== require :-)
> > opinion !== require :-)
>
> > Maybe a better statement than "require" is:
>
> > "We (OSM on behalf of Joomla! & the community) do not REQUIRE the use of
> > the GPL for Joomla Extensions, however 'we' believe and it is 'our'
> > opinion that most extensions are derivative works of Joomla! and must
> > be licensed under the GNU GPL."
>
> > Kindest regards
> > Phil.
> > (yeah I know, don't get me started, kettle black etc... blah blah :-) )
>
> > P.s.: The Joomla! project is no substitute for an attorney. If you have
> > specific legal questions that require precise answers we strongly
> > suggest you attain legal counsel in your own jurisdiction.
> > [
> >http://opensourcematters.org/index.php?option=com_content&view=articl...
Oli Griffiths
As is always the case with these kind of discussions, inevitably we've ended up wandering down a path of opinions, people biting at each other, miss-quoted information and so on.
The original post that tobias made was essentially about how to make a commercial joomla extension and to protect ones software. This then evolved into what business models are out there for developing commercial joomla extensions that comply with the JED rules (and thus the GPL).
We started a google wave to list out the various options but this hasn't been updated since march 19th.
Its all very well and good listing out major organisations who have made offering gpl products work, but seriously, listing Apple as a company as an example of how one can make money from GPL software? I doubt many people reading this thread have a company even 1% the size of apple or business models to match.
From my perspective these questions of if a joomla extension is a derivative work are pointless in debating between ourselves because the only way these sorts of questions are ever really answered is by lawyers. Now it may very well be that "some" extensions are only using the included php file (be it a mod_xxx.php, plugin php file or component index file) to lever a completely separate application into joomla and they will have to argue their case accordingly, but most extensions will use part of the joomla library and thus according to the JED are derivative works. As far as I can tell, if you don't like that stance, tough, those are the rules, argue them all you want but at the end of the day, you don't make them, the JED do, and if you want to listed in the JED then you have to comply with their rules. If you’re not fussed about being listed in the JED and you believe your component complies with the GPL license then by all means list it elsewhere but be prepared to argue your case that you comply with the GPL at the very least if OSM come knocking at your door.
All I, and from what I see other extension developers want is a definitive list of commercial business models that satisfy the JED terms. This would be an invaluable resource for any joomla developer. Also a FAQ would be useful with questions like “can I encrypt my extension” or “can I license my extension for per use” etc as these are some of the most common questions ive seen asked. Answers to these kind of questions from the JED’s point of view would be very useful.
What are peoples thoughts?
Oli
Contact Organic Development:
Telephone: 0845 869 765
Web: http://www.organic-development.com
Email: in...@organic-development.com
Twitter: http://twitter.com/growwithorganic
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Organic Development Ltd.
If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in error.
Amy Stephen
I agree with your description of where things are at - and how that
relates to product placement on JED. I think you have an excellent
handle on the situation.
JED has an FAQ that addresses many questions, including the question
on encryption (no, it's not allowed.)
http://docs.joomla.org/Joomla!_Extension_Directory_FAQs#Can_I_submit_non-GPL_licensed_extensions.3F
If we were able to license "per use", then, we really wouldn't be
using the GPL. So, that can't be allowed.
I would not welcome pre-approved business plans from JED or any
additional regulation beyond what the GPL requires. If we comply with
the GPL, that's all that should be required. I'm even a little uneasy
with the rule against encryption although I will not debate it. But
the GPL really does not require it and I would be favorable to the
project doing the same.
There is nothing in the GPL that requires we sit each customer down
and explain to them their rights.
There is nothing in the GPL that would prohibit a developer from
offering support on a per site basis, for example.
Many developers are offering automatic upgrades and that can certainly
be managed within the GPL terms.
There is a lot of room for creative business plans - and a clear
boundary from the project -- if you want JED presence or you think you
can defend a choice other than the GPL if OSM comes knocking.
So that there is no confusion on my position - I support the project's
stand on the GPL and I expect OSM to enforce it, because we all have
to use the same rules or it's simply not fair. What I hope for is that
we all agree to those boundaries and start cooperating with one
another instead of debating the nuances of the rules and reminding of
the force that can bring compliance. Let's just move forward.
On Apr 7, 4:56 am, Oli Griffiths <o...@organic-development.com> wrote:
> Hi All,
>
> As is always the case with these kind of discussions, inevitably we've ended up wandering down a path of opinions, people biting at each other, miss-quoted information and so on.
>
> The original post that tobias made was essentially about how to make a commercial joomla extension and to protect ones software. This then evolved into what business models are out there for developing commercial joomla extensions that comply with the JED rules (and thus the GPL).
>
> We started a google wave to list out the various options but this hasn't been updated since march 19th.
>
> Its all very well and good listing out major organisations who have made offering gpl products work, but seriously, listing Apple as a company as an example of how one can make money from GPL software? I doubt many people reading this thread have a company even 1% the size of apple or business models to match.
>
> From my perspective these questions of if a joomla extension is a derivative work are pointless in debating between ourselves because the only way these sorts of questions are ever really answered is by lawyers. Now it may very well be that "some" extensions are only using the included php file (be it a mod_xxx.php, plugin php file or component index file) to lever a completely separate application into joomla and they will have to argue their case accordingly, but most extensions will use part of the joomla library and thus according to the JED are derivative works. As far as I can tell, if you don't like that stance, tough, those are the rules, argue them all you want but at the end of the day, you don't make them, the JED do, and if you want to listed in the JED then you have to comply with their rules. If you’re not fussed about being listed in the JED and you believe your component complies with the GPL license then by all means list it elsewhere but be prepared to argue your case that you comply with the GPL at the very least if OSM come knocking at your door.
>
> All I, and from what I see other extension developers want is a definitive list of commercial business models that satisfy the JED terms. This would be an invaluable resource for any joomla developer. Also a FAQ would be useful with questions like “can I encrypt my extension” or “can I license my extension for per use” etc as these are some of the most common questions ive seen asked. Answers to these kind of questions from the JED’s point of view would be very useful.
>
> What are peoples thoughts?
>
> Oli
>
> Email: i...@organic-development.com
Phil E. Taylor
Only the copyright holders can enforce the GPL on their code - as OSM
"does not aggregate the copyrights of its code contributors" it cannot
enforce the GPL on that code. No one at OSM has a legal right to come
knocking... (Unless of course then ALSO happen to be one of the
copyright holders of the GPL code in question);
"Since the GPL is a copyright license, the copyright holders of the
software are the ones who have the power to enforce the GPL. If you see
a violation of the GPL, you should inform the developers of the
GPL-covered software involved. They either are the copyright holders, or
are connected with the copyright holders."
Kindest regards
Phil.
Ref:
http://opensourcematters.org/index.php?option=com_content&view=article&id=54
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#TOCWhoHasThePower
Amy Stephen
lol! oh boy, not even going there with you, Phil. ;-)
I'll make my point again - even with that angle in mind.
If we want our extensions on JED -> we gotta use the GPL. Them's the
house rules. Agreed?
If we want to use another license, and we are cool with the Extension
not being on the JED, then, we can go it alone. We might never hear a
peep about it. Or, one day, there may come a rap on the door. Whether
the knock is from a duly authorized member of OSM, or it's Louis, or
it's Andrew, or it's Ed McMahan, absent the big smile and check,
*someone* from *somewhere* - could knock on our door and ask us what
the heck we think we are doing and ask us with persuasive ways to
stop.
Or, maybe "they" won't.
To be honest, I don't really care how that all plays out. I intend to
comply with the community rules without any need for anyone to
threaten me legally or to explain to me the specifics of who is going
to do what to me and why they are able to do so. If I don't like the
community rules, I'll find somewhere else to play where the rules are
more to my liking.
May I pass go, now? :)
On Apr 7, 7:13 pm, "Phil E. Taylor" <p...@phil-taylor.com> wrote:
> Sorry Amy :-) Once again...
>
> Only the copyright holders can enforce the GPL on their code - as OSM
> "does not aggregate the copyrights of its code contributors" it cannot
> enforce the GPL on that code. No one at OSM has a legal right to come
> knocking... (Unless of course then ALSO happen to be one of the
> copyright holders of the GPL code in question);
>
> "Since the GPL is a copyright license, the copyright holders of the
> software are the ones who have the power to enforce the GPL. If you see
> a violation of the GPL, you should inform the developers of the
> GPL-covered software involved. They either are the copyright holders, or
> are connected with the copyright holders."
>
> Kindest regards
> Phil.
>
>
> On 08/04/2010 01:00, Amy Stephen wrote:
>
> > if you want JED presence or you think you
> > can defend a choice other than the GPL if OSM comes knocking.
>
> > So that there is no confusion on my position - I support the project's
> > stand on the GPL and I expect OSM to enforce it,
>
>
>
> smime.p7s
> 6KViewDownload
Phil E. Taylor
correcting your factually incorrect statements that you so easily make
publically can that can be mis-understood and accepted as fact by
"younger" and less experienced in understanding the "GPL".
You have a responsibility to state facts and not bread further confusion
by bending those facts.
This is why the GPL is so mis understood by so many, because well
meaning people like yourself state their opinion as a rock solid fact -
and others believe them without checking the facts.
There is too much quoting of "opinion" without backing it up with the
references to prove it.
Twice within a week you have been guilty of this.
Dont state something as fact, without the supporting evidence.
Kindest regards
Phil.
Amy Stephen
Appreciate you clarifying those things that you found confusing.
Thanks Phil.
> >> Ref:http://opensourcematters.org/index.php?option=com_content&view=articl......
>
> >> On 08/04/2010 01:00, Amy Stephen wrote:
>
> >>> if you want JED presence or you think you
> >>> can defend a choice other than the GPL if OSM comes knocking.
>
> >>> So that there is no confusion on my position - I support the project's
> >>> stand on the GPL and I expect OSM to enforce it,
>
> >> smime.p7s
> >> 6KViewDownload
>
>
>
> smime.p7s
> 6KViewDownload
Oli Griffiths
This is exactly my point of my previous post.
Theses discussions always get littered with opinions/suggestions/or just
plain wrong information.
The point I was trying to make was not that the JED should set rules on what
business models to use but to offer advice for people to say "These
following business models comply with the JED terms (and thus the GPL). This
isnt a definitive list but we can say for sure that if you adopt one of
these models then your extensions will be listed in the JED" kind of
approach.
Is there a list of "Rules" anywhere for the JED, cant find it on the FAQ's?
A kind of "your extension must comply with the following rules/statements to
be listed"
There is still debate about per site licensing. Amy you say this is not
allowed within the terms of the GPL, other posts (I believe there was one
with a quote from someone from the JED) state that this is ok so long as
the PHP code is available. From what I understand, other content packaged
with the extension may be licensed under a separate license if you wish, and
one can enforce the per site license in your php code/java
code/javascript/flash etc etc. Obviously someone "can" remove the
restrictions from the php as it is not compiled, however doing so will
probably break your other licenses if they then go on to distribute your
extension with the other materials included.
My point is, I still don't know what business models are acceptable within
the realms of the JED terms and it would be good to get clarification on
what models are ok and what aren't. This sort of information would be really
useful and I feel should be listed on the JED for new developers, well and
existing ones.
Whats your thoughts?
Oli
Contact Organic Development:
Telephone: 0845 869 765
Web: http://www.organic-development.com
Email: in...@organic-development.com
Twitter: http://twitter.com/growwithorganic
elin
Elin
> Email: i...@organic-development.com
Amy Stephen
On Apr 9, 5:38 am, Oli Griffiths <o...@organic-development.com> wrote:
> Amy, Phil, everyone
>
> This is exactly my point of my previous post.
>
> Theses discussions always get littered with opinions/suggestions/or just
> plain wrong information.
>
> The point I was trying to make was not that the JED should set rules on what
> business models to use but to offer advice for people to say "These
> following business models comply with the JED terms (and thus the GPL). This
> isnt a definitive list but we can say for sure that if you adopt one of
> these models then your extensions will be listed in the JED" kind of
> approach.
>
> Is there a list of "Rules" anywhere for the JED, cant find it on the FAQ's?
> A kind of "your extension must comply with the following rules/statements to
> be listed"
>
> There is still debate about per site licensing. Amy you say this is not
> allowed within the terms of the GPL, other posts (I believe there was one
> with a quote from someone from the JED) state that this is ok so long as
> the PHP code is available. From what I understand, other content packaged
> with the extension may be licensed under a separate license if you wish, and
> one can enforce the per site license in your php code/java
> code/javascript/flash etc etc. Obviously someone "can" remove the
> restrictions from the php as it is not compiled, however doing so will
> probably break your other licenses if they then go on to distribute your
> extension with the other materials included.
Oli -
If our extensions are derivative of the core, then, we must use the
core's license.
There is a lot in that sentence, beginning with the word "If."
The project's position on Templates acknowledges elements that are not
derivative of core are not then subject to the core's license. If you
add your own CSS or your own JS, for example, those can be examples of
work that would not have to adopt the core's license.
A developer could license a PHP Extension using the GPL and then
distribute elements that are not derivative of the core using a
different license.
That's exactly what the Template shops do. If you look at a
RocketTheme distribution, for example, Andy uses the GPL for the
index.php and the various PHP extensions. He is well within his right
to restrict distribution on those pieces that are *not* derivative of
core. But, he cannot restrict distribution of the GPL'd pieces.
We should be able to do the same things with our Extensions that the
Template developers are able to do. I can think of no reason to
restrict a component developer more than a template developer. I
suppose JED could debate whether or not they would allow us to display
the Extension that had been packaged that way, but I would hope they
don't since doing so restricts developers more than the GPL. Why would
we want to do that? Gotta leave some room for creative approaches to
earn a living.
But, Oli, that is not the same thing as saying we could use the GPL
for an Extension, and then add a requirement that the Extension can
only be used on one site. It is impossible to both 1) grant a user the
right to distribute the work as they see fit, and 2) restrict usage to
one site. There should be no debate that doing this is not only not
allowed, but technically impossible.
If we are building businesses on these decisions, it is important to
make certain we can defend our decisions - if we found ourselves in
the position where we had to defend our choices - by involving an
attorney with knowledge in this area. The project is simply not in the
legal business and we shouldn't expect them (and I would add - I don't
want them) to describe how we can do business.
OSM must protect the license. If they have questions about our
approaches, there are ways for them to engage with us on those issues.
But, turning to OSM or JED for legal advise is not a good idea for the
project or for us.
BTW - it's good to have Phil making clarifications. No worries there.
I'm sure there are ways I worded this response, too, that he might be
able to do in a way that makes more sense to someone else. It's okay,
no worries.
>
> My point is, I still don't know what business models are acceptable within
> the realms of the JED terms and it would be good to get clarification on
> what models are ok and what aren't. This sort of information would be really
> useful and I feel should be listed on the JED for new developers, well and
> existing ones.
>
> Whats your thoughts?
>
> Oli
>
> Email: i...@organic-development.com
Tobias Jonch
Oli Griffiths
Im just going by what ive read from this discussion regarding license
restrictions and so on.
From what Ive read its been said that its ok to license other parts of your
extension with a license other than gpl that are not derivative of the core
joomla framework.
Adding usage restrictions to those assets is also ok from what I understand.
Also, adding restrictive subroutines to your php code (from what ive read)
is allowed, as long as the code is open source. The PHP code can be
redistributed under the GPL, yes it may not work on another install, but the
developer is free to remove those restrictions as they see fit, its still
open source and still gpl. The restrictions are in there not to cover the
redistribution of the PHP code, but of the extension as a whole, of the
other assets within the extension that are licensed separately.
The above statement is mostly with respect to responses to this thread (and
this thread
http://groups.google.com/group/joomla-dev-general/browse_thread/thread/78b91
8a635615bbc) the from members of the JED AND a response I received from
Michael Fotsch of gpl.org and fsf.org:
-- Quote - 12/12/2009 ---
> 1. If my software has to be distributed as GPL
> can I restrict the use of the software (to 1 domain for example)
> and have restriction routines within the code enforce this?
You cannot legally restrict the use of the software. You can, of course,
add code so that the program will only work on Mondays, but users are
free to remove this part of the code and distribute the program without it.
> 2. Am I allowed to attach additional terms to the GPL license that
> contractually inhibits the user from redistributing my software under
> copyright laws as my product will have other materials included with it
> (documentation, logos, and other content) that can not be GPL¹d?
You cannot add restrictions to the terms of the GPL. You can license
independent material (such as documentation, as long as it is not
derived from other GPLed material) under different licenses. However,
users can still distribute the program under the GPL by removing this
material.
------------
(question 1 relates to software that is entirely gpl, question 2 relates to
software that is part gpl and part separate license).
I really don't see what the problem is with this approach. If I offer a
component for sale and state these are the terms by which I am willing to
sell you this product:
1. you can use it on one install/domain
2. the php code is licensed as GPL and you may learn/adapt/redistribute etc
3. all other material including content/images/javascript/css etc is
copyright of ABC Ltd and is licensed for use within this application on 1
domain/instll
4. you may not redistribute the component as a whole as this will violate
the copyright and terms of sale of this product. Only the PHP code may be
redistributed.
This way the extension developer is protected, the php is still open source
so the developer can do as they please with it and everyone is a winner. Why
should I be ok with someone buying my product with no restrictions in it and
them redistribute it to 1000 people, how does that help the developer.
Is this a question for the JED mailing list?
Oli
> --
> 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.
>
Contact Organic Development:
Telephone: 0845 869 765
Web: http://www.organic-development.com
Email: in...@organic-development.com
David Barrett
>>
I really don't see what the problem is with this approach. If I offer a
component for sale and state these are the terms by which I am willing to
sell you this product:
1. you can use it on one install/domain
2. the php code is licensed as GPL and you may learn/adapt/redistribute etc
3. all other material including content/images/javascript/css etc is
copyright of ABC Ltd and is licensed for use within this application on 1
domain/instll
4. you may not redistribute the component as a whole as this will violate
the copyright and terms of sale of this product. Only the PHP code may be
redistributed.
<<
Point 1 breaks GPL - you are adding a restriction to the licence.
Point 2 breaks GPL - if the content is required by the (apparently) GPL
component, then you are adding a restriction to the GPL licence. CSS and
Javascript cannot be defined as "independent material" if it is needed for
the component to operate.
Point 3 - under GPL, the copyright IS owned by the developer/company. You
cannot add the domain restriction however.
Point 4 - this breaks GPL.
See: http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL (if you modify the
GPL, it is incompatible with the GPL)
If the above licence modifications are added to a component, then the
component is not GPL (even if the PHP code is).
As far as I can see most of the objections to GPL are coming from developers
worried about someone buying their component and then redistributing it for
nothing. Due to the nature of the licence, this is allowed under GPL. The
best defence for this (in my opinion), is to keep the extension updated.
Most users of the software/component would rather get it from the original
developer and pay for support. You can provide support only to registered
users if needed, and also provide updates via a protected area of a site
(available by subscription, for example).
With reference to the JED TOS (http://extensions.joomla.org/tos):
2. Extensions must be licensed as GPL in order to be listed, with the
exception of the Tools category. Additional restrictions may not be placed
on top of the GPL. Do note that the GPL does allow developers to charge for
their products.
This surely means that the whole extension must be GPL. If you want to
licence part of it under a different licence, it cannot be distributed as a
package (if you wish inclusion in the JED, that is).
In my opinion, GPL should be considered a philosophy backed by a licence.
At the point a developer starts trying to get out of certain parts (e.g.
licensing parts of something under none GPL to "Protect their interests"),
then they are not truly embracing the GPL. GPL means free as in speech, not
as in beer - there are many acceptable ways to charge for GPL offerings that
benefit everyone (the developer and the user). I believe the vast majority
of people are happy to pay for support or subscriptions from the original
developer, and the few that aren't probably wouldn't pay for anything
anyway.
Dave Barrett
http://www.cedit.biz/
Oli Griffiths
My apologies, I hadn't looked at the JED TOS for a while and missed the
point that the ENTIRE extension must be GPL.
I believe your second point that Javascript and CSS files must be GPL if the
package they are used with is GPL to be an incorrect statement. GPL works by
filtering down. IE if I make software that USES GPL libraries to operate
then my extension must be GPL (certainly the php parts). If I make my own
css and javascript that does not extend gpl code then I do not have to
license my coe as GPL if I do not wish to. The GPL doesn't filter up, only
down. Regardless of whether or not my component would work without them is
irrelevant.
At no point would one be adding terms to the GPL license as this is clearly
not allowed and is specifically stated in the GPL. The restrictions would be
added to the additional materials packed with a component, not the GPL code,
thus one wouldn't be breaking any terms of the GPL license.
However, this is all largely irrelevant if an extension must be entirely GPL
as stated in the JED TOS (god, we're starting to need a glossary with all
the TLA's in this thread)
It has also been stated in the GPL business models discussion that packaging
a component that will only work on one domain IS acceptable within the terms
of the JED, BUT you can not phone home to check the license or anything, and
this was stated by a JED representative if I remember rightly.
Are any members of the JED team watching this thread? If so, could you
comment?
Oli
David Barrett
>>. It has also been stated in the GPL business models discussion that
packaging a component that will only work on one domain IS acceptable within
the terms of the JED, BUT you can not phone home to check the license or
anything, and this was stated by a JED representative if I remember
rightly.<<
But surely while you can state this for an extension (i.e. not as a licence
term), it is not enforceable in any way as GPL means you CANNOT add this
restriction (and a restriction it is). If it is released under GPL, then
the user can install it on anything he likes and redistribute it if they
want to - the limit of one domain is meaningless unless it is added as a
licence term, and doing this means the component is no longer GPL. At the
point a component is released as GPL it is largely pointless having a phone
home as any reasonable developer could simply remove such code. GPL
enforces the freedom of the user - which means that once they have the code
they are free to use it.
>> IE if I make software that USES GPL libraries to operate then my
extension must be GPL (certainly the php parts).<<
If your software uses GPL libraries, then it must be released as GPL if you
are releasing it as a package. So long as you don't redistribute it, there
isn't an issue. At the point you redistribute it, you are breaking GPL (see
http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem. You cannot
distribute GPL libraries with your component if it isn't itself GPL - you
would need to split it (i.e. distribute the GPL parts as a package, GPL,
then distribute your software as a separate, none-GPL, package).
>>If I make my own css and javascript that does not extend gpl code then I
do not have to
license my code as GPL if I do not wish to.<<
I believe you do if you want to redistribute it as a (single) package - as
explained in the link above. Of course, if you released it as separate
packages (i.e. your CSS/Javascript in one package, and the PHP GPL code in
the other) then there isn't an issue - you can release both under different
licences.
Dave.
Hi David,
Oli
--
Ian MacLennan
Ian
David Barrett
I think you may have misunderstood my point (and I probably explained it badly!). I believe that the majority of people are happy to pay a reasonable price for an extension, and also for ongoing support of such an extension. In practise I believe that most of the worries that developers seem to have (how can I protect my code, how can I stop people distributing it, etc.) aren’t in fact a worry as the vast majority of people would get the extension from the original developer if possible, and pay for support.
My point about the domain limitation was that at the point an extension is limited to a domain by licence, it is not GPL. Presumably if it were limited to one domain by code, this would have no effect on the licence – but I for one would think twice about buying such an extension, just as I would not buy a none-GPL extension. Currently I only charge for one of my extensions, but what I am essentially selling is support and access to the documentation – limiting the extension to a single domain isn’t in the interests of myself (due to the extra overhead required to manage this) or my customers.
Regards,
Dave Barrett
http://www.cedit.biz
Rules Manager for
Outlook - sorting your inbox so you don't have to
Oli Griffiths
We have 10 employees who all need wages paying each month, and to release an extension that allows any tom, dick or harry to just take our extension and email it to their mate, or pop it on their server for anyone to download for free completely undermines the effort that my and my staff put into building the software in the first place.
Now I know you cant stop someone who is determined to steal your code, if microsoft and adobe cant stop it, nobody cant. But for me its about making it not worth the effort to strip out the logic from the extension that limits its use in the first place, but to purchase a new copy with the support associated with that.
Is it perfectly fine to package GPL code with non-GPL code, to add restrictions to the GPL code that enforce the licenses of the other non-GPL code. You are still free to use the GPL code as you wish, strip out the enforcement subroutines, but you would be in breach of license if you redistribute the whole application with those restrictions removed.
However, the JED TOS states that the extension must be GPL, there fore nullifying the point above as the whole thing has to be GPL anyway (something that I don’t really feel is fair).
The only sure fire way around this is hosted services, where part of your component is hosted externally and a valid license is required to use that service.
I feel that it is fair that someone should have to pay for each instance of a piece of software that they want to use. Its not ok to buy a film, copy it, and give a copy to all your friends, so why is it ok to do the same thing with software.
Im sure others will disagree with me on my point above.
Oli
On 12/04/2010 16:55, "David Barrett" <da...@cedit.biz> wrote:
I think you may have misunderstood my point (and I probably explained it badly!). I believe that the majority of people are happy to pay a reasonable price for an extension, and also for ongoing support of such an extension. In practise I believe that most of the worries that developers seem to have (how can I protect my code, how can I stop people distributing it, etc.) aren’t in fact a worry as the vast majority of people would get the extension from the original developer if possible, and pay for support.
My point about the domain limitation was that at the point an extension is limited to a domain by licence, it is not GPL. Presumably if it were limited to one domain by code, this would have no effect on the licence – but I for one would think twice about buying such an extension, just as I would not buy a none-GPL extension. Currently I only charge for one of my extensions, but what I am essentially selling is support and access to the documentation – limiting the extension to a single domain isn’t in the interests of myself (due to the extra overhead required to manage this) or my customers.
Regards,
Dave Barrett
http://www.cedit.biz <http://www.cedit.biz/>
Rules Manager for Outlook <http://www.outlookrulesmanager.com/> - sorting your inbox so you don't have 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> .
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
Telephone: 0845 869 765
Web: http://www.organic-development.com
Email: in...@organic-development.com
Twitter: http://twitter.com/growwithorganic
David Barrett
>> Is it perfectly fine to package GPL code with non-GPL code, to add restrictions to the GPL code that enforce the licenses of the other non-GPL code. You are still free to use the GPL code as you wish, strip out the enforcement subroutines, but you would be in breach of license if you redistribute the whole application with those restrictions removed.<<
This is the bit that I don’t agree with. You cannot package GPL code and none-GPL code together:
http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
Regards,
Dave.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
Oli Griffiths
However, as is always the case with these things, what is classes as a “Proprietary system”?
I wouldn’t say that javascript/css/images/documentation make a proprietary system. The PHP is the main bulk of the application which will remain GPL, one is just licensing these additional resources separately.
No?
ToniMarie
Very briefly:
As Elin stated, the JED-specific stuff really should be asked of the
JED team, BUT...
As far as our rule that the entire extension must be GPL, it's not
itemized in our JED rules but we in the JED are aware that independent
JS and CSS/graphics may be non-GPL as long as removing them does not
inhibit function. We'll accept many things as long as they do not
inhibit function as GPL products, but they often need to be evaluated
on a case-by-case basis and reviewed before we will accept them. We
also work with the developer to be sure that the wording on the
developer's site makes the terms of the extension abundantly clear to
users before download or purchase.
It's simply easier for everyone for the extensions to be GPL, you
don't have to wait for us to work through whatever exceptions you
require. Exceptions mean JED internal review, which takes time, and
you may end up having to readjust wording to the point where it's
unacceptable to you.
In the JED we are simply trying to not encounter future license
violation situations where one day a Joomla core copyright holder is
coming back and naming us as part of the problem. If we always err on
the side of caution, we never have to worry about it.
And as we have seen time and time again, the prohibitive factor in
redistributing commercial GPL extensions for free is that said re-
distributor will not maintain or support code for free, so while you
may try the product, eventually you have to come crawling back to the
bug developer to get a paid subscription to fix or upgrade. From a
business perspective it could even be considered free advertising.
We do not have a list of acceptable or suggested business models as we
are in no position to advise developers from a financial perspective.
I would never want that responsibility hanging over me. Your money is
your money, but we will do everything we can to work with you to make
sure your plans fall within our rules.
When in doubt about whether your particular business model will work
within our rules, do email us at te...@extensions.joomla.org or myself
at toni....@extensions.joomla.org .
Toni Marie