Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up Licensing #4077

Open
skef opened this issue Dec 22, 2019 · 115 comments
Open

Clean up Licensing #4077

skef opened this issue Dec 22, 2019 · 115 comments

Comments

@skef
Copy link
Contributor

@skef skef commented Dec 22, 2019

Apparently there is a desire to eventually get FontForge back to a BSD-compatible state. This is something the project has recently made great, but seemingly un-noted, progress towards. And the current state of the messaging is a little embarrassing.

Given the desire, this is what the current LICENSE file says about GPL:

These files were created under the GPL License:

fontforge-20120731-b/
aclocal.m4      configure.dynamic       configure.static.in
config.guess    configure.dynamic.in    ltmain.sh
config.sub      configure.in            Makefile.dynamic.in
configure       configure.static        Makefile.static.in

fontforge-20120731-b/fontforge:
Makefile.dynamic.in     Makefile.static.in

fontforge-20120731-b/gdraw:
Makefile.dynamic.in     Makefile.static.in

fontforge-20120731-b/gutils:
giomime.c       Makefile.dynamic.in     Makefile.static.in

fontforge-20120731-b/inc:
fontforge-config.h.in

fontforge-20120731-b/plugins:
ANALYZE_MAP.COM Makefile.in

fontforge-20120731-b/Unicode:
Makefile.dynamic.in     Makefile.static.in

Obviously almost all of these have been removed by @jtanx's CMake work.

fontforge-config.h.in now claims a BSD license at the top, in contrast with the statement in LICENSE, but has commented out lines at the end that presumably aren't BSD, strictly speaking. Perhaps those could be removed?

giomime.c is now g_giomime.c and may be the only remaining stumbling block. The authors, and therefore copyright holders, of each commit from when @JoesCat moved the function out of giomime.c are:

Suppose we add a section to LICENSE for copyright holders of g_giomime.c to re-license their portion as BSD by adding a statement of agreement via a PR. Then we ask each author above to do so. Then, assuming that has happened, we change the license at the top of the file to BSD with a note that it is also available under GPL and pointing to the LICENSE file notations. Assuming the Open Group License is more or less BSD equivalent, would the project then be validly BSD, at least by its own standards?

@jtanx

This comment has been minimized.

Copy link
Contributor

@jtanx jtanx commented Dec 23, 2019

For clarification, all my contributions can be taken to be under the original BSD license or whatever permissive license is most suitable. I also support trying to relicense FontForge under the more permissive license over GPLv3.

But I think we're going to have more problems than just that giomime file, if you search for GNU:

$rg  GNU.*General -l
COPYING.gplv3
fontforge/bezctx_ff.c
gdraw/ggdkdrawP.h
gutils/g_giomime.c
fontforgeexe/fontlint.pe
inc/ffglib.h
fontforgeexe/sfundo.c
fontforgeexe/sfundo.h
fontforgeexe/wordlistparser.c
fontforgeexe/wordlistparser.h
doc/html/faq.html
pycontrib/FontCompare/fontcompare
pycontrib/FontCompare/setup.py
doc/html/index.html
tests/fonts/NimbusLGCUni-Regular.sfd
Packaging/debian/cp-src/copyright
pycontrib/FontCompare/fc/BitmapHandler.py
pycontrib/FontCompare/fc/DocCompare.py
pycontrib/FontCompare/fc/FontCompare.py
pycontrib/FontCompare/fc/GlyphConsistency.py
pycontrib/FontCompare/fc/main_ui.py
pycontrib/FontCompare/fc/mockify.py
pycontrib/FontCompare/fc/__init__.py
pycontrib/FontCompare/unittests/unittests.py
@khaledhosny

This comment has been minimized.

Copy link
Contributor

@khaledhosny khaledhosny commented Dec 23, 2019

All my contributions since the license change (basically since George Williams left) are under GPLv3 and I have no desire to relicense them and I would no longer contribute to FontForge if it were to be relicensed under a non-copyleft license.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 23, 2019

Noted. I still think this is worth pursuing. It was always in my mind inevitable that in the pursuit of reversion to BSD we'd need to either remove or rewrite some people's contributions, either due to refusal to relicense or inability to make contact.

@jtanx

This comment has been minimized.

Copy link
Contributor

@jtanx jtanx commented Dec 23, 2019

fontforge-config.h.in now claims a BSD license at the top, in contrast with the statement in LICENSE, but has commented out lines at the end that presumably aren't BSD, strictly speaking. Perhaps those could be removed?

I rewrote fontforge-config.h myself, so I'd say the license is accurate. The reason for that GPL license was probably because the .in file used to be generated by autoconf, which is now no longer the case.

but has commented out lines at the end that presumably aren't BSD, strictly speaking

These would have been written by GW - https://github.com/fontforge/fontforge/blob/v20120731-b/fontforge/configure-fontforge.h which is BSD licensed.

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 23, 2019

All my contributions since the license change (basically since George Williams left) are under GPLv3 and I have no desire to relicense them and I would no longer contribute to FontForge if it were to be relicensed under a non-copyleft license.

See, this is what I was talking about over in #677. Is the statement in the LICENSE file alone enough to mean that this isn't @khaledhosny's decision when it comes to other contributions, because the license at the top of the file governs the contribution? What happens when copyright holders raise objections like this?

If every contribution in the past 6 years is maybe-GPL and maybe-BSD the whole idea of a switch seems pretty hopeless.

@jtanx

This comment has been minimized.

Copy link
Contributor

@jtanx jtanx commented Dec 23, 2019

From LICENSE:

  • Contributions to existing files must be made under the existing license for that file
@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 23, 2019

Right, so the question is: if someone never read that and made a contribution, does it apply?

@jtanx

This comment has been minimized.

Copy link
Contributor

@jtanx jtanx commented Dec 23, 2019

Right, sorry I misread your question.

I dug back, and it's been there since 2012 (#165), which was around where it was relicensed as a whole to GPLv3.

I'm not a lawyer of course, but I'd say so; the wording is pretty clear cut.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 23, 2019

Obviously it applies because they're releasing their contributions under the license we've included.

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 23, 2019

Well, if that's right, and the project is prepared to refer any contributor who thought the arrangement was different to that language, let me go through the rest of this stuff.

  • fontforge/bezctx_ff.c: based on the copyrights at the top it looks to me like the GNU license claim stems from a mislabling. It's stated to be written by GW in 2007
  • gdraw/ggdkdrawP.h: Use of G_GNUC_PRINTF(5, 6) for LogEx(). Seems trivial to work around
  • gutils/g_giomime.c: Would have to otherwise-implement some of this
  • fontforgeexe/fontlint.pe Doesn't seem like this would translate to the rest of the distribution -- if necessary could put in separate repo or could ask Matthew Skala if he would relicense.
  • inc/ffglib.h, fontforgeexe/sfundo.c, fontforgeexe/sfundo.h, fontforgeexe/wordlistparser.c, fontforgeexe/wordlistparser.h: 2013-5ish @monkeyiq stuff. If this was payed work then it shouldn't be the author's decision how it's licensed, but that doesn't mean it isn't his decision.
  • pycontrib/FontCompare/* I doubt this is relevant to the question at hand. Could always distribute separately if necessary.
  • The doc files just need to be clarified.
  • NimbusLGCUni-Regular.sfd is used in test118.pe. We can always whip up another font with PostScript references and multiple encodings per glyph (which is what 118 tests).
  • Packaging/debian/cp-src/copyright just has a defunct note about configure.

Only the g_giomime.c and @monkeyiq files on here are non-trivial. The latter we would have to work out what the rights are or ask him to relicense.

@jtanx

This comment has been minimized.

Copy link
Contributor

@jtanx jtanx commented Dec 23, 2019

gdraw/ggdkdrawP.h: Use of G_GNUC_PRINTF(5, 6) for LogEx(). Seems trivial to work around

I think this was just an issue with my search, I was searching for GNU.*General which matched

GNUC_PRINTF(5, 6);   // General

glib is LGPL licensed, so it should be fine as is.

giomime should be trivial enough to rewrite.

@frank-trampe

This comment has been minimized.

Copy link
Contributor

@frank-trampe frank-trampe commented Dec 23, 2019

Per Fred's comment, the top-level license is necessarily derivative of the per-file licenses. It was only possible to switch to GPLv3 because it was compatible with the per-file BSD licenses. It did not change the actual licenses on those files; it just stated terms (non-exclusive) under which the project could be used and established a default for the future.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 23, 2019

So this is all good news, we can switch soon! We should immediately send a message to the fontforge-devel list reminding people of this. Then we should get a PR through which will switch the "main" license back to the GW BSD license.

Exciting!

@frank-trampe

This comment has been minimized.

Copy link
Contributor

@frank-trampe frank-trampe commented Dec 23, 2019

@khaledhosny, could you explain your root concern here? To be clear, the top-level license is mostly nominal as I stated before. Even after a reversion of that license to the original BSD license, you would still be able to use any code in the project under a license compatible with the file in which it is located. Specifically, you would still be able to use and to distribute the entire project under GPLv3 terms, as far as I can tell, or this change would at least not make you unable to do so.

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 23, 2019

So the overall legal argument might be restated this way:

  1. The project was basically entirely BSD in the GW era, which ended around 2012.
  2. At that point there was a switch to distributing under GPL, which was possible because BSD compatible with that license.
  3. At the same time, the top-level LICENSE file clarified that contributions to individual files would continue to be governed by the license appearing at the top of each file.

Therefore even if it might be possible to switch from BSD to GNU and have future contributions to a given file then be GPL licensed, FontForge was explicit about the file-level license situation from the start of the GPL phase.

Therefore (the argument goes) all that is necessary now to distribute under BSD again is to address whatever files carry a GPL or otherwise non-BSD-like license. Which is probably pretty close to the list above.

@frank-trampe

This comment has been minimized.

Copy link
Contributor

@frank-trampe frank-trampe commented Dec 23, 2019

@skef, that all seems right to me.

I'm in bed and can't do a line-by-line blame review, but most of Ben's code was collab stuff (removed) and word list parser (heavily rewritten since), right? Is there actually significant code of his remaining?

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 23, 2019

@frank-trampe what's confusing about his message? He indicated he prefers contributing to copyleft projects, probably because he supports the kind of restrictions that @twardoch objects to. That's sort of the point of "full" GPL.

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 23, 2019

@frank-trampe I listed the five files as I described them: inc/ffglib.h, fontforgeexe/sfundo.c, fontforgeexe/sfundo.h, fontforgeexe/wordlistparser.c, fontforgeexe/wordlistparser.h. All of these carry GPL license notices and Ben copyrights. Given the top-level license file any subsequent changes will also be GNU, so we'd have to look at those.

@frank-trampe

This comment has been minimized.

Copy link
Contributor

@frank-trampe frank-trampe commented Dec 23, 2019

@skef, I know it's unlikely, but there are often strategic calculations on other priorities that inform a preference for copyleft license rather than a general distaste for permissive licenses. (The CDDL on the Solaris kernel is my favorite example of this.) I want to be absolutely sure that there's not a make-everybody-happy button here before I give up on its existence.

By the way, maintainers of two other rather significant projects (one commercial and one permissively licensed) have previously expressed strong interest in using functionality in FontForge, particularly the overlap removal, should it ever adopt compatible licensing terms.

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 23, 2019

@frank-trampe that's reasonable. And I shouldn't speak for @khaledhosny.

I've "blamed" those five files. It's mostly Ben with subsequent fixes by core project members with a few stray lines from others. If @JoesCat is willing it shouldn't be a big deal assuming we can deal with the Ben authorship one way or another.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 23, 2019

I would argue that switching this project to GPL was pretty much a hijacking. That was never George's intent. In 2012 99% of the code was George's. For twelve years, at that time, BSD was in use.

It's our consensus to bring it back and that the change was (a) not positive; I'd say some of us even agree the change was (b) done in an underhanded way.

@frank-trampe

This comment has been minimized.

Copy link
Contributor

@frank-trampe frank-trampe commented Dec 23, 2019

I was similarly not happy about it at the time.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 23, 2019

Certain people pretty much took advantage of the fact that the project's governance was in limbo to impose their own vision on the project which was never George's, and which no rational observer would have believed to have been George's.

@frank-trampe

This comment has been minimized.

Copy link
Contributor

@frank-trampe frank-trampe commented Dec 23, 2019

@skef, regarding sfundo files, are you sure a lot of that wasn't just moved out of other existing files?

@twardoch

This comment has been minimized.

Copy link

@twardoch twardoch commented Dec 23, 2019

Contributing to code without reading the license terms is like signing a contract without reading it. It's still binding, because the assumption is that you're a sane individual who is resposible for your own actions.

I think that in software development, there is a common understanding that the legal structure follows the physical organization of the code. So if something is in a file, and that file has a particular license, then the contributed changes also fall under this license. If there is a folder A and subfolders and there is no explicit licensing info in the sub-folders or files with, but there is a license attached to that folder A, that license applies to the files and subfolders inside that folder A.

It's a simple cascading logic, similar to how CSS works. And licenses are really just a system of granting and removing rights, or of permissions and limitations — that ultimately could be “compiled” in the software sense.

I never thought of law as much different as programming code. It's code that is interpreted and executed by human brains, but could also be made to be interpreted and executed by machines.

In my view, the license of a piece of a software program is very much an integral part of the program. If there are two pieces of software that cannot be made interoperable due to legal restrictions, it's exactly the same as if those two pieces of software were worth in two different programming languages that aren't compatible. In a way, it's very similar, both are “technical” problems.

Personally, I’d very much applaud the effort of consolidating the FontForge license back into the form that expresses the spirit and intentions of the program’s original creator, George Williams. This current mixed setup feels to me like when some software is written in C++ but suddenly gets contributions in Python and JS that make a complex beast with tons of dependencies out of something originally pure.

I think that creators of original work have full rights to set the permissions and limitations any way they feel. But I've always felt that when you're adapting, extending and maintaining, it's most ethically correct to follow the original author’s intentions — unless there are some very good reasons why additional limitations or additional permissions are added.

I have not followed the FontForge project close enough to know what the rationale behind introducing additional limitations via GPL3 was, and what benefit it gave to the software itself. Perhaps there was some benefit I hadn’t seen.

But because I like simplicity and predictability, I’d welcome it if FontForge were licensed in a simple and predictable way, i.e. the same license, compatible with the original author’s intent.

Optional components that, ideally, exist in separate repos, and which can be omitted when building FontForge, could of course be licensed any other way.

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 23, 2019

@ctrlcctrlv some vendor who wants to include parts of FontForge in a product based on its BSD licensing is not going to want to hang their legal hat on our views about GW's intent.

@frank-trampe They don't seem to have been "moved" in the sense that git blame -C reveals a prior location. So they're likely rewritten enough to reset the copyright and therefore the licensing.

@frank-trampe

This comment has been minimized.

Copy link
Contributor

@frank-trampe frank-trampe commented Dec 23, 2019

Agh, okay. I'll look at those a bit more tomorrow.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 23, 2019

I think we should send this letter to fontforge-devel:

Greetings:

We write to remind contributors that the main license of the FontForge project has always been a BSD-compatible license. Most contributions are under this license.

In 2012, when George left the project, certain individuals who stepped in to fill the power vacuum imposed a GPL dual-licensing scheme. This is because the BSD is GPL-compatible, but GPL code is not BSD-compatible. Even now, in 2019, however, only a very small minority of commits are licensed only under the GPL license.

We announce:

  • It is our goal that the code be once again consist of 100% BSD-licensed code.
  • No pull request accepted after the date of this announcement may be GPL-only.

Certain individuals may get an e-mail from us asking them to kindly re-license their contributions under the original BSD license. Failure to do so may result in your changes being removed.

This announcement summarizes the consensus view of the majority of FontForge's active maintainers.

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 23, 2019

I suppose the summary point, though, is that this looks very tractable already if a certain small set of people play ball.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 23, 2019

From my view of things, the most important vote right now is @JoesCat's. If he agrees we could be 100% BSD again by the New Year.

@davelab6

This comment has been minimized.

Copy link
Member

@davelab6 davelab6 commented Dec 25, 2019

Going back to the 2012 code and choosing another name is defeatist. We're clearly in the majority, we have no reason to do that.

You would need unanimity not majority to avoid going back to 2012 and replaying with a filter for GPL parts.

@ilyaza

This comment has been minimized.

Copy link

@ilyaza ilyaza commented Dec 25, 2019

IANAL, but one may also consider a different approach:

  • isolate the poisoning contributions into a separate branch on GIT.
  • Have another branch which is purely BSD.

To get a working code, one merges two branches. And one can freely borrow code from the BSD-only branch.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 25, 2019

You're not in charge of The Project anymore Dave, so please don't try to dictate what will happen. I'm not doing that by simply keeping track of who is on what side.

For sure some people's work will need to be removed if their contributions were to GPL-only files unless they vote Yay on Question №2.

If The Project decides that licensing is per-file, everyone is free to have their opinion, and if you all think The Project is wrong, that's fine.

@ilyaza

This comment has been minimized.

Copy link

@ilyaza ilyaza commented Dec 25, 2019

What I propose above is yet finer licensing than “per-file”.

@ilyaza

This comment has been minimized.

Copy link

@ilyaza ilyaza commented Dec 25, 2019

You're not in charge of The Project anymore Dave, so please don't try to dictate what will happen. I'm not doing that by simply keeping track of who is on what side.

For sure some people's work will need to be removed if their contributions were to GPL-only files unless they vote Yay on Question №2.

If The Project decides that licensing is per-file, everyone is free to have their opinion, and if you all think The Project is wrong, that's fine.

What is your agenda? If you want people to borrow from “your” code, your license should be solid enough to satisfy them, not you.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 25, 2019

My agenda (or what I'd like to see happen) is that the GPL-only contributions are identified, cordoned off, replaced where necessary, and a BSD-like license is returned to.

If The Project determines some patches to be BSD that you think are actually GPL (because you vote Nay on Question №1), feel free to pursue your GPL rights you think you're owed in court. That's really all there is to it.

@ilyaza

This comment has been minimized.

Copy link

@ilyaza ilyaza commented Dec 25, 2019

My agenda (or what I'd like to see happen) is that the GPL-only contributions are identified, cordoned off, replaced where necessary, and a BSD-like license is returned to.

This is not agenda. What are doing this for?

(And, AFAIK, I never contributed any code, so my involvement is purely educational.)

@ilyaza

This comment has been minimized.

Copy link

@ilyaza ilyaza commented Dec 25, 2019

OK, we'll pretend then

Instead of doing “pretend-voting”, why not just collect statements from the contributors that they agree with BSD-license on their contributions? (The voting would not free you from such collecting anyway…)

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 25, 2019

I believe George Williams' intent was for his project to be BSD or similarly licensed and I think that continuing with a GPL default for new contributions is not respecting that.

There's nothing pretend about the voting. The voting is really happening. It's just you think, we're wrong on the merits. You think the "GPL cordon" should be wider than The Project has decided it will be. You're entitled to that opinion, but ultimately it won't change how anything proceeds beyond acting as a kind of amicus curiae brief from a non-contributor.

@davelab6

This comment has been minimized.

Copy link
Member

@davelab6 davelab6 commented Dec 25, 2019

So they're likely rewritten enough to reset the copyright and therefore the licensing.

This is not valid. On key point of copyright is that it applies to derivative works, and code licensed under GPL can only be derived under the GPL. So assuming that the per-file licensing is valid - which like Khaled I dispute - then rewriting code that has parts that are GPL means the complete work remains GPL.

@davelab6 There's a lot of cross discussion in this issue, but here you're quoting me and responding and I want to clarify my point and its relation to your response.

I appreciate the clarified context! Thank you

The overall argument is about the licensing of various files.

I think what set me off was the idea that copyright can be 'reset' through derivative work. Adam's proposal that replacing GPL licensed work with BSD licensed work, word by word, seems ahem "novel" to me because it seems like derivation rather than combination.

I'm responding in your quote to @frank-trampe, who was asking about the status of certain files with GPL licenses at the top. He's asking whether some of the original sources were directly copied from BSD-licensed files. I'm saying that it appears not, so therefore the entire contents of those specific files are, regardless of other factors, GPL licensed from the per-file perspective.

Got it. If the per-file thing is valid, I agree.

However, if Khaled or others say they didn't read the per-file thing and the work they hold copyrights to is only licensed under GPL, I think we have to accept that is the case. I don't think there's a legal basis for "gotcha" clauses a-priori, I think the gplv3 section 5c about "the whole work" and section 7 about removing additional permissions are the basis for Khaled's position, and I think Adam's exhortation for ethics is worthwhile - because Khaled is asserting his contributions are only available under GPLv3, if people want to contribute replacement work so that there's no Trace left of Khaled or others work left, I think that is fine.

But playing gotcha would not be.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 25, 2019

I don't think there's a legal basis for "gotcha" clauses a-priori

I do

@davelab6

This comment has been minimized.

Copy link
Member

@davelab6 davelab6 commented Dec 25, 2019

You're not in charge of The Project anymore Dave

Right. But no one is. This is an unincorporated project with multiple rightsholders, not just of code copyright. No single person is in charge of the project, except by mutual consent.

Like Adam, I've been around the block and was pulled into this thread, so I figured you might want to hear what I have to say.

so please don't try to dictate what will happen.

Likewise.

I'm not doing that by simply keeping track of who is on what side.

But you are seeking to dictate what will happen.

For sure some people's work will need to be removed if their contributions were to GPL-only files unless they vote Yay on Question №2.

If The Project decides that licensing is per-file, everyone is free to have their opinion, and if you all think The Project is wrong, that's fine.

There is no entity called "The Project." There are only Individual Contributors.

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 25, 2019

But no one is.

Is that really true? I think now we're getting into issues of governance, which I welcome. I've always thought this project has confusing governance.

My understanding, having been a contributor now for a few years, is that @frank-trampe has the final vote, and is the "Maintainer", and can decide (and then enact) the will of "The Project".

Are you saying I'm wrong?

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 25, 2019

@ilyaza

You say that from a legal perspective there is no implicit licensing. Can I assume, then, that I could right now declare all of my contributions so far incompatible with a GNU license, and the project would have to back them out?

@davelab6

This comment has been minimized.

Copy link
Member

@davelab6 davelab6 commented Dec 25, 2019

But no one is.

Is that really true? I think now we're getting into issues of governance, which I welcome.

I don't see how this issue can be anything but about governance 🤓

I've always thought this project has confusing governance.

My understanding, having been a contributor now for a few years, is that @frank-trampe has the final vote, and is the "Maintainer", and can decide (and then enact) the will of "The Project".

Are you saying I'm wrong?

Completely :) Frank is only able to decide things between people because those people consent to him playing that role. "The Project" and "The Maintainer" are as valid as Monopoly™ Dollars; they work only because the people using them mutually agree they work.

@davelab6

This comment has been minimized.

Copy link
Member

@davelab6 davelab6 commented Dec 25, 2019

@ilyaza

You say that from a legal perspective there is no implicit licensing. Can I assume, then, that I could right now declare all of my contributions so far incompatible with a GNU license, and the project would have to back them out?

Libre licenses can't be revoked, although some jurisdictions have an implicit or underlying time out on licensing unless the license explicitly says it lasts forever - @twardoch dealt with this in Poland with the OFL in the Lato project.

Khaled's contributions aren't being revoked, he's saying he only ever distributed them under the GPL per it's 5c and 7 sections.

It's a fine distinction between that and saying "oh actually everything I contributed was actually under cddl, gotcha"

@ctrlcctrlv

This comment has been minimized.

Copy link
Member

@ctrlcctrlv ctrlcctrlv commented Dec 25, 2019

Let's say Frank decides that the "gotcha clause" as you're calling it is legally valid, and the GPL cordon is drawn according to that interpretation.

Does Frank have the power to do that? If not, what's stopping him from exercising that power?

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 25, 2019

@davelab6 If there is no implicit licensing then my code isn't libre-licensed now and there's nothing to revoke. It can't work both ways.

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 25, 2019

@davelab6 So my code is GPL, without me saying anything, based on the existence of license files in the project, but what those files say specifically is irrelevant when it comes to @khaledhosny's code whether or not he said anything in the past about how it was to be licensed? How do the license file contents apply to me in this way but not to him?

@ilyaza

This comment has been minimized.

Copy link

@ilyaza ilyaza commented Dec 25, 2019

@ilyaza

You say that from a legal perspective there is no implicit licensing. Can I assume, then, that I could right now declare all of my contributions so far incompatible with a GNU license, and the project would have to back them out?

Exactly. (Unless you explicitly licensed your contribution before.)

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 25, 2019

@ilyaza OK, good. That view has the notable virtue of being consistent.

You sort of implied this at the start of your first comment, but from this perspective almost all open source software is on very shaky legal ground theoretically. Practically speaking -- and this sort of law tends to be pretty practical when it comes down to it -- it means that open source ultimately relies on copyright holders not raising legal objections.

I personally suspect that that isn't how things work now, even if it may have been 25 years ago. There may now be what amounts to common law based on how many projects rely on these licenses and the conventions around them.

@ilyaza

This comment has been minimized.

Copy link

@ilyaza ilyaza commented Dec 25, 2019

Libre licenses can't be revoked

This is a self-fulfilled prophesy: this depends-on/defines what the word “libre” means…

Again, a point of view of 25 years ago: if I maintain my copyright, I can revoke my license at any time. (This is why FSF was (is?) mandating the transfer of copyright to them.)

Anyway, the common sense says that unless a licence is written in such a way that it cannot be revoked (and the point of view above says that this is not possible), it can be revoked. Do you way that all licenses with “Libre” in their names are written like this?

@jtanx

This comment has been minimized.

Copy link
Contributor

@jtanx jtanx commented Dec 25, 2019

I found this quite interesting:

https://www.lexology.com/library/detail.aspx?g=489c0dfb-2376-4d20-a449-ca81cd2c721e

Even without a CLA, open source projects can leverage the policies of popular online code repositories like GitHub. GitHub projects can benefit from the default “inbound=outbound” contribution policy in GitHub’s Terms of Service. According to this policy, whenever a contributor makes a contribution to any GitHub repository containing notice of a license, the contributor agrees to license the contribution under the same terms

https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license

Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and you agree that you have the right to license your contribution under those terms. If you have a separate agreement to license your contributions under different terms, such as a contributor license agreement, that agreement will supersede.

Isn't this just how it works already? Yep. This is widely accepted as the norm in the open-source community; it's commonly referred to by the shorthand "inbound=outbound". We're just making it explicit.

@ilyaza

This comment has been minimized.

Copy link

@ilyaza ilyaza commented Dec 25, 2019

There's nothing pretend about the voting. The voting is really happening.

“It really happening” has nothing to do with whether it is “pretend-voting”. We can vote between participants of this issue whether to impeach Stalin. It could really go through and it would still be pretend-voting.

@skef

This comment has been minimized.

Copy link
Contributor Author

@skef skef commented Dec 25, 2019

@frank-trampe

This comment has been minimized.

Copy link
Contributor

@frank-trampe frank-trampe commented Dec 25, 2019

Voting to impeach Stalin might provide a nice point of unity for us. But more likely a crushing illustration of our disunity, so I won't propose it.

On the question of whether to pursue BSD licensing to the extent we can legally do so, I think that we have unanimity among people who consider themselves active contributors to the project (not counting @khaledhosny since he keeps removing himself from project membership and not counting @JoesCat since he seemingly has declined to give an opinion on this). Also George.

I share @skef's feeling that @ilyaza's signed-contract-only rule is sufficiently impractical that common law would be necessarily more accommodating.

The situation in which we find ourselves ought not to be terribly unusual. There are surely thousands of other projects that include files under different licenses, bundled together under the least permissive compatible license (or not bundled due to license incompatibilities like djvulibre and djvudigital), and I have not yet seen a successful legal claim that their per-file licenses are somehow invalid by inclusion of the top-level license. I'm not even convinced that our disclaimer that the per-file license applies is necessary. Unless the top-level license declares the per-file license inoperative or invalid, I see no reason that the per-file license would be invalid.

@jtanx

This comment has been minimized.

Copy link
Contributor

@jtanx jtanx commented Dec 25, 2019

My take is that the wording in LICENSE (which has remained the same since switching to GPLv3 overall), the per-file license, and the Github TOS make it pretty clear cut that contributions made to each file take on the license of that file, which in the majority of cases, is the (modified?) BSD license.

@twardoch

This comment has been minimized.

Copy link

@twardoch twardoch commented Dec 27, 2019

A couple of points:

In most legal systems, the concept of what is a legally binding action is stacked. Explicit consent to publishing your work under specific license terms is “best”, but the majority of collaborative opensource software development has functioned without CLAs. In addition to confirming the intent to publish the work under a specific license, the CLAs often address the notion of surrendering the right to be incliuded in the list of copyright owners. But without a CLA, for pretty much all software there is, the fact that an individual submits a patch signals the intent that the individual agrees that the patch is incorporated into the code under the terms the code is published under.

The question here seems to be: what are the terms that the current code is published under. There seems to be some disagreement about it.

There is explicit verbiage in the LICENSE file that acknowledges a de facto dual licensing is the code as it stands today, but made in such a way that 100% of the code is published under GPL and at the same time some 98% (or whatever) of the code is also published under BSD (while a small amount is only GPL).

If, 7 years into that, someone now comes and says “oh, well, the legal situation described in the LICENSE file isn’t true because I didn't read that file” — to me that is a disregard to all those users who have, in those past 7 years, read the LICENSE and have trusted that what it describes is true. I don't know how many people have downloaded and installed FontForge in the last 7 years, but I think a whole lot of them would now be unpleasantly surprised if it turned out that they got “misled”.

If there is a file that starts with information about the terms you may use that file (the license), and you download that file, change it and published the changed file without any extra comment about the terms (and that is what happens, effectively, when you publish a patch), the simplest assumption that the vast majority of the audience who are trying to interpret your actions in good faith would make is that you have published your changed version of the file under the terms that are stated at the beginning of the file. Because you've had ample chances to do something else if that wasn't your intention.

If person A puts out a garden gnome in front of their house, with the sign that says “please take this away free of charge”, person B comes, takes the gnome, adds a red dot on the gnome’s nose and puts it in front of their own house but keeps the sign attached, then person C comes along and takes the gnome away — and suddenly person B says “no no, I kept the sign but I didn't really understand the implications of keeping it”... Well...

I’m oversimplifying — but licensing isn't that different. It's simple: if we succumb to the thinking that what's stated in the header of a file isn't necessary the real licensing terms for that file, and that what's stated in the LICENSE file in a top folder isn't necessarily the real licensing terms for the files that don't have the licensing terms explicitly stated in their header — then basically we’re throwing away 30 years of opensource development practice.

I think that would give wonderful cannon fodder for all who say that proprietary licensing from a designated vendor is better than “unclear” and “potentially unstable“ opensource licensing.

This thread already gives me wonderful talking points about why someone might say it’s “dangerous” to use opensource software — because you use/fork/modify/use parts of it in good faith, and then 5 years later it turns out that you’ve read the “wrong text“ and in fact the terms were different than the terms you saw and read.

@twardoch

This comment has been minimized.

Copy link

@twardoch twardoch commented Dec 27, 2019

BTW, I don't think using opensource software is dangerous, because I trust that people publish software responsibly. Sure, there are cases where some person takes someone elses proprietary or otherwise licensed code, removes the copyright entry and the original licensing terms, and sticks in something of their own — so as a user, I should not have limitless faith that “what I read on Github is true”.

But that's why I've been told and taught, also by people like Dave, that one of the benefits of opensource is the “public review and vetting”. Especially if it's done in collaborative environments like Github.

This whole opensource thing was supposed to lift the burden from me, the user, of reviewing and vetting the single vendor and trusting that vendor’s credibility — that the software I’m downloading is reasonably free from malicious code, and also free from legally dubious stuff that I, as a user, could suddenly be held accountable for.

Sure, the concept of most permissive licenses is that, as a user, I don't get a warranty or an indemnification. But the collective wisdom of collaborative opensource was supposed to provide a reasonable alternative to legal warranties and indemnifications, to replace it with trust.

I’m sorry to see my faith in that system dwindle. It hasn’t vanished, because I still believe that the collective wisdom will prevail :) And to my best ability and knowledge, I believe in “my interpretation” of the current legal situation, which is: trust the code. If we’re talking about the freedom of the code, if we’re, in a sense, subjectifying the code — I think that we shouldn’t do that selectively.

I attribute the same substance to the license terms in the headers of the files, and to the LICENSE file in the top folder, as I do to the function that removes a glyph. All these things “tell their own story”, to both human and machine. The work speaks by itself. The comments, opinions, statements of intent etc. — they're commentary, annotations. They’re an important addendum, but they're not part of the software.

@twardoch

This comment has been minimized.

Copy link

@twardoch twardoch commented Dec 27, 2019

What's part of the extended software is of course the culture behind its development. With hundreds of thousands of opensource projects, and 30+ years of software publishing, there are certain practices, procedures and common expectations. And in my opinion at the very core of those there is Ockham’s razor: prefer the explicit over the implicit, prefer the written over the unwritten, and then always go ones level up if you need clarification — look for precedents, analogous situations, more general legal or technical documents and practices.

I’m not in any position to give advice. I’ve spoken here because I have an interest in licensing, and clarity regarding licensing and legal status of fonts and font-related software has been something I’ve been following with interest.

I only have very very basic formal training in the subject (classes in German civil and public law and in copyright, 20-25 years ago at university), plus a lot of reading afterwards, a few conversations with lawyers on both sides of the Atlantic, and writing a few font EULAs. :)

So — whatever comes out of this very debate, I’ll be most interested. It does affect my own “business life” (if you can call it that) marginally: there is a slim chance that I might want to have an option to re-use some of the BSD-licensed code in another project, but this is all in the “optional potential” realm.

I’m more interested in seeing how a debate about licensing of a major piece of software that's relevant to my line of work is going to play out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.