Re: data and software licence incompatabilities?
Francesco Poli has been a longtime subscriber to the debian-legal mailing list. He has quite extensive knowledge about licensing, and is often the first person to answer inquiries about new licenses sent to the list. Not only that, but he reaches out to help you personally and does an excellent job on giving a fair shake to opposing view points. It'd be a serious loss without his involvement, even if I disagree with him. However, he also consistently, repeatedly uses the list to tell people about his personal positions on licenses where these disagree with the position taken on behalf of the project by the Debian ftp team. Worst things have happened. *yawn* Best, Clark -- 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/1378235120.30845.17486957.287f1...@webmail.messagingengine.com
Re: Public Domain again
On Thu, Jan 31, 2013, at 07:56 PM, Paul Tagliamonte wrote: In addition, I'd like to note that's what CC0 is for, really. It has some neat fall-back clauses that trigger in the event a jurisdiction doesn't allow for public domain works as such, and also releases database rights[1] which some other public domain dedications may not :) The CC0 also expressly excludes a patent license to use the work held by the author. This makes CC0 excellent vehicle for groups wishing to share example code for a patented technique so that they may request royalty after it becomes popular. The FSF has determined that CC0 is a free software license, however, the OSI has decided to pass (http://opensource.org/faq#cc-zero) If you wish to become dependent upon software which is dedicated to the public domain under the CC0, you might want to see if the original author would strike clause 4a as part of their dedication. -- 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/1360067734.8199.140661187049717.0399b...@webmail.messagingengine.com
Re: National Land Survey open data licence - version 1.0 - 1 May 2012
Timo, I'm not sure why a open source license wouldn't work? In any case, here are some comments. 2.2. Duties and responsibilities of the Licensee Through reasonable means suitable to the distribution medium or method which is used in conjunction with a product containing data or a service utilising [sic] data covered by this licence [sic] or while distributing data, the Licensee shall: * mention the name of the Licensor, the name of the dataset(s) and the timewhen the National Land Survey has delivered the dataset(s) (e.g.: contains data from the National Land Survey of Finland Topographic Database 06/2012) * provide a copy of this licence or a link to it, as well as It seems that these are OK, since these notices could be placed into an About box or similar structure? * require third parties to provide the same information when granting rights to copies of dataset(s) or products and services containing such data and This one seems problematic since it would require some sort of license assent mechanism. Perhaps this requirement could be softened to be a conditional, if you require acceptance of your own license, you must require acceptance of this one? * remove the name of the Licensor from the product or service, if required to do so by the Licensor. How do you comply with this given the other requirements? Best, Clark -- 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/1336655243.8135.140661073725377.2c87d...@webmail.messagingengine.com
Re: Bug#669356: electricsheep unsuitable for Debian main?
Linus, So, it's my opinion that there are two core requirements for free software: the license needs to be free and the whole work must be included. What follows is my personal opinion, and I'm not a lawyer, a representative of Debian Legal, or providing any sort of legal advice. Whole Work -- If the software is completely usable without _requiring_ specific non-free parts for its operation, then you've got the whole work. It is the users' right to mix or use the work in any way they wish, including with proprietary content files that may be downloaded. On Fri, Apr 20, 2012, at 02:42 AM, Linus Lüssing wrote: However as far as I know the electricsheep package currently heavily relies on non-free content to function properly which could make it unsuitable for Debian main. Providing the user the ability to cause the software to download and use non-free resources on a website is quite fine, so long as the screen saver's software would completely work as the user might expect without requiring those non-free resources. If the work is effectively crippled without the connection to their proprietary content, then they've not licensed the whole work so as a matter of policy, I'd prefer partial-works not be included in Debian. In this case, it's not uncommon for someone to fork the (incomplete) GPL'd work, remove non-free (CC licensed) parts and contribue a working free software program. The authors should know this is a real possibility by using the GPL license. The videos downloaded and displayed by Electric Sheep are Creative Commons licensed (a mixture of CC-BY and CC-BY-NC). Some jobs rendered by the network may be for images or animations which are not sheep at all, and will not appear in the screen-saver. Some of these are used for commercial purposes in order to support the developers and servers that make the software. I don't see the point. In my personal opinion, if the web-browser analogy holds (that Electric Sheep is a browser for screen saver videos), then this should be unnecessary. In this case, the user would have the ability to configure where it could get additional screen saver materials at their own discretion. Free License - What is meant by sheep generated by the algorithem on the http://electricsheep.org/reuse page? Are these content files that are downloaded? If so... is there any value to the software besides connecting to a proprietary website? If not, and the automatically generated sheep are part of the whole work that is being licensed, there is a conflict between what this clarification page and standard GPL license they use. If they mean to restrict the output of their program such that it is under the by-nc, then their license should have a non-free term with this restriction, in which case, their software isn't free (or even open source). It definately isn't GPL licensed. Otherwise, if they intend to license their program under the terms of the GPL, then the output of this program is unencumbered and they should remove their clarification comment about sheep generated by the algorithem since it is incorrect. I hope this helps. This stuff can be complex so I'm sure others may have a different take on it. Best, Clark -- 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/1335024173.24581.140661065450701.55f8e...@webmail.messagingengine.com
Re: foremost package - Licence of debian/* files
On Sat, Apr 14, 2012, at 12:24 PM, Charles Plessy wrote: I would rather suggest a license more in line with public domain works, such as Creative Commons zero license, the SQLite public domain dedication, or the GNU all-permissive license. For software works, I don't think this group should be recommending public domain. The SQLite dedication lacks a fallback license, the CC0 license explicitly withholds a patent license, and the unlicense has not had legal review. The GNU all-permissive license doesn't include the word use, which is an implicit patent grant. When a recommendation from this group is possible for a permissive work, I'd propose Apache 2.0 and Expat/MIT style license if at all possible since it protects both the one dedicating the work and also those who would incorporate the work in larger compositions. I'm not a Lawyer, This is not Legal Advice. Best, Clark -- 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/1334414385.28272.140661062351373.743ee...@webmail.messagingengine.com
Re: Using freetranslation.mobi to translate .po files
On Sun, Mar 25, 2012, at 01:36 PM, Ben Finney wrote: I think this is a false assumption, the service itself required creativity to implement, and the specific choice of word associations in specific contexts is not algorithmic nor factual, but individual calls by translation submitters who have granted the translation service license to use their work. By the same argument, the GCC copyright holders can claim to hold copyright in every program compiled using GCC, and the copyright holders in PHP can claim copyright in every web page that program renders. I think that's exactly as unsound as the argument you present. I don't think your comparison is sound. A compiler is going from one synthetic anguage with well defined semantics to another. A human language translation isn't simmilar at all. If you insist on assuming that the output is indeed the result of a mechanical compilation and if you presume the final result is GPLv2+, then the process must comply with Clause #6 of the GPLv3. This requires the corresponding *source code* needed to _generate_ the work from its source code be compatibly licensed Hence, if you want to compare this process to the GCC case... the translator itself must be released under the GPLv3. I think presuming the translation output isn't copyrighted is wishful thinking, valuing *your* copyrights over the copyrights of others. For example, if the chunks arn't copyrightable, and assembling chunks is just an automated process... why is the source document copyrightable, it's just a series of uncopyrighted facts (e.g. words). If the sequence matters, then you're not just sending chunks to the service, you're sending the entire document. I'm not a lawyer, this isn't legal advice. Best, Clark -- 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/1332769110.8480.140661054187485.22ed5...@webmail.messagingengine.com
Re: Using freetranslation.mobi to translate .po files
On Mon, Mar 26, 2012, at 09:53 AM, Steve Langasek wrote: Not in the least. Releasing something under GPLv2+ means the recipient gets to *choose* which version of the GPL they're complying with, including when they create derivative works. I've not studied GPLv2 at all, I was using GPLv3 since I'm at least a bit familar with it. That said, I don't think you could take the output of the translation and pretend that it is licensed via the GPLv3. I presume GPLv2 is similar. In the GPLv3 only case, I think there's also still room to maneuver; even though the translation is initially a mechanical translation, once done, doesn't this translation then become a new part of the *source*, subject to hand editing and revision? If so, I don't think it falls under section 6. I think there's two ways to look at it. If you look at it through a non-technical lense, the translation is copyrighted and hence you can't simply slap a GPLv2+ license on it. If you want to view it technically, I think the current explanations don't account for copyright on the sequence of non copyrightable chunks; or, if you might randomize your submissions, that the cached results don't amount to copying chunks of the translation dictionary used by the service. US copyright law recognizes that there may be creative expression in the selection and organization of factual information. This is why a phonebook (or a timezone database!), which has a trivial structure of organization and is intended to be exhaustive, is not recognized as having a copyright So, you claim that a translation dictionary isn't copyrightable? I'm not sure this assumption is true -- which words to map to which words isn't factual, it is a judgement call and creative interpretation based on context. Different translators may come up with different word choices. Also, if you're in Europe, you may also have to comply with database laws, which, as I understand it, protect against copying of sweat-of-the-brow collections. So when you choose what bits to feed into the machine and how to assemble the output, the new copyright that attaches is yours, assuming that the choosing and assembling is non-trivially creative; the machine doesn't hold any copyright. While it may be true that the translation process itself doesn't create a derived work, I believe the incorporation of a large corpus of individual creative choices found in the translation mapping do make the resulting translation a derived work. If not, we'd have some strange force of nature which magically aligned peoples minds to consider the same words to have the same meanings ;) I'm not a lawyer. This is not legal advice. Best, Clark -- 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/1332784824.2833.140661054298621.41648...@webmail.messagingengine.com
Re: Using freetranslation.mobi to translate .po files
On Mon, Mar 12, 2012, at 02:09 PM, Petter Reinholdtsen wrote: Now Petter had the idea to feed this into google translations, using http://freetranslation.mobi and committed the result back into the debian-edu-doc svn repository. I don't think you can do this. #1 Translations are copyrightable. Small translations may be non-copyrightable or fair use, but from what I understand, we're talking about the translation of a whole manual. #2 Copyright is automatic, not something you need to claim. Hence, those who produce the translation hold the copyrights to this material. You need permission of the original copyright holder to authorize the translation and the permission of the translator to license their work back under the GPL. #3 FreeTranslation doesn't have a legal notice that puts their translations into the public domain or under the GPL; Google's terms of service explicitly reserves copyright for any content you may access and does not grant a license for its use. Hence, the output of the translation process is *not* licensed under the GPL 2+ as one would need to commit it back. #4 FreeTranslation doesn't have a terms of service; Google's terms assume the right to publicly distribute derivative works under terms incompatible with the GPL. Hence, use of this service with GPL'd material may be both a violation of the original author's license and also Google's terms of service (since you lack the the ability to license the original work as Google requires). It seems Petter is arguing that he might be able to work around the copyright law by only translating a small piece at a time and then assembling the translated pieces. I'm skeptical of this logic, since it doesn't consider the intent of the effort and the work as a whole. Phrases in a creative composition such as a manual arn't a set of independent facts that can be treated individually. The other argument is that the translation service is fully automated and hence there is no expressive creativity in the translations. I think this is a false assumption, the service itself required creativity to implement, and the specific choice of word associations in specific contexts is not algorithmic nor factual, but individual calls by translation submitters who have granted the translation service license to use their work. I suggest that the developer may want to *contact* Google tell them what you wish. They may be willing to accept the input under the terms of the GPL and produce output under those same terms. Especially if the output is reviewed and alternative, corrective phrase translations submitted back to Google under terms which they could use to improve their translation service. I'm not a lawyer, this isn't legal advice. Clark -- 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/1332638619.18646.140661053646433.4b832...@webmail.messagingengine.com
Re: custom license (package: bwctl)
On Tue, Feb 7, 2012, at 05:27 PM, Charles Plessy wrote: Le Sat, Feb 04, 2012 at 09:20:19AM -0500, Clark C. Evans a écrit : | without contemporaneously requiring end users to enter into | a separate written license agreement for such enhancements Ok. So, this language iss the one under debate I guess. Simply putting on a license text isn't sufficient, you need to *require* end users to *enter* into a *written* agreement. In my understanding, “to enter into a written license agreement” can be done by receiving a license text, reading it and accepting it. Even if it might be readable this manner, this clause still creates a non-free burden for those publishing a derived work: distributions must *require* that the user *enter into* the license agreement. Typical proprietary software vendors use an Accept License Terms dialog with a prominent button saying I ACCEPT to satisfy this requirement. Best, Clark -- 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/1328622845.27455.140661033308...@webmail.messagingengine.com
Re: custom license (package: bwctl)
Charles, I'm not a lawyer, but this looks like a one-sided consortium assignment agreement disquised as a BSD license. It's not even remotely free software. Let's read the license. | You are under no obligation whatsoever to provide any | enhancements to Internet2 or its contributors. You're not required to send Internet2 your enhancements. That's definately free, but it could be omitted. | If you choose to provide your enhancements, or if you choose | to otherwise publish or distribute your enhancements Ah. So, what's covered by providing enhancements to Internet2 is any sort of publication or distribution. | in source code form This one is interesting, I guess they explicitly don't want to cover binary distributions of your enhancements. So you can keep those to yourself if you wish. | without contemporaneously requiring end users to enter into | a separate written license agreement for such enhancements Ok. So, this language iss the one under debate I guess. Simply putting on a license text isn't sufficient, you need to *require* end users to *enter* into a *written* agreement. I don't think free software licenses are covered by this clause, for two reasons. First, anything that requires _assent_ by an end user has traditionally been seen as non-free. Secondly, enter into a written agreement means that the licensor must co-sign the agreement, and hence, at the very least be notified of the licensee's usage. This has also been seen as non-free. In summary, although you can license your Enhancements to others without triggering the contribution language, you simply can't use a free and open source license to do so. This clause is meant to permit you to use a *non-disclosure* agreement or some other high-level corp-to-corp sharing agreement. | then you thereby grant Internet2 and its contributors a | non-exclusive, royalty-free, perpetual license to install, use, | modify, prepare derivative works, incorporate into the software or | other computer software, distribute, and sublicense your enhancements | or derivative works thereof, in binary and source code form. So, a one-sided copyleft. So, if you publish your derived work, they can re-license it in any way they wish. However, others can't. On Sat, Feb 4, 2012, at 09:23 AM, Charles Plessy wrote: This license allows to make derivatives under any terms, very similarly to the BSD license. Not any terms, it's absolutely GPL incompatible since your derivative is bound by this extra clause. It makes it impossible to publish derivatives under no terms at all. No it doesn't. Internet2 simply doesn't care since they can use your derivatives without restriction no matter what license you use. Unless, of course, you execute a written agreement with each end-user. | This restriction is much weaker than copyleft licenses, This is in no way a copyleft. Copyleft doesn't require assignment back to the original company, this license effectively does. Thefore, while the validity of this concept of default license may be questionable, I do not think that it is non-free. It is absolutely non-free. But wonderfully disguised. It actively discourages the free publication of course code, by penalizing those that do so with effective assignment of derivatives to Internet2. By contrast, it does exactly what the GPL forbids: permits binary derivative works and encouraging sharing only under under a NDA. IANAL, TINLA Best, Clark -- 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/1328365219.26607.140661032116...@webmail.messagingengine.com
Re: custom license (package: bwctl)
Raoul, This looks like a non-symmetric copyleft-like attempt: then you thereby grant Internet2, its contributors, and its members for that reason, I don't think it's free Clark -- 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/1328291062.12201.140661031821...@webmail.messagingengine.com
Re: custom license (package: bwctl)
I am not so sure. It is not required to give them back the changes. Although you are not required to provide them your enhancements, you are required to provide Internet2 licensing rights that are not granted to others should you wish to make the source code for your derivative work generally available. To me, and I'm not a lawyer, this license seems to discriminate against those who are not members of Internet2. For example, I'm not granted those extra permissions on derivative works. This is truly a clever license... perhaps it is an anti-free license? or the perpetually-permissive-for-consoritum-members license? Best, Clark -- 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/1328301740.24052.140661031878...@webmail.messagingengine.com
Re: Forget Me Not - Commensurate Attribution
On Mon, Jan 23, 2012, at 10:17 PM, Francesco Poli wrote: I am not sure your addition non-permissive term really follows what is allowed by clause 7b... ... Please note the word preservation. You are correct. I apologize for the distraction. So that I'm tracking an actual submission for Debian, I'll prepare very specific/targeted 7b non-permissive term for HTSQL that closely tracks prior usage and is customary. Thank you once again for your thoughtful analysis Francesco! ... I will keep this license clause alive in a submission to the OSI; as we will dual-license some components with a MIT-derived license having similar terms. However, in keeping with Ben's wishes to not use this as a license development forum, I won't pursue this further here. If anyone is interested, you could track this: https://github.com/tip-o-the-hat/fmn#readme and via http://projects.opensource.org/pipermail/license-review/2012-January/72.html Best, Clark -- 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/1327506848.16767.140661027888...@webmail.messagingengine.com
Forget Me Not - Commensurate Attribution
I have approval to release HTSQL (http://htsql) under the AGPLv3 license so long as it contains an attribution requirement as permitted by section 7 of the GPL. We also plan to release some other components of our RexDB work under a more liberal permissive license with a similar attribution requirement. The particular Additional Term I'm proposing can be found here: https://github.com/hattip/fmn/blob/master/GPL-FMN-TERM Rather than do this in a manner that hurts license proliferation, I'm attempting to make generally reusable AGPLv3 clause and such license derived from the MIT so that others that wish attribution could use these terms instead of minting their own. To this end, I've setup a GitHub project, for this Forget Me Not effort: https://github.com/hattip/fmn#readme As part of this broader effort, I hope to also have a simple compliance tool that would generate a static web page that could be used for credits licensing. I'd love your commentary and assistance making this broadly useful and I particularly value feedback by Debian community. Best, Clark -- 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/1327267915.32363.140661026629...@webmail.messagingengine.com
Re: Forget Me Not - Commensurate Attribution
I apologize, the repository is https://github.com/tip-o-the-hat/fmn On Sun, Jan 22, 2012, at 04:31 PM, Clark C. Evans wrote: I have approval to release HTSQL (http://htsql) under the AGPLv3 license so long as it contains an attribution requirement as permitted by section 7 of the GPL. We also plan to release some other components of our RexDB work under a more liberal permissive license with a similar attribution requirement. The particular Additional Term I'm proposing can be found here: https://github.com/tip-o-the-hat/fmn/blob/master/GPL-FMN-TERM Rather than do this in a manner that hurts license proliferation, I'm attempting to make generally reusable AGPLv3 clause and such license derived from the MIT so that others that wish attribution could use these terms instead of minting their own. To this end, I've setup a GitHub project, for this Forget Me Not effort: https://github.com/tip-o-the-hat/fmn#readme As part of this broader effort, I hope to also have a simple compliance tool that would generate a static web page that could be used for credits licensing. I'd love your commentary and assistance making this broadly useful and I particularly value feedback by Debian community. Best, Clark -- 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/1327270775.10375.140661026641...@webmail.messagingengine.com
Re: Forget Me Not - Commensurate Attribution
On Mon, Jan 23, 2012, at 12:08 AM, Francesco Poli wrote: https://github.com/tip-o-the-hat/fmn/blob/master/GPL-FMN-TERM describes itself as an additional permissive term, but seems to actually be an additional requirement. Quite right. I was reading section 7 incorrectly and had mentally omitted the word other. So, you're correct, this is a non-permissive additional term as defined by the GPLv3. I've fixed this, thank you so much! I am not sure I understand which is the category of allowed non-permissive additional terms this one is intended to belong to. Section 7 of the GNU (Affero)GPL v3 lists 6 categories (a through f) of non-permissive additional terms that may supplement of the terms written in the text of the license. I was intending for it to be subject to 7b, in particular, Requiring ... author attributions ... in the Appropriate Legal Notices displayed by works containing it To help move things along, I've written a Language Discussion section in the readme describing my logic. I'm hopeful to have commentary and any corrections you might see. https://github.com/tip-o-the-hat/fmn#readme Best, Clark -- 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/1327301397.16819.140661026667...@webmail.messagingengine.com
Re: ITP fsmark - bug 655224: License restriction for lib_timing.c DFSG compliant?
On Tue, Jan 10, 2012, at 11:11 AM, Martin Steigerwald wrote: 11 * additional restriction that results may published only if 12 * (1) the benchmark is unmodified, and 13 * (2) the version in the sccsid below is included in the report. I think with professional legal assistance the intent of this restriction could be phrased as a permissive additional term under GPLv3 section 7(e). What the author seems to be doing is treating SCCSID as a trademark of sorts and wanting to restrict how this trademark is used in published results. So long as the author is OK with someone making a derived work and publishing results from that work using some other name, then probably there is probably a reasonable compromise here. IANAL, TINLA Clark -- 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/1326227738.9152.140661021749...@webmail.messagingengine.com
Re: GPLv3/Apache argument brought up some concerns over the current state of the GPL
On Mon, Jan 9, 2012, at 07:41 PM, Felyza Wishbringer wrote: My biggest concern is that since it allows for small modifications, what would protect us, as the original authors, from someone taking our source, modifying a single line, then re-releasing under a modified GPLv3 that says that inclusion must state in documentation they had a part in the work. I presume you're referring to provision 7b which requires the *preservation* of specified legal notices or author attributions? I suppose someone could take a GPLv3 licensed copy of your work, modify the source code so that it displays an attribution to themselves in the Legal Notices and then release their changes under the GPLv3 together with a clause under 7b so works derived from theirs couldn't remove the attribution. They could even attempt sell their copy for a few hundred thousand dollars! However, this change wouldn't affect your version, nor anyone who is using your distribution. My guess is that there one-line change would have to be pretty significant for someone to want to use their version over yours. In particular, nothing they would do might force you to add an attribution in your documentation. I can't imagine anyone every doing something like this. IANAL, TINLA Best, Clark -- 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/1326160720.3031.140661021380...@webmail.messagingengine.com
Re: Local community license issue
On Sun, Jan 8, 2012, at 06:10 PM, Charles Plessy wrote: if you and the other contributors are not worried that your works will be used in proprietary derivatives, it may be most simple to take extremely liberal licenses, like the Unlicense, or to explore the way the Translation Project does, that is to promise to not exert copyrights. http://unlicense.org/ http://translationproject.org/html/whydisclaim.html Charles, I think if you're looking for a public domain statement for the Translation Project, I'd use the C0 instead of Unlicense. The C0 license is endorsed by the FSF and will likely be listed as a valid open source license by the OSI. By contrast, the Unlicense is viewed by some legal professionals as being quite problematic. There was a brief mention of Unlicense on the OSI's license-review list this past week, here's a quote from Rick Moen: | I hadn't seen Unlicense before now, but my immediate impression is that | it's not well formed and should be avoided. | | Its first sentence professes to put the covered work into the public | domain. However, then the second sentence professes to grant reserved | rights under copyright law. However, who is granting those rights, the | erstwhile copyright holder who, one sentence earlier, professed to | destroy his or her own title? | | By contrast, CC0 states explicitly that the current copyright holder | is attempting (I paraphrase) to the extent permitted by local law to | disavow in perpetuity and on behalf of all successors all reserved | rights, and _if that is locally unsuccessful_ grants a permissive | license under his/her powers as copyright owner. | | I realize there are a whole lot of software engineers out there who'd | like to handwave copyright law out of their lives (including you), but | it'd be really nice if they'd occasionally bother to consult suitable | legal help before shooting themselves and others in the foot. If you're interested in more, here is a followup message. http://projects.opensource.org/pipermail/license-review/2012-January/52.html -- 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/1326034309.31174.140661020729...@webmail.messagingengine.com
Re: a Free Platform License?
Jeff, Thank you for thoughts on this. Pursuant to Ben's request, the discussion of this hypothetical license (well, a 2nd pass) has been moved to license-disc...@opensource.org http://www.mail-archive.com/license-discuss@opensource.org/msg07871.html Best, Clark -- 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/1324134427.14015.140661012844...@webmail.messagingengine.com
Re: Thoughts on GPL's Appropriate Legal Notices? or the CPAL?
On Thu, Dec 15, 2011, at 09:36 AM, Ben Finney wrote: I'll mention, again, that this forum is not appropriate for general discussion about licenses in the absence of an actual existing work that is proposed for (or already in) Debian. Hi Ben. I'm working to open source a medical informatics package, RexDB, as well as a query language, HTSQL it uses; both of these are used by dozens of research groups (and hopefully many more in the coming years). In particular, one of the primary benefits to using a standard open source license is that the work would be included alongside other Free Software on fine distributions such as Debian. This is why I'm here. What seems to tip the scale in favor of doing an open source release is the GPLv3's provisions for author attribution, in particular as some sort of Incorporates RexDB (thanks Simon) message. As Richard noted allowing some sort of required attribution notice is part of the GPLv3 design. If we added a clause requiring attribution, pursuant to 7(b) of the GPL would Debian legal have any specific issue with this? In particular, both Zarafa and SugarCRM language request a logo, or if not technically feasible, a short phrase Powered By SugarCRM or Initial Development by Zarafa. We would be looking to do something similar and I'm asking for specific thoughts on the appropriateness of this for inclusion in Debian. Thank you for your kind consideration. Best, Clark -- 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/1323953372.11161.140661011975...@webmail.messagingengine.com
Re: Thoughts on GPL's Appropriate Legal Notices? or the CPAL?
On Wed, Dec 14, 2011, at 02:28 PM, Don Armstrong wrote: The critical aspect here is whether author attributions are required to be preserved in the material, or also in the ALNs. Retaining them in the material is clearly reasonable, but I don't believe that forcing them to be present in the ALN is consistent with the terms of the GPL. It seems that 7(b) pretty clearly requires that they be preserved: 7(b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; -- 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/1323954252.14536.140661011988...@webmail.messagingengine.com
Re: Thoughts on GPL's Appropriate Legal Notices? or the CPAL?
On Wed, Dec 14, 2011, at 01:37 PM, Don Armstrong wrote: An interactive user interface displays Appropriate Legal Notices to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. That is, the work can require the displaying of the Copyright notice and that there is no warranty, and that's it. The only other thing that can be done is [r]equiring [the] preservation of specified reasonable legal notices, but that does not include the displaying of those notices. I think these are the criteria used to know when a work is displaying Appropriate Legal Notices, not that it would limit items to be included. In 7(b) the GPLv3 provides for permissive additions which Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it So, I think Attribution is absolutely included, the question for me is if Powered By SugarCRM is a reasonable author attribution. I like Simon's wording of something that would be covered... | (By contrast, incorporates code from SugarCRM would remain a true fact, | and is nicely neutral: a non-binding request to acknowledge use of SugarCRM | is much less adversarial and probably has about the same practical effect.) My broader question is if Debian would permit the distribution of works with a reasonable attribution requirement. Best, Clark -- 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/1323899253.4662.140661011735...@webmail.messagingengine.com
Re: Are Web-API packages need to be in the 'main' repo ?
On Mon, Dec 12, 2011, at 10:17 AM, Christofer C. Bell wrote: What happens if my application gets smart, it looks first for the proprietary dynamic link library; and if it isn't there, it uses a web service wrapper for that library? Would this move an application from contrib to free? This software would not install on a Debian system as software can't install unless its dependencies are met. Let's say the Debian package for this only *suggests* the non-free library in its documentation or splash screen, it will after all work without the library since it can fallback on the proprietary web service. In this way there isn't a technical installation dependency: only if you want it faster. Can my GPL software package go into free now? How about if it downloads the dynamic link library at startup? Again, I think by this logic, the entirety of software included in the Debian archive that is used to access a network service could be labeled contrib or non-free. Only if there isn't a free software implementation of that web service protocol. I think that's a serious mistake. Debian has no control over the operators of external SaaS providers. Isn't that the whole problem? How can software be free if the user who receives the work has absolutely no control or right to actually use the software. If you wish to look at this from a legal perspective, when a client software program is written for the exclusive purpose of interfacing with a proprietary web service, it effectively includes the Terms of Service of that service. Hence, the GDrive adapter isn't just FLOSS licensed, it implicitly includes Google GDrive Terms of Service; which by the way, includes a provision that they can remove the user's right to use the service at any time. What about the 17 year old who can't use the Google+ client that is free software because he is too young? They simply canceled his account. Ah, right, he can still fully use the Google+ *CLIENT* application and enjoy the message about how he doesn't have an account... To embed this -- oversight? -- into Debian policy is, in my opinion, opening a Pandora's box and a grave mistake. One of the real and differentiating social purposes of Debian is to be a distribution of Free software. It's not just a technical thing, it's about denying proprietary software equal footing in the distribution. I know you could argue that it's only the Facebook Client and not Facebook itself that comes on Debian. But, how would a user know this or be able to make the distinction? Why would someone use Diaspora if Facebook is just as free? If a commercial web service wants to be available on GNU/Linux systems, perhaps they should also provide an open protocol with an open source implementation? Is that too much to ask? Best, Clark -- 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/1323710827.5573.140661010662...@webmail.messagingengine.com
Re: Are Web-API packages need to be in the 'main' repo ?
On Monday, December 05, 2011 10:51 PM, Andrei Popescu andreimpope...@gmail.com wrote: On Lu, 05 dec 11, 21:55:28, Alexey Eromenko wrote: The contrib archive area contains supplemental packages intended to work with the Debian distribution, but which require software outside of the distribution to either build or function. This definition does not say 'non-free web services' - but points in such direction. Expanding more on the pidgin example, as far as I can tell pidgin has one single library (libpurple) for all protocols. Pragmatically, I'd give Pidgin a pass since it has substantial free software use, although with a wishlist to split out the modules relying upon proprietary protocols. As you mention, having software which does free and non-free equivalents side-by-side has a particular value. Also, you don't specify what you understand by non-free web services. Remember that both Google and Facebook use XMPP for chat (a free protocol) and they might be using 100% free software on their servers. I picture client and server programs with a protocol between them as partial works; they exist in an intermediate state where they cannot be operated until they are linked together. Therefore, if you have a client that lacks a server, or a server that lacks a client, it makes no sense to talk of them as free software. In particular: 1. Since it's not operational with only what was provided, the user doesn't have the freedom to run the program, for any purpose (freedom #0) 2. Since the user only gets half of the system, the user doesn't have the freedom to study how it works (freedom #1) 3. If you have only the client or server, the user doesn't have the freedom to share the software (freedom #2) 4. Without source code access to the other half, the user has no way to make or distribute modifications (freedom #3) In my opinion, the only way to evaluate a client or server application is if you can construct a full copy of the system (requiring both parts) and demonstrate that it operates as expected by the developer. Certainly, once demonstrated in isolation that you're providing free software either part (the client or the server) may be bound to proprietary software as the user sees fit. This is their right. Concretely, I think if the protocol used has a free software implementation, and if the client has some way to choose a service, then it is absolutely clean (you could run a Jabber/IRC server on your Free Island). If the protocol only has a proprietary implementation, then even if the client code is under a free license, it still isn't a completed work since it depends upon proprietary software for its operation. Hence, it belongs in contrib. Please don't get me wrong, I would love to able to use my system without any package from contrib or non-free, but free software is just not there *yet*. Well, this is why Debian has contrib and non-free, yes? Free software is mostly on par with non-free software except a few special cases, but it is still not enough. It has to be so much better that users will *massively* choose free software, despite the marketing and the migration costs and whatnot. I understand that my opinion here isn't shared widely, but I think it has to go much further than this. Users have to be given a hard choice: there needs to be free software which is exclusive to free platforms. Otherwise we're just competing with one hand tied behind our back. This is where resources should go, not to alienating users by making it even more difficult to switch than it already is. I think clients which exclusively depends upon twitter or facebook are rather clear, while they may be licensed under a Free Software license, they are chained quite profoundly to a proprietary web service. The free/contrib distinction makes people scratch their heads. Why isn't this Free? It's an important lever. Some people just don't think of Twitter or Facebook as software at all and will happily chain their work to it. I think the awareness of this is quite important. User interfaces and package managers could choose to display contrib and non-free works with a special icon or something rather than completely ignoring their existence? Best, Clark -- 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/1323122781.28988.140661007794...@webmail.messagingengine.com
Re: a Free Platform License?
- Original message - From: Clark C. Evans c...@clarkevans.com To: license-disc...@opensource.org Date: Sun, 04 Dec 2011 13:38:20 -0500 Subject: a Free Island Public License? Please find for your amusement and hopeful commentary a different take on what it means to be Free Software. FREE ISLAND PUBLIC LICENSE This software is licensed for any purpose excepting the right to make publicly available derived works which depend exclusively upon non-free software. So long as this copyright and license are included in all substantial copies of this work you may: 1. Publicly copy and use verbatim copies of this work including public distribution and performance. 2. Privately deal with this work in any way you wish, including internal usage, copying, and modification of this work. You may also make publicly available via distribution or public performance any Derived Work only if the following conditions are met: 1. the preferred source code for the Derived Work must be made freely available under this license; 2. the Derived Work must pass the Free Island test. By Derived Work we mean a modified copy or adaptation of this work or a separate work such as a plug-in, protocol adapter, or wrapper which is designed to have intimate interactions with this work's operational details, or interfaces. A Derived Work passes the Free Island test if it could be prepared, modified, compiled, tested, installed, and operated in a manner advertised or expected using only commodity hardware, Free Software, this software, and the Derived Work itself. In particular, the Derived Work fails the test if it in any way depends upon remote network interaction or interfaces to works that do not have a Free Software implementation. By Free Software we mean any software which is readily available to the public without fee and this license, any license approved by the Open Source Initiative or any license considered free by the Free Software Foundation. A safe harbor for passing the Free Island test is if the Derived Work is fully usable as intended when compiled installed on a Debian virtual machine using software only from its 'free' distribution and KVM. If the Derived Work was created for interaction with other works, then it must be fully testable in conjunction with a Free Software alternative of this work as available on this virtual machine. THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, AGAINST INFRINGEMENT, TITLE AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- 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/1323030084.24974.140661007301...@webmail.messagingengine.com
Re: Are Web-API packages need to be in the 'main' repo ?
On Sunday, December 04, 2011 3:55ser PM, Joey Hess jo...@debian.org wrote: Perhaps they should be moved to 'contrib' category, because they interface non-free web-services. Debian's 'main' repository seems not the right place for any such web APIs. ... How far down this line until it belongs in contrib or non-free? I don't know. I'd say that any dependency on non-free remote service fails Debian's Desert Island Test [1] and as such, even if the remote access is free-of-charge and functional, the code using it should be limited to contrib. Software which has a configurable end-point and which access an implementation that is free software is free. Best, Clark [1] http://wiki.debian.org/DesertIslandTest -- 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/1323046941.19489.140661007379...@webmail.messagingengine.com
Re: a Free Platform License?
On Tuesday, November 29, 2011 8:25 AM, Hugo Roy h...@fsfe.org wrote: I am talking of the freedom to distribute copies of the program. If you restrict that freedom to specific people that is clearly not free software, and that is totally consistent with RMS' l, definition as well. The GPL provides conditions for distribution, when those conditions are not met -- you can't distribute a modified copy. Hence, the GPL prevents distribution. tightly integrating looks like it's a derivative work. I don't think this is possible. Both would have to be under GPL terms. (That's not a discrimination!) Zeek does have the right to construct his derived work that combines the GPL and non-free work. He can't put his work under the GPL… and this is true to anybody. He cannot publish his modifications because he cannot put John's non-free under the GPL. Since Zeek can't distribute John's work under the GPL or a compatible license, he doesn't meet the distribution criteria to be a distributable modification of Lisa's work. The GPL isn't preventing distribution. If the GPL was preventing distribution, it would mean in the first place that Zeek has a legal right to distribute a work of authorship. Ok. So this is the crux of why GPL doesn't discriminate; since the GPL didn't provide the right of distribution to Zeek, there isn't any right lost, and hence no discrimination. This right comes from copyright (in the US), but in this precise example it would be a either: * a violation of copyright (John's copyright) if you pretend it's under GPL (or GPL-compatible license) * a violation of the GNU GPL (Lisa's copyright) if you distribute with the non-free library There are no discrimination by the GPL: nobody is allowed to get this program, because Zeek has no right under John's license to publish any derivative work. Oh, let's suppose John's license provides the rights to make derivative works then, provided that his library's license (say with an advertising clause) is incorporated. That's where the non-free comes from; not the GPL. Well, I think this is a terminology / perspective issue. ... So, according to this logic, the Free Platform License described (as derived from GPLv3, without Affero) would also not discriminate against platform users. Since those who would wish to distribute FPL licensed software for use specifically with a non-free platform have no previous rights to do so. Hence, there is no discrimination with this approach. Correct? Clark -- 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/1322580254.17618.140661005089...@webmail.messagingengine.com
Re: a Free Platform License?
On Mon, 28 Nov 2011 10:25 PM, Francesco Poli wrote: On Mon, 28 Nov 2011 16:11:29 + Simon McVittie wrote: The tl:dr version: just use the GPL, or the AGPL if you must. My summary is somewhat similar: please just use the GNU GPL, and nothing more restrictive than that (I don't think the GNU AfferoGPL v3 meets the DFSG, so please avoid that license, as well). Francesco has made a compelling case against including the Affero terms as part of the Free Platform License. So, let's assume that the proposed license is derived from the GPLv3 and doesn't not have restrictions on use; I'll provide an revision of the proposed license text later this week. ... I suppose there are many grounds for dismissing this license and I'm not sure where I stand. Here are the reasons as I've been able to ascertain. License Proliferation: I think that this license is substantially different in its effects than existing licenses and is written in a generic manner. Conflicts with GPL: Unfortunate as it may be, it is not a reason to reject the proposal. Lots of licenses conflict with various GPL versions and there are known techniques for handling these conflicts. By using GPLv3 text as a basis, it will be compatible with the bulk of non-copyleft licenses. Adoption Problems: I think you can't say this license wouldn't be popular. I know many developers who dislike when their work is used in combination with proprietary platforms so much that they'd engage more if their work were exclusive to free platforms; and I know still others who would kill for an effective way to dual-license by charging for compatibility with proprietary platforms. Practical Problems: I think the license would provide a very practical effect; it'd be far harder to make derived works that rely upon specific platform features. That said, this probably needs a bit more exploration. DFSG/Discrimination: This sort of license would treat platform software in the same manner that the GPL treats proprietary libraries. So, I think if there are problems here, the GPL shares those same issues. Free Software Problems: I think this is a free software license, and if it isn't, let's fix it. Did I miss anything? I'd prefer to continue this very helpful discussion if those on debian-legal would be willing to continue to hear me out. In particular, I don't understand the Practical Problems, so any thoughts on this would be especially delightful. Best, Clark -- 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/1322621654.3906.140661005343...@webmail.messagingengine.com
Re: a Free Platform License?
On Tuesday, November 29, 2011 1:35 AM, Osamu Aoki os...@debian.org wrote: This definition of Major Component may include non-free binary blob in non-free kernel modules. For example, ethernel device driver, HDD RAID driver, 3D Video driver, ... If the work requires a particular non-free system library or driver or binary blob for its operation, then distribution would be restricted. However, everything needed to build convey binary distribution from preferred sources is free and if the final work operates on an entirely free platform, then the distribution criteria would be met. Are you sure if a user uses PC with non-free NVIDIA driver as a major component, you request this? If this is your intention ... Or you allow them as long as they use GNU/Linux. For a free software license, how the user chooses to operate the work, on what hardware and on what platform isn't a concern. On Monday, November 28, 2011 4:11 PM, Simon McVittie s...@debian.org wrote: By being a copyleft license with more restrictions than the GPL, I believe your proposed license is non-GPL-compatible. This isn't necessarily a barrier to DFSG compliance, but it's a major practical problem. Yes, I agree it's a practical problem. I also think your comments are accurate. I'm not sure I agree with your conclusion, I need a bit more time to digest your thoughtful analysis. Some interesting corner cases for you to think about: * If your software is ported to run on Wine, an LGPL implementation of the Windows API, is that a free platform? (How could it not be, given that its license is the same as glibc?) If it turns out the same binaries run correctly on a Windows machine, have you achieved anything by using this license, apart from annoying your users? * If your software is ported to run on GNUstep on Darwin, is that a free platform? If it turns out the same binaries run correctly on Mac OS X, have you achieved anything by using this license? Yes. Quite a bit actually. We've ensured that any derived works will build and operate on a free platform and won't require a proprietary operating system for these purposes. Even so, would this be practical? You couldn't just get away with packaging the software in a emulated environment, you'd have to ensure that it operates there as you expect; otherwise, you'd be in violation. Imagine a bug report comes in for a specific version of a platform due to a defect in the system library. To develop an application-level work-around for this bug, you'd first have to ensure that your emulation environment also has this defect. I guess to be absolutely clear about this, the license should define the idea of preferred platform and require that this platform be free software. * If I run your software in a FreeBSD or Linux virtual machine (e.g. VMWare or VirtualBox) on a Windows host, is that allowed? Why/why not? * A PC running your software has a non-free BIOS, and runs FreeBSD with binary-only drivers (nVidia!). Is that allowed? Why/why not? What if the binary-only drivers are needed to boot (network card firmware)? How a user wishes to use a copy of the work in the privacy of their own organization is not the subject of the license. I think the virtual hardware emulation layer may be a great way to think about it. Perhaps the best test for compliance of a distribution is if you can build and deploy the work in an emulated environment (say KVM) running only free software. (out-of-sequence) I don't think whether your license is DFSG-compliant is the important issue here; I do. If Debian, on general principle is opposed to any license that would discriminate based upon platform, then this determination effectively eliminates further discussion. So far in this thread, there have been several comments that lead me to believe that even if this license may be considered free software, it would not be DFSG compliant. On November 24, David Prévot taf...@debian.org wrote: If you're looking for a license that discriminate against [a] group of persons [DGSG5], such as proprietary platforms users, that's not going happen in Debian. On November 26, Ben Finney ben+deb...@benfinney.id.au wrote: Discriminate against proprietary platforms seems to necessarily entail discriminating against a field of use for the work, which violates an essential freedom for the recipient of the work. On November 26, Hugo Roy h...@fsfe.org wrote: This license should prevent distributions which specifically target a proprietary platform. No, you don't want to prevent distributions, that would be like taking away the freedom to distribute copies to specific people. That would not be free. I think the origin for this line thinking resides with DFSG/OSI non-discrimination clauses and has very little do to with RMS's definition of free software. For example, let's consider a case to which the GPL license is found
Re: a Free Platform License?
On Saturday, November 26, 2011 2:59 AM, Hugo Roy h...@fsfe.org wrote: Le vendredi 25 novembre 2011 à 12:04 -0500, Clark C. Evans a écrit : I understand that it's traditional for Free Software to impose restrictions primarily as a condition of distribution; Exactly, they're conditions but not restrictions. And it really seems that what you're looking to impose with the license are restrictions that discriminate. I hardly see how such a licensed software could be free software. If a condition isn't satisfiable, there's no difference. For example, the GPL restricts the distribution of derived works that would include proprietary (non-free) components. | Would Debian consider a Free Platform License (FPL) derived | from the AGPLv3, but with the System Library exception | removed (as well as the GNU specific prologue)? How's removing the exception effective in what you are trying to achieve? This license should prevent distributions which specifically target a proprietary platform. While it would not directly prevent usage of the software on a proprietary platform -- it could hinder it in a practical manner. Consider this license would include System Libraries as part of the Corresponding Source (rather than excepting it). In this case, those who package the software are creating a modified version. As such, the system libraries it is packaged to use must also be licensed under this or a compatible license. The Debian distribution would meet these conditions, proprietary platform distributions won't. For a C language program that must be linked to msvcrt.dll, the distribution condition is pretty much fatal. It'd require users compile their own copy of the program for private use. For interpreted languages, such as Python or Ruby, this sort of license may be less effective since the typical package files are platform independent. If a platform installer was created, for example one that included a runtime engine compiled for a given platform, it'd be restricted. Overall, I think the added encumbrance to distribution might be sufficient to provide an effective discrimination while still remaining free software. People can install a free system library on a proprietary platform and then software licensed as such (GPLv3 minus system library exception) could link to it, but installed on a proprietary platform, which fails at doing what you're trying to do. I'm not sure what case you're outlining here. In the end, I am really not sure a license is what's needed to make free software operating systems grow (and I am also not sure yet another license is needed at all. Copyleft is already essential to achieve that). Thank you for your time Hugo. Best, Clark -- 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/1322293962.19350.140661003759...@webmail.messagingengine.com
Re: a Free Platform License?
I'm looking for a license that discriminates against proprietary platforms. I'm open to any specific effects that may do this, subject, of course, to what is consistent with Debian's values. I'm pretty sure that the above stated intention is not compatible with software freedom. By design, copyleft discriminates against proprietary software. It just happens that the GPL has an exception for system libraries so that it doesn't discriminate against platforms (a specific kind of proprietary software). Just because this exception exists in the GPL doesn't mean that it is necessary requirement for being considered free software. Is it? Discriminate against proprietary platforms seems to necessarily entail discriminating against a field of use for the work, which violates an essential freedom for the recipient of the work. I don't understand how discriminating against a given software component licensed in a particular way would necessarily entail discriminating against a field-of-use, group of users, etc. They seem quite orthogonal concerns to me. If you could prepare the work you're interested in packaging, and the actual set of license terms, the discussion could get more concrete. I'm asking something fairly concrete here already: | Would Debian consider a Free Platform License (FPL) derived | from the AGPLv3, but with the System Library exception | removed (as well as the GNU specific prologue)? Reducing this to an actual license text is quite a bit of effort -- especially if it weren't considered. Best, Clark -- 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/1322293968.19352.140661003757...@webmail.messagingengine.com
a Free Platform License?
I'm looking for a software license, which Debian would support, that actively encourages use of free platforms; and consequently restricts proprietary platforms. While GNU/Linux is the dominant server operating system, it lags on the desktop. Many of my colleagues who were just a few years ago running GNU/Linux on their laptop have switched over to OSX for pragmatic reasons: to avoid hardware device issues and to be compatible with applications that the business folk use. Why don't laptop vendors support GNU/Linux operating systems? Why do business apps still only work on OSX or Windows? I think the issue isn't one of software quality, or effort, or tech people just not getting design. I think the difficulty is how we license our software. Free and open source software can be used without restriction on proprietary platforms, yet, the reverse isn't true. If a open source application is useful enough, it'll be ported to Windows or OSX. As a result, proprietary operating systems have all the goodness we provide -- plus proprietary stuff we don't. A platform's primary value isn't intrinsic. Instead, it is proportional to the platform's user base, which has a virtuous cycle with the applications and services that are available for this platform. Here's the rub. When a free and open source application is ported to a proprietary platform with a higher user base, perhaps it brings higher value to that platform than it does to the free platform it was developed with. At the very least, a port neutralizes any relative advantage the free platform might have had. I think historically this was a very fine trade-off since there was much free software to be written and the best way to get new users was to write software that operates on the platforms they were using. However, is this the right approach going forward? ... Would Debian consider a Free Platform License (FPL) derived from the AGPLv3, but with the System Library exception removed (as well as the GNU specific prologue) [1]? Perhaps more importantly, would a license such as this actually promote free platforms in a manner that could be somewhat enforceable? I'm thinking for example of a Python or Ruby application. Would a Windows specific installer be permitted? Thank you kindly for your thoughts. Best, Clark [1] I'd like to thank RMS for his very helpful feedback. -- 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/1322158134.30046.140661003219...@webmail.messagingengine.com
