Also, the question is not really if any projects have been copying from
TightVNC in the past, but rather if they want to continue copying from
(future) TigerVNC releases, without updating their license, and if that's
something that we care about.
I care about it. For instance, I have a set of VNC benchmark tools
that use verbatim copies of the Tight encoder/decoder source and
benchmark them at the low level. If TigerVNC upgraded its license to
GPL v3, then I'd be forced to upgrade my license as well. GPL v3 is
an impediment in that case.
Are these benchmark tools distributed? If not, there's no need to upgrade
the license. If they are, perhaps it makes sense to include them in the
TigerVNC project?
That's a minor argument, but the point is that we don't know who or what
might want to borrow our code.
If we don't know, why should it affect our choice of license? It's like
developing for an unknown user base.
But as Pierre said, we really don't want other projects to copy or code.
Who is "we"? You do not speak for me on this matter. I personally
think we should encourage people to copy our code. That's the point
of open source, right? Maybe one of those other projects can find
bugs in our codecs or add features that we can't.
If they find bugs, I think it's much better if they report them to the
TigerVNC project, so that we can fix them and include these fixes in
future versions. The same goes for many features. Just making a "copy" of
the source is usually not the best solution.
But you certainly have a point in that we want to enable reuse etc of the
source code. It's just that many of us believes that GPLv3 better
describes the terms.
My suggestion is that we "downgrade" the license if/when we have
identified a case when this is actually needed and makes sense.
It is not possible to downgrade the GPL license once it is upgraded.
It is possible to downgrade if all authors says OK.
I doubt that the community will ever "standardize" around a single
license, but from my point of view, GPLv3 is quite a standard license
nowadays.
I wholly disagree. The more projects use a license, the more that
license has been tested and the better it is understood. Relatively
few projects use GPL v3 at the moment.
It depends a lot on how you count. As I understand it, there are
"thousands" of projects that use GPLv3, but it might also be correct that
this is a small number compared to the number of projects that use GPLv2.
legal precedent. If GPL v2 is so outdated as you claim, then why do
some of the most prominent OSS projects in the world, including the
Linux kernel, still insist upon it and reject the new license?
The Linux kernel is not a typical Open Source projects. For example, the
number of authors is extremely high. Also, as I understand it, at least
some parts are license as "v2" rather than "v2 or higher". This makes
migration much more difficult.
There might be many reasons why the number of GPLv3 projects is yet
relatively small. One main reason is likely the age: GPLv2 has been around
for a much longer time than GPLv3. All old and abandoned or "maintainance
only" projects will of course not migrate to v3 just because it exists.
But of course there are also many people that actually likes v2 better
than v3.
Note, however, that the TigerVNC license is currently "v2+". This means
that we have actually accepted GPLv3. A "migration" to v2 is rather about
removing the possibility of using the code under v2.
If you/we do not like v3 at all, then we need to migrate to "v2 only", but
that is probably not doable.
not in the context that normal applications use the license. As was
pointed out, the GPL v3 adds additional provisions for embedded systems
use that don't apply to our software.
I disagree, VNC is very often used in embedded systems. For example, most
if not all "thin terminals" ships with a VNC server or viewer, often both.
We already have a problem with certain vendors, such as IGEL, which
refuses users to upgrade or modify the installed software (I'm not 100%
sure, but I think these terminals includes an Open Source VNC
implementation.)
What I really want to see is a reasoned legal argument which enumerates
both the risks of upgrading and the risks of not upgrading.
I see very little risk with removing "support" for GPLv2.
I guess the risk of not upgrading involves that TigerVNC is used, per
GPLv2, in a way that we don't like. Say, "tivoization" and things like
that.
I want to know what other prominent OSS projects have made the upgrade
and why they did so (and not "because the FSF said it was a good idea.")
Barring that, my opinion remains with the status quo.
Samba is such a project. gpl3.blogspot.com no longer tracks the migration
progress, but 5 months ago, the number of v3 projects was 3349. See
http://gpl3.blogspot.com/2008/10/gpl-project-watch-list-for-week-of-1024.html.
A conversion rate of something like 100 projects per week seems quite fast
to me.
Best regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
