Re: [A]GPL vs Apache 2

2015-11-04 Thread Paul Wise
On Tue, Nov 3, 2015 at 5:05 PM, Ritesh Raj Sarraf wrote:

> Take Android userspace. I guess nothing there is open. Even the kernel
> can have binary blobs, and we, the users, are left out.

A correction: Android userspace is mostly Free Software and there are
open Android apps available, which enables things like Replicant and
F-Droid to exist as well as for Debian to package parts of Android.

https://www.replicant.us/
https://f-droid.org/
https://packages.debian.org/search?keywords=android

Android uses variants of the Linux kernel, which is licensed under the
GNU GPLv2, any binary blobs are probably violations of the license and
should be dealt with in the usual way; license compliance efforts. For
Linux this is handled by the Software Freedom Conservancy and probably
individual developers and users.

https://sfconservancy.org/linux-compliance/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: [A]GPL vs Apache 2

2015-11-03 Thread Francesco Poli
On Tue, 03 Nov 2015 14:35:43 +0530 Ritesh Raj Sarraf wrote:

[...]
> Honestly, I can't see a reason why AGPL would
> be bad, in the spirit of Free Software.
[...]

Personally, I see reasons why the GNU AfferoGPL v3 is bad: see my own
analysis [1].

Please note that the FTP Masters disagree with me and think that the
GNU AfferoGPL v3 is acceptable for main [2]. But their rationale failed
to convince me [3].

[1] https://lists.debian.org/debian-legal/2007/11/msg00233.html
[2] https://bugs.debian.org/495721#17
[3] https://bugs.debian.org/495721#28



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpxGrEMJSVMb.pgp
Description: PGP signature


Re: [A]GPL vs Apache 2

2015-11-03 Thread Ritesh Raj Sarraf
On Tue, 2015-11-03 at 15:34 +0800, Paul Wise wrote:
> On Tue, Nov 3, 2015 at 4:16 AM, Riley Baird wrote:
> 
> > Not necessarily. It could mean that you want to be as compatible
> with
> > as many open-source licenses as possible.
> 
> The Apache licenses don't fit that definition of "permissive" but
> they
> do fit the definition suggested by Ritesh and the definition used on
> Wikipedia and the one used by the GNU project.
> 
> https://en.wikipedia.org/wiki/Permissive_free_software_licence
> https://www.gnu.org/philosophy/categories.html#LaxPermissiveLicensedS
> oftware

I started thinking about this after reading the recent LWN article.
http://lwn.net/Articles/660428/

A couple years ago, for one of the software that I maintain in Debian,
there was an outcry to change its license. It was initially licensed
AGPL, and in view of some, seen restrictive.

Eventually, it got re-licensed to Apache Software License 2.0.

I did not pay much attention then, but I always have believed that the
FSF have done a great job in ensuring user freedom.

It is a different state now, now that the concept of Free Software has
become successful commercially, and many people/organizations have
found different ways to circumvent that freedom, if it is conflicting
their needs.

There was another article I stumbled upon:
https://www.blackducksoftware.com/files/webmedia/_webinars/2013_06_25_U
nderstanding%20the%20LGPL%20and%20AGPL.pdf

This one talks about GNU AGPL, the license that the software I
maintain, used earlier. Honestly, I can't see a reason why AGPL would
be bad, in the spirit of Free Software.


I think the world is changing now. 15 years ago, when I started, GPL
was the license. Then, Free Software itself was young and not very
successful commercially.

Then, over the years, things started changing. People valued user
freedom. Many people worked on improving software, sharing changes,
benefiting everyone.

But as and when Linux and Free Software caught momentum and became
(commercially) a giant, most people/organizaitons resisted the idea of
giving back, something that the license mandates in a way.

I think what Riley said is true in theory, but is it really true in
spirit?

Take Android userspace. I guess nothing there is open. Even the kernel
can have binary blobs, and we, the users, are left out.

Even HP, in the LWN article, mentions that. Getting a project to be
commercially viable, mandates that it has room to be made proprietary.
Otherwise, chances of organization embracing and collaborating on it is
zilch.

When I briefly worked on Openstack, I signed the CLA. I believe that
too is derived of ASL.

It turns out most people find GPL type licenses too restrictive these
days. Just that who is it "restrictive" for ?

But then some positive things to see too. To the best of my knowledge,
one of the pressing reasons for the birth of systemd (and not, instead,
 collaborating on Upstart) was the license and the CLA.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part


Re: [A]GPL vs Apache 2

2015-11-02 Thread Paul Wise
On Tue, Nov 3, 2015 at 4:16 AM, Riley Baird wrote:

> Not necessarily. It could mean that you want to be as compatible with
> as many open-source licenses as possible.

The Apache licenses don't fit that definition of "permissive" but they
do fit the definition suggested by Ritesh and the definition used on
Wikipedia and the one used by the GNU project.

https://en.wikipedia.org/wiki/Permissive_free_software_licence
https://www.gnu.org/philosophy/categories.html#LaxPermissiveLicensedSoftware

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: [A]GPL vs Apache 2

2015-11-02 Thread Riley Baird
On Mon, 02 Nov 2015 22:58:49 +0530
Ritesh Raj Sarraf  wrote:

> Hi,
> 
> If I was to make a tool for general purpose, to help others, and ensure
> freedom is guaranteed, I'd go with [A]GPL. If I want to make a
> commercial product, I would go and opt for a proprietary license.
> 
> Now I see a reason for people choosing other licenses, like Apache, is
> calling it being more permissive.
> 
> Is it correct to assume "permissive" here refers to the idea of taking
> the code and easily changing it proprietary? Taking the code, and
> mixing it with other proprietary product ?

Not necessarily. It could mean that you want to be as compatible with
as many open-source licenses as possible.


pgpEZBqpHAJUl.pgp
Description: PGP signature