Re: Freeness of vague Synopsys license

[Andreas Bombe]

On Mon, Nov 20, 2017 at 11:11:28AM +, Ian Jackson wrote:
> Andreas Bombe writes ("Freeness of vague Synopsys license"):
> > Keeping these files would be "nice to have" but not a requirement. Users
> > with legacy VHDL projects using Synopsys libraries would need to find
> > and install these libraries themselves if they were removed.
> 
> Even better: that means that in the very unlikely even that someone
> would disagree with our interpretation, we could simply remove these
> files again without having to untangle a lot of within-Debian
> rdepends.
> 
> But even if that weren't the case I think the necessarily implication
> is that permission was granted (and the copyrightholders are likely to
> be estopped from claiming otherwise because everyone has been relying
> on that implied permission for, presumably, years).

Thank you (and Ben). I think I'll go with leaving it in and letting
ftpmasters decide.

A bigger problem were the core IEEE libraries that received a
more-but-insufficiently permissive license in the years since the last
ghdl upload to Debian (from "written permission required for basically
everything" to "free to distribute and use but explicitly no changes
except those permitted in the VHDL standard"). But thankfully there's
now GPL reimplementations for those.


Andreas

Re: French gov open license

[Ben Finney]

Jérémy Lal  writes:

> I don't think there is such a thing named "recognized by DFSG".

I agree.

> A license can pass DFSG or not, and this one, after reading it,
> seems to be okay.

More precisely, “pass DFSG” is not something we can ask of licenses.
Rather, the DFSG are for evaluating a *work* proposed for entry to
Debian.

Until we have a work to examine, with a grant of license from the
copyright holders (and holders of other monopolies) in that work, the
question of DFSG doesn't even come up.

So, the question will need to be asked about a work proposed for entry
into Debian.

-- 
 \ “For myself, I am an optimist — it does not seem to be much use |
  `\  being anything else.” —Winston Churchill, 1954-11-09 |
_o__)  |
Ben Finney

Re: legal issues of libmusicxml

[Ian Jackson]

Joël Krähemann writes ("legal issues of libmusicxml"):
> I consider adding library routines support for MusicXML to my
> application in main.
> 
> http://www.musicxml.com/for-developers/musicxml-xsd/
> http://www.musicxml.org/dtds/license.html
> 
> Would this cause a legal conflict? Or would it make it impossible to
> distribute in main?

Just adding "support" for musicxml doesn't pose any issues whatsoever.

If you need to copy the DTSs into your program then they would have to
be free.  But I read the licence text you linked to and it seems like
a fairly straightforward permissive licence.  It looks
[A]GPL[123]-compatible to me, even.

So unless your "application in main" has a very odd licence, that too
is fine.

Don't forget to copy the licence text etc. into your program, if you
copy the DTDs, of course.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: French gov open license

[Jérémy Lal]

Hi Xavier,

I don't think there is such a thing named "recognized by DFSG".
A license can pass DFSG or not, and this one, after reading it,
seems to be okay.
Hopefully more experimented eyes will read it too.

IANAL,
Jérémy (x97).




2017-11-21 18:35 GMT+01:00 Xavier :

> Hi all,
>
> French government uses now lo/ol license to publish its open datas:
> https://www.etalab.gouv.fr/wp-content/uploads/2014/05/Open_Licence.pdf
>
> "To facilitate the re-use of the « Information », this licence has been
> designed to be compatible with any licence which requires at least the
> attribution of the « Information ». For instance, it is compatible with
> the « Open Government Licence » (OGL) of the United Kingdom, the «
> Creative Commons Attribution 2.0 » (CC-BY 2.0) licence of Creative
> Commons and the « Open Data Commons Attribution » (ODC-BY) licence of
> the Open Knowledge Foundation."
>
> Can it be recognize by DFSG ?
>
> Regards,
> Xavier
>
>

French gov open license

[Xavier]

Hi all,

French government uses now lo/ol license to publish its open datas:
https://www.etalab.gouv.fr/wp-content/uploads/2014/05/Open_Licence.pdf

"To facilitate the re-use of the « Information », this licence has been
designed to be compatible with any licence which requires at least the
attribution of the « Information ». For instance, it is compatible with
the « Open Government Licence » (OGL) of the United Kingdom, the «
Creative Commons Attribution 2.0 » (CC-BY 2.0) licence of Creative
Commons and the « Open Data Commons Attribution » (ODC-BY) licence of
the Open Knowledge Foundation."

Can it be recognize by DFSG ?

Regards,
Xavier

Re: EULA vs BSL,EULA vs BSL

[Walter Landry]

IOhannes m zmölnig (Debian/GNU)  wrote:
> (please CC me, as i'm not subscribed to the list)
> 
> On 2017-11-20 22:20, Walter Landry wrote:
>>>
>>> now i wonder, are these header files licensed under the EULA or under
>>> the BSL?
>> 
>> Are the headers sufficient for development, or does it require some
>> compiled libraries?  If so, it does not matter if the headers are
>> free, since the libraries will be required for any development anyway.
>> 
> 
> good point, with another fun answer:
> in order to successfully use the entire thing, indeed a non-free shared
> library is required.
> the fun part is, that this library is *not* part of the SDK.
> the library is part of another piece of non-free software. however, this
> other piece (including the library) is not protected by the same EULA,
> and it doesn't forbid the distribution (it doesn't explicitely allow it
> either; so i might need to check that with upstream as well).

I think you are just going to have to check with upstream.  The
licensing is inconsistent.

Walter Landry

legal issues of libmusicxml

[Joël Krähemann]

Hi,

I consider adding library routines support for MusicXML to my
application in main.

http://www.musicxml.com/for-developers/musicxml-xsd/
http://www.musicxml.org/dtds/license.html

Would this cause a legal conflict? Or would it make it impossible to
distribute in main?

Bests,
Joël Krähemann

Re: EULA vs BSL,EULA vs BSL

[Debian/GNU]

(please CC me, as i'm not subscribed to the list)

On 2017-11-20 22:20, Walter Landry wrote:
>>
>> now i wonder, are these header files licensed under the EULA or under
>> the BSL?
> 
> Are the headers sufficient for development, or does it require some
> compiled libraries?  If so, it does not matter if the headers are
> free, since the libraries will be required for any development anyway.
> 

good point, with another fun answer:
in order to successfully use the entire thing, indeed a non-free shared
library is required.
the fun part is, that this library is *not* part of the SDK.
the library is part of another piece of non-free software. however, this
other piece (including the library) is not protected by the same EULA,
and it doesn't forbid the distribution (it doesn't explicitely allow it
either; so i might need to check that with upstream as well).

in any case, the SDK comes with a thin wrapper (BSL-licensed) that
dlopen()s the library.

so to answer your question: afaict, all the files required to *develop*
software are licensed under the BSL (but protected by "the EULA").
(and to *use* it you need their properietary library, drivers, firmware
and hardware).


@pabs, regarding alternative hardware: this doesn't help me much given
the couple of Decklink cards lying around in my office.


the question however is really targetted at what I am allows to do with
files that include a BSL boilerplate but are hidden behind a EULA that
forbids distribution.

oh, btw:
upstream only introduced that EULA last year or so.
some versions of the headers in question are already shipped in Debian.
most likely these versions pre-date the surrection of the EULA-wall (so
they're distributed under the BSL in good faith).


vcmxfg
IOhannes

Re: clementine: installs non-free plugin at runtime

[Ian Jackson]

Anthony DeRobertis writes ("Re: clementine: installs non-free plugin at 
runtime"):
> I think it'd be reasonable to make the confirmation dialog explicitly
> say that the plugin is not free software. But other than that, which
> does not warrant severity: serious, I think this bug should be closed as
> not a bug.

With Debian's current stance on recommending non-free software (ie, we
are, contrary to our principles, happy to do it even if the user has
decided they do not want non-free), I agree with you.


Personally I think it should be a bug if any package in main offers to
download and run non-free software, other than in some kind of
restricted environment[1], if the user does not have the Debian
non-free area enabled.

[1] The distinction I am making is between what might normally be
thought of as programs, and situations where a turing-complete
protocol is used to deliver and display something that the user
inevitably knows is controlled by someone else and which they have
explicitly asked for.  For example, the JS in web pages; documents
provided as PostScript files, or whatever.

This rule would distinguish the binary blob Spotify client (forbidden)
from the proprietary music files it downloads (permitted, if there
were a Free client that could do the download).

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.