On Thu, Feb 16, 2017 at 5:00 PM, Karan, Cem F CIV USARMY RDECOM ARL (US) < cem.f.karan....@mail.mil> wrote:
> > -----Original Message----- > > From: John Sullivan [mailto:jo...@fsf.org] > > Sent: Thursday, February 16, 2017 10:10 AM > > To: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan....@mail.mil> > > Cc: license-discuss@opensource.org > > Subject: Re: [License-discuss] [Non-DoD Source] Re: OSI equivalent > > > > "Karan, Cem F CIV USARMY RDECOM ARL (US)" <cem.f.karan....@mail.mil> > > writes: > > > > > --===============0423943140736445875== > > > Content-Language: en-US > > > Content-Type: multipart/signed; protocol="application/x-pkcs7- > signature"; > > > micalg=SHA1; boundary="----=_NextPart_000_00EE_01D28833.18234540" > > > > > > ------=_NextPart_000_00EE_01D28833.18234540 > > > Content-Type: text/plain; > > > charset="utf-8" > > > Content-Transfer-Encoding: 7bit > > > > > > Beyond that, is the FSF interested in compatibility between non-FSF > > > licenses? > > > That is, if MIT and Apache 2.0 happened to be incompatible with one > > > another, would FSF care provided they were both compatible with the > > > GPL? In my opinion, OSI is supposed to be more neutral on the > > > matters, and therefore should care more about such situations. > > > > > > > I can't immediately picture the specific situation you're talking about, > but > > in general we do care. For one thing because we recommend > > other licenses depending on the situation (see > > Caution-https://www.gnu.org/licenses/license-recommendations.en.html). > > > > We also do support all free software, not just GPLed or even just > copyleft > > free software. Our licens...@fsf.org team answers questions > > that have to do with other licenses in both their correspondence with the > > community and in our compliance work. > > OK, so FSF is willing to take this on for OSI? Will OSI defer to FSF on > this? > Ideally there will always be one canonical source of information for > license > compatibility so that there isn't any confusion. > As was mentioned earlier in the thread, the "compatibility" of licenses is a context-specific matter, so the concept of canonical abstract compatibility information seems nonsensical in the general case. As the author of the GPL family of licenses the FSF is a great source of advice on the combinability of other licenses with theirs, although the only opinion that really matters is that of the copyright holder who has chosen to use a particular license. For other license combinations, I would not expect the FSF to volunteer as an authority and doubt their third-party view would be sought. S.
_______________________________________________ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss