Re: Need advice for dual licensing
On Fri, May 13, 2005 at 06:36:53PM +0200, Svante Signell wrote: Hi, Anybody got a good advice for how to dual license some of the software I've developed. I would like to use GPL for non-commercial use (e.g. private persons and universities) and a commercial license for companies. Please Cc: me since I'm not subscribed to this list. Can I suggest something similar to the Aladdin model for Ghostscript - release the current version as paid for, for commercial use, supported by us: after a year GPL it and put support into the community. If your code base is substantially similar from one release to the next - 1.) Bugs will be fixed when noticed by the wider community on the GPL version: if the bugs are still in your Professional/Supported version they're fixed for free, effectively. 2.) Feature requests from the GPL'd version can be rolled into your supported version. 3.) You get free advertising for your pro version and kudos from the rest of the world by releasing slightly older code under the GPL. Be careful how you advertise/plug the paid for version: Aladdin fell out with the FSF because the FSF thought that the free GPL'd version advertised the commercial version too much. Just a thought, Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need advice for dual licensing
On Sun, May 15, 2005 at 12:38:20PM +0200, Svante Signell wrote: in response to Don Armstrong I'm very sorry, the top posting was not intentional. I will also try not to Cc: to people who don't want an extra copy. On Fri, 13 May 2005, Svante Signell wrote: I just wanted to know if dual licensing is possible. It is possible, but when we talk about dual licensing we typically mean that two licenses are applied to a work, and the user can (at the user's option) pick a specific license to use the work under. OK, so this is the case e.g. with mozilla and openoffice? Exactly so. OpenOffice is (some Sun licence) and GPL, Mozilla is MPL in parts and GPL - if I recall correctly. A better instance is Perl - which explicitly offers you the GPL or the Perl Artistic licence at your option. What you seemed to be asking for was two licenses for different (disjoint) sets of users, which isn't going to be DFSG Free unless both licenses are DFSG Free. [And possibly not even then... we'd have to look at it very closely.] Is it possible to release the code as GPL and if necessary relicense at a later stage? Do all contributors to the improved version have to agree on this change of licence. What about copyright issues for contributed code? All contributors would have to agree - in practice, it's very unlikely to happen. Much better is to produce a minimal closed source licence for your commercial/private code - then open it after a period as GPL. This is how Ghostscript worked/works: I think it's also how CUPS works. You can only really do this if you have private code of significant value to begin with. It may also be worth looking at MySQL's way of doing things, or of providing the code free under the GPL but charging for support - and insisting that commercial use requires a support licence to include rights to use your logo and brand [which is more or less what Red Hat is doing at the moment - once your licence terminates, not only can you not get updates but you probably should remove all RH logos/artwork and so on. The RH clones - CentOS, White Box Linux - have to get around this by not including any of the logos/artwork at the beginning.] Not good really, software/information wants to be free :) Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New 'Public Domain' Licence
On Mon, Jun 06, 2005 at 01:38:24PM -0400, astronut wrote: *This message was transferred with a trial version of CommuniGate(tm) Pro* Jeff King wrote: The latter message is from me. I am looking for such a license, as I am trying to avoid ridiculous license propagation. My ideal license would be in one of two forms: - a common PD-ish license for which users can say Oh, the PD license and know what it means (as we do now for the BSD, MIT, and GPL licenses) - a license so short that one can look at it and know what it means (e.g., X is dedicated to the public domain, X may be redistributed in any form without restriction). The consensus I seem to read from debian-legal is that the second type can't exist, because we have to list everything explicitly or our evil heirs can revoke it. -Peff I am probably wrong here, since I joined the list in the middle of the discussion, but can't you just put a notice at the top of the code like this? /* This code was written by name and is hereby released into the public domain */ What's the public domain in the context of UK / European law? [If it exists validly in the UK, for example, how is it to be interpreted if there is a conflict in definition with European Community law?] Public Domain appears to many to be US-centric: better, by far, to have a crack at _some_ kind of licence. It is useful to have explicit permission to use freely for commercial/governmental/not for profit and personal and private use for example. Permission to modify or distribute in other forms is also useful as is explicit permission to sell or distribute as part of other media or to use the information in derivative works. All of the above could reasonably be either inferred or denied depending on how you read or interpret everything between /* and */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR: GFDL Position Statement
On Sat, Jan 21, 2006 at 10:41:26AM +0100, Francesco Poli wrote: On Sat, 21 Jan 2006 16:53:56 +1100 Andrew Donnellan wrote: I think that KPovModeler was developed with the intention that you have POV-Ray installed. It will work fine without it, but it can only save KPMs and POV files, and at the moment there is no other software that can read it. Probably true. Or otherwise, povray upstream authors could be persuaded to relicense in a DFSG-free manner, so that we would *gain* one new interesting package for main, rather than *losing* one (that was wrongly placed in main). ;-) If you read the license files, they intend to change the licence with the next release. Their problem is that they can't find all contributors to release the current version, as far as I can see. Povray will, eventually, get into main :) Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun responds to questions on the DLJ
On Fri, May 19, 2006 at 08:09:18PM -0500, Tom Marble wrote: All: Let me start by repeating the message that Simon and I gave to you at Debconf: there is every reason for us to be friends and working with you is very important for Sun. big snippage of much good explanation and technical stuff Thank you very much indeed for all your hard work - you may just have helped me install mission-critical machines at work much more straightforwardly :) Lots of changes happening to Java licensing, obviously, some announced, some in progress. Your personal contributions and those of wider Sun much appreciated here :) And, as I am sure you know, Rich Green has announced a very interesting Open Source future for Java. Simon, I (and many others) are going to work very hard on that internally so that soon you will be able consider Java for main. Respectfully, --Tom Thanks - your assistance may finally kill off lots of flamewars and arguments throughout the 'Net :) Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License missing in the tarball but present on the website
On Thu, Apr 19, 2007 at 12:24:26PM +0200, Gonéri Le Bouder wrote: Hello, The vdrift upstream uploaded a data tarball with some content licensed under the Creative Commons Attribution-Non-Commercial-Share Alike 2.5 license. After discution there are agree to relicense these files under GNU GPL but the tarball is quite udge ( 200M) and so I think it should provably be easier to publish a notification on the website. Notes in the README.Debian and any relevant docs directory would help. A copy of their email would also be useful in there. This sort of thing would actually be useful in DWN. $foo data relicensed to GPL If the project is relatively fast moving and vdrift is in etch, it might be a good idea to package it with the tarball updated to reflect the licence change for etch r1 whenever that occurs and ask for it to be put into stable-proposed-updates. This would cover all bases: anyone who had got vdrift from r0 would be made aware: anyone who installed from r1 onwards would automatically get the changed licence terms. Any lenny / sid package would just be packaged with the new licence. My question is: in the debian/copyright, is it possible to refere to a license that is on a website or in an archived mailing list. I don't think that's adequate, unfortunately. What if I install from CD and have no 'Net access? Best regards, Gonéri All best, Andy
Re: Are debian/ubuntu distributions commercial applications from a legal point of view?
On Tue, Nov 17, 2009 at 08:48:43PM +, MJ Ray wrote: Laszlo Lebrun wrote: Do you know about any jurisprudence about that question? According to David A. Wheeler, the US Department of Defense has recognised FLOSS (Free/Libre/Open Source Software) as being on the same basis as Commercial Off the Shelf (COTS) in contracts for purchasing and use of software. All best, AndyC -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible violation of license(s) on debian derivative
On Sun, Mar 07, 2010 at 10:39:53PM +, Etenil wrote: Hi everyone, I contact you regarding a possible breach of the terms of at least the GPL license on the Etch-based distribution Elive. http://www.elivecd.org/Help/License As you can see in the above link, the distribution is licensed under CC-by-NC-SA 2.0, which forbids commercial use of the distribution. This licensed is not recognised as free by the FSF and is not compatible with the GPL. Correct: there's also some fairly vague prohibition against using this for warfare - http://www.legalventure.com/clausulamariposa - apparently supported amongst others by Linux Espanol. I like the idea of a Butterfly clause - I'm assuming that they mean butterfly rather than a Spanish insult - but that makes it non-free as a whole, even granted the change noted by Don Armstrong. Can I suggest that you take it up with the people behind this: this is a derivative, not Debian proper. There is a slight problem in that the suggested email bounces you to a site which bounces you straight back to where you started :( Take care, AndyC Please advise. Guillaume Pasquet -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b942b39.9010...@etenilsrealm.nl -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100308075333.ga7...@galactic.demon.co.uk
Re: rtl-sdr packaging: Unable to find copyrtight holders for some files
On Sun, Sep 01, 2013 at 03:31:00PM +0200, Adam Cécile (Le_Vert) wrote:
Hello!
I packaged rtl-sdr [1] a while ago but I'm having a serious legal
issue. Some files related to DVB-T tuners don't have any headers and
upstream [2] didn't answer my call for help...
tuner_fc2580.{c,h} seem to come from a Terratec driver based on
linux v4l project. I found a tarball named
30032011_Cinergy_T_Stick_Black_Linux.tar.gz from their own website
and diff says it's nearly the same as the one included in rtl-sdr,
except some code removed. So this is the original code for sure but
the files still don't include any headers. The main file stands
being based on tuner module but the code doesn't look like being
the one from linux' kernel file tuner-core.c.
tuner_r820t.{c,h} are even worst. I haven't been able yet to found
any upstream on Internet, but I keep looking for it... Main file
says it comes from a Linux kernel driver...
Can you help me ?
Thanks in advance, and please CC me, I'm not subscribed !
Regards, Adam
[1]
http://mentors.debian.net/debian/pool/main/r/rtl-sdr/rtl-sdr_0.5.0+git20130715-1.dsc
[2] http://sdr.osmocom.org/trac/wiki/rtl-sdr
[3] http://linux.terratec.de/tv_en.html
r820t - also possibly Terratec ?
Osmocomm should know, because they have copyright on the whole bundle of
rtl-sdr code.
I'd be really interested as I'm currently trying to get rtl-sdr working on ARM
for
Raspberry Pi / Beaglebone Black.
It may also be worth looking at how they have moved at gnuradio using pybombs
(git://github.com/pybombs/pybombs)
which will pull in all of the appropriate bits to fit in well with gnuradio
itself.
I'm having real problems getting _that_ to work because of libboost not
compiling nicely on ARM
All the best,
Andrew Cater
[amaca...@debian.org]
--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130901165243.ga9...@galactic.demon.co.uk
Re: clarify FTP master delegation?
On Tue, Mar 11, 2014 at 07:19:18PM +, Ian Jackson wrote: That means that it is for the FTP team to set that policy. AFAIAA this is the best description of the FTP team policy: https://ftp-master.debian.org/REJECT-FAQ.html My impression is that the type of issue currently under discussion is not adequately specified in the FTP master delegation, it leaves the FTP masters to do more work on something that is actually quite complicated and has far-reaching ramifications for the project. It also means the FTP masters are in a situation where whatever they do, some people will feel they either did the wrong thing or some people will feel the FTP masters were wrong to make any decision without the project having a policy on the matter. I am very happy that the FTP team are making these kind of decisions for the project. I definitely don't want the DPL to intervene (for example, by making the FTP team delegation more prescriptive). The absence of policy on this also has other ramifications: for example, a DD could upload a non-controversial v1.0 of a package, receive FTP master approval and then later v2.0 comes along with controversial content and according to the wiki, it will be automatically accepted. This is surely done for convenience, not as a matter of policy. If you are aware of an instance where a package which has already gone through NEW has been replaced by a new version which the FTP team would have rejected, you should surely bring this to the FTP team's attention (probably by filing a bug). Debian is extremely careful _not_ to censor arbitrarily, though I can remember a couple of discussions of similar issues. From memory only - One was a very long time ago - could be as long ago as 15 years ago - when the lists were spammed by a Finnish neo-Nazi/white supremacist. At the time, thre were lengthy discussions about removing the content - various peole arguing against rewriting history and removing content from the mailing lists - but one of the prime considerations was that the content amounted to illegality in France/Germany/Austria amongst others. Given the UK's current laws - and, not least, the fact that my German isn't good - I'm not going to go anywhere near the content discussed in the discussions around a hypothetical prospective package and so can't comment further on the realities of the issues in the particular case. We do have to be careful that, as a project, we don't expose people to the possibiltiy of legal action because X is fine in Elbonia (but illegal in Ruritania and the territories of the Voivodship of Servia) for example. The great thing about Debian is that, as a community, we are accepting of everyone interested, willing and able to contribute - religion, gender, race, sexuality, financial status are all, pretty much irrelevant: in practice, the main limitation we place is that applicants must, effectively, have a high standard of communication in technical English and the ability to collaborate. All the best, AndyC amaca...@galactic.dmeon.co.uk / amaca...@debian.org Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21279.25014.252749.830...@chiark.greenend.org.uk signature.asc Description: Digital signature
Re: How to free US governmental code
On Mon, Jun 29, 2015 at 06:07:52PM -0400, James Cloos wrote: WL == Walter Landry wlan...@caltech.edu writes: WL I found something here WL ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change WL I do not think it applies in this case. WL Cheers, WL Walter Landry Thanks for finding that. That is certainly limited to BSD. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 US Government code authored by US Govt. employees is one of the few things that remains public domain _in the US_ Here, you have code written by contractors for the US government. Is there a contact for LANL anywhere ? - if you ask LANL themselves, they may be able to establish who owns the code now and how to free it up appropriately. They will have access to corporate policies / lawyers etc. for their situation and can get permission to give permission. All the best, AndyC -- 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/m3egku88xz@carbon.jhcloos.org -- 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/20150630131511.ga2...@galactic.demon.co.uk
Re: Bug#979101: Legally problematic GPL-3+ readline dependency
On Thu, Jan 07, 2021 at 06:45:14PM -0300, Carlos Henrique Lima Melara wrote: > Control: tags -1 + confirmed > > Hi, folks. > > I'm the new maintainer of devtodo and would appreciate an assistance of the > debian-legal on the license matter. As noted, devtodo is licensed under > GPL-2 only, although there is no boilerplate copyright on the source files. > My suggestion - almost like a flow chart - Talk to the upstream to explain why this is important - to you/to the world. Make the point that explicit boilerplate copyright that is clear is very useful in any circumstances if people want to use or build on upstream's code. Ask nicely for the licence change to be explicitly noted to reflect upstream's recent change from GPL2 to GPL2+ If the licence change is going to be explicitly noted, request that the change be put into the individual source files to make the situation clear and explain that you understand that this may mean extra work but will save work in the longer term. If the licence change is not going to be explicitly noted in the source files suggest that upstream puts the change in the README file with a "Licence change for this project as a whole to GPL v.2+ with effect from date XYZ " if they don't want to change every code file. If upstream doesn't want to make any change to the code anywhere - ask if you can use the email exchange to prove publicly that the licence changed. Remember: it shouldn't be packaged if the licence change is exclusively to Debian Result: If the upstream person explicitly adds the boilerplate copyright to their code files: your job is done for you and you can package that version. If not, there will be a README. If not, you can use the mail exchange. > Taking this into consideration, would a public mail from the upstream to > this bug be enough to change the license to GPL-2+? Or it would be necessary > to add the boilerplate to all source files indicating GPL-2+ licensing? > > I would rather first solve this problem in the upstream instead of dealing > with it in the packaging. > > Thanks in advance, > Carlos (Charles) >
Re: I need help my acct was hacked
On Fri, Sep 03, 2021 at 12:42:52AM -0500, Scarlett Kelley wrote: > My email account sk21rene...@gmail.com and scarlettdickinso...@gmail.com > were hacked and they stole all of my crypto and used github and created an > app called crypto kitties and the character octocat on GitHub I do not know > how to take back my accounts and get justice for this matter. I do not know > how to code on GitHub and my trademark has been stolen and registered under > different names and accounts. Any information or guidance would be greatly > appreciated. If you could tell me the next step to take or someone I could > contact regarding this matter I would greatly appreciate it thank you. My > name is Scarlett Kelley and my telephone number is 18129012893 my email is > sk21renee...@gmail.com or scarlettk...@gmail.com or sk21ren...@gmail.com. Hello Scarlett, I'm not sure that this is the right place or people to ask. This group is primarily about the Debian Linux operating system and issues to do with copyrights/patents/software licences and how these relate to the software that we build and distribute as Debian Linux. This sounds like an issue to take to your local law enforcement or similar it's not something we can help with. All the very best, as ever, Andy Cater
Re: Is 'The Unlicense' DFSG-compliant?
On Wed, Dec 22, 2021 at 07:33:45AM +0100, Jan Gru wrote: > Dear debian-legal-members, > > I am wondering, whether you consider 'The Unlicense' [0] to be > DFSG-compliant? On the OSI-mailing list [1] has been a discussion > arguing, that this license model is > > a) not global > b) inconsistent and > c) unpredictable in its applicability > I think I'd agree with all of the above, especially in light of the comments you refer to below. "Public domain" is a difficult concept eg in the US. [It may be that some Federal employees place code into the public domain by default but they are the only ones]. The author disclaims all interests for themselves: given that the UnLicense includes a verbatim copy of the MIT licence - just attribute the fact that the code was under the UnLicense, note that you are relicensing the code to the MIT licence and go from there? In countries that recognise copyright laws - almost all of them - a full disclaimer of copyright is not possible. this just my opinion. If allowable, it reduces the set of unknown, unenforceablelicences by one and produces greater legal certainty. This is explicitly different to a Github case where there is no discernible licence and therefore no permission to do anything with the code. All the very best, as ever, Andy Cater > Searching debian-legal, however, I did not find any conclusive > discussion about this. So, what do you think about this? Can projects > under the Unlicense be safely included in Debian's package archives? > > Thanks already in advance for clarifying this issue. > > Best regards, > Jan > --- > [0] https://unlicense.org/ > [1] > https://web.archive.org/web/20170301020915/https://lists.opensource.org/pipermail/license-review/2012-January/001386.html >
Re: Re: Is 'The Unlicense' DFSG-compliant?
On Thu, Dec 23, 2021 at 06:58:19AM +0100, Jan Gru wrote: > Dear Andy, > dear list members, > > thank you very much for your reply and your thoughts on this issue. > I want to pose two concrete follow/up questions if you allow. > > On Wed, Dec 22, 2021 at 13:00:08 +0000, Andrew M.A. Cater wrote: > > > > I think I'd agree with all of the above, especially in light of the comments > > you refer to below. "Public domain" is a difficult concept eg in the US. > > [It may be that some Federal employees place code into the public domain > > by default but they are the only ones]. > > > > The author disclaims all interests for themselves: given that the > > UnLicense includes a verbatim copy of the MIT licence - just attribute > > the fact that the code was under the UnLicense, note that you are > > relicensing the code to the MIT licence and go from there? > > > > In countries that recognise copyright laws - almost all of them - a full > > disclaimer of copyright is not possible. > > > > this just my opinion. If allowable, it reduces the set of unknown, > > unenforceablelicences by one and produces greater legal certainty. > > > > This is explicitly different to a Github case where there is no discernible > > licence and therefore no permission to do anything with the code. > > > > All the very best, as ever, > > > > Andy Cater > > > > > > Do you think that Unlicense can not be considered DFSG? It probably disclaims enough that the author has no rights that they want to assert. Probably DFSG in my opinion, then, but not a licence I could suggest to anybody. Relicensing might be cleaner. > Could code under the Unlicense be accepted for Debian's package archives > as it is the case with `tvnamer` [0]? > If it's already in, then someone will have made that determination for themselves previously and the FTP team will have accepted it - so theirs probably no problem with the licence. > Thank you very much in advance for a short reply. > > Best regards > Jan > > --- > [0] https://sources.debian.org/src/tvnamer/2.5-1/UNLICENSE/ >
Re: linuxcnc licensing issues
On Thu, Dec 01, 2022 at 01:38:28PM +0100, Adam Ant wrote: > [Stripping HTML formatting where I see it - could you please use plain text] > > Large portions of the core code base are labeled as LGPL-2 - There is no such > > licence. It is either GPL-2 or LGPL-2.1 > > A bit of history: > > Linuxcnc was forked from a National Institue of Standards and Technology > project called the Enhanced Machine Control (EMC). > https://www.nist.gov/publications/enhanced-machine-controller-architecture > -overview > > As part of the project NIST released code in to the public domain free from > copyright or licence - This code base was then munged for the want of a > better word by a few individuals outside of NIST and additional code added. > The munged code had copyright and licence notices added without the consent > of NIST. > > Whilst public domain code can be used in a FOSS licenced project, without > copyright (which by its very nature, public domain code is free from), any > licence becomes unenforcable. There is also the moral question of taking > public domain code and claiming copyright over it. > > Would the experts of Debian-Legal care to comment ? Disclaimer: I trained as a lawyer years ago but I'm not a US lawyer - this is NOT a legally binding opinion. With respect, I think you misunderstand both US copyright and licensing law for the specific case of software produced by the US Government and its employees. Copyright for what the NIST employees have written remains with the NIST. The originator of any code - in this case the US Govt.- retains the moral right to be identified as the author for those parts that it has written. Because it has been paid for out of US tax dollars, the US Government requires it to be released to the public as public domain in the US. In this instance, the US Govt. is about the only thing left in the US copyright system that can do this. "Public domain" doesn't exist in most of the rest of the world. https://en.wikipedia.org/wiki/Public_domain_in_the_United_States https://en.wikipedia.org/wiki/Copyright_status_of_works_by_the_federal_government_of_the_United_States By the same token, anyone rewriting/modifying that code also has copyright. The author of code can apply any license they like (and can distribute the code themselves with no licence or a licence that means that no-one else could ever distribute it because of a conflict of licences). LGPL-2 is a valid licence. https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License - 2.1 was a point release which also renamed it but retains LGPL as the abbreviation. Hope this helps Andy Cater >
Re: Fonts that must be purchased - nonfree?
On Sun, Jun 11, 2023 at 05:22:17PM +0700, Bagas Sanjaya wrote: > On 6/11/23 16:37, Andrew M.A. Cater wrote: > > On Sun, Jun 11, 2023 at 01:19:48PM +0700, Bagas Sanjaya wrote: > >> Hi, > >> > >> I was stumbled on Söhne font collection, primarily due to ChatGPT > >> uses it for its web interface. I'd like to also use it for hypothetical > >> web app (let's name it foodb) to be packaged in Debian (due to design > >> constraints). However, in order to acquire the font, I have to buy it [1] > >> (buy its license). Can the font be included in Debian package of foodb > >> (or as separate package), or is it non-free? > >> > > > > This would be permanently non-free because it couldn't be distributed > > without individuals purchasing the fonts. Please consider using free > > fonts that already exist within Debian / could be freely packaged and > > distributed. > > > > Hi Andy, thanks for the answer. > > Several questions remain: > > * The foodb upstream has already bought the font license (in case > of Söhne, he bought desktop and web license). If I as Debian packager > wants to also distribute Söhne for the sake of foodb (under license > in the name of Debian), at least both licenses and OEM license must > also be purchased, IMO. Is both all licenses acceptable? That's a licence personal to him: you can't rely on it. The best thing to do is to patch foodb and substitute a free font. > > * With Debian distributing this commercial font, there is a "pirating" > loophole that someone else can extract the font files and distributing > them freely on various sites (including torrent and shady ones) with > Debian licensee attached. What do you think? > This is *precisely* why the Debian Free Software Guidelines exist https://wiki.debian.org/DebianFreeSoftwareGuidelines > * Supposed that the foodb upstream refuses to change the font choice > (and insists on Söhne) due to his preference when I request the > change after reading this fact. What can I do about it? > He doesn't have to change his preferences: if his code is free and you are free to modify it for your preferences, *you* modify it. > Thanks. > > -- > An old man doll... just what I always wanted! - Clara > With every good wish, as ever, Andy Cater
Re: Fonts that must be purchased - nonfree?
On Sun, Jun 11, 2023 at 01:19:48PM +0700, Bagas Sanjaya wrote: > Hi, > > I was stumbled on Söhne font collection, primarily due to ChatGPT > uses it for its web interface. I'd like to also use it for hypothetical > web app (let's name it foodb) to be packaged in Debian (due to design > constraints). However, in order to acquire the font, I have to buy it [1] > (buy its license). Can the font be included in Debian package of foodb > (or as separate package), or is it non-free? > This would be permanently non-free because it couldn't be distributed without individuals purchasing the fonts. Please consider using free fonts that already exist within Debian / could be freely packaged and distributed. Andy Cater > Thanks. > > [1]: https://klim.co.nz/buy/soehne/ > > -- > An old man doll... just what I always wanted! - Clara >
Re: About distribution of modified copy of Debian OS
On Fri, May 19, 2023 at 06:33:35PM +0200, Borja Sanchez wrote: > Dear Debian Project Team, > > My name is Borja Sanchez, writting from Spain. I am currently planning to > run a paid course where I will distribute a modified version of Debian, > rebranded and renamed. This software will be offered at no extra cost as > part of the course materials. > > In addition to this, I wish to inform you that I am also considering > charging a fee for this customized software in the future, separate from > the course fees. > > The custom OS version will be built from the latest Debian stable version, > by running a live-build process to build a ISO image with custom packages, > scripts, assests pre-installed. > > With these points in mind, I have two key questions: > > 1. I would like to confirm that these proposed actions comply with the > GPL's guidelines and Debian's policies. > > > 2. I am interested to know if there are any other considerations, > requirements, or permissions I should be aware of before proceeding with > this plan. > As someone else has suggested, this is not going to make large amounts of money for the software. You will be responsible for all branding checking, security support and so on. If you do this, *please* change the reportbug scripts, the popularity contest script, set up your own bug tracking instance and generally be prepared to handle all queries from your users because Debian will not be able to help them since we won't know how your distribution differs. You may find it easier to use unmodified Debian and just supply a small amount of software hosted and supported by you in addition. Depending on the nature of the course, this might even be simplest by hosting your own website. Also please check the Debian wiki for details of how to set up derivatives. With every good wish, as ever, Andy Cater > > Your expert advice and guidance on this matter would be greatly > appreciated. I value your work and aim to respect the open-source > principles that Debian upholds. > > Thank you for your time. I look forward to your response. > > Best regards, > Borja Sanchez
Re: Updating the PHP license
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 amounts to: change the license > to something well-understood and less problematic. > This seems like a simplification that's long overdue: your methodology and justification seem eminently sensible: go for it! [Disclaimer: IANAL, like most others in this group, but would be very interested in anything that made licensing more understandable or simpler] > So, that’s what I’m proposing to do in a new RFC I’ve drafted for the PHP > project: https://wiki.php.net/rfc/php_license_update > > I’ve not opened this up for discussion within the PHP project yet, since I’m > still collecting feedback, and that’s why I’m sharing it here. I’ve put a lot > of work into presenting what I think is a sound and well-reasoned argument > for this change, and I’m asking for feedback from this group regarding the > method and theory I’m using to go about it. > See above: all looks good. > Thanks in advance! > Thanks to you for proposing this > Cheers, > Ben > All the very best, as ever, Andy Cater (amaca...@debian.org) > > [^1]: > https://duckduckgo.com/?q=site%3Ahttps%3A%2F%2Flists.debian.org%2Fdebian-legal%2F+php > [^2]: https://lwn.net/Articles/604630/ > [^3]: https://ftp-master.debian.org/php-license.html >
