> On May 25, 2024, at 10:03, Francesco Poli wrote:
>
> Some minor nitpicks (once again, by a non-native speaker, so they could
> be wrong...): it's not the PHP License, version 4.0, which adopts the
> 3-clause BSD license; it's the PHP Group which adopts the 3-clause BSD
>
;> Please let me know if you have any feedback on these changes.
> >
> > After a short review, they look OK to me.
> >
> > The only thing that I would emphasize more is: the PHP License, version
> > 4.0 should not just have the text identical to the 3-clause BSD
&
diff of the changes here:
>>
>> https://wiki.php.net/rfc/php_license_update?do=diff%5B0%5D=1716433712%5B1%5D=1716437291=sidebyside
>>
>>
>> Please let me know if you have any feedback on these changes.
>
> After a short review, they look OK to me.
>
> The
33712%5B1%5D=1716437291=sidebyside
>
>
> Please let me know if you have any feedback on these changes.
After a short review, they look OK to me.
The only thing that I would emphasize more is: the PHP License, version
4.0 should not just have the text identical to the 3-clause BSD
license,
> On May 21, 2024, at 19:58, Ben Ramsey wrote:
>
> This is something that didn’t cross my mind while I was putting together the
> RFC, so I’m glad I posted to this list.
>
> Thank you for the suggestions! I’ll update the RFC and will reply here when
> I’ve made the changes.
I’ve updated the
> On May 21, 2024, at 16:32, Francesco Poli wrote:
>
> On Sun, 19 May 2024 14:53:48 -0500 Ben Ramsey wrote:
>
>> On May 19, 2024, at 11:42, Francesco Poli wrote:
> [...]
>>> If the PHP Group decides to elect the 3-clause BSD license as the next
>>> versio
> On May 21, 2024, at 11:49, Richard Laager wrote:
>
> On 2024-05-19 14:53, Ben Ramsey wrote:
>> One of my goals with the RFC is to get rid of the idea of a “PHP License,”
>> so it deprecates the PHP License and *replaces* it with the BSD 3-Clause
>> License. I do
On Sun, 19 May 2024 14:53:48 -0500 Ben Ramsey wrote:
> On May 19, 2024, at 11:42, Francesco Poli wrote:
[...]
> > If the PHP Group decides to elect the 3-clause BSD license as the next
> > version (4.0) of the PHP License, then clause 5 of the PHP License version
> > 3.01
On 2024-05-19 14:53, Ben Ramsey wrote:
One of my goals with the RFC is to get rid of the idea of a “PHP License,” so
it deprecates the PHP License and *replaces* it with the BSD 3-Clause License.
I don’t want there to be a “PHP License, version 4.0.” I think that will
continue to cause
> On May 19, 2024, at 11:42, Francesco Poli wrote:
>
> Here's some feedback about version 0.3 of your RFC.
>
>> The proposed changes for the PHP software repository will not affect
>> the PHP Manual. The PHP Manual will remain licensed under the Creative
>> C
On Sat, 18 May 2024 15:18:36 -0500 Ben Ramsey wrote:
> Hi, all!
Hello Ben!
>
> Over the years, the open source community, including Debian, has had
> a few lengthy discussions and disagreements regarding the PHP
> license.[^1][^2][^3] The TL;DR sentiment of all these discus
On Sat, May 18, 2024 at 03:18:36PM -0500, Ben Ramsey wrote:
> Hi, all!
>
> Over the years, the open source community, including Debian, has had a few
> lengthy discussions and disagreements regarding the PHP license.[^1][^2][^3]
> The TL;DR sentiment of all these discussions amo
Hi, all!
Over the years, the open source community, including Debian, has had a few
lengthy discussions and disagreements regarding the PHP license.[^1][^2][^3]
The TL;DR sentiment of all these discussions amounts to: change the license to
something well-understood and less problematic.
So
Hi,
Currently coinutils [1] is shipping files in
'/usr/share/coin/Data/Samples/', this has been going on for the entire
lifetime of the package, since June 2008. During this time the files has
been assumed to retain the license of the rest of the package, EPL-1.
Upstream has done some changes
in
this particular case.
That said, the _ideal_ situation would be for the copyright holder to
explicitly clarify the situation. My recommendation would be:
Best: Change the make_*.c files to be LGPL.
Good: Change the make_*.c files to put some permissive license grant
into the files. This is the gcc/autoconf
Hi!
At work we have been checking whether switching to FreeSWITCH would
be feasible, with an eye to eventually help package and/or maintain
it in Debian (as part of <https://bugs.debian.org/389591>). One of
the points was doing a license audit. For context, because FreeSWITCH
is licensed
* John Thorvald Wodder, II:
> It is my understanding that when an executable program that depends (directly
> or indirectly) on libraries licensed under (picking one license here) the MIT
> license is compiled into a binary that statically links these libraries, and
>
On Wed, 2023-09-27 at 10:41 -0400, John Thorvald Wodder II wrote:
> So was this problem previously known but under-acknowledged, or was it simply
> not brought up before now? I find it surprising that Debian would allow so
> many license violations to get this far. Is fixing th
On Wed, 2023-09-27 at 11:03 -0400, John Thorvald Wodder II wrote:
> On further inspection, it turns out that bat itself compiles the text
> of its NOTICE file into the binary, and the text is displayed when
> running `batcat --acknowledgements`, so bat's Apache 2.0 license is
> be
* On 9/27/23 21:10, Sam Hartman wrote:
>> "Mihai" == Mihai Moldovan writes:
>
> Mihai> In this case, we're "just" talking about missing notices for
> Mihai> dependencies that are pulled in, which might not be nice, but
> Mihai> also, realistically, nobody would really care about
> "Mihai" == Mihai Moldovan writes:
Mihai> In this case, we're "just" talking about missing notices for
Mihai> dependencies that are pulled in, which might not be nice, but
Mihai> also, realistically, nobody would really care about or try to
Mihai> enforce it (unless somebody
dated the wiki page to link to it.
>>
>> https://wiki.debian.org/StaticLinking
>
> So was this problem previously known but under-acknowledged, or was it simply
> not brought up before now? I find it surprising that Debian would allow so
> many license violations to get this
have requested that
> the ftp-master team turn on auto-rejections for the lintian tag.
On further inspection, it turns out that bat itself compiles the text of its
NOTICE file into the binary, and the text is displayed when running `batcat
--acknowledgements`, so bat's Apache 2.0 license is bein
/StaticLinking
So was this problem previously known but under-acknowledged, or was it simply
not brought up before now? I find it surprising that Debian would allow so
many license violations to get this far. Is fixing the tooling to handle this
considered a priority? If the author of an uncredit
On Wed, 2023-09-27 at 05:24 +, Stephan Verbücheln wrote:
> Are the upstream developers not already legally required to include all
> this information into various places including their “Help-About” menu?
It is definitely not common practice to document the copyright/licens
On Wed, 2023-09-27 at 08:36 +0800, Paul Wise wrote:
> This more general problem is very hard to impossible to solve,
> since it would mean patching every single build toolchain and
> source package [...]
Are the upstream developers not already legally required to include all
this information into
On Tue, 2023-09-26 at 14:20 -0400, John Thorvald Wodder II wrote:
> - bat (In addition to the type of problem discussed above, the source code for
> bat has an Apache 2.0 `NOTICE` file, yet this is not included in the .deb
> package.)
Please file a severity serious bug report against bat
copyright and license of source files we distribute but does not trace
the path from source files to compiled files, and therefore does not
trace which source files each generated file was created from and as a
subset of that problem, does therefore not trace the flow of copyright
and license information
with Athos that we should extend the Lintian warning.
3) Ultimately, it is the ftp-master's job to determine whether php-doc's
license is suitable for Debian or not. I don't think it's
necessary/beneficial to extend this discussion here.
Having said that, I will review and sponsor the package
I am a concerned citizen who, while looking into prior art for handling
dependency licenses in order to inform some of my own projects, stumbled upon
what appear to be systemic license violations in the Debian repositories
regarding dependencies of statically-linked compiled binary programs
?
Figure out (from the history of the code, etc.) if that license applies.
Looking into this a bit, I found this repository (which I am _assuming_,
but have not verified, is a faithful import of NCSA httpd):
https://github.com/TooDumbForAName/ncsa-httpd/
I definitely see some code from mini-httpd's
Dear debian-legal,
I would like to better sum up my earlier question as follows:
I'm in the process of adopting the mini-httpd package.
mini-httpd contains early portions of code commited by Rob
McCool which seem to originate from NCSA httpd. (License:
https://web.archive.org/web/20060830015540
Le 28 juin 2023 16:25:09 GMT+01:00, Joshua Allen a écrit :
>Dear Debian Legal,
>
>I was going through the Nethack General Public License and even though it is a
>free software license obviously not compatible with the GNU GPL, how do you
>maintain it without calling it netha
Dear Debian Legal,
I was going through the Nethack General Public License and even though
it is a free software license obviously not compatible with the GNU GPL,
how do you maintain it without calling it nethack though since the only
official nethack releases can be called nethack. If you
ual lawyer review has how shall we
say been variable for a variety of factors.
Johannes> The non-free binary blobs covered by this license apply to
Johannes> popular platforms like the IMX8MQ (which is used by the
Johannes> purism librem5 phone and the mnt reform laptop) as we
Hi,
Quoting Sam Hartman (2023-06-22 16:46:51)
> >>>>> "Johannes" == Johannes Schauer Marin Rodrigues
> >>>>> writes:
>
> Johannes> Dear Debian legal, I seek advice on the NXP Software
> Johannes> License Ag
Hi all,
Thank you for your prompt responses.
On 2023-06-22 17:49, Sam Hartman wrote:
I mean under xpat, it's certainly free for academic users, and it's also
free for everyone else.
Unless that statement in the readme is in a section called license or
otherwise claims to be a license, I'd
gt; "EvoEF2 is free to academic users."
Andrius> To me such limitation seems to contradict the Expat
Andrius> license, but I wonder what is the legal opinion about such
Andrius> combination. I know that I can always ask the upstream for
Andrius> clarification which I did
>>>>> "Johannes" == Johannes Schauer Marin Rodrigues writes:
Johannes> Dear Debian legal, I seek advice on the NXP Software
Johannes> License Agreement and whether binaries licensed under it
Johannes> are redistributable in non-free(-firmware) o
contributions do not specify a license for his work.
I've worked a bit and found the original NCSA httpd license from the 90s (I'll
post it here to spare you the work). We have concerns about the current
situation and DFSG compatibility. Nicholas( my mentor) stated that apache2
might be in the same
Dear Debian legal,
I seek advice on the NXP Software License Agreement and whether binaries
licensed under it are redistributable in non-free(-firmware) or not. The full
text is at the end of this email. I think the interesting parts are in 2.1, 2.2
and 2.3. If I'm reading this correctly
;
>> "EvoEF2 is free to academic users."
>>
>> To me such limitation seems to contradict the Expat license, but I
>> wonder what is the legal opinion about such combination. I know that I
>> can always ask the upstream for clarification which I did earlier when
o academic users."
>
> To me such limitation seems to contradict the Expat license, but I
> wonder what is the legal opinion about such combination. I know that I
> can always ask the upstream for clarification which I did earlier when
> the restriction was:
>
> "...
Hello,
[Please keep me in CC, I am not subscribed]
I encountered a package EvoEF2 [1] which is licensed under Expat and has
the following in its README.md:
"EvoEF2 is free to academic users."
To me such limitation seems to contradict the Expat license, but I
wonder what is
I have change license and I P because I'm the true Copyright and
intellectual property and patent holder
On Thu, 2023-03-23 at 14:13 +0300, undef wrote:
> Also I found this soundfont in the existing Debian package minuet-data by path
> /usr/share/minuet/soundfonts/GeneralUser-v1.47.sf2. [1]
I suggest you bring this to the attention of minuet-data upstream and
also file a bug about it in Debian if
I don't think this license would pass ftp-master review, there is too
much uncertainty about the provenance and license of the samples.
Thank you for the answer.
Also I found this soundfont in the existing Debian package minuet-data by path
/usr/share/minuet/soundfonts/GeneralUser-v1.47.sf2
On Wed, 2023-03-22 at 23:47 +0300, undef wrote:
> ** License of the complete work **
> You may use GeneralUser GS without restriction for your own music
> creation, private or commercial. This SoundFont bank is provided to the
> community free of charge. Please feel free to us
Hello.
GeneralUser GS [1] is a SoundFont bank for playing MIDI files. Its
license contains such sentences:
---
** License of the complete work **
You may use GeneralUser GS without restriction for your own music
creation, private or commercial. This SoundFont bank is provided
Hi,
V2Fly project provides a geoip data file in
https://github.com/v2fly/geoip. The license is declared as CC-BY-SA-4.0
but it uses the data from GeoLite2, which is licensed under an EULA
https://www.maxmind.com/en/geolite2/eula. The EULA looks like not a
free license.
Debian packages
before.
Do you mean the PHP-3.0[-only] issue:
https://lintian.debian.org/tags/license-problem-php-license
which appears to be the same as the PHP-3.1[-or-greater?] issue?
https://ftp-master.debian.org/php-license.html
Is the problem you're referring appears to be that this license places
Thanks Richard. I was unaware of the XML versions.
So, this would mean that SPDX considers what Debian calls the MIT (Expat)
license to match what SPDX calls MIT because the differences are all either
considered by SPDX to be omittable or replaceable as demonstrated by the tags
in the XML
On Tue, Jan 17, 2023 at 2:06 AM Axel Beckert wrote:
>
> Hi,
>
> Soren Stoutner wrote:
> > There appears to be some question of opinion
>
> Not opinion. Just the point of what the meaning of _text colors_
> *rollingeyes* in a license do mean. I just ignored them an
Hi,
Soren Stoutner wrote:
> There appears to be some question of opinion
Not opinion. Just the point of what the meaning of _text colors_
*rollingeyes* in a license do mean. I just ignored them and then those
two licenses differ.
> as to if the Debian MIT (Expat) License is
>
SPDX itself might have an answer that is satisfactory:
"The original replaceable text appears on the SPDX License List webpage in red
text."
"Omittable text appears on the SPDX License List webpage in blue text."
https://spdx.github.io/spdx-spec/v2.3/license-matching-guid
There appears to be some question of opinion as to if the Debian MIT (Expat)
License is
the same as the SPDX MIT License.
https://www.debian.org/legal/licenses/mit[1]
https://spdx.org/licenses/MIT.html[2]
Can somebody at Debian Legal please comment?
--
Soren Stoutner
so...@stoutner.com
ll either sponsor an upload
> if everything looks good or provide feedback.
The update looks great! I have updated debian/copyright to document
the files that are licensed under a license other than the LGPL, but
otherwise everything looks good. I will upload today.
For the time-being, I will
On Sun, Jan 15, 2023 at 10:02:55PM +0100, Helmar Gerloni wrote:
> > https://lists.debian.org/debian-legal/2023/01/msg5.html
> > https://lists.debian.org/debian-mentors/2023/01/msg00097.html
> Roberto, Tobias, thanks for your answers.
>
> I have removed MagicSFver2.sf2 from the package and
> https://lists.debian.org/debian-legal/2023/01/msg5.html
> https://lists.debian.org/debian-mentors/2023/01/msg00097.html
Roberto, Tobias, thanks for your answers.
I have removed MagicSFver2.sf2 from the package and added a note to
README.Debian.
The new package now depends on
>From my personal experience of 15+ years contacting with authors of thousands
of "free" sound fonts: they are usually composed of sounds taken from random
places, and nobody really knows who made them or what their license are. Many
of them take samples from other "free"
Hello legal team,
I am trying to update the Tuxguitar package from version 1.2 to 1.5.6.
The new version includes the soundfont "Magic Sound Font v2.0". While Tuxguitar
is licensed under LGPL-2.1+, the license of the soundfont file
(MagicSFver2.sf2) is not 100% clear.
The issue was
gt;>https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs
>
> Hi Paul, Thanks for the pointers.
>
> While I am working on packaging details, I still want to make sure it is
> OK to re-introduce the package due to the PHP-3.0 issues I pointed
> before.
&
: License question virtualbox-ext-pack vs.
virtualbox-guest-additions-iso
Date: Thu, 10 Nov 2022 13:54:01 +0100
From: Christian Kuka
To: team+debian-virtual...@tracker.debian.org
Hi all,
In our team we just came across the question which license apply to the
virtualbox debian packages
czw., 20 paź 2022 o 01:53 Michael Lustfield
napisał(a):
> (forgive the phone formatting)
>
> This project is clearly stating that the intended license is GPLv2+. It
> might be specified in just the one file, but that file is also clearly
> intended to represent the project
(forgive the phone formatting)
This project is clearly stating that the intended license is GPLv2+. It
might be specified in just the one file, but that file is also clearly
intended to represent the project.
It's fine as-is, but still worth chatting with upstream. The "LICENSE&
Hello,
I'd like to package [1] a program which is GPLv2+ licensed, but as far as I
can tell, this fact is only stated in a couple [2] of [3] lines of its
setup.py build script. This is a bit of an obscure way to state the license
for my taste. However before I bother the upstream maintainer about
Il giorno lun 3 ott 2022 alle ore 21:50 Simon McVittie ha
scritto:
>
> On Mon, 03 Oct 2022 at 21:12:50 +0200, Roberto A. Foglietta wrote:
> > Are you referring to the special permission given by e-mail by Donald
Randall
> > in 2003?
>
> I think you're misreading the copyright file. Randall Donald
On Mon, 03 Oct 2022 at 21:12:50 +0200, Roberto A. Foglietta wrote:
> Are you referring to the special permission given by e-mail by Donald Randall
> in 2003?
I think you're misreading the copyright file. Randall Donald is a Debian
contributor who asked Nvidia for permission to redistribute their
Il giorno lun 3 ott 2022 alle ore 20:42 Simon McVittie ha
scritto:
> On Mon, 03 Oct 2022 at 19:52:23 +0200, Roberto A. Foglietta wrote:
> > reading this link here below, it seems that compilation and repackaging
> the
> > content is prohibited by their license. W
On Mon, 03 Oct 2022 at 19:52:23 +0200, Roberto A. Foglietta wrote:
> reading this link here below, it seems that compilation and repackaging the
> content is prohibited by their license. What's your opinion on this?
Please note that the Debian maintainers of nvidia-graphics-drivers have
re
Hi all,
reading this link here below, it seems that compilation and repackaging
the content is prohibited by their license. What's your opinion on this?
https://opensource.stackexchange.com/questions/10082/geforce-nvidia-driver-license-for-commerical-use
In fact, up today (515.76) the .run
he
> Richard> file" is consistent with the DFSG. This is one of a variety
> Richard> of 1990s FreeBSD 3-clause BSD variants with such a feature.
>
> Well, under DFSG 4, the license could have required that no
> modifications be made to the source file at all:
>
&g
of a variety
Richard> of 1990s FreeBSD 3-clause BSD variants with such a feature.
Well, under DFSG 4, the license could have required that no
modifications be made to the source file at all:
>4. Integrity of The Author's Source Code
> The license may restrict source-code
Greetings debian-legal!
I understand Debian includes the package libbsd in Debian main. This
package includes a man page with the following license (see
https://git.hadrons.org/cgit/debian/pkgs/libbsd.git/tree/debian/copyright#n214)
License: BSD-5-clause-Peter-Wemm
Redistribution and use
* Sam Hartman:
>>>>>> "Francesco" == Francesco Poli writes:
> Francesco> I am under the impression that a more correct way to
> Francesco> achieve the same results (free or non-free) would be to
> Francesco> create a different licens
On Thu, 08 Sep 2022 23:32:34 -0600 Sam Hartman wrote:
[...]
> That's certainly what the FSF would prefer you do, yes.
> However, there are a few things to consider:
>
> 1) It's not clear that the FSF's copyright on the GPL allows you to
> borrow text from it for your license. I
>>>>> "Francesco" == Francesco Poli writes:
Francesco> I am under the impression that a more correct way to
Francesco> achieve the same results (free or non-free) would be to
Francesco> create a different license, possibly reusing some part
t; Francesco> That does not seem a correct way to apply the GPL...
>
> No, it does not. That term--the term that forbids you from adding
> restrictions--clearly conflicts with the "main body of the license," so
> the main body of the license rather than the GPL con
k-related packages
- OCS iventory
- OpenVAS
- nikto
- brutespray
- 2 Python libraries
- 1 Perl library
- 1 Golang library
> The DFSG item 9 is also more about contamination by means of
> distribution other than interaction between the tools, as it says:
> "The license must not place res
it does not. That term--the term that forbids you from adding
restrictions--clearly conflicts with the "main body of the license," so
the main body of the license rather than the GPL controls. Clearly such
a license is not GPL compatible, although it may be free. Other
discussion in
On Sun, 04 Sep 2022 20:29:24 -0700 Walter Landry wrote:
[...]
> Covered Software is licensed to you under the terms of the GPL
> (Exhibit A), with all the exceptions, clarifications, and additions
> noted in this Main License Body. Where the terms in this Main License
> Body conflic
On Mon, 05 Sep 2022 23:48:38 +0200 Hilko Bengen wrote:
[...]
> It has been suggested that upstream switch the
> license to AGPL3 instead, but nothing of the sort has happened and I
> don't expect such a change to happen anytime soon.
[...]
Speaking for myself: please, no.
Althoug
between the tools, as it says:
"The license must not place restrictions on other software that is
distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium
must be free software."
Considering both things, I'm
Hello all,
On Mon, 5 Sept 2022 at 23:17, Hilko Bengen wrote:
> My analysis posted there in March 2021 still stands: Upstream's broad
> definition about what constitutes a "derivative work" (a term that
> matters a lot in GPL 2) conflicts with the DFSG #9 "License Must
* Samuel Henrique:
> Nmap has just released its version 7.93, and it comes with a new
> license, similar to what it used to be, but it raised people's
> attention so the license got more scrutiny than ever and that resulted
> in long threads with no broad consensus.
nmap 7.90 wi
Samuel Henrique writes:
> Nmap has just released its version 7.93, and it comes with a new
> license, similar to what it used to be, but it raised people's
> attention so the license got more scrutiny than ever and that resulted
> in long threads with no broad consensus.
For the
Nmap has just released its version 7.93, and it comes with a new
license, similar to what it used to be, but it raised people's
attention so the license got more scrutiny than ever and that resulted
in long threads with no broad consensus.
There have been lots of discussions going on about
On Sat, 20 Aug 2022 00:42:39 -0400 Ben Westover wrote:
> Hello,
Hi!
>
> I was going to package some software that has portions licensed under
> the Microsoft Public License. Is it copatible with the DFSG? A quick
> search yielded no results.
There seems to be an [old thread]
Dear Ben,
The MS-PL is an open source license as approved by the Open Source
Initiative:
https://opensource.org/licenses/MS-PL
Given that fact, as well as my own understanding of the license, I
would strongly suspect that this is DFSG-compatible. Please note that
I am not yet a DD, though
>>>>> "Ben" == Ben Westover writes:
Ben> Hello, I was going to package some software that has portions
Ben> licensed under the Microsoft Public License. Is it copatible
Ben> with the DFSG? A quick search yielded no results. Below is the
Ben> f
Hello,
I was going to package some software that has portions licensed under
the Microsoft Public License. Is it copatible with the DFSG? A quick
search yielded no results. Below is the full text of the license.
Thanks,
--
Ben Westover
This license governs use of the accompanying software
Paul Wise writes:
> Looking at the DFSG, I can't think of any conflicts between the items
> in it and this custom license clause.
>
> https://www.debian.org/social_contract#guidelines
>
> All that said, this is license proliferation, which isn't really good,
> so you m
s might be optional, since the
verbatim BSD sections use "must" for the mandatory parts.
The GPL has similar requirements for notices of modification.
On Sat, 2022-07-30 at 12:40 -0700, Dima Kogan wrote:
> The leading sections are just a vanilla 3-clause BSD license, but the
> last p
Hi. I'm currently packaging the geogram project:
https://github.com/BrunoLevy/geogram
It looks like most of it is distributed under a modified 3-clause BSD
license:
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following
On Fri, 2022-07-15 at 18:08 +0200, Julien Puydt wrote:
> * This copyright and license shall be included in all copies or
> substantial portions of the Software.
>
> and the last line worries me a little: is it a DFSG-ok license?
> I prefer asking around since I'm not rea
Hi,
Looks OK for me, Apache 2 license also requires NOTICE file to be included in
all copies if exists and there is no other restrictions.
Cheers,
Yadd
Le 15 juillet 2022 18:08:53 GMT+02:00, julien.pu...@gmail.com a écrit :
>Hi,
>
>I'm interested in packaging UniMath, which has the
Hi,
I'm interested in packaging UniMath, which has the following specific
license:
UniMath copyright and license
=
UniMath consists of the files in the UniMath github repository at
https://github.com/UniMath/UniMath .
UniMath is copyright 2015 by the UniMath
On Tue, 07 Jun 2022 12:11:11 -0400 Antoine Beaupré wrote:
[...]
> Okay, so what's in that `tsl/` folder? there you have *another* LICENSE
> file which is a custom license written specifically (presumably by
> lawyers) for timescaleDB:
>
> https://github.com/timescale/t
Dear Antoine,
> It was pointed out to me that TimescaleDB has a "open core" model and
> it's actually possible to build an "apache-2.0-only" version of the
> program.
Yup, it looks like all files in the tsl/ directory are governed by the
proprietary license, an
It was pointed out to me that TimescaleDB has a "open core" model and
it's actually possible to build an "apache-2.0-only" version of the
program. The differences between the two are here:
https://docs.timescale.com/timescaledb/latest/timescaledb-edition-comparison/
... and guix actually made a
1 - 100 of 9068 matches
Mail list logo
