On Sun, 13 Apr 2025 at 11:20:47 +, Andrew M.A. Cater wrote:
Leaving aside any political topics of disagreement between Debian and OSI
(and leaving aside the OSI position on AI for the moment):
Are there any software licenses that the OSI recognise that Debian doesn't?
Unfortun
On 4/13/25 13:20, Andrew M.A. Cater wrote:
Leaving aside any political topics of disagreement between Debian and OSI
(and leaving aside the OSI position on AI for the moment):
Are there any software licenses that the OSI recognise that Debian doesn't?
This is in a work/commercial conte
Leaving aside any political topics of disagreement between Debian and OSI
(and leaving aside the OSI position on AI for the moment):
Are there any software licenses that the OSI recognise that Debian doesn't?
This is in a work/commercial context: I have argued (for many years) that
"
>>>>> "Joe" == Joe Brockmeier writes:
Joe> Hi all, The Fedora Project is discussing how to properly
Joe> represent code that was originally licensed under the Business
Joe> Source License (BuSL) and other licenses that transform on
Joe> tim
On Sat Jul 27, 2024 at 5:18 PM CEST, Francesco Poli wrote:
[..]
> But debian/copyright does not have a stanza for that file
> (license-incompatibility.md)...
> If you really consider me as a co-author (despite the very little
> contribution I provided), then you should create a separate stanza in
>
Hi all,
The Fedora Project is discussing how to properly represent code that
was originally licensed under the Business Source License (BuSL) and
other licenses that transform on time. [1]
Specifically - let's say there's a project that uses the Business
Source License (BuSL) and is s
On Mon, 22 Jul 2024 01:12:52 +0200 Serafeim Zanikolas wrote:
[...]
> On Sat Jul 20, 2024 at 6:00 PM CEST, Francesco Poli wrote:
> > I think that writing "on-behalf-of: debian-legal@" could give the wrong
> > impression that I have been officially appointed as a spokesperson of
> > the debian-legal
On Wed, 17 Jul 2024 00:38:57 +0200 Serafeim Zanikolas wrote:
> On Tue Jul 16, 2024 at 12:10 AM CEST, Francesco Poli wrote:
> [..]
>
> > If this is an actual concern (on a second thought, I personally think
> > it could be!), some more explicit warning could be added to the
> [..]
> > Perhaps the
On Tue Jul 16, 2024 at 12:10 AM CEST, Francesco Poli wrote:
[..]
> If this is an actual concern (on a second thought, I personally think
> it could be!), some more explicit warning could be added to the
[..]
> Perhaps the background section should be clearer on this.
> And a FAQ could be added.
I
On Tue Jul 16, 2024 at 12:27 AM CEST, Nicholas D Steeves wrote:
> ...this is much more work than 50 lines. People are going to use this
[..]
> I don't have time to check the proposed compatibility matrix for
> correctness, I haven't checked it, so it's wrong to say that I reviewed
that makes sens
On Mon, 15 Jul 2024 18:27:24 -0400 Nicholas D Steeves wrote:
[...]
> People are going to use this
> instead of spending time (and extensive energy) manually checking for
> license compat, thus the reviewer[s] sign-off indicates that the matrix
> is a trusted shortcut.
Well, I hope people will not
"Serafeim Zanikolas" writes:
> Hi Nicholas,
>
>>> can I ask you to both let me know whether you're happy for me to change the
>>> review status to completed?
>
>> Do you mean Salsa/github reviewers? To be honest I don't have time to
>> do a full review...Sorry.
>
> no, I really mean this in the
On Sun, 14 Jul 2024 23:35:18 +0200 Serafeim Zanikolas wrote:
> On Mon Jul 8, 2024 at 11:39 PM CEST, Francesco Poli wrote:
> > On Sun, 07 Jul 2024 15:50:59 +0200 Serafeim Zanikolas wrote:
>
> thanks again Francesco!
You're welcome. :-)
[...]
> > the attached patch
[...]
> > fixes the mistake
[
Hi Nicholas,
>> can I ask you to both let me know whether you're happy for me to change the
>> review status to completed?
> Do you mean Salsa/github reviewers? To be honest I don't have time to
> do a full review...Sorry.
no, I really mean this in the simplest possible way: review the 50 lines
On Mon Jul 8, 2024 at 11:39 PM CEST, Francesco Poli wrote:
> On Sun, 07 Jul 2024 15:50:59 +0200 Serafeim Zanikolas wrote:
thanks again Francesco!
> Not yet, because I made a mistake.
>
> See the attached patch, which fixes the mistake (basically, when I was
> writing the various LGPL rows, I was i
Hi Serafeim,
"Serafeim Zanikolas" writes:
> Francesco, thanks for the patch! applied and pushed (and additionally added
> you
> as an author)
>
> Nicholas, Francesco, you're now both set as reviewers. can I ask you to both
> let
> me know whether you're happy for me to change the review status
On Sun, 07 Jul 2024 15:50:59 +0200 Serafeim Zanikolas wrote:
> Francesco, thanks for the patch!
You are welcome!
> applied and pushed (and additionally added you as an author)
Good.
>
> Nicholas, Francesco, you're now both set as reviewers. can I ask you to both
> let
> me know whether you'r
Francesco, thanks for the patch! applied and pushed (and additionally added you
as an author)
Nicholas, Francesco, you're now both set as reviewers. can I ask you to both let
me know whether you're happy for me to change the review status to completed?
sidenote: I'm toying with the idea of propos
On Fri, 05 Jul 2024 23:17:04 +0200 Serafeim Zanikolas wrote:
[...]
> my inclination is
> to KISS and assume that all "License: MPL-2" is without the copyleft
> restriction
If I correctly understand the design philosophy, risking a false
negative is better than risking a false positive.
So I can a
On Fri, 05 Jul 2024 22:27:41 +0200 Serafeim Zanikolas wrote:
[...]
> please send me a patch, if you don't mind.
[...]
I am attaching a patch that tries to improve the technical note.
I hope this helps.
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
...
ut that
> > because spdx.org/licenses defines a distinct license identifier for the
> > -no-copyleft-exception variant, and dep5 requires the use of spdx
> > identifiers.
> > (which is to say that we can assume that MPL-2 is in fact MPL-2 without the
> > copyleft exception an
)
>
> * why did you drop LGPL-3 from the GPL-2 row? they are incompatible...
>
> * why did you introduce LGPL-2+, LGPL-2.1, and LGPL-3 in the MPL-1.1
>row? as far as I know, the LGPL licenses are (linking-)compatible
>with MPL-1.1 ...
sorry, that's all sloppiness
Hi,
Thanks for your work.
"Serafeim Zanikolas" writes:
> right, I guess that's why the wikipedia diagram distinguishes between MPL-2
> and
> MPL-2-no-copyleft-exception. I think that we don't have to worry about that
> because spdx.org/licenses defines a dis
nes:
> >
> > Apache-2.0: GPL-2
>
> the image I've originally linked to in wikipedia suggests that apache-2 is
> compatible with MPL-2 which in turn is compatible with all GPL licenses.
> what am I missing?
[...]
GPL-2 is compatible with BSD-3-clause
BSD-3-clause is c
least the following ones:
>
> Apache-2.0: GPL-2
the image I've originally linked to in wikipedia suggests that apache-2 is
compatible with MPL-2 which in turn is compatible with all GPL licenses. what am
I missing? (of course, it's possible that an apache-2 lib depends on
MPL-2-no-copyleft
On Sun, 30 Jun 2024 22:37:22 +0200 Serafeim Zanikolas wrote:
> hello Debian legal folks,
Hello Serafeim,
nice to read you!
>
> I'm looking for an up-to-date compatibility matrix of
> /usr/share/common-licenses
> (modulo documentation licenses).
[...]
> I've prepa
I've missed the GPL-2/LGPL-3 incompatibility:
> GPL-2: GPL-3, MPL-1.1
should be:
GPL-2: GPL-3, MPL-1.1, LGPL-3
> LGPL-3: MPL-1.1
should be:
LGPL-3: MPL-1.1, GPL-2
ps. please cc me on replies
signature.asc
Description: PGP signature
hello Debian legal folks,
I'm looking for an up-to-date compatibility matrix of /usr/share/common-licenses
(modulo documentation licenses). I've recently taken over the Debian-native
package adequate, which among other things checks for binaries that link in
libraries that are availabl
best.
>
> Same as for any other file in the source package, list in the
> debian/copyright which files have which copyrights and licenses.
Heh, right - the problem is executing that. :) Folks typically take care to
document the copyright on code, not so often licenses (the FSF licenses be
Same as for any other file in the source package, list in the
debian/copyright which files have which copyrights and licenses.
> Maybe the answer is to repack it away? But that seems weird. It's freely
> redistributable, and that'd be *obscuring* license/copyright details. We
&
Hi Richard,
On Tue, Jan 02, 2024 at 10:31:23PM -0600, Richard Laager wrote:
> I document them the same, except that I also add use the DEP-5 "Comment"
> field to indicate that it came from "B".
That's a nice idea. If I claim my software distribution is licensed under the
GPL, then it's natural t
Hi Paul,
On Sat, Jan 06, 2024 at 01:12:50PM +0800, Paul Wise wrote:
> On Mon, 2024-01-01 at 13:16 -0800, Ross Vandegrift wrote:
>
> > Suppose project A includes code from project B.
>
> The best option would be to talk to upstream about removing the copy,
> further advice about embedded copies i
On Mon, 2024-01-01 at 13:16 -0800, Ross Vandegrift wrote:
> Suppose project A includes code from project B.
The best option would be to talk to upstream about removing the copy,
further advice about embedded copies is on the wiki:
https://wiki.debian.org/EmbeddedCopies
> How should these files
I document them the same, except that I also add use the DEP-5 "Comment"
field to indicate that it came from "B".
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
Hello,
Suppose project A includes code from project B. To be good stewards of license
and copyright data, A incorporates B's license and copyright files into their
source distribution.
How should these files appear in d/copyright? I don't see any suggestion in
[1] or [2].
Thanks,
Ross
(Please
ere to
automatically check for it. Please file a bug report against lintian
asking for license mismatch detection to be implemented.
I will try to try about these.
Thank you again.
2022年12月2日(金) 17:26 Paul Wise :
> On Fri, 2022-12-02 at 15:59 +0900, 野崎耕平 wrote:
>
> > In researching t
On Fri, 2022-12-02 at 15:59 +0900, 野崎耕平 wrote:
> In researching the licenses of the dependent libraries of the programs I
> created,
> I noticed that some packages could be non-GPL library become GPL library by
> patch.
Generally Debian encourages maintainers to license their pac
Hi,
In researching the licenses of the dependent libraries of the programs I
created,
I noticed that some packages could be non-GPL library become GPL library by
patch.
* The original project is not GPL
* There is a mention in the copyright that debian/* is GPL
* Patches to the library source
Am Donnerstag, dem 07.10.2021 um 15:35 -0700 schrieb Walter Landry:
>
> JSON has a license with similar problems. It has the addendum
>
> The Software shall be used for Good, not Evil.
Well, the word "shall" can implicate "may", "will", or "must" and has therefor
legal implications (similar i
On Thu, Oct 7, 2021 at 10:48 PM Francesco Poli wrote:
> What do other debian-legal participants think?
While they are fairly obviously worded in plain English like an
optional request, since they are part of a legal document, they are
supposed to use legal language, and IANAL, so I don't know how
On Thu, 2021-10-07 at 23:56 +0200, Dominik George wrote:
> What does debian-legal say? Could I package the first example for
> Debian, and trust that the amendment is a joke?
> This project is MIT-licensed, but has a note saying:
> "BUT if you become a millionaire using this code, please bought
>
.
Cheers,
Walter Landry
Dominik George writes:
> Hi,
>
> some times, we (the AlekSIS team) stumble upon upstream maintainers
> who consider it funny to add amendments to licenses, or make up fun
> licenses on their own. Here are two examples:
>
> https://github.com/codeed
On Thu, 7 Oct 2021 23:56:57 +0200 Dominik George wrote:
> Hi,
Hello!
>
> some times, we (the AlekSIS team) stumble upon upstream maintainers
> who consider it funny to add amendments to licenses, or make up fun
> licenses on their own.
Personally, I think licenses and joke
Hi,
some times, we (the AlekSIS team) stumble upon upstream maintainers
who consider it funny to add amendments to licenses, or make up fun
licenses on their own. Here are two examples:
https://github.com/codeedu/select2-materialize
This project is MIT-licensed, but has a note saying
On Mon, May 25, 2020 at 12:25 AM Paul Wise wrote:
>
> On Sat, Jul 6, 2019 at 1:55 AM Paul Wise wrote:
>
> > Does anyone have any thoughts about this?
>
> I talked to one of RedHat's lawyers and they mentioned that they have
> dealt with this problem too and concl
On Sat, Jul 6, 2019 at 1:55 AM Paul Wise wrote:
> conserver package is in non-free because of this issue but it appears a
> lot of people did not notice the lack of modification permission.
...
> https://www.conserver.com/pipermail/users/2019-July/msg1.html
Due to the interpretation provided
On Sat, Jul 6, 2019 at 1:55 AM Paul Wise wrote:
> Does anyone have any thoughts about this?
I talked to one of RedHat's lawyers and they mentioned that they have
dealt with this problem too and concluded that these licenses were
intended to cover modification. The current wording of the
On 2020-03-01 5:25 a.m., Florian Weimer wrote:
> * Gabriel Filion:
>
>> From what I could gather, the website specifies that all content is
>> covered by CC-BY 3.0:
>>
>> https://spdx.org/Trademark
>> https://www.linuxfoundation.org/terms/
>>
>> However, I'm not completely sure that the informatio
* Gabriel Filion:
> From what I could gather, the website specifies that all content is
> covered by CC-BY 3.0:
>
> https://spdx.org/Trademark
> https://www.linuxfoundation.org/terms/
>
> However, I'm not completely sure that the information I found is precise
> enough..
The upstream repository a
Hello,
I'm working on a package for a ruby library, ruby-spdx-licenses, for
which I had some questions pop to mind about licensing:
The code ships a json file that contains information about all of the
licenses that the library helps with identifying. This json file was
copied from the SPD
On Sun, 15 Dec 2019 14:25:47 +0100 Jonas Smedegaard wrote:
[...]
> As others in this thread have pointed out, Debian explicitly omits
> classifying license fulltexts as "free software" or "non-free software".
Frankly speaking, I cannot find a message in this thread where others
pointed out that
2019-12-15 1:26:28 PM Jonas Smedegaard : [...]
> As others in this thread have pointed out, Debian explicitly omits
> classifying license fulltexts as "free software" or "non-free software".
>
> As I understand it, you personally classify license fulltexts as
> "non-free software" and then add a
Greetings, all!
[Lurker in the Debian space, decloaking to ask a clarification.]
On 15 Dec 2019, at 07:01, Francesco Poli wrote:
>
> But can DFSG-free data be prepared for the test suite of a program
> intended to identify licenses?!? How can I test whether the program is
> able to
Quoting Francesco Poli (2019-12-15 13:01:16)
> On Sat, 14 Dec 2019 17:41:14 +0100 Jonas Smedegaard wrote:
>
> > Quoting Francesco Poli (2019-12-14 17:22:09)
> [...]
> > > I don't think the exception may also apply when the license text
> > > is the *actual payload* of the package (for instance, a
..
But on the other hand, can non-free data be shipped in the test suite
of a source package in Debian main?
For many kinds of package, DFSG-free data may be specifically prepared
for the test suite.
But can DFSG-free data be prepared for the test suite of a program
intended to identify licenses?!? How
e licensing terms being applied at all to the project covered by
that package.
Examples:
* licensecheck - includes license fulltexts in its testsuite
* libsoftware-license-perl - purpose of project is to emit licenses
I have several times discovered projects shipping with e.g. GPL-3 but
no
On Sat, 14 Dec 2019 14:01:18 +0100 Baptiste BEAUPLAT wrote:
> On 12/14/19 1:03 PM, Jonas Smedegaard wrote:
> > A rich collection of Free license fulltexts is relevant, not only for
> > our users to pick from (even on a lonely island) and copy into new
> > development project, but also as referen
don't recommend going down that route...
What I recommend i to try piece together an alternative XML processing
which produces same output as the Java-based ones used upstream.
I'd be happy to help with that. My preferred hacking environments are
shell and perl. If yours is differen
On 12/14/19 2:01 PM, Baptiste BEAUPLAT wrote:
> On 12/14/19 1:03 PM, Jonas Smedegaard wrote:
>> A rich collection of Free license fulltexts is relevant, not only for
>> our users to pick from (even on a lonely island) and copy into new
>> development project, but also as reference e.g. for testin
thers with same interest at the irc channel #licenses on OFTC.net.
>
> Related is also https://wiki.debian.org/CopyrightReviewTools
Thanks for the pointers. Although my particular use case stops to new
projects, it could certainly be expended to benefit license checkers.
[1]: https://githu
rsion on their
> website).
>
> My question to you is: "Would it be interesting for others if I were
> to create a package with missing text version of licenses?"
>
> Currently, in debian, we have the /usr/share/common-licenses/ that
> includes a couple of one, but
for others if I were to
create a package with missing text version of licenses?"
Currently, in debian, we have the /usr/share/common-licenses/ that
includes a couple of one, but is missing CC- and MIT for instance.
I would find it useful to just cp the file to new projects.
@debian-legal:
* On 8/18/19 10:02 AM, Bagas Sanjaya wrote:
> [...] and not
> NC and ND variant ones? I had tried to find the explanation on this
> mailing list, but seems like there is nothing found.
In very short: the NC part conflicts with point 6: "No Discrimination Against
Fields of Endeavor", because it d
Hello,
I'd like to know why CC-BY and CC-BY-SA licenses are DFSG-free, and not
NC and ND variant ones? I had tried to find the explanation on this
mailing list, but seems like there is nothing found.
Cheers, Bagas
--
An old man doll... just what I always wanted! - Clara
Hi all,
There are several packages (including GCC and Linux) in Debian that
contain files released under several different BSDish licenses that are
missing the explicit modification permission. Many of these files
contain comments indicating that they likely have been modified. I
think that these
On Mon, Aug 20, 2018 at 2:58 AM, Rob Browning wrote:
> # However, this document itself may not be modified in any way
This part is fairly clearly non-free.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Emacs includes these two files:
etc/schema/od-manifest-schema-v1.2-os.rnc
etc/schema/od-schema-v1.2-os.rnc
found here:
https://git.savannah.gnu.org/cgit/emacs.git/tree/etc?h=emacs-26.1
Both specify:
# Copyright (c) OASIS Open 2002-2011, 2013. All Rights Reserved.
#
# All capitali
> Ben Finnley writes:
> > Lev Lamberov writes:
> >
> > while working on migration of swi-prolog package to machine-readable
> > copyright file I've stuck with two licenses, so asking for an advise on
> > how to specify these licenses (I mean what to choos
Lev Lamberov writes:
> while working on migration of swi-prolog package to machine-readable
> copyright file I've stuck with two licenses, so asking for an advise on
> how to specify these licenses (I mean what to choose as their short
> names). I was not able to identify the
Hi,
while working on migration of swi-prolog package to machine-readable
copyright file I've stuck with two licenses, so asking for an advise on
how to specify these licenses (I mean what to choose as their short
names). I was not able to identify them or find in SPDX Open License
List.
p...@reseau-libre.net writes ("[licence] specific licenses for backdoor-factory
software"):
> I'm currently packaging "backdoor-factory" for the pkg-security team.
> The tool is already in kali.
> The upstream sources are hosted here:
> https://github.co
On Tue, May 30, 2017 at 8:45 PM, Philippe THIERRY wrote:
> The main tool is based on the following license file (LICENSE.txt) :
This is almost identical to the 3-clause BSD license, the only change
is s/university|regents/copyright holder/
> You may not redistribute aPLib without all of the fil
Hi,
I'm currently packaging "backdoor-factory" for the pkg-security team.
The tool is already in kali.
The upstream sources are hosted here:
https://github.com/secretsquirrel/the-backdoor-factory
The main tool is based on the following license file (LICENSE.txt) :
---8<---
> Copyright Protection for NIST Standard Reference Data (SRD)
>
> Copyright protection on this compilation of data has been secured by the U.S.
> Department of Commerce in the United States and in other countries that are
> parties to the Universal Copyright Convention, pursuant to Section 290(e)
PICCA Frederic-Emmanuel writes ("NIST data licenses/copyright"):
> I am packaging something which contain some NIST data [1]. The
> license refered by is reproduce here.
>
> I would like to know if this license is DFSG-free or not.
...
> License Information for NIST
Hello
I am packaging something which contain some NIST data [1]. The license refered
by is reproduce here.
I would like to know if this license is DFSG-free or not.
thanks for your help.
Frederic
License Information for NIST data (other than Standard Reference Data (SRD))
This data was d
Hi Mathieu,
(I'm replying directly, I don't know whether you're subscribed to the list.)
On Mon, 26 Oct 2015 17:08:30 +0100, Mathieu AUZENET
wrote:
> I'm looking on your website but i didn't find information.
> Could you please tell me if an exhaustive list
Hello,
I'm looking on your website but i didn't find information.
Could you please tell me if an exhaustive list of all licenses applicable
to Debian Wheezy 7.2.0 exists?
Thanks in advance.
Regards,
Cordialement,
[image: Prometil]
www.prometil.com
Mathieu AUZENET
*Ingénieu
ood idea: CC0 is up for a rework too, they
> >> just decided to get CC 4.0 out of the door first, and the
> >> current CC0 version is *explicitly* discouraged for use
> >> with software.
I was recommending CC0 instead of one of the other CC licenses, ie for
things I&#x
terested in their opinion you can read that
thread:
http://projects.opensource.org/pipermail/license-review/2012-February/92.html
The most important issue IIRC is that it specifically does NOT license
patents. Licenses suitable for software either explicitly give you a
patent license (f
Le Thu, Nov 28, 2013 at 12:03:31PM +0100, Thorsten Glaser a écrit :
> On Thu, 28 Nov 2013, Paul Wise wrote:
>
> > Mike Linksvayer suggests upgrading to CC0 instead:
>
> This is not a good idea: CC0 is up for a rework too, they
> just decided to get CC 4.0 out of the door first, and the
> current
On Thu, 28 Nov 2013, Paul Wise wrote:
> Mike Linksvayer suggests upgrading to CC0 instead:
This is not a good idea: CC0 is up for a rework too, they
just decided to get CC 4.0 out of the door first, and the
current CC0 version is *explicitly* discouraged for use
with software. (Also, Public Domai
On Wed, 2013-11-27 at 10:01 +0800, Paul Wise wrote:
> http://creativecommons.org/weblog/entry/40768
Mike Linksvayer suggests upgrading to CC0 instead:
http://gondwanaland.com/mlog/2013/11/25/upgrade-to-0/
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digi
http://creativecommons.org/weblog/entry/40768
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
On Fri, Sep 27, 2013 at 03:24:58PM +, Thorsten Glaser wrote:
> Hm unsure. It really depends on how far you acknowledge the
> virality of the GPL – Debian, AFAIK, tends to go more with
> the FSF’s extreme interpretation…
I don't think my view is out of line with the FSF's.
This applies to sour
Paul Tagliamonte dixit:
>This is a GPL restriction. Since the upstream code isn't GPL, why are
>you using a GPL argument about build scripts? -- in theory this would apply
>to build scripts for the GPLv3'd debian/* files, but there are none that
Hm unsure. It really depends on how far you acknowl
Given the lack of specific mention of a different license for debian/*
in d/copyright, I think it's fair to say that debian/* was licensed
under CPL, whether intended or not. Still, upstream has changed to
EPL, and Soeren has refused to relicense his work under EPL (and has
offered GPL-3 as an alte
On Fri, Sep 27, 2013 at 01:06:27PM +, Thorsten Glaser wrote:
> Paul Tagliamonte debian.org> writes:
>
> > So, the way *I* see this is so long as the GPL code isn't being put into
> > a combined work with anything (e.g. GPL'd patches), it *should* be OK.
>
> Unfortunately, GPLv3 considers bui
Paul Tagliamonte debian.org> writes:
> So, the way *I* see this is so long as the GPL code isn't being put into
> a combined work with anything (e.g. GPL'd patches), it *should* be OK.
Unfortunately, GPLv3 considers build scripts (thus, d/rules plus the
input for the declarative dh* commands, pl
eral assumption that
it is under the same license as the Upstream work, in particular for the
patches (which is why there is no License field in DEP 3, the Patch Tagging
Guidelines). The CPL is also listed as incompatible with the GPL on FSF's
website, so the patches definitely were not GPL-lice
There is something implicit in paultag's mail, I'll try to make it
explicit. The new license must not be used for any of the existing
files, unless there is a complete rewrite. For example,
debian/changelog is likely to get new copyrightable content and having
that under the two licenses
On Wed, Sep 25, 2013 at 10:37:12AM -0400, Paul Tagliamonte wrote:
> It's a skitch hazy, but I don't think there's an issue with
> distributing CC-BY and GPL code in the same tarball -- the only issue is
> this *MAY* result in GPL issues if *upstream* is GPL, if you've checked
> out some of the CDDL
PL code isn't being put into
a combined work with anything (e.g. GPL'd patches), it *should* be OK.
I couldn't imagine the case to be made against shipping CC-BY images in
a GPL source package, so I don't see why we can't have different
conflicting licenses in the same tar
Dear debian-legalers,
Under the sponsorship of Sébastien Villemot and the Debian science
team, I am in the process of adopting the COIN-OR scientific packages
for linear programming and extensions (incl. coinutils, coinor-osi,
clp, coinor-cbc, etc.).
Here's the issue:
- Since the last upload, ups
Dear Charles,
On Sep 22, 2013, at 5:49 AM, Charles Plessy wrote:
> Le Sat, Sep 21, 2013 at 06:46:55PM -0400, Nick Oosterhof a écrit :
>>
>> are the Open Database License (ODbL) [1] and Database Contents License
>> (DbCL) DSFG [2] compliant? [...] I found an earlier thread [3] where it was
>> a
Le Sat, Sep 21, 2013 at 06:46:55PM -0400, Nick Oosterhof a écrit :
>
> are the Open Database License (ODbL) [1] and Database Contents License (DbCL)
> DSFG [2] compliant? It seems they are not, but I would like to make sure.
>
> Specifically I found an earlier thread [3] where it was argued that
Work
for significant (higher than reasonable production) cost.
Is that a reasonable interpretation?
Thanks for your consideration,
Nick
[1] http://opendatacommons.org/licenses/odbl/1.0/
[2] http://opendatacommons.org/licenses/dbcl/1.0/
[3] http://lists.debian.org/debian-legal/2010/08/msg00036.ht
licence is cc-by-nc-nd.
>
> There are a number of things that strike me as awkward in this piece of
> news.
>
> First of all, we are talking about a program here, aren't we?
> CC licenses are recommended *against* for programs, even by the Creative
> Commons Project itself
s
> finally verifiable:
>
> https://github.com/vvk-ehk/evalimine
>
> But the licence is cc-by-nc-nd.
There are a number of things that strike me as awkward in this piece of
news.
First of all, we are talking about a program here, aren't we?
CC licenses are recommended *a
On 07/14/2013 12:04 PM, Francesco Poli wrote:
>> > I have a package which is licensed under CC-BY 2.0
> Ouch! :-(
>
Estonia has been using e-elections software since 2005 and now it's
finally verifiable:
https://github.com/vvk-ehk/evalimine
But the licence is cc-by-nc-nd.
How can I convin
1 - 100 of 1529 matches
Mail list logo
