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

Re: samba license change



On Wed, 2007-10-10 at 09:19 +0530, Rahul Sundaram wrote:
> Andrew Bartlett wrote:
> 
> > 
> > The problem is, there is no long-term will to maintain such a -compat
> > package.  How long would such a package last - forever if other packages
> > don't move?  Who would maintain it?

I agree with Andrew and you actually give me a chance to explain why.

> I assume whoever is dependent on Samba but can't make the move to a 
> compatible license would be interesting in maintaining it. I don't think 
> it is feasible for us to have a new release of Fedora where something as 
> major as GNOME or KDE does not have any Samba support. Do you?

Well there are 2 possible situations:
A) The projects that depend on samba are willing to address the
licensing problem
B) They are not

If A we have time, we are talking about F9, plenty of time.

If B then they have 2 choices:
B.1) Drop functionality
B.2) Implement/maintain/whatever their own SMB/CIFS support

In both cases I think they should provide the solution. A SONAME bump is
just going to break existing application that do not have any licensing
problem, it is not going to fix the licensing problem for these
projects, a problem they need to solve one way or another anyway.

If they choose B.1 a SONAME bump was useless, broke applications, wasted
time.
If they choose B.2 a SONAME bump was useless, broke applications, wasted
time as they are going to provide their own solution anyway in their
packages (or through a fork, or whatever).

> > The bit that bothers me is that not only was Samba for the longest time
> > mentioned in most GPLv3 news articles, we asked if anybody had a reason
> > not to change our licence, and nobody gave a compelling reason.
> 
> Things are not working a vacuum.

Oh this is exactly right, things do not happen in a vacuum, the license
change of Samba was *largely* anticipated and announced some time ago.
Plenty of time to act. And remember we are not forcing anybody on a
solution, these projects are completely free to choose their own.

> You know the major players in Free 
> dependent on Samba which includes GNOME and KDE. The license 
> incompatibility that would occur as a result of this move was very plain 
>   to everyone involved.

Yes, it was clear, but let me rant a bit:
People started warning about the problems of GPLv2 only licensing
*years* ago, when the GPLv3 work was not started yet but was expected to
start at some point.
Now projects that choose GPLv2 only, choose *consciously* the route of
incompatibility with an upgrade.
now as these projects made that decision, I think it is only fair they
move quickly to fix the problem, they have been given a lot of time to
think, the 3.0.x version will still be maintained (security fixes and
very serious bugs only) for an year after the GPLv3ed 3.2.0 is out.

> Such a transition can take several months if we 
> have to introduce it into the distribution. I don't see any way out of a 
>   maintaining a GPLv2 version of Samba for a while unless everyone 
> involved moves to GPLv3 or compatible licenses for their own software 
> quickly if they are dependent on Samba.

See above, there is still some time, I am holding 3.2.0 (we are still
pre1 anyway) releases for now, they will not hit rawhide until the
matter is solved for Fedora.
But this is a general issue, I urge the people that work with GNOME and
KDE to ask these projects to decide what they are willing to do in the
future without further delaying an inevitable decision.

I sent notice to fedora-devel in advance exactly to start kicking the
whole machine, as I said we have time, but not the whole eternity, and I
haven't seen much around the topic since we made our announcement from
the interested parties.

Nor when we asked for comments *before* changing the license, nor
*after* we announced it. I believe it is time to hear something from our
friends :)

Simo.


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