Re: [License-discuss] I've been asked to license my open source project CC0
Hi Shahar. You already got many answers, but none seem to be complete, so let me have a go... On Tue, Nov 7, 2017 at 8:09 PM, Shahar Or <mightyiamprese...@gmail.com> wrote: > I have been asked to change the license of an open source project of mine > to CC0. I'm reluctant to do so, as it is not OSI approved. > https://github.com/mightyiam/shields-badge-data/issues/28 > Makes sense. I wouldn't do it either. I should say I think Creative Commons is great and all of what they do is well intended. But for software I think there's no justification to not pick an OSI approved license. (Conversely, CC licenses are primarily designed for copyrighted works that are not software code.) The relevant history here is as follows: A couple years ago people proposed to Creative Commons to submit CC0 for OSI certification. You can find that discussion on license-review list if you want to read with your own eyes. Questions were then raised about the fact that CC0 expressly excludes patents from the grant. (Which is fair in the sense that public domain is a concept related to copyright.) Many reviewers voiced an opinion that explicitly reserving the right to sue your users for patent infringment is clearly not compatible with the Open Source Definition. (Notably, OSI has previously rejected licenses on the same grounds. Search for MXL I believe?) CC then withdrew it's submission. Technically then, it's never been decided whether CC0 is open source or not, but it is not OSI approved. Is there good reason for this request, at all? > Probably not. Maybe they don't want other licenses in their repo. It's quite common for open and closed software to include small parts that are BSD, ISC, MIT, etc licensed, even if the software as a whole is licensed under its own license. If they have an actual reason (that is not a policy or possibly a misinformed reason), it would have to be something that is in the ISC license and not in CC0. Seems like warranty and patents are the 2 alternatives? > I mean, can they not otherwise depend on my software, if their software is > CC0 licensed? > When I conveyed my reluctance it was suggested that I dual-license. > Dual-license is often a good solution! You have 1 license that is OSI approved, so you are clearly open source. Then you have other licenses that meet some other specific need. You need to consider still, whether CC0 is a license you want to use. Is it ok that someone would distribute your software without warranty and with explicitly reserving the right to sue for patents? Note that as long as you keep the ISC in your own repo, then people getting the software from you, will still have both the warranty and whatever patent license may be implied by the short ISC license. henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] New maintainer, changing license?
My layman understanding is that that is exactly what it says. On Sat, Jul 29, 2017 at 11:38 AM, Johnny A. Solbu <joh...@solbu.net> wrote: > Hi. > I am the new upstream maintainer of the cd ripper Grip > The code licence is stated as follows: > > == > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License as > * published by the Free Software Foundation; either version 2 of the > * License, or (at your option) any later version. > == > Some files are licenced under the Lesser GPL, with the same type of terms > saying that one can use a later version. > > My question is: Does this mean that I can change it to say it's released > under GPL version 3 and later? > > -- > Johnny A. Solbu > web site, http://www.solbu.net > PGP key ID: 0x4F5AD64DFA687324 > > ___ > License-discuss mailing list > License-discuss@opensource.org > https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss > -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] FreeAndFair license
I have seen github repositories with MIT or GPL dual licensing (essentially same as what you say). The explanation was that they wanted to use MIT (as is common in Node/JavaScript circles) but also wanted to be GPL compatible, so had added that as an explicit option. (The particular project then dropped the GPL license, after assurances that MIT is considered to be GPL compatible.) henrik On Sun, Jun 11, 2017 at 1:45 AM, Lawrence Rosen <lro...@rosenlaw.com> wrote: > Thanks for your comments, Joe. Please let me know how OSI responds to your > license questions. > > > > I'd like to make one other comment on dual licensing. I support that as a > commercial business strategy. But the only practical dual licensing > strategies for a licensor that makes sense to me are choices between the GPL > or AGPL and a complex (and perhaps more profitable) commercial license. Your > "FreeAndFair" choice between the GPL and the BSD – assuming it is a fair > dual licensing choice and not, as in your license, a discriminatory > provision between categories of users – presents an obvious choice for a > licensee to make: The BSD is always a better license than the GPL. > > > > I am surprised by offers at GitHub and elsewhere of open source software to > the public under "either the BSD or the GPL". Take the BSD! It is fully > compatible with the GPL anyway. Always take the more generous offer of > software! > > > > I'm also copying some friends at OSI, but I'm not copying your email. > > > > /Larry > > > > Lawrence Rosen > > Rosenlaw (www.rosenlaw.com) > > 3001 King Ranch Rd., Ukiah, CA 95482 > > Cell: 707-478-8932 > > > > From: Joe Kiniry [mailto:kin...@freeandfair.us] > Sent: Tuesday, June 6, 2017 10:55 AM > To: lro...@rosenlaw.com > Cc: Brent Turner <turnerbre...@gmail.com>; Alan Dechert <dech...@gmail.com> > Subject: Re: FreeAndFair license > > > > > > > ___ > License-discuss mailing list > License-discuss@opensource.org > https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss > -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Fwd: Yet another question about using libraries with different licensed in OSS
On Wed, Jan 18, 2017 at 1:00 PM, Mikkel Bonde <mikbo...@gmail.com> wrote: > I've been maintaining a private piece of package on Github lately, that's > composed from software that's MIT licensed and BSD2 licensed and my own > source code. > > The original author(s) abandoned the project(s) and are not answering neither > mails nor "issues" on Github. > > Am I allowed to publish this as OSS on eg. Github, and if so - is it enough > to include the original licenses and give credit to original authors? I think > it gets a bit hard to figure out whenever you mix licenses. > Yes: Taking over abandoned source code is one of the major points of open source! Some licenses mix well with others and some don't. The general point is that if two licenses have contradictory requirements, you cannot satisfy the combination of them. For the so called "short permissive" licenses like BSD and MIT, the general consensus is that they can be mixed with pretty much anything else. The only annoying part when mixing two of them together is that you must still correctly retain the license for each piece of code. So the source code file that was originally BSD licensed must retain the BSD license in its header, and likewise for the file that is MIT license. You must just be careful not to mix them. For example, you may not want to mix MIT code and BSD code into the same file, just to keep things simple. henrik PS: I like your name! In my ancestral line some hundred years ago there was a sequence of men called Mikkel. And they were of course farmers. One was even called Mikkel Mikkelsson, as his father was Mikkel too. -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] notes on a systematic approach to "popular" licenses
you're not in the > top 10 most popular within five years, then you get retired? But not sure > that's a good idea at all - just throwing it out as one option. > > If a new license meets #1, but not #3 and #4, then OSI's formal policy > should be to approve, but bury it in one of the other proliferation list > groups. (Those groups are actually quite good, and should be fairly > non-controversial — once you have a good policy for what gets in the more > "favored" groups.) I don't think a new "deprecated" group is necessary - the > proliferation categories are basically a good list of that already. > > This is still a somewhat subjective process, and if it had been in place in > '99-'06, it would have been fairly fraught. However, I think most of the > "action" in open source organization has moved on to other areas (e.g., > foundation structure, CoCs, etc.), and the field has matured in other ways, > so I think this is now a practicable approach in ways it would not have been > a decade or even five years ago. > > Miscellaneous notes > > I don't recommend merely updating the existing "popular and..." list through > a subjective or one-time process. The politics of that will be messy, and > without a documented, mostly-objective, data-driven method, it'll again > become an outdated mess. > The OSD should probably be updated. At the least this should be by > addressing things like whether a formal patent grant is required of new > licenses; more ambitiously it might follow Open Data Definition 2.x by > splitting out open licenses from open works. > With SPDX and Fedora providing more comprehensive lists of FOSS licenses, it > might make sense for OSI to link to those as "extended" resources, to reduce > pressure from obscure license authors to get their license approved. > The biggest pressure on this process will continue to be licenses that try > to open up space for new commercial business models (e.g., Fair Source). The > more OSI can write/document/buttress OSD #1, the better. > I used to think a license wizard was a good idea, but I don't any more. I > thought copyleft spectrum was really the only important decision-making > factor, which made the idea plausible, but non-copyleft factors matter much > more than I once thought, and make simplifying to a "wizard" too hard for > OSI (though perhaps still plausible for a third party). > Documentation of what the copyleft spectrum is, what the key licenses on it > are, and what other factors might be relevant, is still a good idea, but are > secondary to getting the basic lists right. > > HTH- > > Luis > > > ___ > License-discuss mailing list > License-discuss@opensource.org > https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss > -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] [Non-DoD Source] Groups/Communities
The FSFE maintains some kind of guild of European free software lawyers. Some of whom are members of this list as well :-) I'm obviously not part of it myself, even if I have once benefited from their collective advice. But I believe there's a mailing list where they keep in touch with each other. https://lwn.net/Articles/230864/ henrik On Wed, Jan 4, 2017 at 10:22 PM, Patrick Masson <mas...@opensource.org> wrote: > My apologies for my lack of specificity. > > I am specifically looking for groups whose members are lawyers. > > Thanks again, > Patrick > > >> All, >> >> Could you please point me to any organizations, groups, lists, etc. >> discussing open source licenses and other legal issues related to >> open source software that you find valuable. >> >> Thank you, >> Patrick > > -- > || | | || | || || | || | ||| | ||| > > Patrick Masson > General Manager & Director, Open Source Initiative > 855 El Camino Real, Ste 13A, #270 > Palo Alto, CA 94301 > United States > Office: (415) 857-5398 > Mobile: (970) 4MASSON > Email: mas...@opensource.org > Website: www.opensource.org > ___ > License-discuss mailing list > License-discuss@opensource.org > https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Views on React licensing?
On Tue, Dec 13, 2016 at 1:17 AM, Rick Moen <r...@linuxmafia.com> wrote: > Quoting Henrik Ingo (henrik.i...@avoinelama.fi): > >> Good to remember that CC0 is not an OSI approved open source license, >> precisely because it did not grant a patent license. > > As someone who was part of that conversation, I feel the above doesn't > accurately summarise its substance: We were in the middle of a > conversation with the submitter about whether CC would consider removing > CC0's blanket exclusion of all patent rights including implied grants, > when the submitter withdraw the licence from the review process -- but > there's no reason to think approval would have been denied, otherwise. > There was a wide consensus that CC0 is very clearly OSD-compliant. I would have to disagree on the part that there was any consensus, wide or otherwise, but you're correct, and thanks for reminding me, that technically the issue was unresolved as the submitting party withdrew the submission. That discussion actually referenced another prior submission, the MXM License related to the MPEG standard reference implementation (http://www.linuxjournal.com/content/should-open-source-licence-ever-be-patent-agnostic) where the main reason for submitting the license was to carve out the patent license from MPL. This submission was also not approved and was cited as precedent when discussing the CC0 license. henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Views on React licensing?
On Mon, Dec 12, 2016 at 7:55 PM, Lawrence Rosen <lro...@rosenlaw.com> wrote: > Henrik Ingo wrote: > > MIT is on record as saying that the MIT license, which is otherwise > equivalent to the 2-clause BSD license, does *not* grant a patent license. I just wanted to catch this email client malfunction above: It was obviously not me who said the above. (No worries, it happens, just wanted to set record straight.) henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Views on React licensing?
On Tue, Dec 6, 2016 at 11:00 PM, Tzeng, Nigel H. <nigel.tz...@jhuapl.edu> wrote: > On 12/6/16, 3:33 PM, "henrik.i...@gmail.com on behalf of Henrik Ingo" > <henrik.i...@gmail.com on behalf of henrik.i...@avoinelama.fi> wrote: >>The question isn't about patents or copyrights. The point is that taking >>an OSI approved license and making additions to it by adding a separate >>file with additional terms and conditions, results in a combination which >>as a whole is not OSI approved open source license. It is no different >>from taking the BSD license and making additions to it within the same >>file. > > In what way is the BSD copyright license impacted by an external patent > grant license? Many people, including significant producers of BSD software, believe that the BSD license is also a patent license. In this context it is not acceptable to use an open source license that grants a patent license, and then add a separate "grant" which in fact limits and is narrower than the BSD license. In more general terms, you cannot take an OSI approved license, add your own limitations, and still claim being open source. (You may or may not be, but the end result is certainly not OSI approved.) Note that I'm stating a general principle here, while at the same time I'm of the opinion that the patent retaliation clause in the React patent grant is in my opinion a good thing. > How is this different than combining a BSD copyright license and an > external trademark license agreement? If an external trademark license agreement would place requirements on the users of open source software that are in conflict with OSD, such a combination would also be unacceptable. Arguably, the attempts at various badgeware licenses are a good precedent on this topic. On the other side, organizations like Red Hat and Mozilla protect the integrity of their own trademarks - and arguably even their users - by asserting that some trademarks can only be present in software releases actually made by themselves. In practice this does not limit the openness / freedom of the software. As evidenced by the existence of CentOS and Iceweasel, it is a simple task to just change that trademarked name to your own when forking the code. Speaking of BSD... Clause #3 in the BSD license is an early historical principle of asserting the same principle: People should release software in their own name. > IMHO it has everything to do with whether patents are in or out of scope > for OSI license approval for copyright licenses. Patents are of course in scope for OSI license approval process, are usually considered as part of every review of new licenses, and most of the commonly used open source licenses have clear and explicit clauses about patents. > That¹s fine as long as there are open source licenses with far more narrow > grants or no grants whatsoever like CC0. Good to remember that CC0 is not an OSI approved open source license, precisely because it did not grant a patent license. henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Views on React licensing?
On Tue, Dec 6, 2016 at 8:28 PM, Tzeng, Nigel H. <nigel.tz...@jhuapl.edu> wrote: > On 12/5/16, 6:55 AM, "License-discuss on behalf of Henrik Ingo" > <license-discuss-boun...@opensource.org on behalf of > henrik.i...@avoinelama.fi> wrote: >>On Fri, Dec 2, 2016 at 6:26 AM, Richard Fontana <font...@opensource.org> >>wrote: >>> - is it good practice, and does it affect the open source status of >>> software, to supplement OSI-approved licenses with separate patent >>> license grants or nonasserts? (This has been done by some other >>> companies without significant controversy.) >> >>This should of course be discouraged. However, I sympathize with this >>kind of setup if it is intended to be a proposal for a license that >>doesn't yet exist. If Facebook a) intends for the combined license to >>qualify as open source, and b) eventually submit it for OSI approval, >>then it seems to me this is a natural path towards such a goal. > > React is BSD and therefore already open source. > > As far as I can tell the OSD doesn¹t explicitly address patents. > Heartache with CC0 wasn¹t based on compliance with the OSD. Any concerns > with React likewise. The question isn't about patents or copyrights. The point is that taking an OSI approved license and making additions to it by adding a separate file with additional terms and conditions, results in a combination which as a whole is not OSI approved open source license. It is no different from taking the BSD license and making additions to it within the same file. Especially in this case, where it is debatable whether the patent grant adds or removes rights compared to plain BSD. (I appreciate the patent grant precisely tries to clarify that uncertainty, but even then the practice of making additions to open source licenses should be discouraged, and is only ok if the intent is to submit the new whole as a new license for OSI certification.) >>> - should Facebook be encouraged to seek OSI approval for the React >>> license including the patent license grant? >> >>Yes. As far as I can see, the BSD + additional stuff should be a >>single file and single license, and OSI approved. > > Why not just use Apache? Because Facebook wants a competitive advantage. > I don¹t see how Facebook is any more trustworthy than any other > corporation nor do I see any difference between Oracle, Facebook, Google > or Microsoft that isn¹t a CEO change away. Sun was very pro-open source > until it went out of business and was acquired by Oracle. > > Patent truces favor the big guys and have zero impact on patent trolls. I > see little need to "allow terms where those companies actually > contributing open source software have an equal or even stronger position > in patent suits² because the level of contributions changes over time, > sometimes rather quickly. > The React license, when used as a generally approved open source license, of course wouldn't be written in a way where Facebook gets a competitive advantage. It would be written in a way where whoever publishes open source - especially useful and popular open source - would get the same competitive advantage. In particular, small guys can enjoy the competitive advantage by making their own small contributions to the React ecosystem (or any other software project adopting same license). Also, since the React license does allow recipients to do counter suits in your hypothetical case where FB has turned into a patent aggressor, I just don't see the merits of your argument at all. > I believe that license terms should be non-discriminatory and range from > more business-friendly terms to more commons-friendly terms so there is a > wide range of applicable open source license for all business cases. I categorize patent grants with wide reaching termination clauses as commons-friendly. Like I said, my only regret is that there aren't licenses being used that would be even more wide reaching than this one. henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Views on React licensing?
On Fri, Dec 2, 2016 at 6:26 AM, Richard Fontana <font...@opensource.org> wrote: > - is it good practice, and does it affect the open source status of > software, to supplement OSI-approved licenses with separate patent > license grants or nonasserts? (This has been done by some other > companies without significant controversy.) This should of course be discouraged. However, I sympathize with this kind of setup if it is intended to be a proposal for a license that doesn't yet exist. If Facebook a) intends for the combined license to qualify as open source, and b) eventually submit it for OSI approval, then it seems to me this is a natural path towards such a goal. > - does the breadth of the React patent termination criteria raise > OSD-conformance issues or otherwise indicate that React should not > be considered open source? My view is clearly no. To me these objections seem similar to people claiming that GPL is unfair, not not as free as permissive licenses, because it does not allow them to use GPL licensed code in certain ways that they would want to. Tough luck, you don't get my sympathies. Technically it seems to me the argument against the React patent grant is that a license must only list conditions applying to the specific piece of software at issue, e.g. contained within a single github repo or tar file. I note that in the reality of today, this opinion seems to purposefully argue for as narrow a patent retaliation clause as possible. Possibly the people (which I don't know) arguing this has such an agenda? The reality of today is that software is commonly distributed in very small pieces. A framework like React is likely to grow not as a single repository, but as an ecosystem of multiple small modules (was it something like trim() that caused such a mess in npm recently?), each version controlled and distributed separately, each with their own license file, however, most of them using the same license. It is IMO a perfectly valid view to say that when you participate in this commons as a whole, such as by downloading and using for free multiple modules of such a commons, you must enter into a patent truce with that community as a whole, not just refrain from suing the particular implementation of some trivial function like trim(). We should also consider that the narrow view would in fact favor more closed source companies suing companies publishing lots of software as open source. (E.g. Oracle vs Google, or Microsoft vs Everyone). Companies not publishing (majority of their software as) open source would enter patent disputes with a stronger hand, since they don't give away anything themselves, but their patent aggression targets have given away right to counter sue for all of their IPR except at most for some specific piece of code at issue. IMO it is in the interest of OSI and the FOSS community to allow terms where those companies actually contributing open source software have an equal or even stronger position in patent suits. In addition to the fact that OSI has historically approved such patent clauses, I'd also want to list as "similar in spirit" precedent the AGPL §13. To achieve its activist goal, the AGPL requires you to distribute not just any AGPL code covered by the license, but also regular GPL code if used in the same work. Speaking of GPLv3, at the time it was drafted I remember I was hoping FSF would put into it similar or even stronger "global patent truce" kind of patent retaliation clause and I was disappointed it didn't. If you ask me, it would be within the OSD for GPL to say essentially: If you assert patents against any GPL licensed software, you've lost your license (maybe even copyright license?) to use any GPLd software from anyone in the world. Probably my position is rather extreme then? > - if the React patent license should be seen as not legitimate from an > OSI/OSD perspective, what about the substantial number of > past-approved (if now mostly obsolete) licenses that incorporated > patent license grants with comparably broad termination criteria? Such a view would therefore be contradictory with precedent. > - should Facebook be encouraged to seek OSI approval for the React > license including the patent license grant? Yes. As far as I can see, the BSD + additional stuff should be a single file and single license, and OSI approved. henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] open source licenses addressing malicious derivatives
Hi Christopher You might want to read up on Mozilla for this topic. They run an unusually thight trademark enforcement regime, precisely for this reason. Basically, the source code is open source, but you cannot leave any user visible traces of their trademark if you add even the smallest change. Red Hat Enterprise Linux has a similarly thight trademark policy for commercial reasons. You can copy it, but trademark must be removed. (So for example, even in documentation, CentOS might refer pseudonymously to "upstream vendor".) In short, trademark is commonly used for this purpose, while licensing not so much. Since trademark rights are quite independent of copyrights, this is also GPL, etc... compatible, since there are no restrictions on the code, you're just protecting your name and reputation. henrik On Wed, Jun 22, 2016 at 11:40 PM, Christopher Sean Morrison <brl...@mac.com> wrote: > Is there any OSI-approved license that provides injunctive relief to an > original author in the situation of a bad actor creating a damaging > derivative? To figure this out, I’ve been researching and trying to sort > out: > > 1) which existing OSI-approved licenses impose derivative requirements > (e.g., such that others must rename, that changes must be itemized, etc) > and, > > 2) whether such a requirement makes the license de facto > GPL/LGPL-incompatible? > > For #1, I know CDDL has a required notice of authorship of modifications > but didn’t see anything else at least amongst the popular licenses. I know > that license+trademark protection is the primary method for several notable > open source products (e.g., Firefox), but getting an injunction solely on > failing to announce modifications seems weak. > > I think the answer to #2 is “probably”, as anything that would hold up in > court would likely be an additional requirement, forbidden by the GNUs, but > would appreciate any insights. > > The backdrop for this is an author reasonably going to court and obtaining > injunctive relief should some bad actor distribute a derivative that was > specifically designed to cause some surreptitious harm to the original > author. Not just a hypothetical case. > > Consider governmental actors where the outcome is political or newsworthy > in nature. State Agency embraces open source, releases “State Agency's > Super Something Yellow”. Bad actor modifies and gets a bad SASSY into the > marketplace. Is there anything outside of trademark registration that > would help State Agency save face and/or get injunctive relief more easily? > > Cheers! > Sean > > > ___ > License-discuss mailing list > License-discuss@opensource.org > https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss > > -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Orphan Works: Summary of proposed 17 USC 514
On Sat, Dec 5, 2015 at 10:02 PM, Michael R. Bernstein <mich...@fandomhome.com> wrote: > On Fri, Dec 4, 2015 at 7:19 AM, Henrik Ingo <henrik.i...@avoinelama.fi> > wrote: >> This is interesting indeed. This is so unusual that I have to ask: >> what is the political context that has given rise to such a proposal >> that would make copyright law more sane, where usually all lobbying >> effort is towards more and longer restrictions? > > > My layman's perspective on that question is that: > > Orphan works owners by definition do not have a lobbying effort > Large holders and producers of copyrighted works will now be able to 'mine' > orphan works for adaptation with little danger, creating new works that they > can aggressively defend, and possibly will aggressively discourage others > from making competing adaptations that are 'too similar'. That knife cuts > both ways, but it is a game Hollywood is familiar with and very comfortable > playing. > Ah right, that makes more sense. I was looking at this with the assumption that any legal content not controlled by the big producers is competition, so that they would have a motive to be against any copyrighted works ever entering the public domain. (Similarly you can often hear copyright lobbyists speaking out against perfectly legal things like Creative Commons, because it's just wrong that you're not paying them.) But you're right that they also stand to gain from co-opting orphaned works and then including them into new, copyrighted productions. henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Orphan Works: Summary of proposed 17 USC 514
Thanks Larry This is interesting indeed. This is so unusual that I have to ask: what is the political context that has given rise to such a proposal that would make copyright law more sane, where usually all lobbying effort is towards more and longer restrictions? henrik On Thu, Dec 3, 2015 at 8:56 PM, Lawrence Rosen <lro...@rosenlaw.com> wrote: > For those who don't want to read the entire report, below is a summary of > draft U.S. copyright legislation, 17 U.S.C. Sec. 514, "Limitation on > remedies in cases involving orphan works." > > > > The orphan works problem is referred to as "perhaps the single greatest > impediment to creating new works." Anyone using an orphan work does so under > a cloud, as there is always the possibility that the copyright owner could > emerge after use has commenced and seek substantial infringement damages, an > injunction, and/or attorneys' fees. A user's ability to seek permission or > to negotiate licensing terms is compromised by the fact that, despite his or > her diligent efforts, the user cannot identify or locate the copyright > owner. > > > > This legislation proposed by the U.S. Copyright Office can have significant > impacts on both U.S. and worldwide copyright practices for literary works – > including software and open source. > > > > /Larry > > > > ** > > > > · Establish a limitation on remedies for copyright infringement for > eligible users who can prove they have engaged in a good faith diligent > search for the owner of a copyright and have been unable to identify or > locate him or her; > > > > · Define a diligent search as, at a minimum, searching Copyright > Office records; searching sources of copyright authorship, ownership, and > licensing; using technology tools; and using databases, all as reasonable > and appropriate under the circumstances; > > > > · Require the Copyright Office to maintain and update Recommended > Practices for diligent searches for various categories of works, through > public consultation with interested stakeholders; > > > > · Permit a U.S. court, in its determination of whether a particular > search qualifies under statute, to take into account a foreign > jurisdiction's certification that a search was in good faith and > sufficiently diligent, provided the foreign jurisdiction provides similar > treatment to qualifying U.S. searches; > > > > · In addition to a diligent search, condition eligibility on a user > filing of a Notice of Use with the Copyright Office, providing appropriate > attribution, and engaging in negotiation for reasonable compensation with > copyright owners who file a Notice of Claim of Infringement, among other > requirements; > > > > · Limit monetary relief for infringement of an orphan work by an > eligible user to "reasonable compensation" – the amount that a willing buyer > and a willing seller would have agreed upon immediately before the use > began; > > > > · Bar monetary relief for infringements of orphan works by eligible > nonprofit educational institutions, museums, libraries, archives, or public > broadcasters, for noncommercial educational, religious, or charitable > purposes, provided the eligible entity promptly ceases the infringing use; > > > > · Condition injunctive relief for infringement of orphan works by > accounting for any harm the relief would cause the infringer due to its > reliance on its eligibility for limitations on remedies; > > > > · Limit the scope of injunctions against the infringement of an orphan > work if it is combined with "significant original expression" into a new > work, provided the infringer pays reasonable compensation for past and > future uses and provides attribution; > > > > · Allow a court to impose injunctive relief for the interpolation of > an orphan work into a new derivative work, provided the harm to the > owner-author is reputational in nature and not otherwise compensable; > > > > · Condition the ability of state actors to enjoy limitations on > injunctive relief upon their payment of any agreed-upon or court-ordered > reasonable compensation; and > > > > · Explicitly preserve the ability of users to assert fair use for uses > of orphan works. > > > > "Orphan Works and Mass Digitization": > http://copyright.gov/orphan/reports/orphan-works2015.pdf > > > ___ > License-discuss mailing list > License-discuss@opensource.org > https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss > -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] BSD 3-clause and copyright notices
sing track of who contributed what code might again be considered bad practice for other reasons. henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Fwd: Question regarding GNU Terms of use
Just to elaborate on Kevin's last sentence: On Thu, Jun 18, 2015 at 4:42 PM, Kevin Fleming kevin+...@kpfleming.us wrote: If by 'commercialize' you mean 'offer for sale', yes, the person could certainly offer the combined work for sale. There exists lots of both GPL and MIT licensed software that is commercialized in the sense that somebody is selling such software. Hence software that is a combination of those two licenses can of course also be sold. henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Can OSI take stance that U.S. public domain is open source?
The analoguous explanation for why cc0 didn't qualify is that it explicitly said you get rights a and b but not c, with c a necessary right to copy and use the software. It should be obvious that - even if you'd disagree wrt patents - at least for some values of c that is clearly not open source. The fact that many older licenses are silent/ambiguous about c, and were written in a time when c didn't exist, is a different problem. henrik On 3 May 2014 23:14, John Cowan co...@mercury.ccil.org wrote: Richard Fontana scripsit: When the MXM license was considered, some people pointed to OSD #7 as suggesting that a sufficiently narrowly-drawn patent license grant in a license would not be Open Source. This was the problem I raised when CC0 was submitted. It was the inconsistency. It depends on your view of how the OSD applies to patents. Since it nowhere mentions them, I don't see how it can apply to them. #7 merely says that licenses of the form You get rights a, b, and c, whereas your transferees only get rights a and b, possibly qualified by unless they sign this, aren't open-source licenses. I continue to think that our CC0 decision was wrong insofar as it can be read as saying that the CC0 license is not an open-source (as opposed to OSI Certified) license. There may be reasons not to certify it, but not to deny that it is open source. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org Female celebrity stalker, on a hot morning in Cairo: Imagine, Colonel Lawrence, ninety-two already! El Auruns's reply: Many happy returns of the day! ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Can OSI take stance that U.S. public domain is open source?
On Sat, May 3, 2014 at 10:34 PM, Richard Fontana font...@sharpeleven.org wrote: On Sat, 3 May 2014 22:07:19 +0300 Henrik Ingo henrik.i...@avoinelama.fi wrote: Does the US government grant itself patents, Yes. and if so, what does it do with those patents? Many are licensed to the private sector for revenue. That is so perverse I cannot even formulate words to explain how I feel about that... Wrt the original question it seems there are good grounds to ask federal employees to pony up an actual open source license, especially one of those that includes a patent license. That said, it seems most will agree that the public domain copyright is for all intents and purposes open source. I suppose this is comparable to how artistic license is open source but preferably you'd use a better license. henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Can OSI take stance that U.S. public domain is open source?
Richard, I just wanted to call out a neat statistical trick you just made: On Sun, May 4, 2014 at 9:06 PM, Richard Fontana font...@sharpeleven.org wrote: On Sun, 04 May 2014 11:48:13 -0500 Karl Fogel kfo...@red-bean.com wrote: I don't know offhand the current count of OSI-approved licenses but I think it is around 70. In a typical traditional server/desktop Linux distro, the numbers of distinct licenses regarded *reasonably* by the communities of users and distributors of that distro as open source must number at least in the several hundreds. (Think of the universe of licenses covering packages considered DFSG-conformant in Debian, since the criteria are at least superficially very similar to the OSD, its descendant.) Sure. But it isn't at bad as you make it sound. The above sounds like more than half of the licenses in Debian (as an example of the distro with most packages) are not OSI certified. At the same time, Debian has over 37k packages and what stats we have from blackduck and other sources make me comfortable in guessing that safely more than 99% and probably more than 99,9% of Debian packages do use an OSI certified license. From this point of view I'd say we are doing very well here. I obviously agree that it is important that reality and OSI converge, but at the same time it serves no useful purpose to spend time certifying things like GPLv1. ...but I think we do need to come to some sort of solution soon. The U.S. government is going to keep releasing what is (obviously) open source software into the public domain; CC0 is also becoming more popular in non-software works and will inevitably make inroads into software too. I'm going to out myself here and say that I believe CC0 is obviously lowercase-o, lowercase-s open source despite the clause about patents. That doesn't mean the OSI should have approved it, that doesn't mean the OSI should recommend its use in its current form or cease its current practice of recommending against its use. I have a similar view of US government public domain works (with the added problem that it is clear that many intellectual property lawyers working across different US government agencies are confused over what 17 USC 105 means). Yes, US works that are public domain worldwide are obviously open source, but as with CC0 this has some implications for how licenses that explicitly mention disposition of patent rights should be treated. Is the US governments exclusion of patents that explicit? I mean I don't contest it as a fact, but to a layman I don't expect legislation to be coherent or 100% intentional. Politics to me seems much more like a one hand giveth, one taketh away kind of situation. Kind of like the discussion whether the US government works truly are worldwide public domain or just except for all the other countries but US public domain. It's messy reality and there's nothing we can do about it. (Another analogue: do software patents exist in Europe or not? That's a good ice breaker for conversation, but I wouldn't want OSI to assume no as the correct answer for purposes of certifying licenses.) CC0 otoh had an explicit sentence excluding patent rights, that to me seems much more problematic. As we are going on the record then, I see a distinction between CC0 being intentionally wrong and US public domain works just being an imperfect legal construct. John keeps asking for statements like above to always be based on specific OSD paragraphs. Maybe that's a good idea. I'll try to express my judgement of CC0: The patent clause in CC0 fails in OSD compliance because: §1: it explicitly reserves the right to restrict some party or any party from selling, giving away and redistributing, now or at a future time. It also explicitly reserves the right to ask for royalties for such sale or redistribtuion. §5 and §6: even if the license text itself is neutral, it reserves the right for the licensor to discriminate between recipients of the license such as prohibiting some recipients from using or redistributing the software, or requiring royalties for some type of use or users. For example separating commercial/non-commercial, geographically or just tactically or even arbitrarily. I should note that this would be a very likely way of enforcing ones patent rights. §7: excluding a patent grant fails the intent of this paragraph, though technically the rights actually included in CC0 do satisfy this paragraph. §8 and §10: I see similar risks here: it is likely that a patent holder could enforce patents in a way that fail to meet the intent of these paragraphs, even if the license text otherwise is neutral here. henrik -- henrik.i...@avoinelama.fi +358-40-5697354skype: henrik.ingoirc: hingo www.openlife.cc My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 ___ License-discuss mailing list License-discuss@opensource.org http
Re: [License-discuss] Can OSI take stance that U.S. public domain is open source?
That's an interesting angle to bite on... Does the US government grant itself patents, and if so, what does it do with those patents? On 3 May 2014 06:45, Richard Fontana font...@sharpeleven.org wrote: On Fri, 02 May 2014 14:55:55 -0500 Karl Fogel kfo...@red-bean.com wrote: This thread on GitHub gets (needlessly?) complicated. It's about a public-domain software work put out by the U.S. government, and there's no clarity on whether calling it open source and citing the OSI's definition of the term would be appropriate: https://github.com/ngageoint/geoevents/issues/2#issuecomment-41739913 Someone cites our FAQ item on it (which, as its primary author, I found tickled my vanity :-) ), but really, I wish they didn't have to cite the OSI FAQ and could instead just say yup, public domain is open source. The things we don't like about public domain (lack of explicit liability limitation, different definitions in different jurisdictions) are not in themselves counter to the OSD, after all. Thoughts? Should OSI look for a route to say that public domain works (like ones put out by the U.S. government) are open source too, or is it just too problematic? This work's authors seem to explicitly say that they are dedicating it to the public domain, not merely (or explicitly at all, as far as I can see here) relying on the notion of statutory public domain for US government works. I'd argue those are two different concepts of public domain (one of which is really something more akin to the effect achieved by CC0). With statutory public domain works, you can't be sure out of context what the status of the work is when published outside the US. See e.g. http://www.cendi.gov/publications/04-8copyright.html#317. I've found that many US government lawyers dealing with open source seem to assume that 17 USC 105 operates worldwide (this sometimes comes up in the form of a refusal to sign CLAs because 'there is no copyright to license'). Also with statutory public domain works you have the same old MXM/CC0 inconsistency problem in a different form. Consider the case of public domain source code created by a US government employee, having features covered by a patent held by the US government. - RF ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Open Source Eventually License Development
Fwiw, I don't mind having this discussion on this list. It's not that far off topic and you're not the first to try. Still it's my opinion that it's outside osi competence to advice or recommend the part of your endeavor that is a proprietary license. Henrik On 15 Aug 2013 04:10, fred trotter fred.trot...@gmail.com wrote: The mandate for this list is facilitate constructive discussion of open source licensing and further the goals of the OSI. Your argument is that this list only exists to determine whether a given license meets the definition of Open Source, and then only discuss it if it meets that definition. You are ignoring the further the goals part of the purpose of this list. I have argued, I hope clearly, how the quality of timer licenses could impact the Open Source community, both positively (if done well) and negatively (if done poorly). Moreover, this very list has debated at length about the best way to handle this issue on multiple occasions. All I have done is create a more advanced artifact to discuss, so that we can work on specifics instead of generalities. If you read carefully, you might note that almost everything I am discussing in my proposal relates to balancing business vs Open Source community interests. I am asking this mailing list for help crafting a proprietary license. It is certainly ironic but not at all off-topic. -FT On Wed, Aug 14, 2013 at 12:45 PM, Henrik Ingo henrik.i...@avoinelama.fiwrote: Sorry for accidental sending... The time delayed license should of course be an osi approved one, and preferably one of the commonly used ones: gpl, bsd, and so on... The licenses are what they are and there isn't much to discuss there, you just pick one. How you intend to write your proprietary license is then outside the osi mandate to support, and off topic for this list. Henrik On 14 Aug 2013 20:40, Henrik Ingo henrik.i...@avoinelama.fi wrote: Hi fred I think what you are asking for guidance on, is outside the mandate of osi, and fsf too. The time delayed license should of On 14 Aug 2013 19:24, fred trotter fred.trot...@gmail.com wrote: Hi, I am sending this to both FSF and OSI people. Please tolerate my use of the various terms interchangeably, I know the various rules but I am talking to two different communities, if at all possible please permit me to skip the I don't like your choice of terms lecture. I have just returned from OSCON, where I gave an Ignite talk on Open Source Eventually, which is yet-another-fine time ransom license that converts to FLOSS. While there I had several meetings with Monty Widenius about his Business Source concept. He and I have tentatively agreed to merge our efforts. I was also advised by Simon Phipps and Deborah Bryant to investigate the history of the concept here on the mailing list, which I have done. I have seen the history with GhostScript, the thread on delay-able open source licenses from Qian Hong and the recent and original discussions about TGGPL from zooko. With that historical context in mind, let me outline my aim. First, no ransom license of any type should ever be OSI approved as an Open Source license or be FSF approved as a Free Software License. Ransom licenses are proprietary until they are Open Source or Free/Libre. I am not going to ask you to compromise the core values of our community by putting lipstick on a pig. Second, despite this, both OSI and FSF should consider having a position, either formally or informally on these licenses. We need to standardize on one specific license text that is known good for this type of business approach to avoid license proliferation. Real world FOSS users would be better served by having a standard license, than having lots of slight variations because: * All of the promotors of this concept are writing different licenses, so we are again facing a license proliferation problem. * Poorly written or understood versions of this license could taint the release of subsequently released FLOSS software. * Automated license compliance systems will have a difficult time evaluating licenses that always have different data (dates) embedded in the license text. * Companies using the delayed method should have the option to choose from the menu of OSI/FSF/CC licenses as the target licenses * The license should support different proprietary intents, such as Monty's aim to favor small business with costless versions, or zooko's idea of creating a proprietary community. No version of these proprietary intents should be able to mar the conversion of the license to a FOSS license at the specified conversion date. * Users should be able to trust that they have the right to perform the conversion to FOSS themselves and should not be in a position to pay for software with the mere promise of a subsequent and separate release. * Companies who are using this method should have a limit
Re: [License-discuss] Open Source Eventually License Development
Hi fred I think what you are asking for guidance on, is outside the mandate of osi, and fsf too. The time delayed license should of On 14 Aug 2013 19:24, fred trotter fred.trot...@gmail.com wrote: Hi, I am sending this to both FSF and OSI people. Please tolerate my use of the various terms interchangeably, I know the various rules but I am talking to two different communities, if at all possible please permit me to skip the I don't like your choice of terms lecture. I have just returned from OSCON, where I gave an Ignite talk on Open Source Eventually, which is yet-another-fine time ransom license that converts to FLOSS. While there I had several meetings with Monty Widenius about his Business Source concept. He and I have tentatively agreed to merge our efforts. I was also advised by Simon Phipps and Deborah Bryant to investigate the history of the concept here on the mailing list, which I have done. I have seen the history with GhostScript, the thread on delay-able open source licenses from Qian Hong and the recent and original discussions about TGGPL from zooko. With that historical context in mind, let me outline my aim. First, no ransom license of any type should ever be OSI approved as an Open Source license or be FSF approved as a Free Software License. Ransom licenses are proprietary until they are Open Source or Free/Libre. I am not going to ask you to compromise the core values of our community by putting lipstick on a pig. Second, despite this, both OSI and FSF should consider having a position, either formally or informally on these licenses. We need to standardize on one specific license text that is known good for this type of business approach to avoid license proliferation. Real world FOSS users would be better served by having a standard license, than having lots of slight variations because: * All of the promotors of this concept are writing different licenses, so we are again facing a license proliferation problem. * Poorly written or understood versions of this license could taint the release of subsequently released FLOSS software. * Automated license compliance systems will have a difficult time evaluating licenses that always have different data (dates) embedded in the license text. * Companies using the delayed method should have the option to choose from the menu of OSI/FSF/CC licenses as the target licenses * The license should support different proprietary intents, such as Monty's aim to favor small business with costless versions, or zooko's idea of creating a proprietary community. No version of these proprietary intents should be able to mar the conversion of the license to a FOSS license at the specified conversion date. * Users should be able to trust that they have the right to perform the conversion to FOSS themselves and should not be in a position to pay for software with the mere promise of a subsequent and separate release. * Companies who are using this method should have a limit to the maximum time they can delay a release, because 20 years would be just as bad as a software patent. * The licensing methods should be compatible with automated compliance software. * The licensing methods should be compatible with current file conventions README, LICENSE, COPYRIGHT etc etc * The license should work for hardware, bioware and other things, not just software. * end users should be mostly protected from any obvious misuse of the license With that in mind, I would like to propose the following process to develop this idea further. First, I would like for the OSI and FSF people on this list to consider some kind of new status for a license, like OSI tolerated or OSI Not Open Source But It Doesn't Suck , or Not Free Software but tolerated for this purpose or something like. Some way to clearly mark this as the standard way of time delaying a FOSS release but not actually OSI/FSF Approved. Second I would like for interested parties to join me developing the license on GitHub. https://github.com/ftrotter/OSE At this stage, I am accepting issue creation and will be using that to remove obvious bugs from the text. If a git pull feels comfortable to you, that works too. I will of course require copyright assignment for text modifications. Once the basic license no longer sucks I will setup a co-ment instance for public comment. Finally I might be able to get NOD (my employer) to actually pay for a legal review once everything is done. We will be releasing data sets under the resulting license as soon as it is ready. Remember, I am not specifically advocating for the Time Ransom License approach. I remain somewhat uncomfortable with the approach. However, I am somewhat more uncomfortable not being able to make a living making Libre Software. There are enough people doing this that unless we sort something formal out, an FLOSS project is going to be put in a situation where
Re: [License-discuss] Open Source Eventually License Development
Sorry for accidental sending... The time delayed license should of course be an osi approved one, and preferably one of the commonly used ones: gpl, bsd, and so on... The licenses are what they are and there isn't much to discuss there, you just pick one. How you intend to write your proprietary license is then outside the osi mandate to support, and off topic for this list. Henrik On 14 Aug 2013 20:40, Henrik Ingo henrik.i...@avoinelama.fi wrote: Hi fred I think what you are asking for guidance on, is outside the mandate of osi, and fsf too. The time delayed license should of On 14 Aug 2013 19:24, fred trotter fred.trot...@gmail.com wrote: Hi, I am sending this to both FSF and OSI people. Please tolerate my use of the various terms interchangeably, I know the various rules but I am talking to two different communities, if at all possible please permit me to skip the I don't like your choice of terms lecture. I have just returned from OSCON, where I gave an Ignite talk on Open Source Eventually, which is yet-another-fine time ransom license that converts to FLOSS. While there I had several meetings with Monty Widenius about his Business Source concept. He and I have tentatively agreed to merge our efforts. I was also advised by Simon Phipps and Deborah Bryant to investigate the history of the concept here on the mailing list, which I have done. I have seen the history with GhostScript, the thread on delay-able open source licenses from Qian Hong and the recent and original discussions about TGGPL from zooko. With that historical context in mind, let me outline my aim. First, no ransom license of any type should ever be OSI approved as an Open Source license or be FSF approved as a Free Software License. Ransom licenses are proprietary until they are Open Source or Free/Libre. I am not going to ask you to compromise the core values of our community by putting lipstick on a pig. Second, despite this, both OSI and FSF should consider having a position, either formally or informally on these licenses. We need to standardize on one specific license text that is known good for this type of business approach to avoid license proliferation. Real world FOSS users would be better served by having a standard license, than having lots of slight variations because: * All of the promotors of this concept are writing different licenses, so we are again facing a license proliferation problem. * Poorly written or understood versions of this license could taint the release of subsequently released FLOSS software. * Automated license compliance systems will have a difficult time evaluating licenses that always have different data (dates) embedded in the license text. * Companies using the delayed method should have the option to choose from the menu of OSI/FSF/CC licenses as the target licenses * The license should support different proprietary intents, such as Monty's aim to favor small business with costless versions, or zooko's idea of creating a proprietary community. No version of these proprietary intents should be able to mar the conversion of the license to a FOSS license at the specified conversion date. * Users should be able to trust that they have the right to perform the conversion to FOSS themselves and should not be in a position to pay for software with the mere promise of a subsequent and separate release. * Companies who are using this method should have a limit to the maximum time they can delay a release, because 20 years would be just as bad as a software patent. * The licensing methods should be compatible with automated compliance software. * The licensing methods should be compatible with current file conventions README, LICENSE, COPYRIGHT etc etc * The license should work for hardware, bioware and other things, not just software. * end users should be mostly protected from any obvious misuse of the license With that in mind, I would like to propose the following process to develop this idea further. First, I would like for the OSI and FSF people on this list to consider some kind of new status for a license, like OSI tolerated or OSI Not Open Source But It Doesn't Suck , or Not Free Software but tolerated for this purpose or something like. Some way to clearly mark this as the standard way of time delaying a FOSS release but not actually OSI/FSF Approved. Second I would like for interested parties to join me developing the license on GitHub. https://github.com/ftrotter/OSE At this stage, I am accepting issue creation and will be using that to remove obvious bugs from the text. If a git pull feels comfortable to you, that works too. I will of course require copyright assignment for text modifications. Once the basic license no longer sucks I will setup a co-ment instance for public comment. Finally I might be able to get NOD (my employer) to actually pay for a legal review once everything
Re: [License-discuss] Can copyrights be abandoned to the public domain?
On Fri, Aug 17, 2012 at 5:09 AM, Johnny Solbu joh...@solbu.net wrote: On Friday 17 August 2012 02:15, Russ Nelson wrote: but it's clear that OSI Approved Open Source contributions from people who live in countries that claim Moral Rights is inferior to people who live in countries which don't. Says who? And why? I believe Finland has the concept of Moral Rights. As a IANAL summary, the concept seems to be that even if I license or sell away the commercial rights to my creation, I retain certain rights that I can never give away, such as the right to be correctly cited as the author of my works (which most FOSS licenses require anyway) and weird things like the right to forbid the use of my work for pornography or other things someone might find against my morality. I have never heard anyone actually asserting this for software. Further, some contracts I've signed, such as with Sun Microsystem, included language to the effect that if there are parts of my copyright that I cannot license away, I nevertheless irrevocably waive my right to assert the moral rights in court, even if they are still mine since they cannot be transferred/licensed. I have no idea if such a waiver would mean anything in court since the whole point of the law is quite the opposite. henrik -- henrik.i...@avoinelama.fi +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Can copyrights be abandoned to the public domain?
On Fri, Aug 17, 2012 at 7:51 AM, Henrik Ingo henrik.i...@avoinelama.fi wrote: On Fri, Aug 17, 2012 at 5:09 AM, Johnny Solbu joh...@solbu.net wrote: On Friday 17 August 2012 02:15, Russ Nelson wrote: but it's clear that OSI Approved Open Source contributions from people who live in countries that claim Moral Rights is inferior to people who live in countries which don't. Says who? And why? I believe Finland has the concept of Moral Rights. As a IANAL summary, the concept seems to be that even if I license or sell away the commercial rights to my creation, I retain certain rights that I can never give away, such as the right to be correctly cited as the author of my works (which most FOSS licenses require anyway) and weird things like the right to forbid the use of my work for pornography or other things someone might find against my morality. I have never heard anyone actually asserting this for software. Further, some contracts I've signed, such as with Sun Microsystem, included language to the effect that if there are parts of my copyright that I cannot license away, I nevertheless irrevocably waive my right to assert the moral rights in court, even if they are still mine since they cannot be transferred/licensed. I have no idea if such a waiver would mean anything in court since the whole point of the law is quite the opposite. Oh, one thing I've always wondered though is, what would happen if for instance the thousands of Nokia engineers who wrote code that went into a mobile phone started actually requiring that Nokia would acknowledge them by name as authors of the software. In open source this commonly happens, but for closed source software products it could be a lot of fun! henrik -- henrik.i...@avoinelama.fi +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] proposal to revise and slightly reorganize the OSI licensing pages
On Mon, Jun 11, 2012 at 9:41 AM, Bruce Perens br...@perens.com wrote: On 06/10/2012 10:49 PM, Rick Moen wrote: I believe this is entirely consistent with what I said, Bruce. You even said 'Read caselaw.' I think we need to come to grips to the fact that it may be possible for GPL software to be embedded within a proprietary software product a la NuSphere without the result being infringement. At least as long as they provide source and a license statement for the GPL part. If you go back to Progress Software (NuSphere) v. MySQL, the MySQL guys signed a contract with Progress without ever having it vetted by a lawyer. NuSphere had a reasonable assumption that they had a right to embed the program in their product. The MySQL guys messed up in a big way and were lucky to not have had to pay for it. To be clear, NuSphere did not embed MySQL in their product, rather they embedded closed source components into MySQL and shipped a modified MySQL without corresponding source. http://www.gnu.org/press/mysql-affidavit.html (MySQL specific part begins at §26) This is not comparable to the customary use of MySQL where some Java or PHP application uses MySQL as is, and over an API like JDBC to store data. It is true that MySQL AB used to interpret the GPL as covering also this use case. When buying Sun, Oracle has denounced this interpretation and was supported by Eben Moglen and Carlo Piana in doing so. (http://openlife.cc/blogs/2011/january/reposting-mark-schonewilles-blog-how-gpl-applies-mysql-use-cases ) Anyway, the NuSphere case was not an example of this use case. All that said, yes, if one takes the Using an API doesn't create derivative works to its extreme, then essentially the GPL and LGPL would be the same thing. Which would be a funny relevation after a couple decades of successful GPL enforcements and several companies building a successful business on a more strict interpretation of GPL / the law. henrik -- henrik.i...@avoinelama.fi +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] proposal to revise and slightly reorganize the OSI licensing pages
On Mon, Jun 11, 2012 at 10:37 AM, Bruce Perens br...@perens.com wrote: On 06/11/2012 12:18 AM, Henrik Ingo wrote: To be clear, NuSphere did not embed MySQL in their product, rather they embedded closed source components into MySQL Per Eben's testimony, the Gemini storage engine, using the MySQL API for storage engines. True, so still relevant for this thread. I just wanted to make a difference of X embedding MySQL (the common case) vs embedding Gemini into MySQL (there are less than 20 companies in the MySQL space for whom this is relevant). henrik -- henrik.i...@avoinelama.fi +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] BSD, MIT [was Re: Draft of new OSI licenses landing page; please review.]
On Thu, Apr 5, 2012 at 6:35 PM, John Cowan co...@mercury.ccil.org wrote: do not belong in a first-class list here in 2012. Apache fills the same purpose[1] (permissive license) while being better drafted and properly handling patents. Without getting into other issues, I'd hope we can agree that BSD/MIT All true, and I greatly favor Apache. But BSD/MIT are well-understood and still extremely pervasive. Looking at Google Code, which was founded fairly recently, Apache dominates; looking at Sourceforge and Freshmeat, MIT and BSD dominate. So put Apache before MIT/BSD, but don't drop them altogether. +1 In fact, MIT/BSD will continue to serve a few very important use cases: We have projects which will forever be GPLv2 licensed: Linux and MySQL are the 2 that come quickly to mind. We have people who wish to publish code that is permissively licensed, yet can be combined with those GPLv2 projects. Now we have the issue that FSF considers the Apache License incompatible with the GPLv2, so (whether or not you agree with the FSF), then in practice using Apache License is not an option. BSD (or MIT) is what we in practice end up using in these cases. There's also the fact that many people like to have as short a license as possible. While there are good reasons why Apache License is longer than BSD (that's why it's a better license), I would say the BSD/MIT licenses are good enough to cater to this need. henrik -- henrik.i...@avoinelama.fi +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and non-GPL binaries in one distribution
On Thu, Jan 12, 2012 at 10:53 PM, Rick Moen r...@linuxmafia.com wrote: Quoting Henrik Ingo (henrik.i...@avoinelama.fi): On this topic there are many opinions out there and little case law, but personally I've always thought that if the FSF as the author of the GPL thinks something is permitted, then at least that much must be permitted and you can quite safely do that. In the general case (obviously excepting GNU packages), FSF is not the copyright holder and licensor. Hence, it cannot speak properly to other licensors' intentions, and its opinions are not relevant to what such licensors are willing and able to permit. (It would not in that case have standing in any related litigation, either, but that's a different subject.) This is an important point, yes. Otoh the GPL is the same license for everyone that uses it. At least in an ideal world it cannot apply in one way to your software and another to mine, since it is the same text. Lacking more legal precedent (on this particular topic) we can only guess what the real answer is, but it seems the authors of the license text should at least get a say in that general discussion, even if they wouldn't have standing in some particular lawsuit. henrik -- henrik.i...@avoinelama.fi +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and non-GPL binaries in one distribution
On Thu, Jan 12, 2012 at 11:29 PM, Chad Perrin per...@apotheon.com wrote: In that, the only way the opinion of the license's author really seems to factor into things once the license has already been written is as a contribution to the common understanding of the license. For that purpose, however, it is only one of many potential inputs to the common understanding of the license. Yes. However, when referring to the GPL FAQ, I actually believe it represents the common understanding of a rather large portion of the FOSS community, not just the understanding of Stallman or perhaps Moglen. (Granted, for many it is just that they accept whatever the FSF says, for others it might be they don't want to argue with the FSF, but even so, their acceptance then contributes to the common understanding.) Hence I find it a useful though not legally authoritative document. The real point I was trying to make however is that the GPL FAQ seems to function well as a safe baseline for what is very likely allowed. Most people who disagree with the FSF interpretation (such as Rosen in this thread) usually believe a more permissible interpretation of copyright law is correct. Hence, it seems while Rosen writes that the FSF position is wrong, in this particular case they both would agree that 2 separately running programs (sharing no code) are not derivative works of each other and hence. It's also important to take the (stated) intent of the work's author into consideration, If the author(s) has(have) given such a statement, and if it is equal to or more permissible than the common understanding of the GPL, then that would of course be the most usable information to go with and the rest of the discussion is unnecessary. henrik -- henrik.i...@avoinelama.fi +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
On Tue, Dec 27, 2011 at 5:07 PM, Tzeng, Nigel H. nigel.tz...@jhuapl.edu wrote: I'm trying to find an appropriate licensing strategy for our company, and I'm expressly trying to prevent and understand the sort of shims that seem to be standard industry practice. If our work can't be protected from these creative circumventions by the GPL, then we probably won't use this license. If it's not a derivative work then it's not a derivative work and you should have no heartache. If it is a derivative work then you have legal recourse to correct it. IMO, appropriate licensing strategy is far more a business decision than a legal one. If you wish to develop As others have suggested you can look at Affero if you think vanilla GPL v3 too lax. Note that Affero GPL does not in any way change the question of what is a derivative work and how you could insulate yourself from effects of (A)GPL by using a Web API or other shim approach. Since the FSF does not define what is a derivative work of something else, it obviously couldn't possibly do so. If A is a service and B is a program using this service over a HTTP Web API, and 1) A is licensed under the GPL, or 2) A is licensed under the AGPL In both cases #1 and #2 B could be licensed as whatever, the only difference is that in #2 the person who makes available A as a service has to make the source code of A available, as set forth by AGPL. The whole point of the derivative work debate is that the license of A does not have any effect on B. (Unless of course you are of the opinion it does have an effect, in which case that should be your opinion equally for both #1 and #2 anyway.) henrik -- henrik.i...@avoinelama.fi +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
