Re: EPL and GPL incompatibility

[Ángel González]

On 10/09/16 16:45, George Bateman wrote:

Also, if upstream are wrong, is the mechanism described at
https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
sufficient to resolve the problem?
Yes, they should granting an additional permission to link with 
libraries covered by the Eclipse Public License. Granting that shouldn't 
be a problem since they already think it's allowed.


The only nitpick is that all copyright holders (of the GPL code linking 
with incompatible libs) would need to agree on this, not just eg. the 
main developer.

Re: Can "rockyou" wordlist be packaged in Debian?

[Ángel González]

On 21/09/16 01:46, Ben Finney wrote:

Thanks for raising this question.

Eriberto Mota  writes:


Well, the quoted event resulted in a file with 14 million passwords,
distributed by Kali Linux.

Do you have any reference to the discussions those people had over their
license to distribute that information?

I would expect such a discussion to get into the issue of whether a
single password is subject to copyright restrictions, and further
whether a compiled collection of such works is itself subject to
copyright restriction.

I would want to see such a discussion with clear, solid support for the
freedom to redistribute that work under a free license, before proposing
its distribution in Debian.


IMHO, the passwords themselves are unlikely to pass the threshold of 
originality.
Looking at the longer entries, there are a few passphrases,¹ but not 
much that could be considered copyrightable. In addition, the fact that 
passwords appeared multiple times is also an indicator that there was 
little to no originality involved.


Another question would be if the database itself could be copyrighted, 
but given that there was no compiling effort at all from rockyou, that 
won't be the case.² Plus, it was a US company, where there are no 
database rights.


However, I wonder if the fact that it was stolen would be a problem.

Best

¹ and a lot of waste. In some cases they were probably inserted from 
spambots which confused it with a comment field.
² Ok, they might claim that their only goal creating the rockyou website 
was getting such password list from their users, but that would equal 
admitting an ever bigger misdemeanor.

Re: C-FSL: a new license for software from elstel.org

[Ángel González]

On 21/01/16 22:33, jonathon wrote:

5. When applying changes to the source code you need to leave your name,
your email address and the date of your modifications so that other
people may contact you.

Fails the Desert Island Test

jonathon

Maybe not.
a) The guy could have an email address created before getting stranded
b) Else he could use an email address @localhost

It would fail for new generations born in that island that only 
programmed in paper, though :)

Re: C-FSL: a new license for software from elstel.org

[Ángel González]

Some general feedback:

On 21/01/16 22:49, Elmar Stellnberger wrote:

CONVERTIBLE FREE SOFTWARE LICENSE
Version 0.8, 2016-01-21 , *** This is just a draft ***
copyright 2016, by Elmar Stellnberger
Everyone is permitted to copy and distribute verbatim copies of this 
license document. You must not modify the license itself.
This license applies to any software containing a notice by the 
copyright holder saying that it may be used under the terms of the 
Convertible Free Software License. If a specific version number is 
mentioned then usage rights include this version as well as any newer 
version which will always be similar in spirit to this license. The 
term Convertible Free Software license may be abbreviated as C-FSL.


1. Any work under this license comes completely without any warranty 
or any kind of liability such as lost revenues, profits, harm or 
damage of any kind even if the authors should have been advised of the 
possibility of such harm or damage. It may be seen as research work 
and does not claim for fitness to any particular usage purpose.


2. The term 'source code' applies to the preferred form that is used 
to develop or apply changes to a work under this license referred to 
herein as 'the work'. You are allowed to modify or change the source 
code if you accept that the resulting changed work will become subject 
to this license. As soon as you apply any change this is an implicit 
consent to fully comply with this license and a consent that the work 
may be used under this license.


3. It is your obligation that the changed version of your sources will 
be available to the public for free. Available for free means that 
there will be no undue hinderance in obtaining the given item like a 
registration of the person who wants to download or obtain the given 
item. Available for free also means that you must not charge for the 
given item itself apart from the possibility to require a reasonable 
charge for the physical reproduction of the data.
You pretty much are forcing that each time the text editor contents are 
changed, a commit with that revision is immediatly published on the 
internet.



4. You are allowed to issue an 'automatic derivation process' on the 
source code which will result in so called 'object code'. As soon as 
you wanna share the object code with other people you are oblidged to 
make all utilities and data necessary to obtain the object code either 
availabel under C-FSL or any other open source license approved by 
opensource.org. The given data and utilities need to be available to 
the public for free.
This means a propietary compiler cannot be used with these programs 
(even if the source code are eg. standard C89).



5. When appyling changes to the source code you need to leave your 
name, your email address and the date of your modifications so that 
other people may contact you. We suggest to list all changes by 
contributors either in a separate changelog file or in the header of 
the changed file. 

You should allow anonymous contributions, or contributing under a pen name.
See also https://en.wikipedia.org/wiki/Nymwars

Also IMHO it should allow collapsing several entries of the same author, 
or even summarising the whole changelog (if the original authors only 
mentioned author names, for instance).


Furthermore you need to give your changed version a 'marker' which may 
be used to distinguish it from the upstream version when being 
distributed to other people. The distributed product needs to be of 
the form upstream name - dash upstream version - dash your marker 
optionally followed by a version number under your control. The marker 
needs to be unique, at least two letters in size. We suggest it to 
reflect the name of your company or distribution.


What about the fork of a fork of a fork?
IMHO it should be possible to replace the marker of the intermediate 
company, without having to append to the version or use different name.



6. You may choose to create a fork of a work under C-FSL by giving it 
a completely different name. However you need to assert that people 
will know that your fork is based on the original work. If your 
program has a graphical user interface the whole C-FSL license as well 
as in case of a fork a complete reference to the base product 
including email address and web presence must be accesssible via the 
GUI. Otherwise a plain text copy of this license as well as the 
aformentioned reference to the base product where applicable need to 
be given and packed alongside the distributed product. If your program 
has a comprehensive help, a manual or info page and is a fork the base 
product needs to be fully referred to there including a contact email 
and web presence. It does not apply to quick or short command line 
help output as long as a more comprehensive help page is also available.


What if the original author prefers a simple: «This file is licensed 
under C-FSL, see http://c-fsl.license/legal»?

Re: debian status on using the PHP license for pear/pecl extensions

[Ángel González]

If the current FAQ entry related to PHP hasn't changed since 
http://web.archive.org/web/20051016231155/http://ftp-master.debian.org/REJECT-FAQ.html, 
I don't think the entry, and most importantly the phrase « That license, 
up to the 3.x which is actually out, is not really usable for anything 
else than PHP itself» can be applied to license v3.01 released *after* that.


IMHO the ftp masters shouldn't be applying such FAQ entry and have to 
reevaluate the new license instead.


(I should note that someone slightly edited it in the meantime, adding a 
comma and changing its → it's; so maybe they *did* review 3.01 and found 
nothing else worth changing)



Best

Re: non free broadcom-sta-dkms_6.30.223.248-3_all.deb for wireless driver bmc4313

[Ángel González]

On 30/10/15 01:05, Gabriel Tachtatzis wrote:
First time use  non-free.I do not know nothing how must used.I can use 
this driver bcm4313


Sorry.
I tray install driver wireless bcm4313.
I install in easy in ubuntu 15.10 but have problem with debian.
The non-free do no understand if i can use.


The non-free repository is called that way because its contents are not 
free software, not because it is illegal to use them (generally: it may 
not be so in your country, or sometimes a piece of hardware is needed). 
That said, you must be more careful with their licenses, since you can't 
assume the goodness DFSG-vetted licenses have.
You can read the license of this package on 
http://metadata.ftp-master.debian.org/changelogs//non-free/b/broadcom-sta/broadcom-sta_6.30.223.248-3_copyright


How to install a program from the non-free repository is out of scope 
for this list, but I suspect you didn't add the repository, and/or you 
didn't refresh the package list before attempting to install.


Best regards

Re: Is mpage DFSG compatible?

[Ángel González]

I have to agree with the interpretations of the given text.

However, in addition to the license in the README file, it also comes 
with COPYING
and COPYING.LESSER files with the text of GPL and LGPL, which seems to 
imply they

wanted to allow distributing the program under (L)GPL.
Seems worth a clarification by the copyright owner, those may be old 
copyright notices,

and they are probably willing to relicense.

That may not be possible for Contrib/mfix/test.ps, but that file could 
be stripped.

Re: Is mpage DFSG compatible?

[Ángel González]

On 18/10/15 23:27, Eriberto wrote:

Thanks Riley and Ángel!

Ángel,

The copyright notices in headers should be considered as priority over
licenses inside generical files. So, the upstream intents provided by
generical copyright files shouldn't be considered when packaging and
if the files have headers. I understood your words, but the main
license is non-DFSG (IMHO).

Thanks a lot for your help!

Regards,

Eriberto
Sure. I was considering that they probably *intended* it to be available 
under

(L)GPL, and would thus be sympatetic to (properly) license under them.
Not that Debian should solely rely on those files when there is more 
specific

copyright information.

Kudos to Ben for noticing that old Changelog entry.

Re: Source files

[Ángel González]

On 15/10/15 00:50, Riley Baird wrote:

On Wed, 14 Oct 2015 23:47:02 +0200
Francesco Poli  wrote:


The alternatives you propose are vague at best.

For further details on what I think about the definition of source,
anyone interested may read my essay:
http://www.inventati.org/frx/essays/softfrdm/whatissource.html

That's a good essay! Hopefully, something like that will become the
reference that Debian actually uses in the future.

Yes, good work, Francesco.



I have some concerns, though:

The preferred form of a work for making modifications to it.

This fails to address the issues raised earlier in this thread:
What about CVS headers?

Well, the file with the CVS headers is probably what you would use
for making modifications.



What about patches created using quilt?

quilt is a version control system (in form of patches). IMHO it doesn't
affect for the definition of source. You don't edit the file using quilt,
you use vi, emacs, notepad… and store the changes using quilt, but
you could as well be using tar(1).
The source is the file that you edit. It may be distributed as original
file + a number of patch files, but that's orthogonal.



The person whose preference should be taken into account is the
one who last modified the version of the work under consideration.
If he/she prefers to modify the work in a given form, then that
form is the source code for the work.

Company A writes a program A* in C++ and gives binaries away under a
free license to Person B. Person B has excellent knowledge of how to
edit binary executables and changes it to create program B*. It would follow 
that the binary executable
is source.

Yes. The source for B* is the binary. The source for A* is the C++ files.
(I added the names above for clarification)

However, that shouldn't lead to the that compiling a program and 
changing two bytes with an hex editor makes the original files no longer 
be “source”.
In most cases, we should also look at the source of A* when working with 
B*, at least if B* is expected to be free software.




One completely different thing is when nobody has some form of
the work any longer. That form cannot be preferred for making
modifications, since it no longer exists. In this case, the actual
source is the preferred form for making modifications, among the
existing ones.

I write a program in C++ and release the binaries under a free license.
The binaries are not the source form. But five years later, when I lose
the USB which contained the only copy of the C++ code, the binaries
become source.
I'm most worried about authors falsely claiming «I lost the source» as 
an excuse for not disclosing them.



I'm also not too keen on the last part about space-inefficient form for 
audiovisual works. Which once more shows that software licenses are not 
the best suited license for media files :)

Re: Expat + exception = DFSG-compatible?

[Ángel González]

El 13/10/15 21:53, Ben Finney escribió:

Dmitry Smirnov  writes:


But my question really is whether it can be re-phrased to
blacklist/mention known offender(s) in a DFSG-compatible manner and
how...

The goal of excluding specific people, or groups of people, is not
compatible with software freedom. It's also not compatible with the
DFSG. Such a goal cannot be met in a free software license.

So, the resolution would entail getting at *why* They want to exclude
certain people, and see whether that underlying goal can be met.

That's the real point.

I guess something similar to what you wanted could be achieved by a 
wording like:
«This license does not provide any new rights to LitWare Inc. over the 
code for which they were terminated pursuing GPL §8 after they failed to 
comply with the license terms after being repeatedly notified since 2005.»


which is quite different than:
«The company Coho Winery cannot use this work, since when the founder 
filed for divorce [from me], it said very nasty things»

or
«Blue Yonder Airlines is not allowed to use this software, since planes 
are dangerous and nobody should operate them»



"some people just don't deserve free work to be made available to them." 
could mean anything.

Re: Consensus about the Academic Free License (AFL) v3.0

[Ángel González]

On 13/06/15 06:36, Walter Landry wrote:

Ángel Gonzálezkeis...@gmail.com  wrote:

On 12/06/15 23:22, Walter Landry wrote:
I would strongly disagree here. Requiring documentation of any sort 
in addition to the source code is a big step. This is not a minor 
thing. 

I don't think requiring that some documentation is provided with the
source code, makes it unfree.

Of course it does.  Mandating a minimum quality before releasing
things may be good software practice, but it is decidely unfree.  This
license prevents a certain class of modifications that, in the
original author's eyes, makes things worse.  But later people may
disagree in good faith.  For example, suppose that there is
documentation, but it is out of date to the point where it is
misleading.  This license prevents removing that misleading
documentation.  Even if you write new documentation, you have to
distribute the old documentation as well.

Cheers,
Walter Landry
I very carefully talked about requiring *some* documentation, as 
something opposed it to all available documentation, which is what AFL 
requires and makes it problematic.
Ironically, the most free program wrt this clause is one with no 
documentation at all.



--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/557cc075.2020...@gmail.com

Re: Consensus about the Academic Free License (AFL) v3.0

[Ángel González]

On 12/06/15 23:22, Walter Landry wrote:

Charles Plessyple...@debian.org  wrote:

Here are a few comments about the license.

  - point 3) is poorly worded, but assuming it is well-intented, it is Free.

I would strongly disagree here.  Requiring documentation of any sort
in addition to the source code is a big step.  This is not a minor
thing.
I don't think requiring that some documentation is provided with the 
source code, makes it unfree.


However, it could be intended to mean anything from Please don't strip 
comments from the code or Keep the doc/ folder from the repository 
when producing a src tarball to Include any documentation ever written 
related to modifying the original work (a patch howto, an emacs manual?).
If the licensor has a copy of Knuth's TAOCP (ie. it's available 
documentation), and it describes something on-topic for modifying the 
original work (eg. the work uses linked lists, described in Chapter 2) 
then the Licensor agrees to provide a machine-readable copy of TAOCP. ∎



--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/557b7d1c.8070...@gmail.com

Re: Is libav's current packaging scheme OK for Debian?

[Ángel González]

(CCing Bálint again, see previous mail in 
https://lists.debian.org/557459e3.6090...@debian.org)


On 07/06/15 16:49, Simon McVittie:

On 07/06/15 14:19, Bálint Réczey wrote:

The question now is how we should interpret DFSG with regard to Live
DVD-s. Should we stop packaging Libav (and later FFmpeg) in the
current scheme because it allows preinstalling hedgewars (GPLv2 only)
with libavcodec-extra-56 making the DVD violating the license of the
packages or let this be a concern for Live DVD creators?

The thing that is not allowed is either distributing a derivative work
of hedgewars source code with additional restrictions beyond those of
the GPL-2, or distributing a derivative work of libav source code with
additional restrictions beyond those of either GPL-2 or GPL-3.

The hedgewars binary is clearly a derivative work of hedgewars source
and, if you believe the FSF's assertions about dynamic linking, libav
source (via the libavcodec56 GPL-2+ binaries, to which it links).

I find it hard to justify how the hedgewars binary could possibly be a
derivative work of libavcodec-extra-56, given that libavcodec-extra-56
was not involved anywhere in the preparation of the hedgewars binary,
which (presumably) only uses published interfaces from libavcodec56.
Those interfaces happen to be compatible with those found in
libavcodec-extra-56.
You don't need the library source either for linking to a GPL library 
with dlopen(3). Still, the final program is considered [by the FSF] a 
derivative work of the library.
This looks very similar to libreadline issues, see 
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL


On the other hand, building with libavcodec56 but running with 
libavcodec-extra-56 would be similar to the psql libreadline workaround 
(bug 603599), currently used in Debian.




--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/557b8680.8020...@gmail.com

Re: GPL + question

[Ángel González]

On 30/05/15 03:30, Riley Baird wrote:

Only the copyright holder can change what a *work* is licensed as.

Unless the copyright holder grants the permission to do so, I would
say...

Let's say I hold copyright on a work, and I grant someone else
permission to change the license of a work. Who would enforce the
second license? Only a copyright holder can enforce their copyrights.
IMHO you would be the one responsible for enforcing the license... 
unless you also
granted (delegated?) the right of enforcing the work license to someone 
else.



--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/556a2aa5.90...@gmail.com

Re: GPL + question

[Ángel González]

On 31/05/15 00:10, Riley Baird wrote:

On Sat, 30 May 2015 23:24:53 +0200
Ángel Gonzálezkeis...@gmail.com  wrote:

IMHO you would be the one responsible for enforcing the license...

Exactly. So, if a work is originally licensed under GPL-2+ and Person A
makes a copy and gives it to Person B under GPL-3. Now consider that
Person B gives a copy to Person C under GPL-2+. Person A can't enforce
the original copyright holder's copyrights. I find it difficult to
believe that the original copyright holder would enforce Person A's
license.


unless you also
granted (delegated?) the right of enforcing the work license to someone
else.

I'm not sure that you can grant the right of enforcing the license to
someone else,

Copyright collecting societies do so.


otherwise why wouldn't copyleft authors just let
give everyone the right to enforce their license?
I suspect that for legal litigation you may need to represent the 
copyright owner.
Also note that if authors gave that power to everyone, anyone attempting 
to exercise that
right would still need the author in order to prove that the author 
didn't also provide a

propietary license to the infringer,¹ so it wouldn't be that useful.
Usually, copyright collecting societies are the only ones entitled to 
license that author's
work, and their position when detecting infringement is thus quite 
different.



¹ unless they also gave up the right to ever license it under different 
terms, perhaps. A

very bad idea IMHO.


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/556a50c1.2070...@gmail.com

Re: Dual licensed LGPL2.1/GPL3 linking to GPL3 with OpenSSL exception

[Ángel González]

On 28/02/15 02:31, Riley Baird wrote:

Hi -legal!

I was reviewing a package classified-ads for Debian, and I noticed a 
potential problem in the process. Namely, the author of the program has decided to use 
GPL3 with the OpenSSL exception. However, they have taken some files from Nokia which are 
dual licensed under either LGPL2.1 or GPL3. I think that since Nokia did not make the 
OpenSSL exception, Debian cannot legally distribute the result. However, I assume that it 
would be okay if the maintainer decided to change their license to LGPL2.1. Can someone 
confirm whether all of this is correct?

The project is here: https://github.com/operatornormal/classified_ads/
and the Nokia-licensed files are here: 
https://github.com/operatornormal/classified_ads/tree/master/textedit

Yours thankfully,

Riley Baird
Or they could keep the files from Nokia under LGPL2.1, and use 
GPL3+openssl exception for the rest of the files. Given that they have 
proper headers, I don't see a problem with that, although I would 
mention that in the readme.



PS: I don't see the OpenSSL exception anywhere there.



--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54f1e526.3060...@gmail.com

Re: Bug#779377: Dual licensed LGPL2.1/GPL3 linking to GPL3 with OpenSSL exception

[Ángel González]

On 01/03/15 00:05, Riley Baird wrote:

Or they could keep the files from Nokia under LGPL2.1, and use
GPL3+openssl exception for the rest of the files. Given that they have
proper headers, I don't see a problem with that, although I would
mention that in the readme.

But what license would the work as a whole be distributed as, then?

I see your problem now. Silly conflicts between opensource licenses.
Maybe LGPL2.1 can be upgraded to GPL3+openssl exception?
It fits the spirit of those licenses, but I don't know if that'd 
actually be

possible from a legal POV.


A LGPL2.1 library can be used in a binary under GPL3+openssl exception 
since section 6 states:
«you may also combine or link a work that uses the Library with the 
Library to produce a work containing portions of the Library, and 
distribute that work under terms of your choice, provided that the terms 
permit modification of the work for the customer's own use and reverse 
engineering for debugging such modifications» but I don't think you can 
apply GPL + openssl exception terms to a LGPL work since IMHO that would 
no longer be the  ordinary GNU General Public License.


Another option would be to relicense the program adding a LGPL linking 
exception, too.


If upstream doesn't mind relicensing under LGPL (per #25), I would 
recommend doing so, as that will be much clearer.


About Lenin photograph:
Don't concern about imaginary countries. Copyright is sufficiently 
complex with the existing ones :)
It's over 50 years pma which seems to be the copyright duration in 
Russia. And for US, which is not following
the shorter term rule of the Berne Convention, it's also PD for being 
published before 1923. I don't think it would be a problem, but IAANAL.



--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54f2634b.1020...@gmail.com

Re: Does logo under CC BY SA makes entire project SA

[Ángel González]

Simon pointed out the key question: if it is a derivative work or just 
an aggregation of two works (code + logo, or logo + text). I don't think 
it would be considered a derivative but IANAL.
Also note that even if the executable was a derivative work of the logo 
(and thus subject to the CC-BY-SA), the source code is not. You could 
remove/replace the logo and use the result following just the MIT 
license. Independently of being loaded at runtime or hardcoded.
It's even more clear for the documentation. Suppose you have a pdf with 
the logo on the first page, and CC-BY text in the rest. I could strip 
the first page and release the result under CC-BY, even if the full pdf 
could only be used under CC-BY-SA (which may or may not be the case).



IANAL, for legal issues consult with a lawyer, etc.


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54ee1fe3.4080...@gmail.com

Re: Some questions about trademark, copyright and dfsg

[Ángel González]

2) As a way to get funding and money. If a commercial company wants to 
support an open source project by becoming sponsor and include their 
logo in the software (for instance in an about menu or in the map of a 
game). Their logo and name are obviously trademarked and copyrighted. 
If I include this logo will my project be considered as dfsg friendly 
? Considering the whole package except the logo and sponsors part are 
open and free for modifications.
There is no way a company will openly allow their logo to be 
modified. In fact even debian protect its own logo.


https://www.debian.org/trademark

Does that mean open source and free software project can't include 
sponsor logo and company name ?


There's no problem in including the company name. Including the sponsor 
logo would make the application slightly unfree.


Also note that some logos are so simple there's no copyright on them.


3) if a debian packager modify my software for any reason. Will they 
warn me about modifications ? Will they change the name to avoid any 
confusion between my original project and the fork made by debian ? 
Will they remove sponsor logo for instance without warning us ?


The main reason for removing a logo would precisely be in order to allow 
it into Debian. The name could be changed, although IMHO it's not a 
reason strong enough for requiring that.


Regards


PS: I think you are looking at these things from the wrong perspective,. 
but it's good you asked.



--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e59c87.8080...@gmail.com

Re: Standard implementation of constant, copyright or not ?

[Ángel González]

On 15/01/15 23:39, Guilherme Brondani Torri wrote:

Thank you Walter.

Perhaps I should be more specific about the usage of the headers.

The included headers are distributed verbatim. The headers are 
included verbatim (stored as a constant string) into the binary. The 
headers provide physical constants and physical concepts to a model 
compiler. In case the user does not have a set of headers of his own, 
the binary spits out the verbatim copy to allow the model to be 
processed. In other words, the user has rights over the LGPL portion 
and can bypass the non-LGPL pass if he/she wishes to. (...)


So it seems it is not an integral part of the compiler, just a handy 
hardcoded value. I would change the compiler (preferably at upstream) to 
read those entries from individual files at /usr/share/ if not provided 
by the user. Put a package with just those files in non-free. If the 
compiler AND the user didn't provide those AND those default files don't 
exist (non-free pkg not installed), abort with a message explaining what 
they need.




If not I will think about ways not to anger and frustrate the users 
offering a tool that does not work out of the box.
As I understand it, the compiler _could_ work without those headers 
(assuming the unlikely case that the user had them himself). Otherwise, 
it can live in contrib and depend on the non-free package.

Re: Python library under permissive GPL-compatible license optionally using GPL library

[Ángel González]

Yaroslav Halchenko wrote:

Dear fellas who know much more about licensing than me.

I might have even asked before (since we are in a similar situation with
PyMVPA/shogun) but forgot what was the summary:

If we have a library X in Python, released under some GPL-compatible
license (e.g. BSD-3 or Expat) and then using (optionally) some GPL code
(at run time) provided by another library Y -- what are the implications?
Am I wrong on any of the following statements

- the project X codebase doesn't have to be relicensed to GPL
- the project X can use project Y (since under GPL compatible license)

- It is only at 'run time' when actual linking to the library Y happens,
   so project must comply with GPL but whose responsibility it is then
   and what needs to be enforced?

   - original distributor of X must have provided all the sources with
 modifications?  But it was user's decision to use GPL'ed library

   - or user must somehow make sure he has the sources... (sounds
 dubious)

- is mere ability to be used with GPL licensed library Y makes
   distributors of code of X required to comply with GPL? (e.g. provide
   modified sources)

Thanks in advance for your feedback

[1] http://mail.scipy.org/pipermail/nipy-devel/2014-December/010707.html

If the distributor were a distro like Debian IMHO:
- package X can be licensed under Expat
- package Y is licensed under GPL (I would probably add a warning on the 
description)


As package X already meets GPL requeriments that's not really a problem.

However, let's call X' to X + GPL-incompatible changes.

Then X' and Y couldn't be used together.


I suppose that if X' distributor actively encourage its users to use Y 
with its incompatible X',

he could be deemed liable for encouraging those copyright violations.
(this is quite different from simply allowing generic modules to be loaded)


You may be interested in the linking-with-libreadline story.


For your case I would simply document it (on a license page, when listing
modules for download… it will depend on your website structure)


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/548b7dc0.7010...@gmail.com

Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license

[Ángel González]

Thorsten Glaser wrote:

Ángel González dixit:


On 30/07/14 22:00, Stas Malyshev wrote:

You could not distribute other derived products bearing the name of PHP
- but distributing PHP itself is fine, since it's not a product derived
from PHP but the actual PHP. If Debian OTOH decides to make their own

The actual PHP is still normally patched in a distribution.


+  4B= On the other hand, minor patches to products already containing

Absolutely no! That would make the situation much worse.
This is very vague language, which will not help but
add insecurities.
I understand that's what the PHP developers are trying to express with 
the PHP License
(although it's not explictely named as such). You may prefer a term like 
substantially

modified but it's the same thing.



There is some ambiguity on what is a B+minor patchB;, but I feel it's better
to leave that to the courts should a lawsuit really arise (which would be a

The very idea of a distribution doing licence review is to
avoid things that could possibly, ever, go to court.
There are clear cases of minor changes (eg. it applies some three-line 
patches), clear
cases of major changes (suppose that the php engine was changed to run 
javascript
instead!) and cases where it's not that clear (and should thus be 
avoided without a

package rename).

You can see Scratch_Trademark_Policy for an example of lawyer-written 
text using similar terms.

http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code#Scratch_Trademark_Policy

Please remember that we are just talking about changes that Debian 
itself may want to
perform (so it doesn't require a renaming which would be bad both for 
PHP and Debian

users).



or later. Use Common Sense for determining if it's a minor patch.

That does not work in a legal environment, unfortunately.
That tried to explain the . Yet some dumb could that their 
javascript-running engine
can be named php-foo because he has a series of three-line patches 
converting one

into the other.



This is why the OSI (and many others) say to please leave
writing licences (code for the scripting language called
legalese) to experts (lawyers), just as we’d not want the
lawyers to write C code.
This was just a proposal that could serve as starting point. I wouldn't 
expect that PHP

blindly accepted it without consulting a lawyer!



Would this change have the blessing of Debian and the approval of PHP?

I highly doubt it. The current php5 source package in Debian
has 49 patches… on top of a 5.6 release candidate. Things like
porting to new platforms, etc. are not minor. One is named
“hack-phpdbg-to-explicitly-link-with-libedit.patch”. You could
say that every distribution makes a fork.
Even with that funny name, it only changes 
PHPDBG_EXTRA_LIBS=$PHP_READLINE_LIBS to PHPDBG_EXTRA_LIBS=-ledit 
-ltermcap.
I have reviewed them. Most are trivial-minor at first sight, often 
chanes to m4s.

Some fpm patches do define new functions and may deserve a second look (but
are still simple, specially when compared to the full codebase).
use_embedded_timezonedb.patch does , although .

You raise a good point about porting, although it doesn't seem so bad. 
Those

should be small changes (perhaps problems would appear if you needed to
include a lot of patches copying libc functions not available natively…
but instead of copyng them on each program, they should be a library).


At the end of the day, php is substantially the same software on Linux 
or Hurd
(where ptrace(2) doesn't work so Debian patched it), using date.timezone 
or getting

it from /etc/localtime
Changes to the build system seem specially clear as “not changing too 
much” the program itself.




Looking at a BSD… there are 34 patches in MirPorts for PHP
as well,
I count only 20 :S (all minor things, some that should have been done at 
PHP)


(As an aside, it's sad in general to check package patches, since most 
of them

should really be at upstream…)



though the licence information there is set to say
that binaries may not be redistributed.
You are creating the patches with a license not allowing binary 
redistribution?? You leave me

speechless.



Another option would be to simply rename PHP to… Icescriptinglanguage? ;-)
Well, that would be bad for Debian users just due to not fixing the 
license to say what they
mean. Quite similar to the problem a few years back of djb programs 
(considered
uncopyrightable by himself) which could not be considered PD due to lack 
of an explicit

license.


Thanks for your insights, Thorsten



PS: The cvs daemon at anoncvs.mirbsd.org doesn't seem to be listening on 
its IPv4 interface (81.169.181.30).

Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license

[Ángel González]

On 30/07/14 22:00, Stas Malyshev wrote:

On the other hand, my own reading of the PHP Licence is that we may not,
in fact, distribute (binaries of) modified versions of PHP software (the
interpreter as well as everything else under that licence), period - but

You could not distribute other derived products bearing the name of PHP
- but distributing PHP itself is fine, since it's not a product derived
from PHP but the actual PHP. If Debian OTOH decides to make their own
fork of PHP, they can distribute it still, but not under the name of
PHP. I don't think Debian even claimed that the thing they distribute
under the name of PHP is anything but the original product, so I don't
see a problem here. I'm not sure why there's an effort to seek maximally
contorted interpretation of the rules that would appear to disallow
Debian to do something that Debian is already doing, has been doing for
years, and nobody ever objected to Debian doing and nobody ever intends
to object. To me this effort does not seem to be constructive, and not
leading to any improvement of anything, but only to more inconvenience
and annoyance to everybody involved.

They have a point. A buggy php version with an added patch that avoids
that it crashes when run on even dates could be considered -from a legal
POV- a «derivative product of PHP». Legal-speak is quite different than
common sense.

Trying to keep the spirit of the PHP License and at the same time solve 
that
strict interpretation, I propose the following change to the PHP License 
3.01,

which will hopefully please both parties:


--- 3_01.txt2014-07-30 22:58:13.682449866 +0200
+++ 3_02.txt2014-07-30 23:20:07.332445907 +0200
@@ -24,6 +24,13 @@
  from gr...@php.net.  You may indicate that your software works in
  conjunction with PHP by saying Foo for PHP instead of calling
  it PHP Foo or phpfoo
+
+  4½ On the other hand, minor patches to products already containing
+ the PHP label, including without exception those fixing its
+ security and/or functionality, are not considered a new product
+ and do not require any additional permission. Nonetheless their
+ version string should be modified in order to clearly differenciate
+ them from the official versions published by the original author(s).

   5. The PHP Group may publish revised and/or new versions of the
  license from time to time. Each version will be given a

Notes:
There is some ambiguity on what is a «minor patch», but I feel it's better
to leave that to the courts should a lawsuit really arise (which would be a
non-clear case) than attempting to set an arbitrary limit on number of diff
lines or an appropiate ratio with the original code, which would fail sooner
or later. Use Common Sense for determining if it's a minor patch.

Still, bugfixes are explicitely listed as minor, given that they will be 
the most

common case and the one which concerns Debian modifications.

The result of those small modifications of PHP-labeled products is that 
requisites
of §3 and §4 are waived, which IMHO is in the spirit of the PHP License 
as asserted

by the current usage.

The mention for modifying the version string was inspired by Thorsten 
email, and
is related to the clause present on other licenses that a Modified work 
should be
presented as such. A variant would be changing the should into 
shall. I chose
the former version to allow waiving the requirement for trivial changes 
or those
without a clear version string (think on builds from git or from 
proposed patches).


The term “original author(s)” was preferred over “The PHP Group” for 
including works

by third parties.

PS: 4½ is just a placeholder for discussion, the final version would 
need renumbering.



Would this change have the blessing of Debian and the approval of PHP?


--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d969ef.7090...@gmail.com